On 2017-11-09 22:11, Nicolas Cellier wrote:
>
>
>
> I think we have as much as possible already.
> Non equality resolve more surprising behavior than it creates.
> It makes the implementation more mathematically consistent
> (understand preserving more properties).
> Tell me how you are going to sort these 3 numbers:
>
> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} sort.
>
> tell me the expectation of:
>
> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size.
>
>
> A clearly stated rule, consistently applied and known to
> everybody, helps.
>
> In presence of heterogeneous numbers, the rule should state the
> common denominator, so to say. Hence, the numbers involved in
> mixed-mode arithmetic are either all converted to one
> representation or all to the other: whether they are compared or
> added, subtracted or divided, etc. One rule for mixed-mode
> conversions, not two.
>
>
> Having an economy of rules is allways a good idea.
> If you can obtain a consistent system with 1 single rule rather than
> 2 then go.
> But if it's at the price of sacrificing higher expectations, that's
> another matter.
>
> Languages that have a simpler arithmetic model, bounded integer, no
> Fraction, may stick to a single rule.
> More sofisticated models like you'll find in Lisp and Scheme have
> exact same logic as Squeak/Pharo.
>
> sophisticated... (i'm on my way copying/pasting that one a thousand times)
>
> We don't have 2 rules gratuitously as already explained.
> - Total relation order of non nan values so as to be a good
> Magnitude citizen imply non equality
> - Producing Float in case of mixed arithmetic is for practicle
> purpose: speed
> (What are those damn Float for otherwise?)
> it's also justified a posteriori by (exact op: inexact) -> inexact
>
> What are you ready to sacrifice/trade?
>
>
Let me check if I correctly understand the reason for the dual rule
regime for mixed computations:
(1) preservation of = as an equivalence and of total ordering. This is
ensured by converting Floats to Fractions.
(2) performance in case of the 4 basic operations, which is the reason
for the second conversion rule from Fractions to Floats.
Now, the gain in speed by exercising (2) really depends on how the
numbers "mix" in a long chain of operations. I guess for most uses of
mixed arithmetic it doesn't make any noticeable difference with respect
to a pure Fraction computation. Besides, correctly converting a Fraction
to a Float requires more computation than the opposite.
So, to answer your question, if preservation of total order and = is
worthwhile even in case of mixed numbers, I would sacrifice speed for
the sake of the principle of least surprise. One rule, Float->Fraction,
slightly less speed.
But for those cases where the gain in speed from using Floats would make
a noticeable difference, we are entering the hard, counter-intuitive
realm of limited precision arithmetic anyway. We better be experts in
the first place. And as experts we will find a way out of the one-rule
regime by performing explicit Fraction->Float conversions where needed
and won't face surprises.
The only reason to prefer the opposite one-rule, that would always
convert Fractions to Floats in mixed computations, is compatibility with
the commercial Smalltalk implementations. Granted, it's not a sound
reason but a pragmatic one.
