Why don't we switch to C like floating pointed arithmetic instead of automatic expansion to reals?

[Walter Bright via Digitalmars-d]

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?