Issue 4957 in pharo: Let asScaledDecimal use the right number of decimals

Status: Accepted
Owner: [hidden email]
Labels: Type-Feature

New issue 4957 by [hidden email]: Let asScaledDecimal use the right  
number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

This change comes from Squeak:

Let (1/10) asScaledDecimal answer 0.1s1 rather than 0.10000000s8
Let 1 asScaledDecimal answer 1s0 rather than 1.00000000s8

An interesting application is 0.1 asFraction asScaledDecimal which prints  
exactly what is represented in the machine.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #1 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Ah, the original comment was:

Nicolas Cellier uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-nice.400.mcz

==================== Summary ====================

Name: Kernel-nice.400
Author: nice
Time: 13 February 2010, 11:31:43.4 pm
UUID: 20e6c813-25cb-7548-9ba7-63a83f3b5193
Ancestors: Kernel-nice.399

Change the policy for conversions to ScaledDecimal
Always honour the number of decimal places (scale) passed as argument to  
asScaledDecimal:

When no scale is passed, uses strictly necessary number of decimal places  
if the number is exact (not Float) and if a finite decimal representation  
exists.
Otherwise uses the default of 8 decimal places.

This makes more sense IMO than previous implementation. Integer version was  
screwing the user by not fulfiling the requested number of decimal places,  
I can't believe it was the right interpretation of the ANSI standard.... Or  
someone gives me a good rationale.

=============== Diff against Kernel-nice.399 ===============

Item was added:
+ ----- Method: Integer>>asScaledDecimal (in category 'converting') -----
+ asScaledDecimal
+       "The number of significant digits of the answer is the same as the  
number of decimal digits in the receiver."
+       ^ ScaledDecimal newFromNumber: self scale: 0!

Item was added:
+ ----- Method: Fraction>>asScaledDecimal (in category 'converting') -----
+ asScaledDecimal
+       "Convert the receiver to a ScaledDecimal.
+       If there is a finite decimal representation of the receiver, then  
use the exact number of decimal places required.
+       Else, use a default number of decimals."
+
+       | pow2 pow5 q q5 |
+       pow2 := denominator lowBit - 1.
+       q := denominator bitShift: pow2 negated.
+       pow5 := 0.
+       [q = 1]
+               whileFalse: [
+                       q5 := q // 5.
+                       (q - (5 * q5)) = 0 ifFalse: [^super  
asScaledDecimal].
+                       q := q5.
+                       pow5 := pow5 + 1].
+       ^self asScaledDecimal: (pow2 max: pow5)!

Item was removed:
- ----- Method: Integer>>asScaledDecimal: (in category 'converting') -----
- asScaledDecimal: scaleNotUsed
-       "The number of significant digits of the answer is the same as the
-       number of decimal digits in the receiver.  The scale of the answer  
is 0."
-       #Numeric.
-       "add 200/01/19 For <integer> protocol."
-       ^ ScaledDecimal newFromNumber: self scale: 0!


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixReviewNeeded

Comment #2 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Name:  
SLICE-Issue-4957-Let-asScaledDecimal-use-the-right-number-of-decimals-nice.1
Author: nice
Time: 31 October 2011, 11:21:25 pm
UUID: 31c76efe-4fdc-4e0c-8cce-d58e529bcfa4
Ancestors:
Dependencies: Kernel-nice.962, KernelTests-nice.365

Change and test for  
Issue-4957-Let-asScaledDecimal-use-the-right-number-of-decimals


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #3 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

ANSI does not specify the message #asScaledDecimal, so we cannot turn there  
for help. ANSI, by itself, makes you specify the scale using  
#asScaledDecimal:.

I generally agree that it is desirable that the default scale be exact for  
numbers that have a finite representation.

Why are Floats not included in this? All Floats have an exact decimal  
representation (though the converse is certainly not true), and could be  
included in the fix by defining Float>asScaledDecimal as:

asScaledDecimal
   ^ self asFraction asScaledDecimal

This would be my preference.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Why not...

The advantage I see of (0.1 asFraction asScaledDecimal) other super (0.1  
asFraction asScaledDecimal: 8) is to expose the secret digits which are  
kept out of printed form in the latter case...

However, 0.1 asFraction asScaledDecimal is already 55 digits after the  
decimal point, and 1.0e-30 many more...

And 0.1 asFraction asScaledDecimal squared would still hide many digits, so  
the advantage will soon vanish anyway, and may soon become a drag...

Is there another advantage?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Hi Nicolas,

I'm not sure I understand your point in your last post, although everything  
you say is true.

What I'm proposing is, for instance, that (0.1 asScaledDecimal) would yield  
a ScaledDecimal with scale 55. I like the proposed Fraction implementation,  
and my proposal seems seems the most consistent with that implementation,  
which can produce numbers of very large scale, depending on the Fraction's  
value.

In both the cases of Fraction or of Float, if one wants less than full  
precision, one should specify what scale to round to by using  
#asScaledDecimal:.

Regards,

-Martin


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #6 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

OK, I understand, your proposition has the merit of uniformity: though  
Float are inexact, ALWAYS use exact precision when possible (there is a  
finite representation).

Anyway, we'll have at most 1074 digits, not that much ;)
0.0 ulp asFraction asScaledDecimal

Another possible implementation for Float would be to convert to the  
ScaledDecimal having equal printed notation, like 0.1 asScaledDecimal =  
0.1s1, but that's not what we currently have...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Attached a transcription of #absPrintExactlyOn:base: to play with:
0.1 asMinimalDecimalFraction asScaledDecimal = 0.1s1

A good property is that we should have
     x asMinimalDecimalFraction asScaledDecimal asFloat = x
for any finite Float x.

That's interesting, but if Float asFraction defaults to asExactFraction,  
maybe asScaledDecimal should too.

Attachments:
        Float-asMinimalDecimalFraction.st  3.2 KB


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #8 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Oops, 1.0e-100 asMinimalDecimalFraction asFloat did fail, here is a new  
attempt

Attachments:
        Float-asMinimalDecimalFraction.st  3.2 KB


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #9 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Nicolas I read all the discussion and I missed the last part :).
Now I will integrate the slice and my question is should I  integrate  
Float-asMinimalDecimalFraction too?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Closed
        Labels: Milestone-1.4

Comment #10 on issue 4957 by [hidden email]: Let asScaledDecimal use  
the right number of decimals
http://code.google.com/p/pharo/issues/detail?id=4957

Slice integrated in 14215 and also the asMinimalDecimalFraction.
I hope that this is ok.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker