On 29 Jun 2014 05:48, "H. S. Teoh via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On Sat, Jun 28, 2014 at 08:41:24PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > > On 6/28/14, 6:02 PM, Tofu Ninja wrote: > [...] > > >I think this thread needs to refocus on the main point, getting > > >math overloads for float and double and how to mitigate any > > >problems that might arise from that. > > > > Yes please. -- Andrei > > Let's see the PR! >
I've already raised one (already linked in this thread). More to come! > And while we're on the topic, what about working on making std.math > CTFE-able? So far, CTFE simply doesn't support fundamental > floating-point operations like isInfinity, isNaN, signbit, to name a > few, because CTFE does not allow accessing the bit representation of > floating-point values. 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. > This is a big disappointment for me -- it defeats > the power of CTFE by making it unusable if you want to use it to > generate pre-calculated tables of values. > > Perhaps we can introduce some intrinsics for implementing these > functions so that they work both in CTFE and at runtime? > > https://issues.dlang.org/show_bug.cgi?id=3749 > 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. Once CTFE supports that, it won't be difficult to get std.math to be CTFE-certified. :) > Thanks to Iain's hard work on std.math, now we have software > implementations for all(?) the basic math functions, so in theory they > should be CTFE-able -- except that some functions require access to the > floating-point bit representation, which CTFE doesn't support. All it > takes is to these primitives, and std.math will be completely CTFE-able > -- a big step forward IMHO. > 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. 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) There should be a bug report somewhere that I outlined the exact steps in. Regards Iain.
