2017-11-10 1:18 GMT+01:00 <[email protected]>:
> On 2017-11-10 00:02, Henrik Sperre Johansen wrote:
> > raffaello.giulietti wrote
> >> On 2017-11-09 21:49, Stephane Ducasse wrote:
> >>> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier
> >>> <
> >
> >> nicolas.cellier.aka.nice@
> >
> >> > wrote:
> >>>> Note that this started a long time ago and comes up episodically
> >>>> http://forum.world.st/Fraction-equality-and-Float-
> infinity-problem-td48323.html
> >>>> http://forum.world.st/BUG-Equality-should-be-transitive-
> tc1404335.html
> >>>> https://lists.gforge.inria.fr/pipermail/pharo-project/2009-
> July/010496.html
> >>>>
> >>>> A bit like a "marronnier" (in French, a subject that is treated
> >>>> periodically
> >>>> by newspapers and magazines)
> >>>
> >>> Hi nicolas except that now we could a chapter describing some of the
> >>> answers :)
> >>>
> >>
> >> It's easy to make = behave as an equivalence if the two objects it
> >> operates on are of the same class.
> >>
> >> But it is well-known that it's hard when their classes are different,
> >> short of implementing = trivially in this case.
> >>
> >> This is to say that there's no real hope to make = an equivalence if the
> >> wish is to make it useful in the presence of different kind of objects.
> >>
> >> In the context of numeric computations, luckily, there is some hope when
> >> conversions, if possible at all, are all performed consistently. But the
> >> same conversions should then be applied for all operations, whether
> >> comparisons or subtractions, etc., to ensure more familiar properties.
> >> This is not currently the case in Pharo.
> >>
> >>
> >>
> >> Raffaello
> >
> > Personally, I rather like = being transitive across different types of
> > objects, which is the case with the current implementation.*
> > It would not be if, like you suggest, multiple Fractions = the same
> Float.
> > Take a moment to also reflect on what it would mean if, as the
> implication
> > goes, a float represents a range of numbers on the rational number line,
> > rather than a single point.
> > Taken to its logical conclusion, it follows you'd need to also redefine
> the
> > other mathematical operators to reflect this, as well as conversion to
> exact
> > numbers like Integers and Fractions being lossy, rather than the other
> way
> > around.
> > You could certainly build an interesting system of floats with such a
> > property (I can swear I've read a paper on one somewhere...), but it
> > wouldn't be the world of IEEE754 Floats we live in.
> >
> > Other properties one might deem beneficial, such as
> > a + b > a if b > 0,
> > or
> > (a + b) + c = a + (b + c)
> > are not true in the context of floats. Does that mean we need to fix them
> > too?
> > My 2c: It feels like you are asking Floats to be something they're not,
> and
> > the answer simply isn't to try and paint over issues and try and make
> them
> > look like something they're not.
> >
> > Cheers,
> > Henry
> >
> >
>
> Personally, I could live without mixed arithmetic between unlimited and
> limited precision numbers: I would always be explicit in the
> conversions. They are so different in nature, like apples and oranges are.
>
> This also entails that I would accept that 1 = 1.0 evaluates to false,
> that 1 <= 1.0 throws an exception and all consequences of this.
>
> But this would be unacceptable for most Smalltalkers for many good
> reasons. And, as you point out, = and total ordering are easily
> preserved if Floats are converted to Fractions. But then please convert
> Floats to Fractions even when adding, multiplying, etc.
>
> To me a Float does not stand for an interval. It's just a real number
> that happens to have strange, unfamiliar operations that resemble the
> pure ones. Some familiar properties also hold for these strange
> operations, others do not.
>
>
>
> It would be tempting, but a priori I don't believe it would be sustainable.
What is nice in Smalltalk is that we can just try.
(a bit less easy for int+float because it's hardwired in the primitives and
maybe the JIT too)
So in current Pharo, if I just define
Fraction>>adaptToFloat: f andSend: m
^f isFinite
ifTrue: [f asFraction perform: m with: self]
ifFalse: [f perform: m with: self asFloat]
and symmetric in
Float>>adaptToFraction: f andSend: m
^self isFinite
ifTrue: [f perform: m with: self asFraction]
ifFalse: [f asFloat perform: m with: self]
then World does not seem to fall apart...
We would need to measure if noticeable slow down happens
