www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Force usage of double (instead of higher precision)

reply Simon =?UTF-8?B?QsO8cmdlcg==?= <simon.buerger rwth-aachen.de> writes:
According to the standard (http://dlang.org/spec/float.html), the 
compiler is allowed to compute any floating-point statement in a 
higher precision than specified. Is there a way to deactivate 
this behaviour?

Context (reason why I need this): I am building a "double double" 
type, which essentially takes two 64-bit double-precision numbers 
to emulate a (nearly) quadruple-precision number. A simplified 
version looks something like this:

struct ddouble
{
     double high;
     double low;

     invariant
     {
         assert(high + low == high);
     }

     // ...implemententations of arithmetic operations...
}

Everything works fine at run-time, but if I declare a 
compile-time constant like

enum pi = ddouble(3.141592653589793116e+00, 
1.224646799147353207e-16);

the invariant fails because it is evaluated using 80-bit 
"extended precision" during CTFE. All arithmetic operations rely 
on IEEE-conform double-precision, so everything breaks down if 
the compiler decides to replace them with higher precision. I am 
currently using LDC on 64-bit-Linux if that is relevant.

(If you are interested in the "double double" type, take a look 
here:
https://github.com/BrianSwift/MetalQD
which includes a double-double and even quad-double 
implementation in C/C++/Fortran)
Jun 28
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:

 (If you are interested in the "double double" type, take a look 
 here:
 https://github.com/BrianSwift/MetalQD
 which includes a double-double and even quad-double 
 implementation in C/C++/Fortran)
Nice work can you re or dual license under the boost license ? I'd like to incorporate the qd type into newCTFE. As for your problems they can be worked around. by assigning every temporary to a variable. Which will enforce the discarding of precision.
Jun 28
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:
 As for your problems they can be worked around.
 by assigning every temporary to a variable.
 Which will enforce the discarding of precision.
Sorry for the misinformation! I was using the newCTFE fork which fixes this. Indeed you'll have no way to get rid of the excess precision except for creating a function per sub-expression.
Jun 28
parent reply Simon =?UTF-8?B?QsO8cmdlcg==?= <simon.buerger rwth-aachen.de> writes:
Thanks a lot for your comments.

On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:
 [...]

 Nice work can you re or dual license under the boost license ?
 I'd like to incorporate the qd type into newCTFE.
The original work is not mine but traces back to http://crd-legacy.lbl.gov/~dhbailey/mpdist/ which is under a (modified) BSD license. I just posted the link for context, sorry for the confusion. Doing a port to D does not allow me to change the license even though I not a single line from the original would remain (I think?). I might do a completely new D implementation (still based on the original authors research paper, not on the details of their code). But 1. I probably would only do a subset of functions I need for my work (i.e. double-double only, no quad-double, and only a limited set of trancendental functions). 2. Given that I have seen the original code, this might still be considered a "derivative work". I'm not sure, copyright-law is kinda confusing to me in these cases.
 Indeed you'll have no way to get rid of the excess precision 
 except for creating a function per sub-expression.
No, doesn't seem to work. Here is a minimal breaking example: double sum(double x, double y) { return x + y; } bool equals(double x, double y) { return x == y; } enum pi = ddouble(3.141592653589793116e+00, 1.224646799147353207e-16); struct ddouble { double hi, lo; invariant { if(!isNaN(hi) && !isNaN(lo)) assert(equals(sum(hi, lo), hi)); } this(double hi, double lo) { this.hi = hi; this.lo = lo; } } But there are workarounds that seem to work: 1. remove the constructor (I think this means the invariant is not checked anymore?) 2. disable the invariant in ctfe (using "if(__ctfe) return;") 3. Don't use any ctfe (by replacing enum with immutable globals, initialized in "static this").
 I was using the newCTFE fork which fixes this.
Does this mean your new CTFE code (which is quite impressive work as far as I can tell), floating point no longer gets promoted to higher precision? That would be really good news for hackish floating-point code. Honestly, this whole "compiler gets to decide which type to actually use" thing really bugs me. Kinda reminiscent of C/C++ integer types which could in principle be anything at all. I thought D had fixed this by specifying "int = 32-bit, long = 64-bit, float = IEEE-single-precision, double = IEEE-double-precision". Apparently not. If I write "double", I would like to get IEEE-conform double-precision operations. If I wanted something depending on target-platform and compiler-optimization-level I would have used "real". Also this 80-bit-extended type is just a bad idea in general and should never be used (IMHO). Even on x86 processors, it only exists for backward-compatibility. No current instruction set (like SEE/AVX) supports it. Sorry for the long rant. But I am puzzled that the spec (https://dlang.org/spec/float.html) actually encourages double<->real convertions while at the same time it (rightfully) disallows "unsafe math optimizations" such as "x-x=0".
Jun 29
parent reply Luis <luis.panadero gmail.com> writes:
On Thursday, 29 June 2017 at 12:00:53 UTC, Simon Bürger wrote:
 Thanks a lot for your comments.

 On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:
 [...]
This is only happening on CTFE ? Enforcing to use the old 8086 FPU for any float/double operation would give a lot performance penalty on any modern CPU.
Jun 30
parent reply kinke <noone nowhere.com> writes:
On Friday, 30 June 2017 at 11:42:39 UTC, Luis wrote:
 On Thursday, 29 June 2017 at 12:00:53 UTC, Simon Bürger wrote:
 Thanks a lot for your comments.

 On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:
 [...]
This is only happening on CTFE ? Enforcing to use the old 8086 FPU for any float/double operation would give a lot performance penalty on any modern CPU.
CTFE only (incl. parsing of literals). Just make sure you don't happen to call a std.math function only accepting reals; I don't know how many of those are still around.
Jun 30
parent reply kinke <noone nowhere.com> writes:
On Friday, 30 June 2017 at 16:21:18 UTC, kinke wrote:
 CTFE only (incl. parsing of literals). Just make sure you don't 
 happen to call a std.math function only accepting reals; I 
 don't know how many of those are still around.
Oh, apparently most still are. There are even some mean overloads for double/float only casting and forwarding to the `real` implementation.
Jun 30
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 30 June 2017 at 16:29:22 UTC, kinke wrote:
 On Friday, 30 June 2017 at 16:21:18 UTC, kinke wrote:
 CTFE only (incl. parsing of literals). Just make sure you 
 don't happen to call a std.math function only accepting reals; 
 I don't know how many of those are still around.
Oh, apparently most still are. There are even some mean overloads for double/float only casting and forwarding to the `real` implementation.
That is not a problem. The only problem is that the excess is not discarded at the end. Which is because of the design of the constant-folder.
Jun 30
parent kinke <noone nowhere.com> writes:
On Friday, 30 June 2017 at 16:39:16 UTC, Stefan Koch wrote:
 On Friday, 30 June 2017 at 16:29:22 UTC, kinke wrote:
 On Friday, 30 June 2017 at 16:21:18 UTC, kinke wrote:
 CTFE only (incl. parsing of literals). Just make sure you 
 don't happen to call a std.math function only accepting 
 reals; I don't know how many of those are still around.
Oh, apparently most still are. There are even some mean overloads for double/float only casting and forwarding to the `real` implementation.
That is not a problem. The only problem is that the excess is not discarded at the end. Which is because of the design of the constant-folder.
I was referring to runtime performance, as that was what Luis was concerned about.
Jun 30
prev sibling parent reply kinke <noone nowhere.com> writes:
On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:
 I am currently using LDC on 64-bit-Linux if that is relevant.
It is, as LDC on Windows/MSVC would use 64-bit compile-time reals. ;) Changing it to double on other platforms is trivial if you compile LDC yourself. You'll want to use this alias: https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.d#L19, https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.h#L19
Jun 28
parent reply Simon =?UTF-8?B?QsO8cmdlcg==?= <simon.buerger rwth-aachen.de> writes:
On Thursday, 29 June 2017 at 00:07:35 UTC, kinke wrote:
 On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:
 I am currently using LDC on 64-bit-Linux if that is relevant.
It is, as LDC on Windows/MSVC would use 64-bit compile-time reals. ;) Changing it to double on other platforms is trivial if you compile LDC yourself. You'll want to use this alias: https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.d#L19, https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.h#L19
Huh, I will definitely look into this. This might be the most elegant solution. Thanks for the suggestion.
Jun 29
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 29 June 2017 at 12:02:48 UTC, Simon Bürger wrote:
 On Thursday, 29 June 2017 at 00:07:35 UTC, kinke wrote:
 On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:
 I am currently using LDC on 64-bit-Linux if that is relevant.
It is, as LDC on Windows/MSVC would use 64-bit compile-time reals. ;) Changing it to double on other platforms is trivial if you compile LDC yourself. You'll want to use this alias: https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.d#L19, https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.h#L19
Huh, I will definitely look into this. This might be the most elegant solution. Thanks for the suggestion.
Required a custom build of the compiler for the library to work is rather inelegant imo. However It might allow you to make progress the quickest. Note that this only changes the type all ct-float-math is done at to double. which means that know float and real will be double. (Which is probably better then having float and double transform into 80bit reals)
Jun 29