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

"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

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

Dave schrieb:
> "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?

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.

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. 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.

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.