This doesn't mean you have to ignore a fast algorithm for the proper task.

Mapping B => b0=11 is most likely producing the same effect like mapping B to two digits b1,b2 < 10 with b1 for odd and b2 for even positions.

From there on you can still use the fast algorithm.

Otherwise I don't understand the point of the whole thread and am quizte happy I didn't try to waste time on coding an even faster solution.

"Otherwise I don't understand the point of the whole thread and am quizte happy I didn't try to waste time on coding an even faster solution."

That seems a bit harsh. Everything here is still usable from Inline::C when pure speed is wanted. Since I made a "clone" of an existing module, it seems having it work like that one, but still quite a bit faster, is worthwhile. Apparently, it's not just Standard & Poor's using letters and values > 10 for this kind of stuff. Looks like OpenMRI and The Regenstrief Institute do as well.

I can either make another module that's purely about speed, or see if your suggestion above pans out for this module.

> Apparently, it's not just Standard & Poor's using letters and values > 10 for this kind of stuff. 

A Luhn mod N algorithm is still OK, but base 10 with a bigger input set would be quite random.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}