Unless of course I am misbehaving...
Some months ago I was messing about with primorials, can't remember why, and things went pear-shaped. wrong results, in spite of trying _unsigned etc. (Unsigned would have suited me fine, maybe I was tinkering with encryption, in which case truncation on overflow would be perfect, and I had a vague idea that in a previous version I did actually get truncation, but I am unsure.)
Anyway, I scribbled a bit of code to test the stuff (in case I errr... was fouling up) and it seemed unfortunately not to be the case, because then I could have fixed it myself.
OK, so here follows the test source. Please run it for yourself, either to prove that I fouled up (I hope!) or to consider fixing up the QB arithmetic. (I am running on a W10 desktop with a plain Intel processor, plenty of memory etc, and all the QB I have run so far has behaved itself much better than I have.) Here goes:
OPTION BASE 0
Top = 14
DIM Primorial(Top), Prims(Top), P AS _UNSIGNED _INTEGER64
P = 2 ^ 62
PRINT "Start:"
PRINT USING "##########################"; P
PRINT USING "##########################"; P * 2
PRINT USING "##########################"; P + P
PRINT USING "##########################"; P * 4
PRINT USING "##########################"; P + P + P + P
DEFLNG I-N
DATA 0002,0003,0005,0007,0011,0013,0017,0019,0023,0029,0031,0037
DATA 0041,0043,0047,0053,0059,0061,0067,0071,0073,0079,0083,0089
DATA 0097,0101,0103,0107,0109,0113,0127,0131,0137,0139,0149,0151
DATA 0157,0163,0167,0173,0179,0181,0191,0193,0197,0199,0211,0223
FOR I = 1 TO Top
READ Prims(I)
NEXT
Primorial(0) = 1
FOR I = 1 TO Top
Primorial(I) = Primorial(I - 1) * Prims(I)
PRINT USING "##########################"; Prims(I), Primorial(I), Primorial(I) \ Primorial(I - 1)
NEXT
END
You will note that at the start of the code, the pure binary arithmetic has behaved well: values for 2^62 ok. 2^63 OK, allowing for overflow into the sign position, and 2^64 might as well give 0, given that the only 1-bit had gone to bit heaven. I reckon I could live with that one way or another, but have a look at the primorials.
The code is simple, if undocumented: multiply successive primes from a READ list, giving successive primorials. At the end of the line, divide the putative primorial by the previous primorial, which should give the current prime, but in several cases does not, because the current primorial is wrong.
Up to primorial 19 it is fine, but primorial 23 comes out 6 short, which error propagates to higher levels with elaborations.
Please assist, someone.
