QB64x64 math differences from QB64x32

[Ryster]

Hello
Maybe someone met with erroneous mathematical calculations in QB64x64. Namely, I have a program that in QBx64 displays the wrong result, while in QB64x32 the same identical program displays correctly.

Regards - Ryster

[FellippeHeitor]

You forgot to attach the program. Also to explain the issue.

[Ryster]

Code: QB64: [Select]

1. J = 4381911: A = 52
2. B# = 4 * (J + A + 1401) + 3
3. G = 5 * INT((B# MOD 1461) / 4) + 2
4. D = INT((G MOD 153) / 5) + 1
5. M = ((INT(G / 153) + 2) MOD 12) + 1
6. PRINT D; M

[FellippeHeitor]

I see the different values for D in the 32bit version and in the 64bit version. It probably boils down to how math with floating point numbers is done differently in the two architectures.

Math experts may come along and help shed some light to the issue. Especially given your complex math there, which probably also plays a part.

[FellippeHeitor]

I can safely add that you merging SINGLE and DOUBLE variable types is playing a part in the problem as well.

Please add DEFDBL A-Z to the top of that sample code you provided (or DIM all variables AS DOUBLE) and you will see that calculations will perform identically, regardless of it being 32bit or 64bit.

[Ryster]

Thank you.
But it doesn't seem to me that combining double precision numbers with a single number must result in an error. I have over a thousand such patterns in the code with various variable designations and it will take a lot of time to correct it all. I hope that one of the QB64x64 experts will improve this shortcoming. Below is the code that counts correctly.

J# = 4381911: A# = 52
B# = 4 * (J# + A# + 1401) + 3
G = 5 * INT((B# MOD 1461) / 4) + 2
D = INT((G MOD 153) / 5) + 1
M = ((INT(G / 153) + 2) MOD 12) + 1
PRINT D; M

[FellippeHeitor]

Again, this requires understanding of how computers handle floating point math, and you'd better adapt your code now that you've found the issue.

QB64 is just instructing the computer to calculate. And that does vary according to architecture.

Issue solved as far as I'm concerned.

[Ryster]

And for me it is not solved.
It cannot be that in a 32-bit 2 + 2 = 4, and in a 64-bit 2 + 2 = 5

[FellippeHeitor]

Uparty Ryster,

If you tell me that 2 + 2 results in something different according to architecture, then I'll eat my words.

Now please come back to this topic after reading and understanding the links below:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
https://stackoverflow.com/questions/31415712/floating-point-differences-between-64-bit-and-32-bit-with-round

[SMcNeill]

What's probably happening is that the 32-bit build is using the 80-bit FPU registers to do the calculation and the 64-bit build is using the SIMD operations using 64-bit values, causing a slight discrepancy. Note that both answers agree to 14 decimal places, which is about the best you can hope for with 64-bit floating point values.

There are several compiler flags which you can set to modify precision operations (I posted them in another post similar to this one; I’ll see if I can find you the link in a bit), which may help with your specific system architecture.  We don’t set any of those flags by default, as we need to keep things working for the plurality of systems possible, but you can try them out and see what might work best for your own specific needs.

Try these compiler options here: https://www.qb64.org/forum/index.php?topic=1798.msg113933#msg113933

[SMcNeill]

I’ll post a quote from stack exchange where someone had an answer to a similar issue:

GCC can also generate instructions that use the old x87 FPU, but when generating x86-64 code, the default is to use SSE2. On Mac OS X, the default is to use SSE2 even in 32-bit since all Intel Macs have SSE2. When it generates instruction for the 387, GCC does not set the precision of the FPU to the double format, so that computations are made in the 80-bit double-extended format, and then rounded to double when assigned.

As a consequence:

If you use only double computations, Visual Studio should generate a program that computes exactly at the precision of the type, because it is always double(**). And if on the GCC side you use -msse2 -mfpmath=sse, you can expect GCC to also generate code that computes at the precision of doubles, this time by using SSE2 instructions. The computations should match.
Or if you make both GCC and Visual Studio emit SSE2 instructions, again, the computations should match. I am not familiar with Visual Studio but the switch may be /arch:SSE2.
This does not solve the problem with math libraries, which is indeed an unsolved problem. If your computations involve trigonometric or other functions, you must use the same library as part of your project on both sides. I would recommend CRlibm. Less accurate libraries are fine too as long as it's the same library, and it respects the above constraints (using only double or compiled with SSE2 on both sides).

(*) There may be a way to instruct it to generate SSE2 instructions. If you find it, use it: it will solve your particular problem.

(**) modulo exceptions for infinities and subnormals.

As this guy indicates; the solution may be just as simple as setting a compiler specific flag on your system.  (Probably the -msse2 -mfpmath=sse option in the 64-bit version.)

[luke]

You are performing calculations that are solely in the domain of integers, since your divisions are always rounded (to negative infinity).

Thus your choice of floating-point variables to hold these results is a poor one.

Prefer an integer type, like so:

Code: [Select]

DEFLNG A-Z

J = 4381911
A = 52
B = 4 * (J + A + 1401) + 3
G = 5 * INT((B MOD 1461) / 4) + 2
D = INT((G MOD 153) / 5) + 1
M = ((INT(G / 153) + 2) MOD 12) + 1
PRINT D; M


[Ryster]

Can you correct the code - displays the error in the first line.

[FellippeHeitor]

Can you correct the code - displays the error in the first line.

The code does work perfectly, Uparty Ryster.

  [ You are not allowed to view this attachment ]

Your problem is something else at this point.

[Ryster]

To FellippeHeitor
I see you have a lot to say in this Forum. Therefore, I agree to delete my profile from qb64.org/forum.
Goodbye