<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 3:46 PM, Matt Keenan <span dir="ltr"><<a href="mailto:matt.keenan@oracle.com" target="_blank">matt.keenan@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Just wanted to report a SPARC specific issue with Erlang.</blockquote></div><br></div><div class="gmail_extra">I'm not entirely convinced it is with Erlang, so consider this inquiry. Sparc uses a 64bit wide internal representation of IEEE 754 double binary fp numbers, whereas the internal representation in x86 is 80 bit wide (due to that being the width of the 387 coprocessor back in the day).<br><br></div><div class="gmail_extra">exp(-1162.102134881488)<br><br></div><div class="gmail_extra">is 2.02048... x 10^-505 which is smaller than the smallest representable float. The limit, as x -> -infty is 0 for exp(_), so one would argue that the correct output in this case is 0.0.<br><br></div><div class="gmail_extra">Erlang simply calls into the C math.h exp function for this, but it does FP exception checks around the point. One way to figure out what happens would be to get hold of a SPARC machine, write a simple C program doing the same and verifying that the SPARC compilers agrees on that one with an x86 program. I could imagine some way it provokes an FP exception on the SPARC architecture, but not on x86 due to the extra bits x86 has in internal encoding width.<br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">-- <br><div class="gmail_signature">J.</div>
</div></div>