www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - is real an 80-bit type or not?

reply Bill Baxter <wbaxter gmail.com> writes:
I read somewhere (won't say where ;-)) that someone is annoyed by D 
"pretending that "real" is an 80-bit type".  Is it not?  real.sizeof 
sure seems to return 10 for me.

--bb
Dec 15 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 I read somewhere (won't say where ;-)) that someone is annoyed by D 
 "pretending that "real" is an 80-bit type".  Is it not?  real.sizeof 
 sure seems to return 10 for me.


It is with DMD.  I'm not sure if GDC uses 80 or 64-bit reals on the x86.


Sean
Dec 15 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 I read somewhere (won't say where ;-)) that someone is annoyed by D 
 "pretending that "real" is an 80-bit type".  Is it not?  real.sizeof 
 sure seems to return 10 for me.


It's an 80-bit type on all (make that "both") DMD platforms...
It varies on the platforms and architectures that GDC supports.

"int" is a fixed 32-bit type, everywhere. "real" varies in size.
It's 80-bit on Intel, 64 bits on PowerPC and 128 bits on SPARC ?

It's defined as the "largest hardware implemented" float type.
Basically since it maps directly onto the "long double" C type.

--anders

PS. real.sizeof varies between Intel too, due to padding.
     But it should be the same x87 format of the registers.

     GDC manual says: "On Win32, GDC allocates 12 bytes for
     the real type, while DMD allocates 10 bytes."
Dec 15 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
That all sounds perfectly reasonable.  So why would that make it onto 
someone's "top D peeves" list?

--bb

Anders F Björklund wrote:

 Bill Baxter wrote:
 

 I read somewhere (won't say where ;-)) that someone is annoyed by D 
 "pretending that "real" is an 80-bit type".  Is it not?  real.sizeof 
 sure seems to return 10 for me.


 
 
 It's an 80-bit type on all (make that "both") DMD platforms...
 It varies on the platforms and architectures that GDC supports.
 
 "int" is a fixed 32-bit type, everywhere. "real" varies in size.
 It's 80-bit on Intel, 64 bits on PowerPC and 128 bits on SPARC ?
 
 It's defined as the "largest hardware implemented" float type.
 Basically since it maps directly onto the "long double" C type.
 
 --anders
 
 PS. real.sizeof varies between Intel too, due to padding.
     But it should be the same x87 format of the registers.
 
     GDC manual says: "On Win32, GDC allocates 12 bytes for
     the real type, while DMD allocates 10 bytes."
Dec 15 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Perhaps they think that "real" should always be a 64-bit type?  There 
are a few different ways that statement could be interpreted.

Bill Baxter wrote:

 That all sounds perfectly reasonable.  So why would that make it onto 
 someone's "top D peeves" list?
 
 --bb
 
 Anders F Björklund wrote:

 Bill Baxter wrote:


 I read somewhere (won't say where ;-)) that someone is annoyed by D 
 "pretending that "real" is an 80-bit type".  Is it not?  real.sizeof 
 sure seems to return 10 for me.



 It's an 80-bit type on all (make that "both") DMD platforms...
 It varies on the platforms and architectures that GDC supports.

 "int" is a fixed 32-bit type, everywhere. "real" varies in size.
 It's 80-bit on Intel, 64 bits on PowerPC and 128 bits on SPARC ?

 It's defined as the "largest hardware implemented" float type.
 Basically since it maps directly onto the "long double" C type.

 --anders

 PS. real.sizeof varies between Intel too, due to padding.
     But it should be the same x87 format of the registers.

     GDC manual says: "On Win32, GDC allocates 12 bytes for
     the real type, while DMD allocates 10 bytes."
Dec 15 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:

 Perhaps they think that "real" should always be a 64-bit type?  There 
 are a few different ways that statement could be interpreted.


Or they're just mathematical purists who don't think a type named 'real' 
should have finite precision and range :p.
Of course, then they'd have to complain about 'int' being limited to 
-2^31..2^31-1 too.
And let's not get into ireal and creal...
Dec 15 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 I read somewhere (won't say where ;-)) that someone is annoyed by D 
 "pretending that "real" is an 80-bit type".  Is it not?  real.sizeof 
 sure seems to return 10 for me.







 "int" is a fixed 32-bit type, everywhere. "real" varies in size.





 That all sounds perfectly reasonable.  So why would that make it onto 
 someone's "top D peeves" list?


In my case it's on my pet peeves list because of the "it's 10 for me".
So you have hardcoded assertions that real.sizeof > double.sizeof...

Kinda like the "if (Win32) else //linux ;", it's making assumptions.
They are valid for DMD, but break for GDC - and make porting harder ?

But most of all I dislike the "imaginary real" and the "complex real".
(see http://www.digitalmars.com/d/archives/digitalmars/D/18061.html)

Since it's not going to change anyway, I'm OK with coping with it...
But still think the 16-bit and 128-bit types would have been nice ?

--anders
Dec 16 2006
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
Anders F Björklund wrote:

 Bill Baxter wrote:
 
 In my case it's on my pet peeves list because of the "it's 10 for me".
 So you have hardcoded assertions that real.sizeof > double.sizeof...
 
 Kinda like the "if (Win32) else //linux ;", it's making assumptions.
 They are valid for DMD, but break for GDC - and make porting harder ?
 
 But most of all I dislike the "imaginary real" and the "complex real".
 (see http://www.digitalmars.com/d/archives/digitalmars/D/18061.html)
 
 Since it's not going to change anyway, I'm OK with coping with it...
 But still think the 16-bit and 128-bit types would have been nice ?


I see.  So really it's nothing particular to D.  More with D users, and 
even then, users making assumptions about platforms is far from unique 
to D.  Glad to know it's nothing seriously wrong with D's 80-bit math on 
platforms that have it.

--bb
Dec 16 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Anders F Björklund wrote:

 Bill Baxter wrote:
 

 I read somewhere (won't say where ;-)) that someone is annoyed by D 
 "pretending that "real" is an 80-bit type".  Is it not?  real.sizeof 
 sure seems to return 10 for me.






 

 "int" is a fixed 32-bit type, everywhere. "real" varies in size.




 

 That all sounds perfectly reasonable.  So why would that make it onto 
 someone's "top D peeves" list?


 
 In my case it's on my pet peeves list because of the "it's 10 for me".
 So you have hardcoded assertions that real.sizeof > double.sizeof...
 
 Kinda like the "if (Win32) else //linux ;", it's making assumptions.
 They are valid for DMD, but break for GDC - and make porting harder ?
 
 But most of all I dislike the "imaginary real" and the "complex real".
 (see http://www.digitalmars.com/d/archives/digitalmars/D/18061.html)
 
 Since it's not going to change anyway, I'm OK with coping with it...
 But still think the 16-bit and 128-bit types would have been nice ?


It is a bit weird that D has 'cent' and 'ucent' as reserved words, but 
not 'quadruple'.
Dec 17 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:em43j6$7tl$1 digitaldaemon.com...


 It is a bit weird that D has 'cent' and 'ucent' as reserved words, but not 
 'quadruple'.


I'd hope it'd be just "quad" :S  "quadruple" is a little lengthy.
Dec 17 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jarrett Billingsley wrote:


It is a bit weird that D has 'cent' and 'ucent' as reserved words, but not 
'quadruple'.


 
 I'd hope it'd be just "quad" :S  "quadruple" is a little lengthy. 


I think it will be "real".

--anders
Dec 17 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:em4k50$olh$1 digitaldaemon.com...


 I think it will be "real".


Then what happens when you want an 80-bit float?  Or if, far in the future 
or on really exotic architectures, 128-bit floats are not the biggest type?
Dec 17 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jarrett Billingsley wrote:


I think it will be "real".


 
 Then what happens when you want an 80-bit float?  Or if, far in the future 
 or on really exotic architectures, 128-bit floats are not the biggest type? 


But "real" is not defined as an 80-bit type...
When 256-bit floats arrive, they will be real.

I suggested using "extended" for fixed 80-bit.
And that real should be converted to an alias.

--anders
Dec 18 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:em5irr$1l2o$1 digitaldaemon.com...


 But "real" is not defined as an 80-bit type...
 When 256-bit floats arrive, they will be real.


That's my point.  A 128-bit float would only be 'real' as long as it's the 
largest floating point type available.  So there'd need to be another name 
for them -- preferably 'quad'.


 I suggested using "extended" for fixed 80-bit.
 And that real should be converted to an alias.


I think early in D's development 'real' was called 'extended'.  There are 
still a few vestiges (commented out stuff) in the compiler source if I 
remember.  That was before my time with D, though, so I couldn't tell you 
why it was changed.  'extended' does make more sense, and since 'real' is a 
qualitative type, it should be an alias (defined by the compiler, perhaps).
Dec 18 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jarrett Billingsley wrote:


 That's my point.  A 128-bit float would only be 'real' as long as it's the 
 largest floating point type available.  So there'd need to be another name 
 for them -- preferably 'quad'.


I think using "quad" for quadruple precision floating point makes sense.


 I think early in D's development 'real' was called 'extended'.  There are 
 still a few vestiges (commented out stuff) in the compiler source if I 
 remember.  That was before my time with D, though, so I couldn't tell you 
 why it was changed.  'extended' does make more sense, and since 'real' is a 
 qualitative type, it should be an alias (defined by the compiler, perhaps). 


Walter didn't like the name "extended" very much:
http://www.digitalmars.com/d/archives/10261.html

--anders
Dec 18 2006
parent Don Clugston <dac nospam.com.au> writes:
Anders F Björklund wrote:

 Jarrett Billingsley wrote:
 

 That's my point.  A 128-bit float would only be 'real' as long as it's 
 the largest floating point type available.  So there'd need to be 
 another name for them -- preferably 'quad'.


 
 I think using "quad" for quadruple precision floating point makes sense.
 

 I think early in D's development 'real' was called 'extended'.  There 
 are still a few vestiges (commented out stuff) in the compiler source 
 if I remember.  That was before my time with D, though, so I couldn't 
 tell you why it was changed.  'extended' does make more sense, and 
 since 'real' is a qualitative type, it should be an alias (defined by 
 the compiler, perhaps). 


 
 Walter didn't like the name "extended" very much:
 http://www.digitalmars.com/d/archives/10261.html
 
 --anders


Thanks for that link. It explains a lot -- the fact that someone 
immediately started flaming Walter is quite unfortunate. No-one 
mentioned that "imaginary real" is a horrible oxymoron.

(IMHO, they should have been "real", "imaginary" and "complex" rather 
than real, ireal, creal).
Dec 19 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:

 "Don Clugston" <dac nospam.com.au> wrote in message 
 news:em43j6$7tl$1 digitaldaemon.com...
 

 It is a bit weird that D has 'cent' and 'ucent' as reserved words, but not 
 'quadruple'.


 
 I'd hope it'd be just "quad" :S  "quadruple" is a little lengthy.


That could be trouble for 3D apps where 'quad' is commonly used as an 
abbreviation for 'quadrilateral'.  As in glBegin(GL_QUADS).

That said, I'm sure we could all cope.

--bb
Dec 17 2006
parent Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:

 Jarrett Billingsley wrote:

 "Don Clugston" <dac nospam.com.au> wrote in message 
 news:em43j6$7tl$1 digitaldaemon.com...


 It is a bit weird that D has 'cent' and 'ucent' as reserved words, 
 but not 'quadruple'.


 I'd hope it'd be just "quad" :S  "quadruple" is a little lengthy.


 
 That could be trouble for 3D apps where 'quad' is commonly used as an 
 abbreviation for 'quadrilateral'.  As in glBegin(GL_QUADS).
 
 That said, I'm sure we could all cope.
 
 --bb


My personal preference would be for the type names to explicitly contain 
their size:

int8, uint8, int16, uint16, int32, uint32, int64, uint64
float32, ifloat32, float64, ifloat64, float80, ifloat80

It's completely clear. No one will ever misunderstand the type sizes. 
And the introduction of more-precise math operations will automatically 
imply new names for the new types.

--benji
Dec 18 2006