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.
> *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
B��timent B 40, Avenue
Halley 59650��Villeneuve��d'Ascq
Num��ro de t��l��phone:
+333 59 35 86 40
> 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)
--
Ing. Davide Grandi
email : davide.grandi@mclink.it
mobile : +39 339 7468 778