> *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]
<mailto:[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]
<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*
--
Ing. Davide Grandi
email : [email protected]
mobile : +39 339 7468 778
