<div dir="ltr"><div>I think you may have interpreted me as saying something I didn't try to say.</div><div><br></div>To clarify, what I was indicating was that during the compilation of your 'DodgyFloat' supplying package a bunch of warnings about unimplemented methods would scroll by.<div>
<br></div><div>-Edward</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 23, 2014 at 8:06 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</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>This does work.</div><div><br></div>MINIMAL is checked based on the definitions supplied locally in the instance, not based on the total definitions that contribute to the instance.<div>
<br></div><div>Otherwise we couldn't have the very poster-chid example of this from the documentation for MINIMAL</div>
<div><pre style="border-width:1px;border-style:solid;padding:0.3em;color:maroon">class Eq a where
(==) :: a -> a -> Bool
(/=) :: a -> a -> Bool
x == y = not (x /= y)
x /= y = not (x == y)
{-# MINIMAL (==) | (/=) #-}</pre></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 23, 2014 at 7:57 PM, John Lato <span dir="ltr"><<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</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">There's one part of this alternative proposal I don't understand:<div class="gmail_extra"><br><div class="gmail_quote">
<div>On Mon, Apr 21, 2014 at 5:04 AM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</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><br></div>
<div>* If you can compile sans warnings you have nothing to fear. If you do get warnings, you can know precisely what types will have degraded back to the old precision at <b>compile</b> time, not runtime.</div></div></blockquote>
<div><br></div></div><div>I don't understand the mechanism by which this happens (maybe I'm misunderstanding the MINIMAL pragma?). If a module has e.g.</div><div><br></div><div>> import DodgyFloat (DodgyFloat) -- defined in a 3rd-party package, doesn't implement log1p etc.</div>
<div>></div><div>> x = log1p 1e-10 :: DodgyFloat</div><div><br></div><div>I don't understand why this would generate a warning (i.e. I don't believe it will generate a warning). So the user is in the same situation as with the original proposal.</div>
<div><br></div><div>John L.</div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">
On Mon, Apr 21, 2014 at 5:24 AM, Aleksey Khudyakov <span dir="ltr"><<a href="mailto:alexey.skladnoy@gmail.com" target="_blank">alexey.skladnoy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On 21 April 2014 09:38, John Lato <<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>> wrote:<br>
> I was just wondering, why not simply numerically robust algorithms as<br>
> defaults for these functions? No crashes, no errors, no loss of precision,<br>
> everything would just work. They aren't particularly complicated, so the<br>
> performance should even be reasonable.<br>
><br>
</div></div>I think it's best option. log1p and exp1m come with guarantees<br>
about precision. log(1+p) default makes it impossible to depend in such<br>
guarantees. They will silenly give wrong answer<br>
</blockquote></div><br></div>
</div></div></blockquote></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>