Dear Nicolas

> On 13.09.2019, at 11:47, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> 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...

Thanks for the analysis!

what i take as a tangential message here is that we probably should promote exact arithmetics more.
It's probably too easy to end up in inexact-land with the things we currently do…

Best regards
	-Tobias

> 
> 
> 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
> > >
> > >
> > >
> >
> >
> >
> 
>