polyml 5.5.2-4

[James Clarke]

Hi Gianfranco,

>> I quickly looked at the test
>> setRoundingMode(TO_POSINF);
>> check(getRoundingMode() = TO_POSINF);
>> val pos = 1.0/3.0;
>> check(pos * 3.0 > 1.0);
>> val neg = ~1.0/3.0;
>> check(neg * 3.0 > ~1.0);
>> 
>> 
>> well, I'm not sure the test is correct, I mean, you might have the exact 1.0 value too
> 
> 1/3 can’t be represented exactly, so when rounding to +Inf, you get a little bit more than 1/3. 3 can be represented exactly, so 3 * 1/3 is a little more than 1, and since the rounding mode is set to +Inf it should therefore round to a little over 1. I’m pretty sure the test is correct; certainly it works on every other supported platform.

I just wrote a test program (modified from when I was debugging and fixing qemu’s ppc rounding mode...):

    #include <fenv.h>
    #include <stdio.h>

    int main(int argc, char **argv) {
        int ret;
        ret = fegetround();
        printf("Current rounding: %d\n", ret);
        ret = fesetround(FE_UPWARD);
        printf("Setting to FE_UPWARD (%d): %d\n", FE_UPWARD, ret);
        ret = fegetround();
        printf("Current rounding: %d\n", ret);
        double one = 1.0;
        double three = 3.0;
        double third = one / three;
        printf("1.0 / 3.0: %.18f\n", third);
        double aboutOne = third * 3.0;
        printf("1.0 / 3.0 * 1.0: %.18f\n", aboutOne);
        ret = fegetround();
        printf("Current rounding: %d\n", ret);
        return 0;
    }

On amd64:

    Current rounding: 0
    Setting to FE_UPWARD (2048): 0
    Current rounding: 2048
    1.0 / 3.0: 0.333333333333333371
    1.0 / 3.0 * 1.0: 1.000000000000000223
    Current rounding: 2048

On armel:

    Current rounding: 0
    Setting to FE_UPWARD (4194304): 0
    Current rounding: 4194304
    Current rounding: 4194304
    1.0 / 3.0: 0.333333333333333315
    1.0 / 3.0 * 1.0: 1.000000000000000000

Besides FE_UPWARD having a different value (given that it’s platform-specific), armel calculates 1.0 / 3.0 as 0.333333333333333315, which is wrong for FE_UPWARD (but correct for FE_NEAREST), and I imagine there are similar issues for the other rounding modes (other than FE_NEAREST). Any thoughts as to what could be going on?

Regards,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20160125/7571e9fa/attachment.sig>