Don Clugston wrote:

> I completely agree with Walter that 'extended' was a dreadful name for 80 bit floats. I really like 'real'. But since it's not a fixed size, it's behaving exactly like an alias. It would be natural to have corresponding aliases for 'imaginary' and 'complex'.

"extended" is the name of the FP format, though ? But maybe it needed a spiffier name, like "ext" (just like "quadruple" is shortened to "quad")

And "extended" isn't that much worse than "long double", is it... ? :-)

--anders

Dave wrote:

>> That certainly is the core of the issue. The D specification contains a
>> bit of theoretical talk about portability, but effectively the language
>> is an x86-only language only.
> 
> Hrm, that's a little strong: http://home.earthlink.net/~dvdfrdmn/d/
> GDC's been running on AIX and non-intel Mac for a while now. IIRC, elsewhere there has been a working port for HPUX as well.

On PowerPC, the "real" type is the same as the "double" type.

The new 128-bit long double type in GCC 4.0 and Mac OS X 10.4
can't be used for D language since it is not fully compliant.
(being made out of two linked double registers, it doesn't do
all of the exceptions in the same way. Same format, though...)

SPARC should have a real 128-bit long double type, I think.
Not sure if it's in hardware or if it is emulated, though ?


The silly thing about the 80-bit/long double on X86, besides
that not every compiler supports it, is the size/alignment:

                        size    align
DM Windows (32-bit)     10      2
Mac OS X86 (32-bit)     16      16
GCC Linux (32-bit)      12      4
GCC Linux (64-bit)      16      16

Not that the larger storage formats buys you extra precision,
it's just padded with zeros... (for better alignment I think)

--anders

Anders F Björklund wrote:
> Don Clugston wrote:
> 
>> I completely agree with Walter that 'extended' was a dreadful name for 80 bit floats. I really like 'real'. But since it's not a fixed size, it's behaving exactly like an alias. It would be natural to have corresponding aliases for 'imaginary' and 'complex'.
> 
> "extended" is the name of the FP format, though ? But maybe it needed a spiffier name, like "ext" (just like "quadruple" is shortened to "quad")
> 
> And "extended" isn't that much worse than "long double", is it... ? :-)

IMHO, it is much worse. It has absolutely no indication that it's a floating-point number. The full name is "extended precision float".
"double" has a very long history in C-related languages. Extended doesn't.

I think it doesn't matter much what it is called. It should almost never appear in code. (Code that uses it is CPU-specific, so some low-level library code like isfinite() will use it, but not much else). User code should almost always use "real".

(Arguably, they could even be called float80_80 for Windows, float80_96 for Linux32, float80_128 for Linux64, because of the differences in padding. The Linux64 format is binary compatible with the IEEE quadruple format; it behaves identically to a quad where the precision has been set low).

Don Clugston wrote:

> I think it doesn't matter much what it is called. It should almost never appear in code. (Code that uses it is CPU-specific, so some low-level library code like isfinite() will use it, but not much else). User code should almost always use "real".

Sounds good to me. Bringing back imaginary and complex would be enough,
then user code could use "real" and "complex" and not worry about it...
Like you mentioned, that's simple to do by using alias in the interim.

Any "extended" and "quadruple" would only be in lowlevel future layers.
("real" would automatically alias to type double, extended or quadruple)
If they're not used much, maybe they don't even need any "short forms".

> (Arguably, they could even be called float80_80 for Windows, float80_96 for Linux32, float80_128 for Linux64, because of the differences in padding. 

Then again, on any single platform you would only encounter one of them?
For instance "register" variables holding them would be the same on all.

Cross-platform data would be more work, but could use different padding.
(i.e. storing/reading 10 bytes, and adjust the padding according to ABI)

> The Linux64 format is binary compatible with the IEEE quadruple format; it behaves identically to a quad where the precision has been set low).

Interesting, hadn't thought of that... But it's very good news I think.
(Mac uses the same 128-bit format, in the Intel ABI for Mac OS X 10.4)

It's cool because you can then use the quad format for data exchange,
even if neither PowerPC/Intel will use it internally. (just 64+64/80)

--anders

Anders F Björklund wrote:
> Georg Wrede wrote:
> 
>> Ehh, if I understand this correctly, this would be the opposite from:
>>
>> Define "bitsizenames" as the ultimate "Genuine Types", and only alias them to the "usually used" types.
> 
> Yes, this would be the opposite from changing the base type names...
> 
> But all those D types (again: except for real) have a fixed size, so
> it's nothing like what you encounter in the old C headers/libraries ?
> 
> The only question is which of them is genuine and which is the alias.
> 
>> This "opposite" is what I have a problem with. I start seeing ghosts in the bedroom as soon as somebody tries to define "reality" with a set of incongruent "colloquial" names, and only then -- and as defined by them, define the "reality" types.
>>
>> I hope I've seriously misunderstood the above post.
> 
> Depends on what you read into it. It's only a pragmatic approach, based
> on the assumption that the names in the current type list won't change.
> 
> Thus, adding types with embedded bit sizes would *have* to be aliases ?
> Here was the entire list, with the floating points changed and added to:
> 
> INTEGER
> byte (8)
> short (16)
> int (32)
> long (64)
> cent (128)
> 
> FLOATING-POINT
> half (16)
> float (32)
> double (64)
> extended (80)
> quad (128)
> 
> I don't think the current D names are that bad. Similar to C and Java...
> And I don't think that they (D) are going to change, either ? Do you ?
> 
> And whether you use "int" or "int32_t", and perhaps "double" or e.g.
> "Float64", is more a matter of style and taste than of the D language ?

"911? Er, yes, can I get Ghost Busters! And don't hang up on me, please!!"

Georg Wrede wrote:

>> I don't think the current D names are that bad. Similar to C and Java...
>> And I don't think that they (D) are going to change, either ? Do you ?
>>
>> And whether you use "int" or "int32_t", and perhaps "double" or e.g.
>> "Float64", is more a matter of style and taste than of the D language ?
> 
> "911? Er, yes, can I get Ghost Busters! And don't hang up on me, please!!"

I'm still not sure what the nature of your particular ghouls was here ?

Did you want the basic D types to be renamed to something including
the general type and the bit size instead ? (int32, float64, etc.)

Because I just don't see that name change coming to the D language...
Of course, Walter is the one that would know. Us others hack aliases.

--anders