Is there a bug in the Rosetta code for Luhn numbers for 19 digit numbers?

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Is there a bug in the Rosetta code for Luhn numbers for 19 digit numbers?

Wikipedia says about Payment_card_number:
The leading six or eight digits of the card number comprise the issuer identification number (IIN) sometimes referred to as the "bank identification number (BIN)". The remaining numbers on the card, except the last digit, are the individual account identification number. The last digit is the Luhn check digit. IINs and PANs have a certain level of internal structure and share a common numbering scheme set by ISO/IEC 7812. Payment card numbers are
composed of 8 to 19 digits,[1] as follows:

Wikipedia also gives the Luhn algorithm:
From the rightmost digit (excluding the check digit) and moving left, double the value of every second digit. The check digit is neither doubled nor included in this calculation; the first digit doubled is the digit located immediately left of the check digit. If the result of this doubling operation is greater than 9 (e.g., 8 × 2 = 16), then add the digits of the result (e.g., 16: 1 + 6 = 7, 18: 1 + 8 = 9) or, alternatively, the same final result can be found by subtracting 9 from that result (e.g., 16: 16 − 9 = 7, 18: 18 − 9 = 9).
Take the sum of all the digits.
If the total modulo 10 is equal to 0 (if the total ends in zero) then the number is valid according to the Luhn formula; otherwise it is not valid.
The Rosetta code "Luhn test of credit card numbers" validation:

The Luhn test is used by some credit card companies to distinguish valid credit card numbers from what could be a random selection of digits.

Those companies using credit card numbers that can be validated by the Luhn test have numbers that pass the following test:

  1. Reverse the order of the digits in the number.
  2. Take the first, third, ... and every other odd digit in the reversed digits and sum them to form the partial sum s1
  3. Taking the second, fourth ... and every other even digit in the reversed digits:
  1. Multiply each digit by two and sum the digits if the answer is greater than nine to form partial sums for the even digits
  2. Sum the partial sums of the even digits to form s2
  1. If s1 + s2 ends in zero then the original number is in the form of a valid credit card number as verified by the Luhn test.
The Luhn algorithm doubles every second digit read from the right. Take '372' which is valid according to Wikipedia. It is invalid according to Rosetta where s1 is 3+2=5. s2 is 4. The sum is 9 which does not end in 0.
It seems to me that the Rosetta code only works for even-numbered codes. This seems unbelievable. What have I missed?



The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A
N-0378 Oslo    
Norway                     Tel: (+47) 468 58 625