<p dir="ltr"><br>
On 29 Jun 2014 05:48, "H. S. Teoh via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On Sat, Jun 28, 2014 at 08:41:24PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:<br>
> > On 6/28/14, 6:02 PM, Tofu Ninja wrote:<br>
> [...]<br>
> > >I think this thread needs to refocus on the main point, getting<br>
> > >math overloads for float and double and how to mitigate any<br>
> > >problems that might arise from that.<br>
> ><br>
> > Yes please. -- Andrei<br>
><br>
> Let's see the PR!<br>
></p>
<p dir="ltr">I've already raised one (already linked in this thread).</p>
<p dir="ltr">More to come!</p>
<p dir="ltr">> And while we're on the topic, what about working on making std.math<br>
> CTFE-able? So far, CTFE simply doesn't support fundamental<br>
> floating-point operations like isInfinity, isNaN, signbit, to name a<br>
> few, because CTFE does not allow accessing the bit representation of<br>
> floating-point values.</p>
<p dir="ltr">As it stands, as soon as the above mentioned PR for Phobos is merged, isNaN and isInfinite on float and double types will be CTFE-able. However that depends on whether or not float->int painting will be replaced with a union.</p>

<p dir="ltr">> This is a big disappointment for me -- it defeats<br>
> the power of CTFE by making it unusable if you want to use it to<br>
> generate pre-calculated tables of values.<br>
><br>
> Perhaps we can introduce some intrinsics for implementing these<br>
> functions so that they work both in CTFE and at runtime?<br>
><br>
>         <a href="https://issues.dlang.org/show_bug.cgi?id=3749">https://issues.dlang.org/show_bug.cgi?id=3749</a><br>
></p>
<p dir="ltr">CTFE support for accessing basic types in unions - as in painting between all kinds of scalar types, with special support for static arrays (via vectors) should be all that is required.</p>
<p dir="ltr">Once CTFE supports that, it won't be difficult to get std.math to be CTFE-certified. :)</p>
<p dir="ltr">> Thanks to Iain's hard work on std.math, now we have software<br>
> implementations for all(?) the basic math functions, so in theory they<br>
> should be CTFE-able -- except that some functions require access to the<br>
> floating-point bit representation, which CTFE doesn't support. All it<br>
> takes is to these primitives, and std.math will be completely CTFE-able<br>
> -- a big step forward IMHO.<br>
></p>
<p dir="ltr">The original goal was making std.math non-asm implementations *genuinely* pure/nothrow/@safe for GDC x86, and for other ports like ARM, SPARC so LDC benefits also.</p>
<p dir="ltr">Andrei was the one who sold me on the idea if making them CTFE-able.  However,  I stopped just short of that goal because of this missing feature of DMD - though I did implement it in GDC as proof of concept that it is possible (code not actually published anywhere)</p>

<p dir="ltr">There should be a bug report somewhere that I outlined the exact steps in. </p>
<p dir="ltr">Regards<br>
Iain. <br>
</p>