roundTo: strange behavior

Hi Nicolas,
regarding rounding Fractions:
i use fractions if i want to get an exact result (eg for comparing the result with Float calculations). if #round: returns a Float all further calcs (with Fractions) will get contaminated, since the rest will become Floats too. Hence the "asScaledDecimal: numberOfWishedDecimal" seems better to me, but i wonder why these transformations at the end are necessary at all? just for the looks? i'd suppose every person, who knows how to use Fractions, also knows how to append a #asScaledDecimal: to a result by himself, should he want that.

taking as an example financial calcs that first use 2 decimals. occasionaly the final result will be basepoints, often small ones like 0.003. with scaledDecimals the result would be (ok, look like) 0 since scaledDecimals also contaminate the calc. of course one could correct this simply with an #asScaledDecimal:3 at the end. nevertheless a first look at the zero result would surprise me for a tenth of a second.
werner

Hi Werner,

I don't know the purpose of round: at all.

Most often this kind of message was used before printing probably because lack of versatile formatted print messages.

In Squeak I replaced most usages of roundTo: by printShowing(Max)DecimalPlaces:.

Now if it has been added in Pharo and other languages, there must be some use cases I presume.

Maybe the analysis could be carried on these use cases?

Beware, converting a Fraction asScaledDecimal will NOT round.

Only the printString is rounded, but the number keeps its whole precision.

Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s.

ScaledDecimals as they are now are just Fraction with a different printString...

Not very much added value.

Nicolas

 

On 10/26/2016 09:58 AM, Nicolas Cellier wrote:

2016-10-26 9:14 GMT+02:00 stepharo <[hidden email]>:

Hi nicolas

So what is the solution? We can integrate fast a solution.
I would really like to see them fix in Pharo 60.
I'm writing a book for newbie and this is the third time I change one chapter
so may be I should stop and throw away this chapter.

1) for Fraction:

round: numberOfWishedDecimal
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self * v) rounded / v) asFloat

or just replace asFloat if you wish to remain exact:

round: numberOfWishedDecimal
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal

2) for Float, it is in 15471:

round: numberOfWishedDecimal

    | v maxNumberOfDecimals |
    maxNumberOfDecimals := self class precision - 1 - (self exponent max: self class emin).
    maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self asFraction * v) rounded / v) asFloat

or if Fraction already answers a Float:

round: numberOfWishedDecimal
    | maxNumberOfDecimals |
    maxNumberOfDecimals := self class precision - 1 - (self exponent max: self class emin).
    maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
    ^ self asFraction round: numberOfWishedDecimal

 

It's slower than current implementation, but will round exactly to the nearest Float.

It's possible to have faster implementation up to 22 decimals if you provide a fused-multiply-accumulate primitive...

Sorry for being slow minded,
yes of course financial apps is exactly the case where round: would be usefull and NEEDS to be exact.

Hi Nicolas,
yes, i know. suppose you calc some financial thing and one intermediate result will be in $. you have to round this Fraction-result  to 2 decimals. now you use this to further calc basepoints as the final result. you have to convert this to 3 decimals. looking at this final result with 2 decimals can be be irritating for a moment, if you debug the calcs. and <g> btw i never use scaledDecimals.
werner

On 10/26/2016 02:06 PM, Nicolas Cellier wrote:

2016-10-26 13:11 GMT+02:00 test <[hidden email]>:

Hi Nicolas,
regarding rounding Fractions:
i use fractions if i want to get an exact result (eg for comparing the result with Float calculations). if #round: returns a Float all further calcs (with Fractions) will get contaminated, since the rest will become Floats too. Hence the "asScaledDecimal: numberOfWishedDecimal" seems better to me, but i wonder why these transformations at the end are necessary at all? just for the looks? i'd suppose every person, who knows how to use Fractions, also knows how to append a #asScaledDecimal: to a result by himself, should he want that.

taking as an example financial calcs that first use 2 decimals. occasionaly the final result will be basepoints, often small ones like 0.003. with scaledDecimals the result would be (ok, look like) 0 since scaledDecimals also contaminate the calc. of course one could correct this simply with an #asScaledDecimal:3 at the end. nevertheless a first look at the zero result would surprise me for a tenth of a second.
werner

Hi Werner,

I don't know the purpose of round: at all.

Most often this kind of message was used before printing probably because lack of versatile formatted print messages.

In Squeak I replaced most usages of roundTo: by printShowing(Max)DecimalPlaces:.

Now if it has been added in Pharo and other languages, there must be some use cases I presume.

Maybe the analysis could be carried on these use cases?

Beware, converting a Fraction asScaledDecimal will NOT round.

Only the printString is rounded, but the number keeps its whole precision.

Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s.

ScaledDecimals as they are now are just Fraction with a different printString...

