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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Reply via email to