Hi Davide, Using decimals is a possibility which already exists, just add a $s at end of the literal. What you suggest is to change the syntax and use decimal as the default, and another notation (or no literal notation at all, just asFloat message send) for floating point numbers.
It's worth trying, but IMO, you will encounter these limitations: - decimals currently are implemented as unlimited precision Fraction. For long calculations, they will tend to grow in size and slow down the system (I have developped a symbolic calculation library in Smalltalk 30 yeras ago and thus used the Fraction extensively, so I know what it can cost). - decimals currently are not decimals but arbitrary fractions (for example 2.0s / 3 will be represented as Fraction 2/3 internally). But they print as a rounded decimal representation which can't convert back to the same number, and thus is not the most convenient for REPL style. - most decimals operations are slower than floating point operations. Suggested notations like aaa.bbb(cccc) for a repeating pattern cccc could be indeed used to deal with REPL problem. Or we could emulate some limited precision decimals (preferably with floating point). But it's hard to address all the issues above together. For simple geometry problems we soon need Algebraic numbers, and then transcendental, so the usefulness of unlimited fraction is limited anyway. In practice, we rapidly need approximations, that's where highly optimized and carfully thought floating point shine... Personnally, if Pharo want to go down that road, I would at least keep a literal notation for floating point, given the universality and interest of such numbers. Le dim. 23 sept. 2018 à 16:31, Davide Grandi <[email protected]> a écrit : > > *rational number* > CORRECT, for any BASE and any string : > > at worst, repeating decimals (eg [TYPO -->0,1<--] 0.1 in base 3 = 1/3 ~ > 0.333...), that are ultimately fractions. > > but for 10, 2 and 5 bases and combinations thereof (Z = 2r, 5r, 10r, 20r, > ...), any string ZrXXX.YYY will lead to a decimal number with finite and > precise number of digits. > > ... or, maybe, I'm wrong and insisting on wrong premises and conclusions > in front of all the public... > > Davide Grandi > > On 19/09/2018 22:54, Julien wrote: > > Hello, > > Ok, I read all the mails. I see your point about not cancelling the > possibility to use #to:by: on any Number. > > However, the remark from David Grandi seems really relevant to me. > > You can NOT write anything else than a *rational number* when writing a > literal using the XXX.XXX pattern. > > I think it would be legit to generate scaled decimal by default from float > literals and to be able to get Float only by either explicitly specify it > (#asFloat, etc…) or because of computation that lead to a Float (e.g. the > need to approach an irrational number ?). > > I would be curious to see the impact of such change in the compiler on the > system. > > Maybe a first step is indeed to implement a rule in Renraku to encourage > people to use ScaledDecimals. > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant à l’Université de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq > Numéro de téléphone: +333 59 35 86 40 > > Le 19 sept. 2018 à 09:22, Davide Grandi <[email protected]> a > écrit : > > > 0.0 to: 1.0 by: 0.1 > Receiver and arguments, lexically (the dot), are float BUT > are written as decimal number (zero, one, one tenth). > > I think that in a text you can ONLY write "decimal" numbers or (in bases > other than 10 [or with factors other than 2^x and 5 ?]), at worst, > repeating decimals > (eg 0,1 in base 3 = 1/3 ~ 0.333...), that are ultimately fractions. > > So, may be, if the receiver or an argument is a float the compiler may > issue a warning and compile to non-float, if receiver or arguments are > computed ... there should be a default behaviour. > > Best regards, > > Davide Grandi > (PS : I work mainly in an ERP that has only integers ... and doubles) > > On 18/09/2018 11:52, Guillaume Larcheveque wrote: > > Maybe #to:by: should convert its parameters in Fraction to avoid Floats > problems (not sure, just an idea) > > 2018-09-18 11:25 GMT+02:00 Esteban Lorenzano <[email protected]>: > >> On 18 Sep 2018, at 11:13, Guillermo Polito <[email protected]> >> wrote: >> >> On Tue, Sep 18, 2018 at 11:06 AM Julien <[email protected]> >> wrote: >> >>> Hello, >>> >>> I realised that it is possible to create an interval of floats. >>> >>> I think this is bad because, since intervals are computed by >>> successively adding a number, it might result in precision errors. >>> >>> (0.0 to: 1.0 by: 0.1) asArray >>> #(0.0 0.1 0.2 0.30000000000000004 0.4 >>> 0.5 0.6000000000000001 0.7000000000000001 0.8 0.9 1.0) >>> >>> The correct (precise) way to do it would be to use ScaledDecimal: >>> >>> (0.0s1 to: 1.0s1 by: 0.1s1) asArray >>> #(0.0s1 0.1s1 0.2s1 0.3s1 0.4s1 >>> 0.5s1 0.6s1 0.7s1 0.8s1 0.9s1 1.0s1) >>> >>> I opened an issue about it: >>> https://pharo.fogbugz.com/f/cases/22467/Float-should-not-implement-to-to-by-etc >>> >>> And I’d like to discuss this with you. >>> >>> What do you think? >>> >> >> Well, I think it's a matter of balance :) >> >> #to:by: is defined in Number. So we could, for example, cancel it in >> Float. >> However, people would still be able to do >> >> 1 to: 1.0 by: 0.1 >> >> Which would still show problems. >> >> Nevertheless, I have seen this a lot of times. >> >> 0.0 to: 1.0 by: 0.1 >> >> Is a common use case. >> >> >> And moreover, we could try to do >> >> 1 to: 7 by: (Margin fromNumber: 1) >> >> And even worse >> >> 1 to: Object new by: (Margin fromNumber: 1) >> >> I think adding type-validations all over the place is not a good >> solution, and is kind of opposite to our philosophy... >> >> So we should >> - document the good usages >> - document the bad ones >> - and live with the fact that we have a relaxed type system that will >> fail at runtime :) >> >> yup. >> But not cancel. >> >> Esteban >> >> >> Guille >> >> -- > *Guillaume Larcheveque* > > > -- > Ing. Davide Grandi > email : [email protected] > mobile : +39 339 7468 778 > >