Not very much added value.

Nicolas

 

On 10/26/2016 09:58 AM, Nicolas Cellier wrote:

2016-10-26 9:14 GMT+02:00 stepharo <[hidden email]>:

Hi nicolas

So what is the solution? We can integrate fast a solution.
I would really like to see them fix in Pharo 60.
I'm writing a book for newbie and this is the third time I change one chapter
so may be I should stop and throw away this chapter.

1) for Fraction:

round: numberOfWishedDecimal
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self * v) rounded / v) asFloat

or just replace asFloat if you wish to remain exact:

round: numberOfWishedDecimal
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal

2) for Float, it is in 15471:

round: numberOfWishedDecimal

    | v maxNumberOfDecimals |
    maxNumberOfDecimals := self class precision - 1 - (self exponent max: self class emin).
    maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self asFraction * v) rounded / v) asFloat

or if Fraction already answers a Float:

round: numberOfWishedDecimal
    | maxNumberOfDecimals |
    maxNumberOfDecimals := self class precision - 1 - (self exponent max: self class emin).
    maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
    ^ self asFraction round: numberOfWishedDecimal

 

It's slower than current implementation, but will round exactly to the nearest Float.

It's possible to have faster implementation up to 22 decimals if you provide a fused-multiply-accumulate primitive...

So what is the definition of printShowingMaxDecimalDigit:?
I have the impression that there is a confusion between the rounding a number and the printing of his value in a given format.

we can deprecate roundTo: if necessary.

I think roundTo: is OK. #round: is not, and should be deprecated (at least for Floats). For Floats, the idea of rounding to a specific number of decimal digits is a fantasy. Here's why: Floats cannot exactly represent most common decimal fractions. For example:

0.1 -- not representable

0.2 -- not representable

0.3 -- not representable

0.4 -- not representable

0.5 -- hey, representable!

0.6 -- not representable

0.7 -- not representable

0.8 -- not representable

0.9 -- not representable

1.0 -- representable.

*Printing* a Float to a specific rounded decimal format is a sensible idea, and should be encouraged. But trying for a "rounded Float" *number* just can't be done exactly (except by converting to a Fraction).

Fractions can be rounded to exact decimal fractions, so something like "myFraction roundTo: 1/100" makes sense. But the current implementation of round: on Fraction that converts to a Float just gets you the misery detailed above.

I've put a single slice in the inbox for the 3 issues because they all are related.

See slice comment:

For Float, implement guard to prevent overflow (15471), and use exact representation for intermediate results (asFraction) so as to avoid double rounding problems (15473)

For Fraction (15472), choose an exact representation for result rather than Float. This is because such method is particularly usefull for financial/monetary applications.

Yes. Fraction or ScaledDecimal. Not Floats, unless the developer understands the needs of the financial world and the limitations of Floats very well.

Regards,

-Martin

2016-10-27 9:51 GMT+02:00 Denis Kudriashov <[hidden email]>:

2016-10-27 8:31 GMT+02:00 Martin McClure <[hidden email]>:

I think roundTo: is OK. #round: is not, and should be deprecated (at least for Floats). For Floats, the idea of rounding to a specific number of decimal digits is a fantasy. Here's why: Floats cannot exactly represent most common decimal fractions. For example:

0.1 -- not representable

0.2 -- not representable

0.3 -- not representable

0.4 -- not representable

0.5 -- hey, representable!

0.6 -- not representable

0.7 -- not representable

0.8 -- not representable

0.9 -- not representable

1.0 -- representable.

*Printing* a Float to a specific rounded decimal format is a sensible idea, and should be encouraged. But trying for a "rounded Float" *number* just can't be done exactly (except by converting to a Fraction).

Fractions can be rounded to exact decimal fractions, so something like "myFraction roundTo: 1/100" makes sense. But the current implementation of round: on Fraction that converts to a Float just gets you the misery detailed above.

On 10/26/2016 01:00 PM, Nicolas Cellier wrote:

I've put a single slice in the inbox for the 3 issues because they all are related.

See slice comment:

For Float, implement guard to prevent overflow (15471), and use exact representation for intermediate results (asFraction) so as to avoid double rounding problems (15473)

The double rounding problem is not the fundamental problem, the fundamental problem is that what is desired does not exist, because Floats cannot exactly represent most decimal fractions. So this can't really fix it.

Exactly. Thank's for good explanation

Nonetheless, if user asked to round a Float, we must give him back a Float.
We ain't gonna answer a ScaledDecimal because we think that it's better for him: we don't know what is better for him.
And we MUST do our best to round correctly to the NEAREST Float that is 0.1e0, 0.2e0, ... 1.0e0

