pset 1 credit.c invalid cards are valid by cs50

It was said that you can verify if the credit card number is valid by using Luhn’s algorithm. If you done mathematical operations right, after them, you know if the card is valid if the last digit in the sum is a 0.

So I was checking for that of course, beside starting numbers and car number length. But check50 said my code is wrong. I would get this message:

~/workspace/pset1/ \$ check50 2016.credit credit.c
:) credit.c exists
:) credit.c compiles
:( identifies 378282246310005 as AMEX
\ expected output, but not "INVALID\n"
:( identifies 371449635398431 as AMEX
\ expected output, but not "INVALID\n"
:( identifies 5555555555554444 as MASTERCARD
\ expected output, but not "INVALID\n"
:( identifies 5105105105105100 as MASTERCARD
\ expected output, but not "INVALID\n"
:( identifies 4111111111111111 as VISA
\ expected output, but not "INVALID\n"
:( identifies 4012888888881881 as VISA
\ expected output, but not "INVALID\n"
:) identifies 1234567890 as INVALID
:) rejects a non-numeric input of "foo"
:) rejects a non-numeric input of ""

I was sure it is right, because I tested with this imaginary number 4000000001040, which is valid according to Luhn's algorithm and it works. Then I decided to remove check for Luhn’s algorithm, just that, I compiled it again and it worked fine. Everything was valid after check50.

So I wanted to see what is going on there. I took one number (371449635398431) form check50 output and done the math according to Luhn's algorithm. The result was 107, and by that it was invalid by Luhn's algorithm. Only if it end with 0 it is valid.

So, it's normal to get INVALID as output. But cs50 check50 says it should be valid AMEX card.

So, I am asking here. Am I wrong or what? Should I use Luhn's algorithm to check for validation?

371449635398431 is a valid AMEX card. From this post:

3 7 1 4 4 9 6 3 5 3 9 8 4 3 1

Okay, let’s multiply each of the underlined bold digits by 2

7*2 + 4*2 + 9*2 + 3*2 + 3*2 + 8*2 + 3*2

That gives us:

14 + 8 + 18 + 6 + 6 + 16 + 6

Now let’s add those products' digits (i.e., not the products themselves) together:

1 + 4 + 8 + 1 + 8 + 6 + 6 + 1 + 6 + 6 = 47

Now let’s add that sum (47) to the sum of the digits that weren’t multiplied by 2:

47 + 3 + 1 + 4 + 6 + 5 + 9 + 4 + 1 = 80

If the total’s last digit is 0 (or, put more formally, if the total modulo 10 is congruent to 0), the number is valid!

You definitely need to use Luhn's algorithm to check for validation.

• Thank's a lot. I was wrong. I was missing the second step 1 + 4 + 8 + 1 + 8 + 6 + 6 + 1 + 6 + 6 = 47. The math I was doing was: 7*2 + 4*2 + 9*2 + 3*2 + 3*2 + 8*2 + 3*2 = 74 and then 74 + 3 + 1 + 4 + 6 + 5 + 9 + 4 + 1 = 107 Jan 27 '17 at 9:31

Where you got 107, I did the maths without calculator, and got to 90. Keep in mind that the digits to double start with the second to last digit (so first digit could be regular or doubled), and that a doubled 8 results in 1+6=7.

 Well, it's 80, and the difference of 27 being a multiple of 9 indicates you are treating doubled larger numbers wrong.

2*0 => 0
2*1 => 2
2*2 => 4
2*3 => 6
2*4 => 8
2*5 => 1+0=1
2*6 => 1+2=3
2*7 => 1+4=5
2*8 => 1+6=7
2*9 => 1+8=9

which is a nice scheme, as it maps ten different input digits to ten different output digits.