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

[Ilya Yaroshenko via Digitalmars-d]

On Friday, 5 August 2016 at 09:24:49 UTC, Walter Bright wrote:
> On 8/5/2016 12:43 AM, Ilya Yaroshenko wrote:
>> You are wrong that there are far fewer of those cases. This is 
>> naive point of
>> view. A lot of netlib math functions require exact IEEE 
>> arithmetic. Tinflex
>> requires it. Python C backend and Mir library require exact 
>> IEEE arithmetic.
>> Atmosphere package requires it, Atmosphere is used as 
>> reference code for my
>> publication in JMS, Springer. And the most important case: no 
>> one top scientific
>> laboratory will use a language without exact IEEE arithmetic 
>> by default.
>
> A library has a lot of algorithms in it, a library requiring 
> exact IEEE arithmetic doesn't mean every algorithm in it does. 
> None of the Phobos math library functions require it, and as 
> far as I can tell they are correct out to the last bit.

No. For example std.math.log requires it! But you don't care 
about other compilers which not use yl2x and about making it 
template (real version slows down code for double and float).

> And besides, all these libraries presumably work, or used to 
> work, on the x87, which does not provide exact IEEE arithmetic 
> for intermediate results without a special setting, and that 
> setting substantially slows it down.

x87 FPU is deprecated. We have more significant performance 
issues with std.math. For example, it is x87 oriented, is slows 
down the code for double and float. Many functions are not 
inlined. This 2 are real performance problems.

> By netlib do you mean the Cephes functions? I've used them, and 
> am not aware of any of them that require reduced precision.

Yes and many of its functions requires IEEE. For example log2.c 
for doubles:
	z = x - 0.5;
	z -= 0.5;
	y = 0.5 * x  + 0.5;
This code requires IEEE. The same code appears in our std.math :P