> On 18 Sep 2018, at 11:13, Guillermo Polito <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
