my @LUHN10_map = ( 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 );
sub johannz_LUHN10
{
    my @number = split('', shift);
    my ($sum, $pos) = (0, scalar(@number));
    $sum += $pos--%2 ? $_ : $LUHN10_map[$_]
        for (@number);
    ($sum % 10 == 0) ? 1 : 0;
}
[download]

Your algorythm is very fast. Congratulations! I tried to come up with something close in speed to what you have, but I could not. Instead I will submit my attempt in the hopes that it might spawn off an idea for someone else:

sub dkubb_LUHN10 {
  my $number = shift;
  my $sum;
  ($sum += chop $number) ... ($sum += $LUHN10_map[chop $number]) 
    while $number ne '';
  ($sum % 10 == 0) || 0;
}
[download]

Update: The last line was: $sum % 10 || 0;

This algorith fails on '49927398716' in my test case. That was the code given on the LUHN-10 website. It comes up with a sum of 62 when it should be a sum of 70 per the original algorithm.

I am curious if you can explain how the

($sum += chop $number) ... ($sum += $LUHN10_map[chop $number]) while $
+number ne '';
[download]

logic works. I just (like 1 minute ago) learned about the bi-stable operator.

---

While typing this, I figured out why this failed my test case. The call to '...' is persistant across subroutine calls. In my test case, I use

('125', '49927398716', '4992739872')
[download]

and it failed on '49927398716'. When I used

('125', '49927398716', '49927398716','4992739872')
[download]

it failed on the 1st '49927398716' and on '4992739872' so I can only assume this operator maintains its state.

UPDATE: This also fails on '620' since the bi-stable does not flip state if the side that is being evaluated returns false(or 0). So a number ending in '0' will not be processed correctly.

johannz you are right! I had no idea the range operator (...) was persistent across subroutine calls. I expected it to maintain it's state while inside the while loop, but reset itself each time the subroutine was called.

perlop gives an explanation of the ... operator. It's definately something I have not used much before, or seen used, so I wanted to give it a try.

While I was trying to figure out why my example didn't work in all cases, I came up with the following that returned the correct values during testing:

sub dkubb_LUHN10 {
  my $number = shift || return 0;
 
  my $sum;
  $sum += chop($number) + $LUHN10_map[chop $number] 
    while "$number";
 
  ($sum % 10 == 0) || 0;
}
[download]

my @luhnmap_1 = (0,2,4,6,8,1,3,5,7,9);
my @luhnmap_2 = ();
for my $x (0..9) {
  for my $y (0..9) {
    @luhnmap_2[$y*10+$x]=$luhnmap_1[$y]+$x;
  }
}

sub LUHN10 {
  my $num = shift;
  my $sum = 0;
  while ($str = substr $num, -2, 2, "") {
    $sum+=$bigmap[$str];
  }
  return $sum % 10 ? 0 : 1;
}
[download]

As bonus, if you don't count the additional table code (aw, come on, please :) ), it's shorter! You can increase this speed some more if you want, but the only way to get a huge increase is to create a bigger table (instead of 10 or 100 elements, try 10,000!). Not sure if it's worth going the next step (the memory and upfront cost).

Enjoy,
Gryn

  return not chop $sum
[download]

  return $sum % 10...
[download]