Thanks thanks for your report.
I do not have the answer but this is important to get aware of that.
Stef
On Feb 27, 2011, at 10:08 PM, t olschewski wrote:
> Hi, using formatted number output recently I got the following output:
>
> 1.0 printPaddedWith: $0 to: 2.1. "'01.0'"
> 1.0 printPaddedWith: $0 to: 2.2. "'01.00'"
> 1.0 printPaddedWith: $0 to: 2.3. "'01.00'" <-- wrong
> 1.0 printPaddedWith: $0 to: 2.4. "'01.000'" <-- wrong
> 1.0 printPaddedWith: $0 to: 2.5. "'01.00000'"
>
> running Float>>printPaddedWith:to: in the debugger showed me that the reason
> of this odd behaviour seems to be produced by Float>>truncated and/or
> Float>>fractionPart. I can provoke errors of that kind even easier:
>
> (2.3 fractionPart * 10) truncated. => "2" (instead of 3)
>
> In Primitive 51 (primitiveTruncated for Float>>truncated) I read
>
> frac = modf(rcvr, &trunc);
>
> so the problem looks like an issue with rounding errors in Math-Library's
> modf
> function.
>
> Indeed, I can reproduce the odd result of "(2.3 fractionPart * 10)
> truncated."
> in C++ using modf:
>
> // g++ -lm truncate.cpp && ./a.out
> #include<iostream>
> #include<cmath>
> using namespace std;
> int main(){
> double f1, f2, f3;
> modf(10 * 0.3, &f1);
> cout << f1 << endl;
> modf(10 * modf(2.3, &f2), &f3);
> cout << f3 << endl;
> }
> // output:
> // 3 (ok)
> // 2 (error - should be 3)
>
> Question: what can be done about this?
>
> As a matter of fact, several important methods spread over a number of
> classes
> (Float, Number, Morph ... being among them) are senders of Float>>truncated
> or
> Float>>fractionPart, so rounding errors in primitive 51 or 52 could provoke
> unexpected behaviour in surprising places.
>
>
> --
> View this message in context:
> http://forum.world.st/rounding-errors-tp3327130p3327130.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
