Anders F Björklund wrote:
> Norbert Nemec wrote:
> 
>> That discussion was before my time and obviously nobody back
>> then had strong feelings against talking about "really complex numbers".
> 
> 
> Walter didn't like the "extended" keyword, so he renamed it "real": http://www.digitalmars.com/d/changelog.html#new054 [DMD 0.54, 2003]

That's interesting! This was nearly one year before I seriously got in contact with D for the first time. I remember that the "creal/ireal" names offended me right away when I read the specification. I wrote a message about it to the newsgroup and people started discussing about the type naming in all directions, but there didn't seem to be anybody who even understood the irony of "complex real" and "imaginary real" numbers.

> Several people hated "imaginary real" and "complex real", though ? But I guess they left and never came back, or something like that.

It really seems that people with mathematical background really either left of gave up on the issue back then.

>> Therefore the final word still is: "Do in the library whatever you want, the language definition will not be changed again."
> 
> That's my understanding as well, with the 64-128 bit floating type. I'd rather have the basic D types be of a fixed size, but that's me.

Exactly my opinion: The basic types should have well-defined bit-sizes and be portable across architectures.

The best names for a floating point types with fixed bit size are type names that have the bit-size incorporated: float32, float64, float80 and so on. Correspondingly there would be ifloat32, ifloat64 and ifloat80. For complex numbers, the naming is not obvious, but I would go for cfloat32 for a complex float made up of two float32 numbers.

Any library interfacing C code would then probably define
	alias float32 float;
	alias float64 double;

The standard library should then pre-define the precious type names "real", "complex" and "imaginary" to some reasonable default, that may be architecture dependent and can easily be changed. The regular user should be encouraged to use these aliases without depending on a fixed size. This will result in code that can easily be compiled with a different precision or moved inside a template library where "real" becomes a parameter.

This would solve several problems:

* currently, there is no type name for 80-bit floats

* the current naming scheme has no obvious extension towards 16-bit, 128-bit or other bit-size floating point numbers.

* the current definition of "real" is dangerous:
"largest hardware implemented floating point size"
If you implemented D on some future architecture that supports 1024-bit
floats in hardware, "real" would have a float1024, even if the high
data-rate makes this a very bad general choice.

* the mechanism that determines the size of "real" is not clear at all. It may be hard-wired in the compiler or there may be a compiler-switch which is different for every implementations. Using plain aliases, the mechanism is completely transparent any can use the full flexibility of conditional compilation.

* The ridiculous concept of "really complex numbers" and "irreal" numbers is finally off the table and D can stop being ashamed in view of the seriously mathematical world.

Greetings,
Norbert

B.t.w: just added this point to the "unofficial wishlist":
	http://all-technology.com/eigenpolls/dwishlist/index.php
under the name "Precise names for floats"

Please vote for it if you think it is important.



Norbert Nemec wrote:
> Anders F Björklund wrote:
> 
>>Norbert Nemec wrote:
>>
>>
>>>That discussion was before my time and obviously nobody back
>>>then had strong feelings against talking about "really complex numbers".
>>
>>
>>Walter didn't like the "extended" keyword, so he renamed it "real": http://www.digitalmars.com/d/changelog.html#new054 [DMD 0.54, 2003]
> 
> 
> That's interesting! This was nearly one year before I seriously got in contact with D for the first time. I remember that the "creal/ireal" names offended me right away when I read the specification. I wrote a message about it to the newsgroup and people started discussing about the type naming in all directions, but there didn't seem to be anybody who even understood the irony of "complex real" and "imaginary real" numbers.
> 
> 
>>Several people hated "imaginary real" and "complex real", though ? But I guess they left and never came back, or something like that.
> 
> 
> It really seems that people with mathematical background really either left of gave up on the issue back then.
> 
> 
>>>Therefore the final word still is: "Do in the library whatever you want, the language definition will not be changed again."
>>
>>That's my understanding as well, with the 64-128 bit floating type. I'd rather have the basic D types be of a fixed size, but that's me.
> 
> 
> Exactly my opinion: The basic types should have well-defined bit-sizes and be portable across architectures.
> 
> The best names for a floating point types with fixed bit size are type names that have the bit-size incorporated: float32, float64, float80 and so on. Correspondingly there would be ifloat32, ifloat64 and ifloat80. For complex numbers, the naming is not obvious, but I would go for cfloat32 for a complex float made up of two float32 numbers.
> 
> Any library interfacing C code would then probably define
> 	alias float32 float;
> 	alias float64 double;
> 
> The standard library should then pre-define the precious type names "real", "complex" and "imaginary" to some reasonable default, that may be architecture dependent and can easily be changed. The regular user should be encouraged to use these aliases without depending on a fixed size. This will result in code that can easily be compiled with a different precision or moved inside a template library where "real" becomes a parameter.
> 
> This would solve several problems:
> 
> * currently, there is no type name for 80-bit floats
> 
> * the current naming scheme has no obvious extension towards 16-bit, 128-bit or other bit-size floating point numbers.
> 
> * the current definition of "real" is dangerous:
> "largest hardware implemented floating point size"
> If you implemented D on some future architecture that supports 1024-bit
> floats in hardware, "real" would have a float1024, even if the high
> data-rate makes this a very bad general choice.
> 
> * the mechanism that determines the size of "real" is not clear at all. It may be hard-wired in the compiler or there may be a compiler-switch which is different for every implementations. Using plain aliases, the mechanism is completely transparent any can use the full flexibility of conditional compilation.
> 
> * The ridiculous concept of "really complex numbers" and "irreal" numbers is finally off the table and D can stop being ashamed in view of the seriously mathematical world.
> 
> Greetings,
> Norbert

