I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.

This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?

Thanks
Iain.

On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
> I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
>
> This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
>
> Thanks
> Iain.

Commit reference:
https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395

Am Fri, 16 Aug 2013 18:38:08 +0200
schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:

> On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
> > I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
> >
> > This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
> >
> > Thanks
> > Iain.
> 
> Commit reference: https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395
> 

Compiling phobos fails with this message:

../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static assert  "Only 80-bit and 96-bit reals are supported by lrint()"

real is 64 bit on most (all?) ARM machines.


I also started the compiler test suite some time ago but it will take some more time till it's finished.

On 18 August 2013 09:54, Johannes Pfau <nospam@example.com> wrote:
> Am Fri, 16 Aug 2013 18:38:08 +0200
> schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:
>
>> On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
>> > I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
>> >
>> > This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
>> >
>> > Thanks
>> > Iain.
>>
>> Commit reference: https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395
>>
>
> Compiling phobos fails with this message:
>
> ../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static assert  "Only 80-bit and 96-bit reals are supported by lrint()"
>
> real is 64 bit on most (all?) ARM machines.
>
>
> I also started the compiler test suite some time ago but it will take some more time till it's finished.


OK, fixed that: https://github.com/D-Programming-GDC/GDC/commit/196fdf37b3b3e7d25b09a1cac1f30e313274e6e5

:o)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 18 August 2013 15:27, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 18 August 2013 09:54, Johannes Pfau <nospam@example.com> wrote:
>> Am Fri, 16 Aug 2013 18:38:08 +0200
>> schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:
>>
>>> On Friday, 16 August 2013 at 16:33:17 UTC, Iain Buclaw wrote:
>>> > I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
>>> >
>>> > This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
>>> >
>>> > Thanks
>>> > Iain.
>>>
>>> Commit reference: https://github.com/D-Programming-GDC/GDC/commit/a4e0b2928b92fae3448ec541f8ec86ffea4c8395
>>>
>>
>> Compiling phobos fails with this message:
>>
>> ../../../../gcc-4.8.1/libphobos/src/std/math.d:3264: Error: static assert  "Only 80-bit and 96-bit reals are supported by lrint()"
>>
>> real is 64 bit on most (all?) ARM machines.
>>
>>
>> I also started the compiler test suite some time ago but it will take some more time till it's finished.
>
>
> OK, fixed that: https://github.com/D-Programming-GDC/GDC/commit/196fdf37b3b3e7d25b09a1cac1f30e313274e6e5
>

Made the tiniest amendment: https://github.com/D-Programming-GDC/GDC/commit/05b6e48d5d7736c7bcaeff9d71c807bcd0132dca


Should be all good after some preliminary testing vs __builtin_lrintl() results.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Am Fri, 16 Aug 2013 18:33:14 +0200
schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:

> I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
> 
> This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
> 
> Thanks
> Iain.

I found a bug in the floor implementation for 64 bit reals:

int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
The constants are wrong: At least 0x7ff must be 0x7ff0.

(Remember, the 16 bits are s|eeeeeeeeeee|???? )

However, the results are still wrong and I don't really understand how that equation should work.

The 'naive' and working way to write this is
--------
int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
--------

I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then the result is still left-shifted by 4 and needs to be right-shifted:
-------
int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
-------

is also working, but I don't know what's the advantage of this version.

floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?

On 20 August 2013 10:07, Johannes Pfau <nospam@example.com> wrote:
> Am Fri, 16 Aug 2013 18:33:14 +0200
> schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:
>
>> I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
>>
>> This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
>>
>> Thanks
>> Iain.
>
> I found a bug in the floor implementation for 64 bit reals:
>
> int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
> The constants are wrong: At least 0x7ff must be 0x7ff0.
>
> (Remember, the 16 bits are s|eeeeeeeeeee|???? )
>
> However, the results are still wrong and I don't really understand how that equation should work.
>
> The 'naive' and working way to write this is
> --------
> int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
> --------
>
> I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then the result is still left-shifted by 4 and needs to be right-shifted:
> -------
> int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
> -------
>
> is also working, but I don't know what's the advantage of this version.
>
> floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?
>
>

Thanks, it should be:

---
int exp = ((vu[F.EXPPOS_SHORT] >> 4) & 0x7ff) - 0x3ff;



I'll raise a pull to fix as my pull into phobos got merged this morning. :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 20 August 2013 10:57, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 20 August 2013 10:07, Johannes Pfau <nospam@example.com> wrote:
>> Am Fri, 16 Aug 2013 18:33:14 +0200
>> schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:
>>
>>> I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
>>>
>>> This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
>>>
>>> Thanks
>>> Iain.
>>
>> I found a bug in the floor implementation for 64 bit reals:
>>
>> int exp = (vu[F.EXPPOS_SHORT] & 0x7ff) - 0x3ff;
>> The constants are wrong: At least 0x7ff must be 0x7ff0.
>>
>> (Remember, the 16 bits are s|eeeeeeeeeee|???? )
>>
>> However, the results are still wrong and I don't really understand how that equation should work.
>>
>> The 'naive' and working way to write this is
>> --------
>> int exp = ((vu[F.EXPPOS_SHORT] & 0x7ff0) >> 4) -1023;
>> --------
>>
>> I assume 0x3ff should be changed to 0x3ff0 which is 1023 << 4. But then the result is still left-shifted by 4 and needs to be right-shifted:
>> -------
>> int exp = (((vu[F.EXPPOS_SHORT] & 0x7ff0)) - 0x3ff0) >> 4;
>> -------
>>
>> is also working, but I don't know what's the advantage of this version.
>>
>> floatTraits also has EXPBIAS = 0x3f_e_0? How was that value obtained?
>>
>>
>
> Thanks, it should be:
>
> ---
> int exp = ((vu[F.EXPPOS_SHORT] >> 4) & 0x7ff) - 0x3ff;
>
>
>
> I'll raise a pull to fix as my pull into phobos got merged this morning. :o)
>

