Re^10: Faster Luhn Check Digit Calculation?

> Unfortunately, Algorithm::LUHN supports some odd inputs, like non-numeric strings

Careful, is this algorithm well defined for input >=10 !?!

From the docs:

> For example, Standard & Poor's maps A..Z to 10..35 so the LIST to add these valid characters would be (A, 10, B, 11, C, 12, ...)

provided B=11 is on an odd position, what's the formula now to reduce 2*11?

cross total is 4, but 22-9 =13

and if it's even does 11 stay 11 with cross total 2 or do you take it module 10 hence resulting in 1?

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

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

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

Replies are listed 'Best First'.
Re^11: Faster Luhn Check Digit Calculation? by kschwab (Vicar) on Dec 02, 2018 at 22:51 UTC
Just replicating the original module, including a fairly straight port to C that's passing the original module's tests... Maybe I'll make a separate module that "does the right thing", but isn't compatible with Algorithm::LUHN.	[reply]
Re^12: Faster Luhn Check Digit Calculation? by LanX (Saint) on Dec 03, 2018 at 00:22 UTC
> 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}	[reply]
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


Pathologically Eclectic Rubbish Lister
	PerlMonks