Norbert Nemec wrote:

>>I'd rather have the basic D types be of a fixed size, but that's me.
> 
> Exactly my opinion: The basic types should have well-defined bit-sizes
> and be portable across architectures.

It could just be a side-effect of DMD only targetting one architecture ?

The real type is 80 bits in register on all the supported platforms, it
just varies in size when stored to mem/disk (80 on Windows, 96 on Linux,
and will probably increase to 128 bit when 64-bit Linux is supported ?)
Usually it just follows the platform definition of "long double", for C.

> The best names for a floating point types with fixed bit size are type
> names that have the bit-size incorporated: float32, float64, float80 and
> so on. Correspondingly there would be ifloat32, ifloat64 and ifloat80.
> For complex numbers, the naming is not obvious, but I would go for
> cfloat32 for a complex float made up of two float32 numbers.
> 
> Any library interfacing C code would then probably define
> 	alias float32 float;
> 	alias float64 double;
> 
> The standard library should then pre-define the precious type names
> "real", "complex" and "imaginary" to some reasonable default, that may
> be architecture dependent and can easily be changed. The regular user
> should be encouraged to use these aliases without depending on a fixed
> size. This will result in code that can easily be compiled with a
> different precision or moved inside a template library where "real"
> becomes a parameter.

I had a similar suggestion, but the other way around... Keep the
current type names, and added the bitsizenames as aliases instead.
(my original post had names similar to stdint, such as float32_t)

I thought including the bit size in the name made it a bit harder to
read and more unattractive, quite similar to the case with integers ?
(i.e. naming those types as int8, int16, int32, int64, int128 instead)


But I haven't heard anything suggesting that "real" will ever change...
As far as I know, that part of the D specification is already decided.

--anders

Anders F Björklund wrote:
>> Exactly my opinion: The basic types should have well-defined bit-sizes and be portable across architectures.
> 
> It could just be a side-effect of DMD only targetting one architecture ?

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.

> The real type is 80 bits in register on all the supported platforms, it just varies in size when stored to mem/disk (80 on Windows, 96 on Linux, and will probably increase to 128 bit when 64-bit Linux is supported ?) Usually it just follows the platform definition of "long double", for C.

This confusion is exactly what I have problems with.

> I had a similar suggestion, but the other way around... Keep the current type names, and added the bitsizenames as aliases instead. (my original post had names similar to stdint, such as float32_t)

That means trying to build something well-defined on top of shaky ground which is exactly what causes the huge mess of C/C++-build systems like "automake" and "autoconf". The build system has to do a number of tests to find out what the implementation-dependend things are on a given system to define portable types. This is just the thing I believed D was supposed to solve.

> I thought including the bit size in the name made it a bit harder to read and more unattractive, quite similar to the case with integers ? (i.e. naming those types as int8, int16, int32, int64, int128 instead)

Harder to read? That's exactly what aliases should be used for. The names including bit sizes are precise, well defined and to the point, which is the best ground to build something on top

> But I haven't heard anything suggesting that "real" will ever change... As far as I know, that part of the D specification is already decided.

