Am Thu, 12 May 2016 08:55:52 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 5/12/2016 3:30 AM, Manu via Digitalmars-d wrote:
> > If you're set on a warning, at least make the warning recommend down-casting the higher precision term to the lower precision?
> 
> Yes, of course. I believe error messages should suggest corrective action.

Because of afore mentioned difference between cast(float)1.30 and 1.30f, the correct action for the original case is to suffix the literal with 'f'. That gives you the correct number to compare to.

-- 
Marco

Am Thu, 12 May 2016 09:03:58 -0400
schrieb Steven Schveighoffer <schveiguy@yahoo.com>:

> Not taking one side or another on this, but due to D doing everything with reals, this is already the case.
> 
> -Steve

As far as I have understood the situation:
- FPU instructions are inaccurate
- FPU is typically set to highest precision (80-bit)
  to give accurate float/double results
- SSE instructions yield accurately rounded results
- Need for 80 bits greatly reduced with SSE
- FPU deprectated on 64-bit x86
- Results of FPU and SSE math differ
- Compiler writers discordant
   GCC: compiler switch for SSE or FPU, SSE default
   DMD: FPU only
- Unless CTFE uses soft-float implementation, depending on
  compiler and flags used to compile a D compiler, resulting
  executable produces different CTFE floating-point results

-- 
Marco

On 5/12/2016 4:32 PM, Marco Leise wrote:
> - Unless CTFE uses soft-float implementation, depending on
>   compiler and flags used to compile a D compiler, resulting
>   executable produces different CTFE floating-point results

I've actually been thinking of writing a 128 bit float emulator, and then using that in the compiler internals to do all FP computation with.

It's not a panacea, as it won't change how things work in the back ends, nor will it change what happens at runtime, but it means the front end will give portable, consistent results.

On Friday, 13 May 2016 at 01:03:57 UTC, Walter Bright wrote:
> I've actually been thinking of writing a 128 bit float emulator, and then using that in the compiler internals to do all FP computation with.
>
> It's not a panacea, as it won't change how things work in the back ends, nor will it change what happens at runtime, but it means the front end will give portable, consistent results.

And be 20x slower than hardware floats. Is it really worth it?

On Friday, 13 May 2016 at 03:18:05 UTC, Jack Stouffer wrote:
> On Friday, 13 May 2016 at 01:03:57 UTC, Walter Bright wrote:
>> I've actually been thinking of writing a 128 bit float emulator, and then using that in the compiler internals to do all FP computation with.
>> [...]
>
> And be 20x slower than hardware floats. Is it really worth it?

Emulator is meant for computation during compilation only, so CTFE results are consistent across different compilers and compiler host hardware (IIUC).

-- Alexander

On 13 May 2016 at 11:03, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/12/2016 4:32 PM, Marco Leise wrote:
>>
>> - Unless CTFE uses soft-float implementation, depending on
>>   compiler and flags used to compile a D compiler, resulting
>>   executable produces different CTFE floating-point results
>
>
> I've actually been thinking of writing a 128 bit float emulator, and then using that in the compiler internals to do all FP computation with.

No. Do not.
I've worked on systems where the compiler and the runtime don't share
floating point precisions before, and it was a nightmare.
One anecdote, the PS2 had a vector coprocessor; it ran reduced (24bit
iirc?) float precision, code compiled for it used 32bits in the
compiler... to make it worse, the CPU also ran 32bits. The result was,
literals/constants, or float data fed from the CPU didn't match data
calculated by the vector unit at runtime (ie, runtime computation of
the same calculation that may have occurred at compile time to produce
some constant didn't match). The result was severe cracking and
visible/shimmering seams between triangles as sub-pixel alignment
broke down.
We struggled with this for years. It was practically impossible to
solve, and mostly involved workarounds.

I really just want D to use double throughout, like all the cpu's that run code today. This 80bit real thing (only on x86 cpu's though!) is a never ending pain.


> It's not a panacea, as it won't change how things work in the back ends, nor will it change what happens at runtime, but it means the front end will give portable, consistent results.

This sounds like designing specifically for my problem from above, where the frontend is always different than the backend/runtime. Please have the frontend behave such that it operates on the precise datatype expressed by the type... the backend probably does this too, and runtime certainly does; they all match.

On Friday, 13 May 2016 at 05:12:14 UTC, Manu wrote:
> No. Do not.
> I've worked on systems where the compiler and the runtime don't share
> floating point precisions before, and it was a nightmare.

Use reproducible cross platform IEEE754-2008 and use exact rational numbers. All other representations are just painful. Nothing wrong with supporting 16, 32, 64 and 128 bit, but stick to the reproducible standard. If people want "non-reproducible fast math", then they should specify it.

On 13 May 2016 at 07:12, Manu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 13 May 2016 at 11:03, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 5/12/2016 4:32 PM, Marco Leise wrote:
>>>
>>> - Unless CTFE uses soft-float implementation, depending on
>>>   compiler and flags used to compile a D compiler, resulting
>>>   executable produces different CTFE floating-point results
>>
>>
>> I've actually been thinking of writing a 128 bit float emulator, and then using that in the compiler internals to do all FP computation with.
>
> No. Do not.
> I've worked on systems where the compiler and the runtime don't share
> floating point precisions before, and it was a nightmare.

I have some bad news for you about CTFE then. This already happens in DMD even though float is not emulated.  :-o

On 5/12/2016 8:18 PM, Jack Stouffer wrote:
> And be 20x slower than hardware floats. Is it really worth it?

I seriously doubt the slowdown would be measurable, as the number of float ops the compiler performs is insignificant.

On 5/12/2016 10:12 PM, Manu via Digitalmars-d wrote:
> No. Do not.
> I've worked on systems where the compiler and the runtime don't share
> floating point precisions before, and it was a nightmare.
> One anecdote, the PS2 had a vector coprocessor; it ran reduced (24bit
> iirc?) float precision, code compiled for it used 32bits in the
> compiler... to make it worse, the CPU also ran 32bits. The result was,
> literals/constants, or float data fed from the CPU didn't match data
> calculated by the vector unit at runtime (ie, runtime computation of
> the same calculation that may have occurred at compile time to produce
> some constant didn't match). The result was severe cracking and
> visible/shimmering seams between triangles as sub-pixel alignment
> broke down.
> We struggled with this for years. It was practically impossible to
> solve, and mostly involved workarounds.

I understand there are some cases where this is needed, I've proposed intrinsics for that.


> I really just want D to use double throughout, like all the cpu's that
> run code today. This 80bit real thing (only on x86 cpu's though!) is a
> never ending pain.

It's 128 bits on other CPUs.


> This sounds like designing specifically for my problem from above,
> where the frontend is always different than the backend/runtime.
> Please have the frontend behave such that it operates on the precise
> datatype expressed by the type... the backend probably does this too,
> and runtime certainly does; they all match.

Except this never happens anyway.