in reply to Re^9: Faster Luhn Check Digit Calculation?
in thread 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]
      > 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]
        "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]

In Section Seekers of Perl Wisdom