<div dir="ltr">.... how would you have an implementation of finite precision floating point that has the "expected" exact algebraic laws for * and +?<div><br></div><div>I would argue that Float and Double do satisfy a form of the standard algebric laws where equality is approximate. </div><div><br></div><div>eg  (a+(b+c)) - ((a+b)+c) <= \epsilon, where epsilon  is some constant multiple of max(ulp(a),ulp(b),ulp(c)).</div><div>(a similar idea applies to pretty much any other algebraic law you can state, such as distributivity etc)</div><div><br></div><div>I do think that it'd be useful if the RealFloat class provided an ulp function (unit of least precision), which is available as part of any IEEE compliant c float library.</div><div><br></div><div>there are MANY computable number represntations where the *exact* algebraic laws dont hold, but this *approximate* form which provides some notion of bounded forwards/backwards relative/absolute error bound guarantee in a particularly strong way.</div><div><br></div><div><br></div><div>i think we should figure out articulating laws that play nice for both the *exact* and *approximate* universes.  the</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 3, 2015 at 7:05 PM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div>On Sun, May 3, 2015 at 4:11 PM, Levent Erkok <<a href="mailto:erkokl@gmail.com" target="_blank">erkokl@gmail.com</a>> wrote:</div><div>   * Tikhon Jelvis suggested these functions should be put in a different class, which suggests that we're following IEEE754, and not some idealized model of numbers. I think this suggestion is spot on, and is very much in line with what I wanted to have.</div><div><br></div></span><div>This is very much in line with a suggestion I've been toying with for</div><div>a long time. Basically, we have three different ideas for how floats</div><div>should behave, and the current implementation isn't any of them. So</div><div>I've been thinking that we ought to deal with this by moving Float out</div><div>of Prelude - or at least large chunks of it.</div><div><br></div><div>The three different models are:</div><div><br></div><div>1) Real numbers. We aren't going to get those.</div><div><br></div><div>2) IEEE Floats. This is what we've got, except as noted, there are</div><div>   lots of things that come with this that we don't provide.</div><div><br></div><div>3) Floats that obey the laws of Num. We don't get that, mostly because</div><div>   getting #2 breaks things.</div><div><br></div><div>The breakage of #3 causes people creates behavior that's surprising -</div><div>at least to people who aren't familiar with IEEE Floats.</div><div><br></div><div>So the proposal I've been toying with was something along the lines of</div><div>breaking RealFloat up along class lines. Those classes where RealFloat</div><div>obeyed the class laws and IEEE Float behavior would stay in</div><div>RealFloat. The rest would move out, and could be gotten by importing</div><div>either Data.Float.IEEE or Data.Float.Num (or some such).</div><div><br></div><div>Ideally, this will leave enough floating point behavior in the Prelude</div><div>that doing simple calculations would just work - at least as well as</div><div>it ever did, anyway. When you start doing things that can currently</div><div>generate surprising results, you will need to import one of the two</div><div>options. Figuring out which one means there's a chance you'll also</div><div>figure out why you sometimes get those surprising results.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>       <mike</div><div><br></div></font></span></div></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>