Interval of Float are not nice to have: we already have!
Here are 4 propositions that I wanted to put on the table:
1) It is recommended to avoid using Interval of Float, because they will
have pitfalls, expecially if you have naive expectations.
2) It is void to try masking the inexact nature of Float by partial
waorkarounds
3) It is recommended to provide implementation robust to inexact
arithmetic, and avoid adding more pitfalls than necessary.
4) It is recommended to teach the limitations.
    Known failures is somehow a way to document that.

But adding some code to explicitly forbid Interval of Float, no, that's
something I would avoid!
IMO, it is a wrong answer to 1).
It's like wanting to over-protect the user because we presume he is dumb
and cannot learn anything complex.
That's not the spirit of Smalltalk IMO. We must make simple things simple,
and open the possibility to make more complex things.
We must not be castrating but inviting and teaching.
After all, making mistakes is a good way to learn, we must not try to
prevent that ;)
IMO the right answer is 4).

Float are full of pitfalls. But we don't forbid Float, do we? They have too
much practical value, and we'd better learn to use them.
Maybe Interval of Float has less value than Float, but it's a bit like
saying that oranges have less value than citruses ;)
They have not much value in the core image, but you cannot presume they
will never have.
Try to make a LogarithmicInterval without Float for example... Analysis of
systems in frequency domain requires such species!

The dicussion I wanted to open was about 2) and 3).
In the past, some wanted to reduce the surprising behavior by masking the
inexact nature of Float arithmetic
(round to nearest in the best case, uncontrolled accumulation of rounding
errors in the worse one).
This was done by encoding arbitrary comparison thresholds in some methods.
But this lead to more surprising behavior in the end, and it is enforcing
wrong expectations.
That's what I tried to document with the new failing tests.

So the first thing is that I wanted to remove those workarounds, and reveal
the true nature of Float, not masking it.
They make things worse IMO.

The second thing is that there are other naive implementations of Interval
methods that won't work with inexact arithmetic.
But with some care, we can rewrite those to also behave better with
inexact. The question if it is worth or not.
It's a trade off between complexity and utility.
That's why it is in the inbox, and we can decide that they are nice to have
or overkill for too few value.
We can also postpone the decision with known failures, fix later, or
delegate to an external package...


Le ven. 13 sept. 2019 à 10:26, Fabio Niephaus <lists at fniephaus.com> a
écrit :

> On Fri, Sep 13, 2019 at 9:57 AM Tobias Pape <Das.Linux at gmx.de> wrote:
> >
> >
> > > On 13.09.2019, at 08:50, Fabio Niephaus <lists at fniephaus.com> wrote:
> > >
> > >
> > >
> > > On Thu, 12 Sep 2019 at 1:02 am, Chris Muller <asqueaker at gmail.com>
> wrote:
> > > "An Interval reversed is generally an Interval, except when made of
> Float."
> > > Should ReversedInterval be renamed to ReversedFloatInterval then?
> > >
> > > +1
> > >
> > > Interval was designed for Integers only.  IMO, it should be copied to
> a separate class, FloatInterval, to implement this capability.
> > >
> > > Does anyone actually need Float support in Interval at this point? Or
> would it make sense to just disallow Floats in Interval for the time being?
> > >
> >
> > I don't see why supporting
> >
> >         2.4 to: 4.5
> >
> > would be a bad idea. At least, it has a proper mathematical meaning.
> > Question is, whether just
> >
> >         (1.0 to: 3.0) includes: 2.5
> >
> > should be true or also
> >
> >         (1 to: 3) includes: 2.5
> >
> > :D
>
> I didn't say it's a bad idea, I wanted to know if someone actually
> needs it right now. If not, I'd just flag this as a "nice to have"
> feature we could support in a future release, but not the one we are
> working on at the moment.
>
> Fabio
>
> >
> > > Fabio
> > >
> > >
> > >
> > >
> > > Nonetheless, this seems to fix #testIntervalOfFloatLast and
> > > #testIntervalOfFloatReversed of IntervalTest. Do we want to integrate
> > > this proposal or shall we mark these two tests as expected failures?
> > >
> > > Fabio
> > >
> > >
> > >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190913/7933f93a/attachment.html>