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 <grndvd63m06f7...@gmail.com> 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 <esteba...@gmail.com >> <mailto:esteba...@gmail.com>>: >> >>> On 18 Sep 2018, at 11:13, Guillermo Polito <guillermopol...@gmail.com >>> <mailto:guillermopol...@gmail.com>> wrote: >>> >>> >>> >>> On Tue, Sep 18, 2018 at 11:06 AM Julien <julien.delplan...@inria.fr >>> <mailto:julien.delplan...@inria.fr>> 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 >>> >>> <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 >>