Yes, it is decided and Walter considers the topic closed. The whole discussion that is going on here is completely academic as is the whole question of portability. But one day, somebody might actually try to port D to a seriously different architecture, and latest at that point, this issue will have to be rolled up again.

Norbert Nemec wrote:
> Anders F Björklund wrote:
>>> Exactly my opinion: The basic types should have well-defined bit-sizes
>>> and be portable across architectures.
>> It could just be a side-effect of DMD only targetting one architecture ?
> 
> 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.

The bottom line is that 'i/c/real' are the only native types where the size is not specified by the language, but by the underlying hardware. This is a big improvement for portability over C/++. According to the rationale, the 'real' type is to encourage programmers to use the max. hardware precision available for fp operations and port things that way.

Let's not over-guru things here:
- float and double are widely understood as 32 bit and 64 bit for a C-lineage language.
- There seems to be little complaint about i/c/float and i/c/double as well.
- The big complaint is from numerics programmers who don't like the irony of ireal and creal. *Just change those to be 'imag' and 'comp'*.
- Walter understandably doesn't want to change the spec. for every floating point type, but this would be a change involving just two of them that we hear constant complaints about and are not yet used ubiquitously.
- If it breaks your code, you can simply alias the old creal and ireal types until you get time to change it.

So you have:

float
ifloat
cfloat

double
idouble
cdouble

real
imag
comp

If Walter would handle the compiler end of things, I would be glad to grep the phobos math libs. and docs. to make the changes there.

Besides getting rid of ireal and creal, imag and comp are short yet descriptive to those who would most likely use them. They will not confuse newbies or make the type system any harder to understand. And they imply a type that is 'native' to the machine like 'real' does because they don't have any connotations of absolute size.

Let's face it, there is no way Walter is going to again change the base fp types (float, double, real). And speaking from the point of view of a humble user who may want to use yet-to-be-built math libraries sometime, I would immediately search for an alternative for a D math library built with aliased types because that would just be one more inconsistency, another thing to learn and remember, and more to concern myself with for porting.

- Dave

Norbert Nemec wrote:

>> I had a similar suggestion, but the other way around... Keep the
>> current type names, and added the bitsizenames as aliases instead.
>> (my original post had names similar to stdint, such as float32_t)
> 
> That means trying to build something well-defined on top of shaky ground
> which is exactly what causes the huge mess of C/C++-build systems like
> "automake" and "autoconf". The build system has to do a number of tests
> to find out what the implementation-dependend things are on a given
> system to define portable types. This is just the thing I believed D was
> supposed to solve.

AFAIK, the only D things undecided are the size of a real and the param
format of a dynamic array. At least those are the ones I've run into...

Size of the other types should be pretty constant ? Even size of a bool.
Already had stdint aliases for integers, so I thought about "stdfloat".

I dropped the idea, since it's not as common to need to set the size of
a float/double in bits, as compared to when using short/long int types.


The D number types are also the same as in Java, which is another plus.
(D adds the unsigned and imaginary/complex variants, which is a bonus)

I renamed real into "extended" here, and just treat "real" as an alias.
But usually I just use float and double, to keep the code portable...


>> I thought including the bit size in the name made it a bit harder to
>> read and more unattractive, quite similar to the case with integers ?
>> (i.e. naming those types as int8, int16, int32, int64, int128 instead)
> 
> Harder to read? That's exactly what aliases should be used for. The
> names including bit sizes are precise, well defined and to the point,
> which is the best ground to build something on top

I've been doing some coding with Mac's C types, which include the bit
size, and it's not *that* bad in practice actually. Just a bit strange:

    typedef unsigned char           UInt8;
    typedef signed char             SInt8;
    typedef unsigned short          UInt16;
    typedef signed short            SInt16;
    typedef unsigned long           UInt32;
    typedef signed long             SInt32;
    typedef uint64_t		    UInt64;
    typedef int64_t		    SInt64;
    typedef float                   Float32;
    typedef double                  Float64;

But when writing regular ANSI C code, using things like "int" or "float"
just feels more readable (to me) than using e.g. "SInt32" or "Float32" ?


So I don't think there are too many problems with all the old "regular"
types, it's just the "real" type that I'm having some minor issues with.