If user asked to round a Fraction or ScaledDecimal, then it's different.
We'd better keep the exactness and use ScaledDecimal rather than convert to a Float.

That's exactly these two things that the SLICE posted in inbox is doing.

i completely agree (well, i would have preferred a pure Fraction result in the pure Fraction case instead of a ScaledDecimal, but so what)

werner

p.s. a pure Fraction result in the pure Fraction case would also insure that the rest of Number is more or less independent of the not very useful ScaledDecimal

I am also for what Martin says :).

On 10/27/2016 10:34 AM, Nicolas Cellier
wrote:

2016-10-27 9:51 GMT+02:00 Denis
Kudriashov <[hidden email]>:

2016-10-27 8:31 GMT+02:00
Martin McClure <[hidden email]>:

I think roundTo: is OK. #round: is not, and
should be deprecated (at least for Floats).
For Floats, the idea of rounding to a specific
number of decimal digits is a fantasy. Here's
why: Floats cannot exactly represent most
common decimal fractions. For example:

0.1 -- not representable

0.2 -- not representable

0.3 -- not representable

0.4 -- not representable

0.5 -- hey, representable!

0.6 -- not representable

0.7 -- not representable

0.8 -- not representable

0.9 -- not representable

1.0 -- representable.

*Printing* a Float to a specific rounded
decimal format is a sensible idea, and should
be encouraged. But trying for a "rounded
Float" *number* just can't be done exactly
(except by converting to a Fraction).

Fractions can be rounded to exact decimal
fractions, so something like "myFraction
roundTo: 1/100" makes sense. But the current
implementation of round: on Fraction that
converts to a Float just gets you the misery
detailed above.

On
10/26/2016 01:00 PM, Nicolas Cellier wrote:

I've put a single slice in the inbox
for the 3 issues because they all are
related.

See slice comment:



For Float, implement guard to prevent
overflow (15471), and use exact
representation for intermediate results
(asFraction) so as to avoid double
rounding problems (15473)

The double rounding problem is not the
fundamental problem, the fundamental problem is
that what is desired does not exist, because
Floats cannot exactly represent most decimal
fractions. So this can't really fix it.

Exactly. Thank's for good explanation

Nonetheless, if user asked to round a
Float, we must give him back a Float.

We ain't gonna answer a ScaledDecimal because we think that
it's better for him: we don't know what is better for him.

And we MUST do our best to round correctly to the NEAREST
Float that is 0.1e0, 0.2e0, ... 1.0e0

If user asked to round a Fraction or
ScaledDecimal, then it's different.

We'd better keep the exactness and use ScaledDecimal rather
than convert to a Float.

That's exactly these two things that the SLICE posted in inbox
is doing.

i completely agree (well, i would have preferred a pure Fraction
result in the pure Fraction case instead of a ScaledDecimal, but
so what)

werner

p.s. a pure Fraction result in the pure Fraction case would also
insure that the rest of Number is more or less independent of the
not very useful ScaledDecimal

I am also for what Martin says .

And also: I'd argue that you NEVER EVER want to use simple Floats for financial applications. In financial applications you really need precision, and Floats have hardware limitations that do not provide precision.

Thanks ***A LOT*** nicolas.

I've put a single slice in the inbox for the 3 issues because they all are related.

See slice comment:

For Float, implement guard to prevent overflow (15471), and use exact representation for intermediate results (asFraction) so as to avoid double rounding problems (15473)

For Fraction (15472), choose an exact representation for result rather than Float. This is because such method is particularly usefull for financial/monetary applications.

2016-10-26 17:28 GMT+02:00 stepharo <[hidden email]>:

Le 26/10/16 à 14:52, Nicolas Cellier a écrit :

Sorry for being slow minded,
yes of course financial apps is exactly the case where round: would be usefull and NEEDS to be exact.

so what is the solution?
I'm lost again.

Hi Nicolas,
yes, i know. suppose you calc some financial thing and one intermediate result will be in $. you have to round this Fraction-result  to 2 decimals. now you use this to further calc basepoints as the final result. you have to convert this to 3 decimals. looking at this final result with 2 decimals can be be irritating for a moment, if you debug the calcs. and <g> btw i never use scaledDecimals.
werner

On 10/26/2016 02:06 PM, Nicolas Cellier wrote:

2016-10-26 13:11 GMT+02:00 test <[hidden email]>:

Hi Nicolas,
regarding rounding Fractions:
i use fractions if i want to get an exact result (eg for comparing the result with Float calculations). if #round: returns a Float all further calcs (with Fractions) will get contaminated, since the rest will become Floats too. Hence the "asScaledDecimal: numberOfWishedDecimal" seems better to me, but i wonder why these transformations at the end are necessary at all? just for the looks? i'd suppose every person, who knows how to use Fractions, also knows how to append a #asScaledDecimal: to a result by himself, should he want that.

