<div dir="ltr"><div>Interval of Float are not nice to have: we already have!</div><div>Here are 4 propositions that I wanted to put on the table:<br></div><div>1) It is recommended to avoid using Interval of Float, because they will have pitfalls, expecially if you have naive expectations.</div><div>2) It is void to try masking the inexact nature of Float by partial waorkarounds</div><div>3) It is recommended to provide implementation robust to inexact arithmetic, and avoid adding more pitfalls than necessary.</div><div>4) It is recommended to teach the limitations.</div><div> Known failures is somehow a way to document that.<br></div><div><br><div>But adding some code to explicitly forbid Interval of Float, no, that's something I would avoid!</div><div>IMO, it is a wrong answer to 1).<br></div>
</div><div>
<div>It's like wanting to over-protect the user because we presume he is dumb and cannot learn anything complex.</div><div>That's not the spirit of Smalltalk IMO. We must make simple things simple, and open the possibility to make more complex things.</div><div>We must not be castrating but inviting and teaching.</div><div>After all, making mistakes is a good way to learn, we must not try to prevent that ;)</div><div>IMO the right answer is 4).<br></div>
</div><div><br></div><div>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.</div><div>Maybe Interval of Float has less value than Float, but it's a bit like saying that oranges have less value than citruses ;)</div><div>They have not much value in the core image, but you cannot presume they will never have.</div><div>Try to make a LogarithmicInterval without Float for example... Analysis of systems in frequency domain requires such species!</div><div>
</div><div><br></div><div>The dicussion I wanted to open was about 2) and 3).</div><div>In the past, some wanted to reduce the surprising behavior by masking the inexact nature of Float arithmetic</div><div>(round to nearest in the best case, uncontrolled accumulation of rounding errors in the worse one). <br></div><div>This was done by encoding arbitrary comparison thresholds in some methods.</div><div>But this lead to more surprising behavior in the end, and it is enforcing wrong expectations.</div><div>That's what I tried to document with the new failing tests.</div><div><br></div><div>So the first thing is that I wanted to remove those workarounds, and reveal the true nature of Float, not masking it.</div><div>They make things worse IMO.<br></div><div><br></div><div>The second thing is that there are other naive implementations of Interval methods that won't work with inexact arithmetic.</div><div>But with some care, we can rewrite those to also behave better with inexact. The question if it is worth or not.</div><div>It's a trade off between complexity and utility.<br></div><div>That's why it is in the inbox, and we can decide that they are nice to have or overkill for too few value.</div><div>We can also postpone the decision with known failures, fix later, or delegate to an external package...<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 13 sept. 2019 à 10:26, Fabio Niephaus <<a href="mailto:lists@fniephaus.com">lists@fniephaus.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 13, 2019 at 9:57 AM Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>> wrote:<br>
><br>
><br>
> > On 13.09.2019, at 08:50, Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Thu, 12 Sep 2019 at 1:02 am, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> > "An Interval reversed is generally an Interval, except when made of Float."<br>
> > Should ReversedInterval be renamed to ReversedFloatInterval then?<br>
> ><br>
> > +1<br>
> ><br>
> > Interval was designed for Integers only. IMO, it should be copied to a separate class, FloatInterval, to implement this capability.<br>
> ><br>
> > 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?<br>
> ><br>
><br>
> I don't see why supporting<br>
><br>
> 2.4 to: 4.5<br>
><br>
> would be a bad idea. At least, it has a proper mathematical meaning.<br>
> Question is, whether just<br>
><br>
> (1.0 to: 3.0) includes: 2.5<br>
><br>
> should be true or also<br>
><br>
> (1 to: 3) includes: 2.5<br>
><br>
> :D<br>
<br>
I didn't say it's a bad idea, I wanted to know if someone actually<br>
needs it right now. If not, I'd just flag this as a "nice to have"<br>
feature we could support in a future release, but not the one we are<br>
working on at the moment.<br>
<br>
Fabio<br>
<br>
><br>
> > Fabio<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Nonetheless, this seems to fix #testIntervalOfFloatLast and<br>
> > #testIntervalOfFloatReversed of IntervalTest. Do we want to integrate<br>
> > this proposal or shall we mark these two tests as expected failures?<br>
> ><br>
> > Fabio<br>
> ><br>
> ><br>
> ><br>
><br>
><br>
><br>
<br>
</blockquote></div>