phobos commit, revision 2157


user: Don Clugston

msg:
D implementation of pow(), avoiding dependence on C. The big benefit is that pow() is now pure, but also improved accuracy of corner cases.
All math functions are now @safe or @trusted, and all are pure nothrow except where implemented by C functions.

http://www.dsource.org/projects/phobos/changeset/2157

On Thu, 2010-11-11 at 17:52 -0500, dsource.org wrote:
> phobos commit, revision 2157
> 
> 
> user: Don Clugston
> 
> msg:
> D implementation of pow(), avoiding dependence on C. The big benefit is that pow() is now pure, but also improved accuracy of corner cases.
> All math functions are now @safe or @trusted, and all are pure nothrow except where implemented by C functions.
> 
> http://www.dsource.org/projects/phobos/changeset/2157


This is awesome!  I have one question, though:  It seems you've made
this work primarily by replacing the call to core.stdc.math.powl() by a
call to exp2(yl2x()), but this is enclosed in a version(INLINE_YL2X)
block.  And this version only seems to be enabled on DMD.  Won't this
cause problems when GDC catches up to DMD, which (rumor has it) isn't
too far off?

-Lars

On 12 November 2010 08:27, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> On Thu, 2010-11-11 at 17:52 -0500, dsource.org wrote:
>> phobos commit, revision 2157
>>
>>
>> user: Don Clugston
>>
>> msg:
>> D implementation of pow(), avoiding dependence on C. The big benefit is that pow() is now pure, but also improved accuracy of corner cases.
>> All math functions are now @safe or @trusted, and all are pure nothrow except where implemented by C functions.
>>
>> http://www.dsource.org/projects/phobos/changeset/2157
>
>
> This is awesome! ?I have one question, though: ?It seems you've made
> this work primarily by replacing the call to core.stdc.math.powl() by a
> call to exp2(yl2x()), but this is enclosed in a version(INLINE_YL2X)
> block. ?And this version only seems to be enabled on DMD. ?Won't this
> cause problems when GDC catches up to DMD, which (rumor has it) isn't
> too far off?

That's an issue for GDC. If INLINE_YL2X isn't defined, it will fall
back to a call to C's pow. This gives the correct results, but it will
fail to compile, because pow isn't pure.
In fact, exactly the same issue applies if D_INLINEASM_X86 isn't defined.
Their simple short-term option would be to lie about the purity of the
C math functions (in core.stdc.math).