Bug in test "too many digits" ?

[ieb]

Hi,
(I am probably going to prove how slow and stupid I am again.... so here goes :) )

String tooMany = nonMatchingSequence(MAX_LENGTH);
tooMany += computeLast(tooMany);
test("too many digits").sendAndExpect(tooMany);

the doc on computeLast(..) is
/** Computes the last digit necessary to pass the Luhn check. */
implying, given a non matching sequence, adding the result of compute last will make it matching.

If the filter is working correctly it should pick up the last X digits and pass the Luhn check, even though the whole number fails for being too long.

nonMatchingSequence(MAX_LENGTH); is 9929316122854070
computeLast(tooMany); is 2
hence
99293161228540702
01234567890123456

Some very simple, dumb, slow code https://gist.github.com/1374825 at produces
Loop From Index 16 to 3 (zero based inclusive) length 14
16 C = 2 x1 2 Acc = 2
15 C = 0 x2 0 0 Acc = 2
14 C = 7 x1 7 Acc = 9
13 C = 0 x2 0 0 Acc = 9
12 C = 4 x1 4 Acc = 13
11 C = 5 x2 1 0 Acc = 14
10 C = 8 x1 8 Acc = 22
9 C = 2 x2 0 4 Acc = 26
8 C = 2 x1 2 Acc = 28
7 C = 1 x2 0 2 Acc = 30
6 C = 6 x1 6 Acc = 36
5 C = 1 x2 0 2 Acc = 38
4 C = 3 x1 3 Acc = 41
3 C = 9 x2 1 8 Acc = 50
99293161228540702
992XXXXXXXXXXXXXX

I have almost certainly made a stupid mistake and (once again) misunderstood the algorithm but I have now checked this manually, with a program and in excel.

[ieb]

http://www.ee.unb.ca/cgi-bin/tervo/luhn.pl?N=93161228540702

?

[cgdecker]

The input to that test is actually "99929316122852072", which doesn't contain any matches.

[ieb]

It is a Luhn but its too long
http://www.ee.unb.ca/cgi-bin/tervo/luhn.pl?N=99929316122852072
99293161228540702 is also a Luhn but its also too long.
http://www.ee.unb.ca/cgi-bin/tervo/luhn.pl?N=99293161228540702
but it also contains a Luhn at
http://www.ee.unb.ca/cgi-bin/tervo/luhn.pl?N=93161228540702
which is short enough.

Depending on how many times you have invoked the random number generator you may get a 17 digit Luhn with a second Luhn embedded in it. Hence the test is dependent on previous state. Note the second Lunh will only ever appear as a result of adding the extra digit.

I am running the tests in a Junit test and running more tests before this one, hence the 17 digit Luhn with a second Luhn embedded. It probably doesn't matter for anyone using the script, and now I know why....

I am not worried about it.

If no one else is.... please just close the issue.
Sorry (once again) for the noise.