digitalmars.D.learn - is real an 80-bit type or not?
- Bill Baxter (4/4) Dec 15 2006 I read somewhere (won't say where ;-)) that someone is annoyed by D
- Sean Kelly (3/6) Dec 15 2006 It is with DMD. I'm not sure if GDC uses 80 or 64-bit reals on the x86.
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (12/15) Dec 15 2006 It's an 80-bit type on all (make that "both") DMD platforms...
- Bill Baxter (4/27) Dec 15 2006 That all sounds perfectly reasonable. So why would that make it onto
- Sean Kelly (3/32) Dec 15 2006 Perhaps they think that "real" should always be a 64-bit type? There
- Frits van Bommel (6/8) Dec 15 2006 Or they're just mathematical purists who don't think a type named 'real'...
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (10/16) Dec 16 2006 In my case it's on my pet peeves list because of the "it's 10 for me".
- Bill Baxter (6/19) Dec 16 2006 I see. So really it's nothing particular to D. More with D users, and
- Don Clugston (3/25) Dec 17 2006 It is a bit weird that D has 'cent' and 'ucent' as reserved words, but
- Jarrett Billingsley (3/5) Dec 17 2006 I'd hope it'd be just "quad" :S "quadruple" is a little lengthy.
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (3/7) Dec 17 2006 I think it will be "real".
- Jarrett Billingsley (4/5) Dec 17 2006 Then what happens when you want an 80-bit float? Or if, far in the futu...
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (6/10) Dec 18 2006 But "real" is not defined as an 80-bit type...
- Jarrett Billingsley (10/14) Dec 18 2006 That's my point. A 128-bit float would only be 'real' as long as it's t...
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (5/13) Dec 18 2006 Walter didn't like the name "extended" very much:
- Don Clugston (6/25) Dec 19 2006 Thanks for that link. It explains a lot -- the fact that someone
- Bill Baxter (5/12) Dec 17 2006 That could be trouble for 3D apps where 'quad' is commonly used as an
- Benji Smith (9/24) Dec 18 2006 My personal preference would be for the type names to explicitly contain...
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
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
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
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
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
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
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
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
Anders F Björklund wrote:Bill Baxter wrote:It is a bit weird that D has 'cent' and 'ucent' as reserved words, but not 'quadruple'.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 ?
Dec 17 2006
"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
Jarrett Billingsley wrote:I think it will be "real". --andersIt 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
"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
Jarrett Billingsley wrote: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. --andersI 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 18 2006
"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
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
Anders F Björklund wrote:Jarrett Billingsley wrote: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).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 19 2006
Jarrett Billingsley wrote:"Don Clugston" <dac nospam.com.au> wrote in message news:em43j6$7tl$1 digitaldaemon.com...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. --bbIt 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
Bill Baxter wrote:Jarrett Billingsley wrote: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"Don Clugston" <dac nospam.com.au> wrote in message news:em43j6$7tl$1 digitaldaemon.com...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. --bbIt 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 18 2006