Pull:  http://j.mp/171CJl7



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Am Fri, 16 Aug 2013 18:33:14 +0200
schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:

> I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
> 
> This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
> 
> Thanks
> Iain.

I did a complete pass through the std.math unit tests. As soon as these issues are addressed, std.math unit tests should succeed on ARM:

Some more small bugs:
(see also
https://github.com/jpf91/GDC/commit/63890f543f60d55bad3dc6bced4d14bc159128e6
)

==========================
In isInfinity we should check for 11 binary '1's, not 12 right?

        return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
            == 0x7FF8_0000_0000_0000;

=>

        return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
            == 0x7FF0_0000_0000_0000;
==========================
In frexp:

vu[F.EXPPOS_SHORT] = cast(ushort)((0x8000 & vu[F.EXPPOS_SHORT]) |
0x3FE0);

=>

vu[F.EXPPOS_SHORT] = cast(ushort)((0x800F & vu[F.EXPPOS_SHORT]) |
0x3FE0);
==========================
Why is ex in frexp unsigned? This line fails because of this:
exp = (ex - 0x3FE0) >> 4;
here ex is always zero so the subtraction doesn't work as ex is
unsigned
==========================




Failing unit tests:
(see also
https://github.com/jpf91/GDC/commit/0d7b3feafdb3629aeccb44b2a28d3344c7675d2f
)
==========================
assert(exp2(0.5L)== SQRT2); //Only 52 mantissa bits are equal
==========================
real n = frexp(0x1p-16384L, x); //value is too small to fit in double
==========================

real y = vals[i][1];
real z = vals[i][2];
real h = hypot(x, y);
For some values only 52 mantissa bits are equal
==========================
assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
//Only 52 mantissa bits are equal
==========================
assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
Fails in exactly the same way on dpaste:
http://dpaste.dzfl.pl/4c794ab8
==========================
assert(pow(x, neg3) == 1 / (x * x * x));
//Only 52 mantissa bits are equal
==========================
assert(feqrel(real.min_normal / 8, real.min_normal / 17) == 3);
//feqrel returns spectacular -732 equal bits. But it's the same on x86
//with double so it's a bug in the test case. I can't fix it as I
//don't know what it's supposed to do

On 22 August 2013 20:45, Johannes Pfau <nospam@example.com> wrote:
> Am Fri, 16 Aug 2013 18:33:14 +0200
> schrieb "Iain Buclaw" <ibuclaw@ubuntu.com>:
>
>> I've pushed in pure implementations of functions in std.math, removing the workaround in core.stdc.math.
>>
>> This passes for x64/x32. Can any ARM testers please report any problems causecd by this update?
>>
>> Thanks
>> Iain.
>
> I did a complete pass through the std.math unit tests. As soon as these issues are addressed, std.math unit tests should succeed on ARM:
>
> Some more small bugs:
> (see also
> https://github.com/jpf91/GDC/commit/63890f543f60d55bad3dc6bced4d14bc159128e6
> )
>
> ==========================
> In isInfinity we should check for 11 binary '1's, not 12 right?
>
>         return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
>             == 0x7FF8_0000_0000_0000;
>
> =>
>
>         return ((*cast(ulong *)&x) & 0x7FFF_FFFF_FFFF_FFFF)
>             == 0x7FF0_0000_0000_0000;
> ==========================
> In frexp:
>
> vu[F.EXPPOS_SHORT] = cast(ushort)((0x8000 & vu[F.EXPPOS_SHORT]) |
> 0x3FE0);
>
> =>
>
> vu[F.EXPPOS_SHORT] = cast(ushort)((0x800F & vu[F.EXPPOS_SHORT]) |
> 0x3FE0);
> ==========================
> Why is ex in frexp unsigned? This line fails because of this:
> exp = (ex - 0x3FE0) >> 4;
> here ex is always zero so the subtraction doesn't work as ex is
> unsigned
> ==========================
>
>

Make Don aware of this. But looks ok to me.  Does it fail in the same way for double on x86/x86_64?


>
>
> Failing unit tests:
> (see also
> https://github.com/jpf91/GDC/commit/0d7b3feafdb3629aeccb44b2a28d3344c7675d2f
> )
> ==========================
> assert(exp2(0.5L)== SQRT2); //Only 52 mantissa bits are equal
> ==========================
> real n = frexp(0x1p-16384L, x); //value is too small to fit in double
> ==========================
>
> real y = vals[i][1];
> real z = vals[i][2];
> real h = hypot(x, y);
> For some values only 52 mantissa bits are equal
> ==========================
> assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
> //Only 52 mantissa bits are equal
> ==========================
> assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
> Fails in exactly the same way on dpaste:
> http://dpaste.dzfl.pl/4c794ab8
> ==========================
> assert(pow(x, neg3) == 1 / (x * x * x));
> //Only 52 mantissa bits are equal
> ==========================
> assert(feqrel(real.min_normal / 8, real.min_normal / 17) == 3);
> //feqrel returns spectacular -732 equal bits. But it's the same on x86
> //with double so it's a bug in the test case. I can't fix it as I
> //don't know what it's supposed to do

These are problems that std/math does assume 80bit precision in most of it's tests.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';