I agree with Nicolas. We should not remove the support for Float intervals completely because they have been around for a while. Instead, we should revise existing workarounds, simplify the code, and document the issues as new failing tests.

+1 for Collections-nice.825.mcz

Best,
Marcel
Am 13.09.2019 11:47:26 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
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 [mailto:lists at fniephaus.com]> a écrit :

On Fri, Sep 13, 2019 at 9:57 AM Tobias Pape <Das.Linux at gmx.de [mailto:Das.Linux at gmx.de]> wrote:
>
>
> > On 13.09.2019, at 08:50, Fabio Niephaus <lists at fniephaus.com [mailto:lists at fniephaus.com]> wrote:
> >
> >
> >
> > On Thu, 12 Sep 2019 at 1:02 am, Chris Muller <asqueaker at gmail.com [mailto: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/20190916/0f440b2d/attachment-0001.html>