Quote:
Originally Posted by phx
The double precision expression of (37.0 * 100.0) / 34.0 yields three different results, depending whether it is calculated by mathieeedoubbas.library, an 68k FPU or a PPC FPU. The rounding mode should always be "round to nearest", as required by ISO-C. |
Actually, ISO C requires the rounding mode to be adjustable, right?
Anyhow
Quote:
Originally Posted by phx
What is correct?  |
Let me clarify this a bit:
If the mathieeedoubbas.library is run on the FPU, and is opened correctly - that is, by the same task(!) that runs the calculations, it configures the FPU as of 3.1.4 and below in "round to zero", double precision. This is *not* a particularly good choice, but it is consistent with the choice the library makes if run on the CPU.
If the library is run on the CPU (no FPU available) and the version is that of 3.1.4 or below, it is implementing "round to zero", double precision. This is fast, but lazy.
Now, on 3.2, things changed (and this was a major task). Now, if the library is run on FPU, it implements "IEEE aware round to nearest", and the same(!) also goes for the CPU implementation. That is rounding mode is again consistent, but the considerably more useful "round to nearest" mode is used.
All again under the constraint "used correctly", i.e. you open the library from the right task, and don't touch the FPCR afterwards.
Quote:
Originally Posted by phx
EDIT: Using John R. Hauser's portable IEC/IEEE Softfloat library yields $4053d55555555556. Whatever that means...
|
This library is also quite fine, and a good source. The mathieeedoubbas was verified with the "Paranoia test".