On 6/29/2014 11:21 AM, Russel Winder via Digitalmars-d wrote:
> Because when reading the code you haven't got a f####### clue how
> accurate the floating point number is until you ask and answer the
> question "and which processor are you running this code on".

That is not  true with D. D specifies that float and double are IEEE 754 types which have specified size and behavior. D's real type is the largest the underlying hardware will support.

D also specifies 'int' is 32 bits, 'long' is 64, and 'byte' is 8, 'short' is 16.

On Sunday, 29 June 2014 at 19:18:49 UTC, Walter Bright wrote:
> On 6/29/2014 11:13 AM, Russel Winder via Digitalmars-d wrote:
>> Very definitely so. Fixed point or integer arithmetic for simple
>> "household" finance fair enough, but for "finance house" calculations
>> you generally need 22+ significant denary digits to meet with compliance
>> requirements.
>
> Doubles are only good to 17 digits, and even that 17th digit is flaky.

The 11 extra bits in an x87 real wouldn't get you to 22 either, though. ;)

David

On Sunday, 29 June 2014 at 19:22:16 UTC, Walter Bright wrote:
> On 6/29/2014 11:21 AM, Russel Winder via Digitalmars-d wrote:
>> Because when reading the code you haven't got a f####### clue how
>> accurate the floating point number is until you ask and answer the
>> question "and which processor are you running this code on".
>
> That is not  true with D. D specifies that float and double are IEEE 754 types which have specified size and behavior. D's real type is the largest the underlying hardware will support.
>
> D also specifies 'int' is 32 bits, 'long' is 64, and 'byte' is 8, 'short' is 16.

I'm afraid that it is exactly true if you use `real`.

What important use-case is there for using `real` that shouldn't also be accompanied by a `static assert(real.sizeof >= 10);` or similar, for correctness reasons?

Assuming there isn't one, then what is the point of having a type with hardware dependant precision? Isn't it just a useless abstraction over the hardware that obscures useful intent?

mixin(`alias real` ~ (real.sizeof*8).stringof ~ ` = real;`);

is more useful to me.

On 29 June 2014 22:04, John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 29 June 2014 at 19:22:16 UTC, Walter Bright wrote:
>>
>> On 6/29/2014 11:21 AM, Russel Winder via Digitalmars-d wrote:
>>>
>>> Because when reading the code you haven't got a f####### clue how accurate the floating point number is until you ask and answer the question "and which processor are you running this code on".
>>
>>
>> That is not  true with D. D specifies that float and double are IEEE 754 types which have specified size and behavior. D's real type is the largest the underlying hardware will support.
>>
>> D also specifies 'int' is 32 bits, 'long' is 64, and 'byte' is 8, 'short' is 16.
>
>
> I'm afraid that it is exactly true if you use `real`.
>

There seems to be a circular argument going round here, it's tiring bringing up the same point over and over again.


> What important use-case is there for using `real` that shouldn't also be accompanied by a `static assert(real.sizeof >= 10);` or similar, for correctness reasons?
>

Breaks portability.  There is just too much code out there that uses real, and besides druntime/phobos math has already been ported to handle all cases where real == 64bits.

> Assuming there isn't one, then what is the point of having a type with hardware dependant precision? Isn't it just a useless abstraction over the hardware that obscures useful intent?
>
> mixin(`alias real` ~ (real.sizeof*8).stringof ~ ` = real;`);
>

Good luck guessing which one to use.  On GDC you have a choice of three or four depending on what the default -m flags are. ;)

On Sun, 2014-06-29 at 19:02 +0000, David Nadlinger via Digitalmars-d
wrote:
[…]
> There is nothing Humpty Dumpty about the current situation. You are simply missing the fact that float and double are already defined as 32 bit/64 bit IEEE 754 compliant floating point numbers in the spec.
> 
> There is nothing ambiguous about that, just as char/int/long have defined bit-widths in D.

I think I am probably just getting "bloody minded" here, but…

If D is a language that uses the underlying hardware representation then it cannot define the use of specific formats for hardware numbers. Thus, on hardware that provides IEEE754 format hardware float and double can map to the 32-bit and 64-bit IEEE754 numbers offered. However if the hardware does not provide IEEE754 hardware then either D must interpret floating point expressions (as per Java) or it cannot be ported to that architecture. cf. IBM 360.

Fortunately more recent IBM hardware has multiple FPUs per core, one of which provides IEEE754 as an option. (Pity the other FPUs cannot be used :-)

Corollary: if D defines the "hardware" representation in its data model then it can only be ported to hardware that uses that representation.

PS Walter just wrote that the type real is not defined as float and double are, so it does have a Humpty Dumpty factor even if float and double do not.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sun, 2014-06-29 at 12:18 -0700, Walter Bright via Digitalmars-d
wrote:
[…]
> Doubles are only good to 17 digits, and even that 17th digit is flaky.

Hence the use of software "real" numbers becoming the norm for calculating these bioinformatics and quant models.

