September 14th, 2003
senji

2003/09/14 00:27:00  Things I really hate (1 and 2 of a continuing series)

1) People who put sticky labels over the barcode and ISBN on the backs of books. 2) Publishers who don't know how to divide ISBNs up into bits properly.
Current Mood: busy

bellinghman

2003/09/14 14:24:53

3) The whole ISBN encoding system anyway.
Modulo 11 check digit? Ah, hello?
At least ISBN bar codes rip the daft thing off and put a proper Modulo 10 one on instead. Either keep eveything in the digit domain, or use characters properly, but using just _one_ character (and that an X, not even proper hex) is just daft.
Oh, and don't mention the language encoding digit.
I'm sorry, you didn't expect an ISBN rant, did you?
L&K ... oops

senji

2003/09/14 16:46:55

X would of course be the traditional digit for 10 in base 12. (E being the digit for 11).

bellinghman

2003/09/15 01:52:34

Aaah.
I assumed it was 'X' from the IVXLCDM sequence. So what is 'E' from?

senji

2003/09/15 02:13:07

Eleven. (If I remember the article on base12 counting I read a few years back correctly, T wasn't chosen for 10 because it is too similar to 7)
I note, though, that the Dozenal Society of Great Britain are now recommending an upsidedown 2 for the 10digit and an upsidedown 3 for the 11digit.

ewx

2003/09/15 01:06:17

I hope I'm remembering my maths correctly:
With successive weights you want the modulus to be coprime to everything in [1,9] so you can detect all single transpositions of adjacent digits. Making it additionally coprime to the weights themselves will detect all single digit errors. (But combinations of either or both these types of errors might escape detection.)
If you have successivevalued positive weights (which I think is an obviously convenient thing to do) then 11 rather looks like the smallest integer satisfying these requirements.

bellinghman

2003/09/15 01:51:04

You can, however, use a weighted modulo 10 algorithm perfectly effectively. The EAN/UPC algorithm is very effective  it won't catch every single digit transposition, but it's designed to catch adjacent digit transpostiion ... transposition ... because that's by far the highest probability, and to catch any single digit being incorrect.
It's also simple enough to do in your head.
Because you've got a single check digit, it's always possible to find a different code that has the same check digit. That's life. You're supposed to be using the code as a database key anyway, and it's really, really unlikely that you'll get (a) a valid check digit even with a code error and (b) that the invalid code can also be found in your product database.
Look at a book bar code  you've got '978', then the ISBN (sans check digit  9 digits), then the Modulo 10 check digit. That code is (AFAIK) just as robust against mistakes, and doesn't require a special key apart from the normal numeric keypad.

ewx

2003/09/15 11:59:22

Good point about EAN (and I'd rather dimly not twigged that ISBN would detect arbitrary single transpositions).


