Hi Eike,
I've got it! You were right (as always). The problem was exactly there:
When fRemainder is weak, for instance due to floating point representation
0.2 gives 0.2000...0018 in double precision and fRemainder may tend to about
1e-15, nPartialDenom cannot represent its reciprocal in 32 bits
Hi Noel,
On Thursday, 2016-06-30 08:51:35 +0200, Noel Grandin wrote:
> Under Windows, the Fraction class uses 32-bit calculations (because long is
> 32-bit on Windows), while on Linux it uses 64-bit values (because long is
> 64-bit on 64-bit Linux)
Just that Laurent's problem wasn't about the
Hi Laurent,
On Wednesday, 2016-06-29 05:19:43 -0700, Laurent BP wrote:
> On Linux, *sal_uLong nFrac* and *nDev* are modified and tend to a solution.
> My tests on Windows, thanks to Jenkin, show that *nFrac* and *nDev* keep the
> same values (respectively 0 and 1). So there is an infinite loop wi
Under Windows, the Fraction class uses 32-bit calculations (because long is
32-bit on Windows), while on Linux it uses 64-bit values (because long is
64-bit on 64-bit Linux)
Which is a right stuffup, and I don't know how to fix it without cascading
changes throughout the codebase.
Lots of places
