In the case of .5, the algorithm uses "banker's rounding": .5 values are always rounded towards the even number.
The round functions means so many things that you should write your own and use it in the future so you know what it does.
That's what I have done for the last 40 years either in code and also in EXCEL.
I ever worked at a software house briefly, they wrote their own rounding function too.Most do: it also depends on the FPU rounding mode (to complicate things further) So even the docs are not always correct, but the default is sufficiently documented.
Do you think Free Pascal would be willing to add a switch to correct the round function, e.g., ppc386 -Borland?No need: you can switch the rounding mode of the FPU both in Delphi and freepascal.
You can switch the rounding mode of the FPU both in Delphi and freepascal.This will not make the expected results. Rounding is too complex to be mapped to the four RoundModes. One problem is in negative numbers. In my math feeling (which may be wrong...) I would expect negative values to round like the positive ones, i.e. Round(-0.5) = -1, Round(-1.5) = -2, etc. I won't get this result whichever value is applied to RoundMode (even for the positive values the result is not as expected). Therefore, the only way to guarantee the result required is to write your own rounding function.
RoundMode rmNearest
-2
0
0
2
RoundMode rmUp
-2
0
0
2
RoundMode rmDown
-2
0
0
2
RoundMode rmTruncate
-2
0
0
2
MyRound
-2
-1
1
2
So what does this mean? Will Free Pascal correct round to its original definition? Add a switch that allows the original definition to be used? Or just ignore the problem? Not doing anything means that original Turbo Pascal code may not work correctly due to round being implemented incorrectly.Unlike Turbo Pascal FPC implements floating point types using the FPU and rounding is implemented on most platforms using the FPU thus the rounding is depending on the specific rounding functionality of the FPU. Thus this won't be fixed and is by design (though we should probably document that this is a known incompatibility).
There is already a switch {$mode TP}, but it also does Banker's rounding (unlike TP7.0). I think this is a bug here clearly. You should file a bug report.Rounding is not influenced by the modes.
If you think Free Pascal's round function is incorrect, you can submit a report to the bugtracker forum:[…]No need, bug reports have been filed and resolved. [PS: not “bugtracker forum”, just “bugtracker”]
[…] Rounding is not influenced by the modes.Huh? Well, then issue #35626 (https://bugs.freepascal.org/view.php?id=35626) has to be closed right away.
[…] Rounding is not influenced by the modes.Huh? Well, then issue #35626 (https://bugs.freepascal.org/view.php?id=35626) has to be closed right away.
My answer explained the current state of affairs which is that the modes don't influence the rounding. Considering that Florian answered in the bug report I'll refrain myself from further comments regarding this.[…] Rounding is not influenced by the modes.Huh? Well, then issue #35626 (https://bugs.freepascal.org/view.php?id=35626) has to be closed right away.
If you have any facts or useful info for the bug, you should consider to post it in the bugtracker. The developers, sometimes are too busy, they do not check this forum frequently.
:-X I checked the web, it said Steven S. Pietrobon was an engineer who ever be a NASA Research Assistant. Are you the one it mentioned?
If you use the {$N-} switch, that should give the same answer regardless of which machine you use, since you have turned off the math coprocessor with all real calculations performed in software.Here is output with {$N-} switch. OS - Windows Vista 32bit, CPU - Intel Pentium Dual E2200.
Here is output with {$N-} switch.
Alright, I see.My answer explained the current state of affairs which is that the modes don't influence the rounding. […][…] Rounding is not influenced by the modes.Huh? Well, then issue #35626 (https://bugs.freepascal.org/view.php?id=35626) has to be closed right away.
[…]It doesn’t say, it doesn’t exist, but it’s ignored, since it’s unsupported.
Not sure why it is not working. For some reason, ppc386 says that the $N switch does not exist! […]
qroot.pas(5,2) Warning: Unsupported switch "$N"
[…]
The N switch is simply not supported. File a report.No, don’t. It’s documented, that it’s recognized for compatibility only (https://www.freepascal.org/docs-html/prog/progsu106.html).
As previously written, anybody using CEIL, TRUNC, ROUND must understand what the intent of the used function is and know the kind of numbers that would be processed.
This is due to small differences in mathematical / arithmetic operations on double.
Not being aware of that fact may mean you can have horribly wrong results.
AND no, it is NOT a BUG.
Are you sure? The trunc function is working correctly, but the 64 bit CPU real calculation is giving less accurate results than the 32 bit CPU real calculation!!!Well, that's only on windows... as documented...
Though that could change depending on the outcome of bug report #35626 (https://bugs.freepascal.org/view.php?id=35626).The N switch is simply not supported. File a report.No, don’t. It’s documented, that it’s recognized for compatibility only (https://www.freepascal.org/docs-html/prog/progsu106.html).
Only the i386 and i8086 targets as well as the x86_64 ones with the exception of Win64 have a separate Extended (10-bit floating point) type. All other targets have Extended as an alias to Double, because their FPUs do not support 10-bit floating point numbers. As the compiler always calculates with the highest available precision there will be differences between the platforms.As previously written, anybody using CEIL, TRUNC, ROUND must understand what the intent of the used function is and know the kind of numbers that would be processed.
This is due to small differences in mathematical / arithmetic operations on double.
Not being aware of that fact may mean you can have horribly wrong results.
AND no, it is NOT a BUG.
Are you sure? The trunc function is working correctly, but the 64 bit CPU real calculation is giving less accurate results than the 32 bit CPU real calculation!!!
This means that if you want more precision than 8 bytes, you need to do your calculations in software!Well, not quite, but it - as it stands - requires some usually simple assembler routines and all the required instructions are supported up to even 512 bits ( if the processor supports it ).
Perhaps Free Pascal needs to add these software floating point options, so that extended is true extended (10 bytes), as well as adding triple and quadruple for 12 and 16 byte precision.It is indeed planned to at least support 10-Byte floating point in software, cause currently it's not trivially possible to cross compile the compiler from x86_64-win64 to i386-win32 (or any other platform without Extended support to i386).