> 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]
<mailto:[email protected]>>:
On 18 Sep 2018, at 11:13, Guillermo Polito
<[email protected] <mailto:[email protected]>> wrote:
On Tue, Sep 18, 2018 at 11:06 AM Julien
<[email protected] <mailto:[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
<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*