And like suggested, it's easy enough to add a few "alias" and live with.
(I'm going to continue to call the X87 80-bit type "extended", I think)

--anders

Anders F Björklund wrote:
> I had a similar suggestion, but the other way around... Keep the
> current type names, and added the bitsizenames as aliases instead.

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.


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.

Anders F Björklund wrote:
> Norbert Nemec wrote:
> 
>>> I had a similar suggestion, but the other way around... Keep the
>>> current type names, and added the bitsizenames as aliases instead.
>>> (my original post had names similar to stdint, such as float32_t)
>>
>>
>> That means trying to build something well-defined on top of shaky ground
>> which is exactly what causes the huge mess of C/C++-build systems like
>> "automake" and "autoconf". The build system has to do a number of tests
>> to find out what the implementation-dependend things are on a given
>> system to define portable types. This is just the thing I believed D was
>> supposed to solve.
> 
> 
> AFAIK, the only D things undecided are the size of a real and the param
> format of a dynamic array. At least those are the ones I've run into...
> 
> Size of the other types should be pretty constant ? Even size of a bool.
> Already had stdint aliases for integers, so I thought about "stdfloat".
> 
> I dropped the idea, since it's not as common to need to set the size of
> a float/double in bits, as compared to when using short/long int types.
> 
> 
> The D number types are also the same as in Java, which is another plus.
> (D adds the unsigned and imaginary/complex variants, which is a bonus)
> 
> I renamed real into "extended" here, and just treat "real" as an alias.
> But usually I just use float and double, to keep the code portable...
> 
> 
>>> I thought including the bit size in the name made it a bit harder to
>>> read and more unattractive, quite similar to the case with integers ?
>>> (i.e. naming those types as int8, int16, int32, int64, int128 instead)
>>
>>
>> Harder to read? That's exactly what aliases should be used for. The
>> names including bit sizes are precise, well defined and to the point,
>> which is the best ground to build something on top
> 
> 
> I've been doing some coding with Mac's C types, which include the bit
> size, and it's not *that* bad in practice actually. Just a bit strange:
> 
>     typedef unsigned char           UInt8;
>     typedef signed char             SInt8;
>     typedef unsigned short          UInt16;
>     typedef signed short            SInt16;
>     typedef unsigned long           UInt32;
>     typedef signed long             SInt32;
>     typedef uint64_t            UInt64;
>     typedef int64_t            SInt64;
>     typedef float                   Float32;
>     typedef double                  Float64;
> 
> But when writing regular ANSI C code, using things like "int" or "float"
> just feels more readable (to me) than using e.g. "SInt32" or "Float32" ?
> 
> 
> So I don't think there are too many problems with all the old "regular"
> types, it's just the "real" type that I'm having some minor issues with.
> 
> And like suggested, it's easy enough to add a few "alias" and live with.
> (I'm going to continue to call the X87 80-bit type "extended", I think)
> 
> --anders

Let's put it this way: until _all_ of the here discussed parameters have become chiseled in stone, and matured till petrification, any serious math user, or library writer, would do well in aliasing (whatever type they that day choose) and using that alias in the entire code.

Only doing that can save them if "the world" changes around them.
(Which really is likely -- until the above said "chiseled in stone and matured till petrification" has materialized.)

Norbert Nemec wrote:
> Don Clugston wrote:
>> I think we could easily amass a lobby group of 100% of the users of
>> complex numbers in D to have a 'complex' alias set up in math.d. And
>> gradually phase out use of creal (which I think would be better named
>> cfloat80 or similar -- make the underlying type itself be of fixed size).
> 
> Well, the whole discussion is pretty much pointless unless Walter is
> willing to touch the topic again. When the topic came up two years ago,
> the final sentence was something like: "Well, I agree that creal sounds
> stupid, but we are not going to roll this up yet again." Obviously, the
> name "creal" was the result of a tedious discussion a little while
> before. That discussion was before my time and obviously nobody back
> then had strong feelings against talking about "really complex numbers".
> Therefore the final word still is: "Do in the library whatever you want,
> the language definition will not be changed again."

I'm OK with that, I really think it's all we need.
* Add the following lines to object.d:

alias ireal imaginary;
alias creal complex;

* Replace all uses of 'creal' in math.d with 'complex'.
* In the documentation, replace 'creal' in the docs with 'complex'.
A simple search-and-replace in both cases. It would only take five minutes. No change to the compiler is required. It wouldn't break any existing code.

Similar to, but much less disruptive than, the bit/bool change that was just made.

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

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 ?

--anders