taking as an example financial calcs that first use 2 decimals. occasionaly the final result will be basepoints, often small ones like 0.003. with scaledDecimals the result would be (ok, look like) 0 since scaledDecimals also contaminate the calc. of course one could correct this simply with an #asScaledDecimal:3 at the end. nevertheless a first look at the zero result would surprise me for a tenth of a second.
werner

Hi Werner,

I don't know the purpose of round: at all.

Most often this kind of message was used before printing probably because lack of versatile formatted print messages.

In Squeak I replaced most usages of roundTo: by printShowing(Max)DecimalPlaces:.

Now if it has been added in Pharo and other languages, there must be some use cases I presume.

Maybe the analysis could be carried on these use cases?

Beware, converting a Fraction asScaledDecimal will NOT round.

Only the printString is rounded, but the number keeps its whole precision.

Example (1/3 asScaledDecimal: 1)*3 = 1.0s, not 0.9s.

ScaledDecimals as they are now are just Fraction with a different printString...

Not very much added value.

Nicolas

 

On 10/26/2016 09:58 AM, Nicolas Cellier wrote:

2016-10-26 9:14 GMT+02:00 stepharo <[hidden email]>:

Hi nicolas

So what is the solution? We can integrate fast a solution.
I would really like to see them fix in Pharo 60.
I'm writing a book for newbie and this is the third time I change one chapter
so may be I should stop and throw away this chapter.

1) for Fraction:

round: numberOfWishedDecimal
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self * v) rounded / v) asFloat

or just replace asFloat if you wish to remain exact:

round: numberOfWishedDecimal
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self * v) rounded / v) asScaledDecimal: numberOfWishedDecimal

2) for Float, it is in 15471:

round: numberOfWishedDecimal

    | v maxNumberOfDecimals |
    maxNumberOfDecimals := self class precision - 1 - (self exponent max: self class emin).
    maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
    v := 10 raisedTo: numberOfWishedDecimal.
    ^ ((self asFraction * v) rounded / v) asFloat

or if Fraction already answers a Float:

round: numberOfWishedDecimal
    | maxNumberOfDecimals |
    maxNumberOfDecimals := self class precision - 1 - (self exponent max: self class emin).
    maxNumberOfDecimals < numberOfWishedDecimal ifTrue: [^self].
    ^ self asFraction round: numberOfWishedDecimal

 

It's slower than current implementation, but will round exactly to the nearest Float.

It's possible to have faster implementation up to 22 decimals if you provide a fused-multiply-accumulate primitive...

i would prefer if #round: will not be deprecated in Floats. in some cases Float>>#round: can be useful, eg optimization problems where one searched value describes the size of a screw, that exists only in certain sizes.

#roundTo: can be used for this (and is specified by ANSI Smalltalk, for those who care). If the screws only come in 16th inch increments, for instance, then "roundTo: 0.0625" will give you an exact result, since 16ths *are* exactly representable as floats.

OTOH, #round: (not in ANSI) appears to promise something that cannot be delivered for Floats, so is misleading, and it spreads the kind of confusion that resulted in this thread.

That's why I favor deprecating #round: for Floats.

Regards,

-Martin

On 10/27/2016 04:12 AM, test wrote:

i would prefer if #round: will not be deprecated in Floats. in some cases Float>>#round: can be useful, eg optimization problems where one searched value describes the size of a screw, that exists only in certain sizes.

#roundTo: can be used for this (and is specified by ANSI Smalltalk, for those who care). If the screws only come in 16th inch increments, for instance, then "roundTo: 0.0625" will give you an exact result, since 16ths *are* exactly representable as floats.

OTOH, #round: (not in ANSI) appears to promise something that cannot be delivered for Floats, so is misleading, and it spreads the kind of confusion that resulted in this thread.

That's why I favor deprecating #round: for Floats.

Regards,

-Martin

feel free to improve the slice.

Hi,
i never made a slice and thought <stupid grin>, i could eventually try to do that in this case, but of course i did not succeed:
1. Nicolas, i do not understand, why you put asScaledDecimal: numberOfWishedDecimal at the end of Fraction>>round:. what would not work, if one simply omitted that?
2. when i make a slice i find no possibility to save it to my pc, to check whether i made things correctly and there is no changes-button in the monticello-browser to look at the diff that slice would make. of course the seasoned programmer has no problems with that, but a simple user like me?
3. this line: "< expr: '(1/3 round: 2)' result: (33/100) >" is not accepted by the browser. i have no idea how to call this example to debug it, perhaps (33/100) is not accepted as a result because Fractions are no literals? and then what?
werner

p.s. regarding your slice, Nicolas, FractionTest>>testRounding needs also to be changed.