Subject: RE: CCL:CAS Registry Numbers algorithm

From: "Shobe, Dave" <[email-masked]>
Date: Thu, 24 May 2001 10:37:51 -0400

Come to think of it: the algorithm might catch transposition errors, but a
single-digit error such as 5555-31-7 vs. 5555-81-7 would not be detected, if
the digits differ by 5 in an even position, or if they differ by an even
number in the 5th position. 

The ISBN algorithm doesn't have this problem since 11 is prime.  However any
error the 11th digit would be completely undetectable.  You could fix this I
suppose by only using digit multipliers that are prime relative to the base.
Thus an improved(?) CAS RN algorithm would take 1234-31-? and calculate
1*1+3*3+4*7+3*9+2*11+1*13.  However, now the multiplers for adjacent digits
would differ by 2 or 4 instead of 1, and a transposition of the type
5555-38-7 vs. 5555-83-7 would not be detected since 3*8+3=27 and 3*3+8=17.

--David Shobe

-----Original Message-----
From: Jacobo Cruces Colado [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 9:36 AM
To: Shobe, Dave
Subject: Re: CCL:CAS Registry Numbers algorithm

 >The algorithm described will catch transposition errors, since in
xxabx-xx-x
 >the "ab" will contribute (k)b + (k+1)a and in xxbax-xx-x the "ba" will
 >contribute (k)a + (k+1)b. ("k" here representing the position of the 2nd
of
 >the transposed digits). For these to make equal contributions to the
 >checksum, (k)b + (k+1)a = (k)a + (k+1)b implies a = b.

However, the CAS RN people advices the algorithm to be defective. 
Apparently, about 17% of the CAS RN could be misschecked.

It should be possible to make a hypothetic algorithm for these numbers 
which avoids any problem of this kind?