www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "extended" vs. "real"

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Q for Walter:
Will it be possible to rename the real type
back into e.g. extended again, before D 1.0 ?

All so that we can avoid the embarrassment
of having the ireal and creal data types...

My suggestion is:
alias extended real;
alias iextended imaginary;
alias cextended complex;

--anders
Mar 03 2005
parent reply "Dave" <Dave_member pathlink.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d06qse$2d78$2 digitaldaemon.com...

Q for Walter:
 Will it be possible to rename the real type
 back into e.g. extended again, before D 1.0 ?

 All so that we can avoid the embarrassment
 of having the ireal and creal data types...

 My suggestion is:
 alias extended real;
 alias iextended imaginary;
 alias cextended complex;

 --anders


Agreed that ireal and creal are not disirable from a numerics POV.

The problem is that "real" corresponds to the hardware, and therefore "real" 
is
a really good name for the concept of 'largest hardware implemented floating
point size' (IMHO). The problem with "extended" is that it implies greater
precision which of course is not actually the case on some hardware.

Can anyone think of a name other than real that would imply the same as it 
does
now?

How about 'intrinsic' (short for 'intrinsic float') for example. It is a 
synonym
for both 'real' and 'native'.

- Dave
Mar 03 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Dave wrote:


 The problem is that "real" corresponds to the hardware, and therefore "real" 
 is
 a really good name for the concept of 'largest hardware implemented floating
 point size' (IMHO).


If it's real, you mean ? Otherwise it could as well be imaginary. :-)


 The problem with "extended" is that it implies greater
 precision which of course is not actually the case on some hardware.


Extended came from: single, double, extended precision.
(where "single" is currently known in D as float, and
"extended" is currently known as real - unfortunately)

But thanks for thinking of the non-X86 crowd...


 Can anyone think of a name other than real that would imply the same as it 
 does now?


The old discussion is here: (from Jan 2003)
http://www.digitalmars.com/d/archives/10261.html


 How about 'intrinsic' (short for 'intrinsic float') for example. It is a 
 synonym for both 'real' and 'native'.


I don't really like it, I can't say...

     ***

One way around the dilemma could be to make "extended" type
a version(X86) only thing, and use "alias double" on others ?
Since that's how it works behind the scenes now, anyway...

version(X86)
{
   alias  extended real;
   alias iextended imaginary;
   alias cextended complex;
}
else
{
   alias  double real;
   alias idouble imaginary;
   alias cdouble complex;
}

I'm sure which is worst of:
- not being able to *guarantee* that extended type is 80-bits
- not having the extended type available on all CPU platforms ?

The "long" type is much easier to emulate with two ints on
32-bit platforms, but emulating an "extended" with two doubles
is a much harder task. Especially when demanding full IEEE 754.


I always found it strange to have 99% of the types fixed in
size, and then have one type who varies from 64 to 128 bits ?

Then again, some say that 80-bits are slow on Pentium too:
See http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Float


It's not like I will be using the darn type anywhow...
Just dislike the "imaginary real" and "complex real" !

--anders
Mar 03 2005
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Dave schrieb:

 "Anders F Bj=F6rklund" <afb algonet.se> wrote in message=20
 news:d06qse$2d78$2 digitaldaemon.com...
=20

Q for Walter:
Will it be possible to rename the real type
back into e.g. extended again, before D 1.0 ?

All so that we can avoid the embarrassment
of having the ireal and creal data types...

My suggestion is:
alias extended real;
alias iextended imaginary;
alias cextended complex;

--anders


=20
=20
 Agreed that ireal and creal are not disirable from a numerics POV.
=20
 The problem is that "real" corresponds to the hardware, and therefore "=


real"=20

 is
 a really good name for the concept of 'largest hardware implemented flo=


ating

 point size' (IMHO). The problem with "extended" is that it implies grea=


ter

 precision which of course is not actually the case on some hardware.
=20
 Can anyone think of a name other than real that would imply the same as=


 it=20

 does
 now?


The cleanest solution (ignoring historical background) would be to use=20
'single' for what is called 'float' in C and 'float' for what is called=20
'real' in D at the moment... The 'extended' could be used for 80/128 bit =

floats if they exists in a given implementation.

However, the concept of 'real' actually need not be part of the language =

but of the library. If the language just gives a list of exact types,=20
the library can then just define types that are 'optimal' in some=20
respect. In any case: it is not possible to say generally what is=20
'optimal' in any case, so the standard library should also refrain from=20
such a notion.
Mar 05 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


 The cleanest solution (ignoring historical background) would be to use 
 'single' for what is called 'float' in C and 'float' for what is called 
 'real' in D at the moment... The 'extended' could be used for 80/128 bit 
 floats if they exists in a given implementation.


Using 'float' for single precision is part of the C legacy. (like "int")
Redefining it to some other arbitrary precision is even more confusing ?

Having grown up on 16-bit platforms I find the "int" and "long" defs to
be confusing enough, but have gotten used to them now by using Java...


 However, the concept of 'real' actually need not be part of the language 
 but of the library. If the language just gives a list of exact types, 
 the library can then just define types that are 'optimal' in some 
 respect.


Which was why I suggested using "alias" instead, for the 'real' type ?
It would still hold "largest hardware implemented floating point size"


 In any case: it is not possible to say generally what is 
 'optimal' in any case, so the standard library should also refrain from 
 such a notion.


I think that the D specification should state that 'extended' should
be at least 80 bits (i.e. more than 64 bits). Whether they really are
X87 80-bits, "real" 128-bits, "fake" 64+64* 128-bits floating points or
if they are stored to memory using 96 or 128 bits is not that important.

But defining 'real' as "64 bits or more", like it is now, is confusing ?
It's better that the extended data type isn't available on all hardware.

--anders

* To be honest, I'm not sure if you can actually get IEEE 754 compliance
   working by implementing a 128-bit long double with two 64-bit doubles?
   The libraries that I have seen so far usually are not fully compliant.
Mar 06 2005