Thanks for finding these.

On 8/5/2016 3:22 AM, Ilya Yaroshenko wrote:
1. https://www.python.org/ftp/python/3.5.2/Python-3.5.2.tgz
mathmodule.c, math_fsum has comment:
   Depends on IEEE 754 arithmetic guarantees and half-even rounding.
The same algorithm also available in Mir. And it does not work with 32 bit DMD.

2. sum_kbn in https://github.com/JuliaLang/julia/blob/master/base/reduce.jl
requires ieee arithmetic. The same algorithm also available in Mir.

I agree that the typical summation algorithm suffers from double rounding. But that's one algorithm. I would appreciate if you would review http://dlang.org/phobos/std_algorithm_iteration.html#sum to ensure it doesn't have this problem, and if it does, how we can fix it.


3. http://www.netlib.org/cephes/
See log2.c for example:
    z = x - 0.5;
    z -= 0.5;
    y = 0.5 * x  + 0.5;
This code requires IEEE. And you can found it in Phobos std.math

It'd be great to have a value for x where it fails, then we can add it to the unittests and ensure it is fixed.


4. Mir has 5 types of summation, and 3 of them requires IEEE.

See above for summation.


5. Tinflex requires IEEE arithmetic because extended precision may force
algorithm to choose wrong computation branch. The most significant part of
original code was written in R, and the scientists who create this algorithm did
not care about non IEEE compilers at all.

6. Atmosphere requires IEEE for may functions such as
https://github.com/9il/atmosphere/blob/master/source/atmosphere/math.d#L616
Without proper IEEE rounding the are not guarantee that this functions will 
stop.

7. The same true for real world implementations of algorithms presented in
Numeric Recipes, which uses various series expansion such as for Modified Bessel
Function.

I hear you. I'd like to explore ways of solving it. Got any ideas?

Reply via email to