After thinking on the issues discussed above, I believe several of the points brought up by Jens are important for this project. This basic problem is a topic that was talked about a lot in the 50s through the 70s. During this period most mainframes were IBM which had a ridiculously low word size of 4 bytes. This limited the size & accuracy of all numbers. If I remember, it limited integers to 9 digits & floating point to an accuracy of 7 digits. After this point you got an integer overflow or truncation in floating point.
The serious problems occur when you divide by a prime number & the result generates a repeating decimal pattern. Floating point math on a computer must truncate the pattern & thus internally the result is inaccurate.
An example: (3.0/7.0)*(7.0/3.0) will not generate 1 in most computer languages. Instead it will generate a decimal number very close to 1. Converting the resultant to integer will not produce exact results with any type of “int” function since the value in general can be above 1 or below 1 & with higher level primes the distance from 1 can get larger. Rounding doesn’t help because it can’t tell the difference between 0.5 or 0.99999 or 1.00001 or 1.49999.
Another factor is the mixing of operations types in floating point math. For multiplication or division, a scientific notation representation of the numbers gives the greatest accuracy but you can not add two scientific numbers so for addition floating point arithmetic uses pseudo integer formalism. This implies resultant decimal accuracy of an addition/subtraction is equal to the lowest accuracy of the 2 numbers.
Thus we get things like: 20*(1.0/3.0) + (1.0/3.0) = 20*(0.333333)+(0.3333333)= 6.9999933
Note as you increase the size of the leading multiplier the inaccuracy increases.
The 2 above factors tend to produce floating point resultants that have small pseudo random numbers added to them. This is why exact compares in floating point tend not to work. The problem worsens as the number of potential primes increases and the size of the numbers increase. If we had been asked to do another common variant of the game that uses a deck of cards then we might have all noticed the problem sooner because it uses a number range of 1 to 13 which includes 2 extra & larger primes.
The solution …
I have come to the conclusion that Jens point about not using decimal math is an absolute requirement for the routine to work consistently. All calculations must be done in integer math & this means all divisions must be re-structured as Jens suggested above so that division is never done unless the final result will be an integer.
A note to Madruga …
If you used floating point math in your perl script you can not be sure you found all solutions correctly.
