<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 19, 2014 at 5:49 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">With the defaults the code is never worse than it is forced to be right now and users do not need to create CPP blocked code to work around this addition.</div>
</blockquote><div><br></div><div>I usually like defaults, and avoiding CPP is good, however with the defaults users will expect better code than they get. Â We aren't doing anyone any favors by introducing the possibility of silent floating-point precision loss from 'exp1m'. Â An "error" default would be better.<br>
</div><div><br></div><div>Besides, the code would be worse than it's forced to be now. Â At least now users who care about this run headlong into the issue. Â If we provide exp1m and log1p, users who use those functions should get the advertised behavior, not loss of precision (I realize not all types would lose precision, but some will).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Without the defaults this becomes a much bigger request, as I'd be asking _every_ author of Floating to add CPP to their packages for a feature they never heard of and probably will never use, and in that situation we'd have to export it from Prelude.</div>
</div></blockquote><div><br></div><div>It's perfectly fine to leave some methods blank; IMHO the resulting run-time error is better than an incorrect default. Â Plus, it's useful for library authors to know that the class has changed; if a default is provided everything will build properly and there is no compile-time indication that library authors should adjust their code.</div>
<div><br></div><div>Originally I was +1 for everything except the defaults, but I'm reconsidering. Â If this is something that most Floating instance authors don't know about and probably won't ever use, do these functions really belong in that class? Â Why not make a separate class for fused algorithms?</div>
<div><br></div><div>John L.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><span class=""><font color="#888888"><div><br></div><div>-Edward</div></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 19, 2014 at 5:42 AM, Scott Turner <span dir="ltr"><<a href="mailto:2haskell@pkturner.org" target="_blank">2haskell@pkturner.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div>
    <div>On 2014-04-17 15:08, Edward Kmett
      wrote:<br>
    </div>
    </div><blockquote type="cite"><div>
      <div>
        <div>On Thu, Apr 17, 2014 at 2:48 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:schlepptop@henning-thielemann.de" target="_blank">schlepptop@henning-thielemann.de</a>></span>
          wrote:<br>
        </div>
      </div>
      </div><div><div class="gmail_extra">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I
            think one should add default implementations. They don't
            have an numerical advantage but they save programmers from
            code breakage.</blockquote>
          <div> </div>
          <div>
            <div>I included the default definitions in code snippet in
              the proposal, so user code that remains unaware of them
              would be unaffected, while packages like compensated, or a
              wrapper around libqd could implement them as needed.
              <div>
                <br>
              </div>
              <div>
                <div style="font-size:12.727272033691406px;font-family:arial,sans-serif"><font face="courier new, monospace">expm1 :: Floating a
                    => a -> a<br>
                    expm1 x = exp x - 1</font></div>
                <div style="font-size:12.727272033691406px;font-family:arial,sans-serif">
                  <font face="courier new, monospace"><br>
                  </font></div>
                <div style="font-size:12.727272033691406px;font-family:arial,sans-serif"><font face="courier new, monospace">log1p :: Floating a
                    => a -> a<br>
                    log1p x = log (1 + x)</font></div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </div></blockquote>
    On the contrary, code that explicitly uses these functions is likely
    to need the precision. Defaults would cause subtle breakage.<span><font color="#888888"><br>
    <br>
    -- Scott<br>
  </font></span></div>

</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div></div>