IBM MOD 11 Algorithm

Post a clever/fast/short implementation of this algorithm

http://en.wikipedia.org/wiki/MSI_Barcode#Mod_11_Check_Digit (IBM version)

¡In any programming language you want!

Skill level: 1 of 10

INB4: Check my Anus

7-digit version in APL (unoptimized):
11|11-11|+/((1+7∣⍳6),2)×⊖(7/10)⊤1234567

def f(n):
    weight = [2, 3, 4, 5, 6, 7]
    X = 0
    for i, char in enumerate(n[::-1]):
        X += int(char) * weight[(i % len(weight))]
    return (11 - (X % 11)) % 11

print f("1234567")

>>2
doesn't werk

>>4
Replace the 1234567 with whatever the barcode number is.

perl6 -e 'my $n="1234567"; say 11 - ([+] $n.split("").reverse >>*>> (2..7)) % 11'

I remember seeing something like that here on /prog/. But it was not difficult to do. Is almost obvious once you understand the basic idea of Perl6 metaoperators.


    ; in: si pointing to reversed digit string
    ;     cx length of digit string
    ; out: al = check digit
    xor ax, ax
calcloop:
    lodsb
    xchg al, ah
aadpos equ $+1
    aad 2
    inc byte [aadpos]
    cmp byte [aadpos], 7
    jbe noreset
    mov byte [aadpos], 2
noreset:
    xchg al, ah
    loop calcloop
    mov al, ah
    aam 11
    neg al
    add al, 11
    aam 11
37 bytes. Anyone want to go for shorter?

ibmWeights = cycle [2,3,4,5,6,7]
check = (flip mod 11) . ((-) 11) . (flip mod 11) . sum . (zipWith (*) ibmWeights) . reverse

>>7
Pig disgusting SMC. Enjoy your instruction cache trashing.

>>7
It is beautiful. ignore >>9

>>8
4.7 megabytes plus libgmp.  Anyone wants to go for larger?

>>7
Sadly, this in is PIG DISGUSTING Intel syntax.

>>9
Who said I wanted fast?

Size optimisation is more important 99% of the time, in code that is run after the program is waiting for something from the user. Speed only in the 1% or so where it really matters. I loathe things like a memcpy() that takes 2KB to implement but is maybe only 50% faster than the simple one that's under a dozen bytes. 200x increase in size for 50% or even 100% increase in speed is NOT efficient. (And in the future, architectural enhancements will make the simple one faster, making the complex one a waste of bytes.)

>>12
GNUfag.

>>12
shit %$%$%ass $%##%$dick

>>13
in the future
Hahaha, no. The advancements come back from the past, when actual smart people made processors with sane ISAs like MIPS or SPARC.

>>15
Try implementing the algorithm in <=37 bytes using your toy ISAs.

Maybe branch delay slots are suited to postincrements, but who would think that was always a good idea?

Idiotic hardware designers who think it's too hard to build highly parallel CISC instruction decoders, that's who.

And don't get me started on their backwards-endianness and stupid forced alignment shit.

Simple to build, and can be pushed reasonably fast, but about as practical as a top fuel dragster.

The real "smart people" are the "Jews" at Intel who know more about hardware design than anyone else. Even AMD can't keep up.