(I rarely see better that 14 or 15 denary digits of accuracy for 64-bit
fp hardware. :-(

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Hopefully there are points here for pedantry and bloody mindedness…


On Sat, 2014-06-28 at 18:32 -0700, Walter Bright via Digitalmars-d
wrote:
[…]
> Keep in mind that D is a systems programming language, and that
implies you get
> access to the hardware types.


On Sun, 2014-06-29 at 12:22 -0700, Walter Bright via Digitalmars-d
wrote:
[…].
> 
> That is not  true with D. D specifies that float and double are IEEE 754 types which have specified size and behavior. D's real type is the largest the underlying hardware will support.
> 
> D also specifies 'int' is 32 bits, 'long' is 64, and 'byte' is 8, 'short' is 16.


D gives access to the hardware types, and D defines the structure of all those types. The only resolution is that D only works on that hardware where the hardware types are the ones D defines. Thus D only works on a subset of hardware, and can never be ported to hardware where the hardware types differ from those defined by D.

So D float and double will not work on IBM 360 unless interpreted, and real would be 128-bit (not IEEE)?

The D real type definitely suffers the C/C++ float and double problem!

I guess we just hope that all future hardware is IEEE754 compliant.


(This is both a trivial issue and a brick wall issue so let's keep thing
humour-ful!)
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 29 June 2014 22:45, Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Hopefully there are points here for pedantry and bloody mindedness…
>
>
> On Sat, 2014-06-28 at 18:32 -0700, Walter Bright via Digitalmars-d
> wrote:
> […]
>> Keep in mind that D is a systems programming language, and that
> implies you get
>> access to the hardware types.
>
>
> On Sun, 2014-06-29 at 12:22 -0700, Walter Bright via Digitalmars-d
> wrote:
> […].
>>
>> That is not  true with D. D specifies that float and double are IEEE 754 types which have specified size and behavior. D's real type is the largest the underlying hardware will support.
>>
>> D also specifies 'int' is 32 bits, 'long' is 64, and 'byte' is 8, 'short' is 16.
>
>
> D gives access to the hardware types, and D defines the structure of all those types. The only resolution is that D only works on that hardware where the hardware types are the ones D defines. Thus D only works on a subset of hardware, and can never be ported to hardware where the hardware types differ from those defined by D.
>
> So D float and double will not work on IBM 360 unless interpreted, and real would be 128-bit (not IEEE)?
>

I'm sure it isn't as bad as you describe for floor and double.  And if it is, then I can't see GCC (C/C++) working on IBM 360 either, without some out-of-band patches.  And so what you allege IBM to have done is a platform problem, not a language one.

Support for IBM extended reals is partial, and will improve as PPC is ported to.


> The D real type definitely suffers the C/C++ float and double problem!
>
> I guess we just hope that all future hardware is IEEE754 compliant.
>

else
  static assert(false, "Here's a nickel, kid. Go buy yourself a real
computer.");  // :)

On Sun, Jun 29, 2014 at 08:54:49AM +0100, Iain Buclaw via Digitalmars-d wrote:
> On 29 Jun 2014 05:48, "H. S. Teoh via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
> >
> > On Sat, Jun 28, 2014 at 08:41:24PM -0700, Andrei Alexandrescu via
> Digitalmars-d wrote:
> > > On 6/28/14, 6:02 PM, Tofu Ninja wrote:
> > [...]
> > > >I think this thread needs to refocus on the main point, getting math overloads for float and double and how to mitigate any problems that might arise from that.
> > >
> > > Yes please. -- Andrei
> >
> > Let's see the PR!
> >
> 
> I've already raised one (already linked in this thread).

Are you talking about #2274? Interesting that your implementation is basically identical to my own idea for fixing std.math -- using unions instead of pointer casting. However, without compiler support for repainting scalars in a union, I couldn't get what I needed to work. I'm trying to make atan2 CTFE-able, but it in turn uses isInfinity, isNaN, signbit, and possibly one or two others, and while I managed to hack isInfinity and isNaN, signbit defeated me due to the signedness of NaNs, which cannot be extracted in any other way.


> More to come!

Are you going to implement repainting unions in CTFE? That would be *awesome*.


[...]
> > Perhaps we can introduce some intrinsics for implementing these functions so that they work both in CTFE and at runtime?
> >
> >         https://issues.dlang.org/show_bug.cgi?id=3749
> >
> 
> CTFE support for accessing basic types in unions - as in painting between all kinds of scalar types, with special support for static arrays (via vectors) should be all that is required.

I thought as much. Currently, unions don't support repainting in CTFE, so it doesn't work. I think that's the last hurdle needed, since with repainting everything else can be done in code.


> Once CTFE supports that, it won't be difficult to get std.math to be CTFE-certified. :)
[...]

Looking forward to that!


T

-- 
Why ask rhetorical questions? -- JC

On Sun, Jun 29, 2014 at 11:18:43PM +0100, Iain Buclaw via Digitalmars-d wrote:
> On 29 June 2014 22:45, Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
[...]
> > The D real type definitely suffers the C/C++ float and double problem!
> >
> > I guess we just hope that all future hardware is IEEE754 compliant.
> >
> 
> else
>   static assert(false, "Here's a nickel, kid. Go buy yourself a real
> computer.");  // :)

+1. :-)


T

-- 
Debian GNU/Linux: Cray on your desktop.