Re^12: Faster Luhn Check Digit Calculation?

> Just replicating the original module, including a fairly straight port to C

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.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

Comment on Re^12: Faster Luhn Check Digit Calculation?

Replies are listed 'Best First'.
Re^13: Faster Luhn Check Digit Calculation? by kschwab (Vicar) on Dec 03, 2018 at 01:11 UTC
"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.	[reply]
Re^14: Faster Luhn Check Digit Calculation? by LanX (Saint) on Dec 03, 2018 at 02:59 UTC
> 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}	[reply]