5.3 printShowingDecimalPlaces: 2 displays '5.29' insteadof'5.30'

Sebastian Sastre ssastre at seaswork.com
Thu Nov 22 20:50:04 UTC 2007


> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Tom Phoenix
> Enviado el: Jueves, 22 de Noviembre de 2007 17:59
> Para: The general-purpose Squeak developers list
> Asunto: Re: 5.3 printShowingDecimalPlaces: 2 displays '5.29' 
> insteadof'5.30'
> 
> On 11/22/07, Sebastian Sastre <ssastre at seaswork.com> wrote:
> 
> > Let's supose the user enters in some
> > input widget with keyboard the '5.30' value. That will end 
> as a Float 
> > at some point.
> 
> Why will it?
> 
> We're talking about monetary units. If you start with a 
> string like '5.30', meaning 530 monetary units, it won't "end 
> as a Float" all by itself. If somebody somewhere wrote code 
> that converted it to floating point, that's a bug.
> 
Even if you don't use computers to achieve that, when you make monetary
values to pass trhough functions they *are* mathematically represented as
float numeric values. At some point we simplify presentations (like the
balance books you mention) of the values.
I certainly agree with you about units. In fact there are equivalence units.
100 cents are 1 dollar, 4 quarters also are equal to 1 dollar and 100 cents.

Aconcagua framework seems to deal quite well with that trough it's Measures
(and amount and a unit). For monetary measures I think I'll store scaled
decimal amounts to gain the accuracy you propose.

> Don't be misled by what looks like a decimal point. If you're 
> working with money, you don't want floating point, no matter 
> what your programming language. Floating point will lose tiny 
> bits due to roundoff; but money numbers are almost always 
> integral numbers of cents, and you don't want to lose any of 
> them. Floating point may be needed to perform some 
> calculations along the way, but you'll use integers to get 
> the books to balance.
> 
I agree. With measures I think I'll be able to achieve that, by using scaled
decimanls in the amounts of the measures, and the rounding will be performed
only in presentation time by the converter of the widget and not in the
internal process, formulas or calculation of the value. 

Cheers!

Sebastian


> ObSqueak: 5.30 asFraction
> 
> Cheers!
> 
> --Tom Phoenix
> 




More information about the Squeak-dev mailing list