Problem 156 (Luhn Algorithm) - Possible non-fixable CC numbers?
Back to General discussions forum
Hey,
I just finished coding my solution to problem #156 and have encountered in the test cases what I consider an 'unfixable' credit card number. Here's is the debug output via print() statements of my Python 3 code:
[*] Trying CC num 2273079656277291
[*] Checksum is currently 71
[*] For 2273079656277291, checksum is 71
[*] For 2723079656277291, checksum is 75
[*] For 2237079656277291, checksum is 76
[*] For 2270379656277291, checksum is 74
[*] For 2273709656277291, checksum is 69
[*] For 2273097656277291, checksum is 69
[*] For 2273076956277291, checksum is 68
[*] For 2273079566277291, checksum is 72
[*] For 2273079665277291, checksum is 72
[*] For 2273079652677291, checksum is 66
[*] For 2273079656727291, checksum is 67
[*] For 2273079656277291, checksum is 71
[*] For 2273079656272791, checksum is 75
[*] For 2273079656277921, checksum is 73
[*] For 2273079656277219, checksum is 72
Traceback (most recent call last):
File "./luhn_algorithm.py", line 58, in <module>
cc_number = swap_digits(list(cc_number))
File "./luhn_algorithm.py", line 42, in swap_digits
input_array[step], input_array[step+1] = input_array[step+1], input_array[step]
IndexError: list index out of range
Why the IndexError is there is clear: The code has tried all pairwise swaps and I don't have any guard against going over len(input_array)-1. But it only does this because no swap gave a checksum that's divisible by 10. Could someone double-check the CC number in question? Is it really unfixable or does my code not catch some odd case?
Wojciech, hello!
Can we check your checksum calculation? I.e. for
2273 0796 5627 7291
sum should be:
2 + 7 + 0 + 9 + 5 + 2 + 7 + 9 + (2 + 3 + 7 + 6 + 6 + 7 + 2 + 1) * 2 == 41 + 34 * 2
I can't get how we can get checksum of 71, though probably I'm missing something? :)
So here's how I get the 71:
You start from the back, and in every other space you take double the digit (and also subtracting 9 if the digit is 5 or greater)
chksum = 1 + (9*2 - 9) + 2 + (7*2 - 9) + 7 + 2*2 + 6 + (5*2 - 9) + 6 + (9*2 - 9) + 7 + 0*2 + 3 + (7*2 - 9) + 2 + 2*2
= 71
What is weird, I just requested a new set of testing data and never encountered another problematic number.
You can also see on the Luhn checker of www.dcode.fr (https://www.dcode.fr/luhn-algorithm) that none of the permutations are valid:
Ah, sorry, I definitely forget how it is working :)
Thanks for explanation!
Let me some time more than to recollect and investigate.
Facing same issue here, for some of the test cases where you need to swap digits, there is just not a proper combination:
Swapping-error recovery initiated for 8995527189624065
The value of the sum before the while is 136
The test string is 9895527189624065
The test string is 8959527189624065
The test string is 8995257189624065
The test string is 8995521789624065
The test string is 8995527198624065
The test string is 8995527189264065
The test string is 8995527189620465
The test string is 8995527189624056
And then checking all those numbers in https://www.dcode.fr/luhn-algorithm shows that none of them are % by 10:
Hi Friend!
there is just not a proper combination
There is. 8995572189624065 seems to be the answer. Note 7 and 2 swapped. Not sure why skipped testing it.
Oh I see! I was grouping them by pairs like this: ['89', '95', '52', '71', '89', '62', '40', '65']
But we should take into account also '99' and '55' and '27' and so on...
Thanks for your help Rodion!