## digitalmars.D - [suggestion] std type aliases

- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Feb 10 2005
- Norbert Nemec <Norbert Nemec-online.de> Feb 10 2005
- =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Feb 10 2005
- Kris <Kris_member pathlink.com> Feb 10 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 10 2005
- Charles Hixson <charleshixsn earthlink.net> Feb 15 2005
- John Reimer <brk_6502 yahoo.com> Feb 10 2005
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> Feb 10 2005
- John Reimer <brk_6502 yahoo.com> Feb 10 2005
- "Charlie Patterson" <charliep1 excite.com> Feb 10 2005
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Feb 10 2005
- "Charlie Patterson" <charliep1 excite.com> Feb 11 2005
- =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Feb 10 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 10 2005
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> Feb 10 2005
- Norbert Nemec <Norbert Nemec-online.de> Feb 11 2005
- "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 10 2005

Here is the full list of my suggested type aliases for D: TYPE ALIAS // RANGE void // void Integer: (std.stdint) byte int8_t // 8-bit signed ubyte uint8_t // 8-bit unsigned (0x00-0xFF) short int16_t // 16-bit signed ushort uint16_t // 16-bit unsigned (0x0000-0xFFFF) int int32_t // 32-bit signed uint uint32_t // 32-bit unsigned (0x00000000-0xFFFFFFFF) long int64_t // 64-bit signed (could be two int registers) ulong uint64_t // 64-bit unsigned (could be two uint registers) cent int128_t // 128-bit signed (reserved for future use) ucent uint128_t // 128-bit unsigned (reserved for future use) Character: (std.stdutf) char utf8_t // UTF-8 \x00-\x7F (ASCII) wchar utf16_t // UTF-16 \u0000-\uD7FF, \uE000-\uFFFF dchar utf32_t // UTF-32 \U00000000-\U0010FFFF (Unicode) Boolean: (std.stdbool) bit bool // false (0) | true (1) byte wbool // false (zero) | true (non-zero) int dbool // false (zero) | true (non-zero) String: (std.stdstr) char[] str // UTF-8, optimized for US-ASCII wchar[] wstr // UTF-16, optimized for Unicode dchar[] dstr // UTF-32, easy codepoint access Floating Point: float // 32-bit single precision (about 6 digits) double // 64-bit double precision (about 15 digits) real // 64/80/128-bit extended precision (platform) ifloat // \ idouble // imaginary versions of the above ireal // / cfloat // \ cdouble // complex (both real and imaginary parts) creal // / No new keywords, just a bunch of useful (?) aliases... --anders Implementation: (Public Domain)module std.stdutf; /* UTF code units */ alias char utf8_t; // UTF-8 alias wchar utf16_t; // UTF-16 alias dchar utf32_t; // UTF-32

module std.stdbool; /* boolean types */ alias bit bool; // boolean (true/false) alias byte wbool; // wide boolean (like wchar) alias int dbool; // double boolean (like dchar)

module std.stdstr; /* string types */ alias char[] str; // ASCII-optimized alias wchar[] wstr; // Unicode-optimized alias dchar[] dstr; // codepoint-optimized

std.stdint already done, by Walter.

Feb 10 2005

Anders F Björklund wrote:ireal // /

creal // /

[ I don't really expect this rant to be taken serious by anyone, but sorry, I just cannot be silent about the issue... ] Warming up the old topic once again: I still think these two names are absolutely ridiculous. Mathematically speaking, 'imaginary' is the exact opposite of 'real', so talking of a 'ireal' which translates to "imaginary real" is a perfect oxymoron. 'complex' on the other hand is a sum of a 'real' and an 'imaginary' number, so 'creal' is another strange construction leading to the suspicion that the creator of the word never really worked with complex mathematics personally. To make it short, the names 'creal' and 'ireal' will simply lead anyone with some background in mathematics laugh out loud and lead him to refuse taking D serious. My suggestion would still be the old one: rename 'creal' to 'complex' and 'ireal' to 'imaginary' (the latter is hardly ever used explicitely, so the long name won't matter) The old excusion 'Everyone is free to use aliases' does not count here. The language specs sets standards that people will follow. If every library defines their own aliases, confusion will be complete. It they don't that means, that I have to real 'creal' and 'ireal' when I read docs or code written by other people which will simply hurt my eyes. (The names 'cfloat' and 'cdouble' don't matter too much, since they don't contain any internal contradiction)

Feb 10 2005

Norbert Nemec wrote:[ I don't really expect this rant to be taken serious by anyone, but sorry, I just cannot be silent about the issue... ] Warming up the old topic once again: I still think these two names are absolutely ridiculous. Mathematically speaking, 'imaginary' is the exact opposite of 'real', so talking of a 'ireal' which translates to "imaginary real" is a perfect oxymoron.

I agree with you completely, it was hard to write that type table and not notice the total weirdness of "creal is made of real and imaginary" Even the old name of "extended" was better than the current one: "real". I'm just glad that my platform of choice doesn't support them anyway, so I might as well use the regular doubles. But a pity for the rest of you. But if it was changed once, it could be changed again - right ? :-P --anders

Feb 10 2005

In article <cugjt3$8f$1 digitaldaemon.com>, Norbert Nemec says...To make it short, the names 'creal' and 'ireal' will simply lead anyone with some background in mathematics laugh out loud and lead him to refuse taking D serious.

I vote they should be called 'unreal' and 'surreal' instead :~)

Feb 10 2005

"Kris" <Kris_member pathlink.com> wrote in message news:cugku2$1fj$1 digitaldaemon.com...In article <cugjt3$8f$1 digitaldaemon.com>, Norbert Nemec says...To make it short, the names 'creal' and 'ireal' will simply lead anyone with some background in mathematics laugh out loud and lead him to refuse taking D serious.

I vote they should be called 'unreal' and 'surreal' instead :~)

Can't do that. I'm reserving them for aliasing bit and bit[]

Feb 10 2005

Kris wrote:In article <cugjt3$8f$1 digitaldaemon.com>, Norbert Nemec says...To make it short, the names 'creal' and 'ireal' will simply lead anyone with some background in mathematics laugh out loud and lead him to refuse taking D serious.

I vote they should be called 'unreal' and 'surreal' instead :~)

for surreal numbers.

Feb 15 2005

I've used a fair amount of complex math during electronics courses. Now that you mention it, I have to agree with you. I can kind of understand how this happened, though. If I'm not mistaken the "real" in mathematics and the "real" in computer science haven't always been exactly analagous. So the oxymoron that surfaced from the merging of the two was probably accidental and, perhaps, only starkly obvious to a mathematician. I can see a mathematics guy coming along and gasping in horror at the site. Others, I'm sure, have looked at this with mild indifference. Nonetheless, your point is valid. We don't want to scare away the math people! - John R. Norbert Nemec wrote:Anders F Björklund wrote:ireal // /

creal // /

[ I don't really expect this rant to be taken serious by anyone, but sorry, I just cannot be silent about the issue... ] Warming up the old topic once again: I still think these two names are absolutely ridiculous. Mathematically speaking, 'imaginary' is the exact opposite of 'real', so talking of a 'ireal' which translates to "imaginary real" is a perfect oxymoron. 'complex' on the other hand is a sum of a 'real' and an 'imaginary' number, so 'creal' is another strange construction leading to the suspicion that the creator of the word never really worked with complex mathematics personally. To make it short, the names 'creal' and 'ireal' will simply lead anyone with some background in mathematics laugh out loud and lead him to refuse taking D serious. My suggestion would still be the old one: rename 'creal' to 'complex' and 'ireal' to 'imaginary' (the latter is hardly ever used explicitely, so the long name won't matter) The old excusion 'Everyone is free to use aliases' does not count here. The language specs sets standards that people will follow. If every library defines their own aliases, confusion will be complete. It they don't that means, that I have to real 'creal' and 'ireal' when I read docs or code written by other people which will simply hurt my eyes. (The names 'cfloat' and 'cdouble' don't matter too much, since they don't contain any internal contradiction)

Feb 10 2005

John Reimer wrote:I've used a fair amount of complex math during electronics courses. Now that you mention it, I have to agree with you. I can kind of understand how this happened, though. If I'm not mistaken the "real" in mathematics and the "real" in computer science haven't always been exactly analagous.

http://en.wikipedia.org/wiki/Real_number says:In mathematics, the real numbers are intuitively defined as numbers that are in one-to-one correspondence with the points on an infinite lineâ€”the number line. The term "real number" is a retronym coined in response to "imaginary number".

Both float and double are equally "real numbers" too. Q for Walter: Why really was the old name of "extended" abandoned ? It fits well with single (float), double, extended precision to me. iextended and cextended might not be the shortest, but they are not as silly as "imaginary real" (ireal). Just a thought. Tue, 21 Jan 2003 "Walter" <walter digitalmars.com> writes:I've never particularly liked the 'extended' keyword for 80 bit floats, and there is a lot of interest in complex floats and complex doubles. So, I'm thinking of renaming and adding a few types: extended = no longer a keyword real = 80 bit floating point cfloat = complex float cdouble = complex double creal = complex real ifloat = imaginary float idouble = imaginary double ireal = imaginary real This would be consistent with the way 'u' is used as a prefix for unsigned. Any thoughts? Objections? Flames <g>?

http://www.digitalmars.com/d/archives/10261.html --anders

Feb 10 2005

Anders F BjÃ¶rklund wrote:John Reimer wrote:I've used a fair amount of complex math during electronics courses. Now that you mention it, I have to agree with you. I can kind of understand how this happened, though. If I'm not mistaken the "real" in mathematics and the "real" in computer science haven't always been exactly analagous.

http://en.wikipedia.org/wiki/Real_number says:

In mathematics, the real numbers are intuitively defined as numbers that are in one-to-one correspondence with the points on an infinite lineâ€”the number line. The term "real number" is a retronym coined in response to "imaginary number".

That does state it quite clearly, doesn't it. :-)Both float and double are equally "real numbers" too.

Yes, but float and double are computer science terms. The mistake was treating "real" as having the same heritage as those two types. The progression becomes inappropriate, especially with the mathematical definiton of "real" being so clear. It looks like "real" was used to describe a hardware register size... Perhaps this was a clumsy moniker that Intel choose? I don't know for sure.Q for Walter: Why really was the old name of "extended" abandoned ? It fits well with single (float), double, extended precision to me. iextended and cextended might not be the shortest, but they are not as silly as "imaginary real" (ireal). Just a thought. Tue, 21 Jan 2003 "Walter" <walter digitalmars.com> writes:I've never particularly liked the 'extended' keyword for 80 bit floats, and there is a lot of interest in complex floats and complex doubles. So, I'm thinking of renaming and adding a few types: extended = no longer a keyword real = 80 bit floating point cfloat = complex float cdouble = complex double creal = complex real ifloat = imaginary float idouble = imaginary double ireal = imaginary real This would be consistent with the way 'u' is used as a prefix for unsigned. Any thoughts? Objections? Flames <g>?

http://www.digitalmars.com/d/archives/10261.html --anders

Feb 10 2005

Maybe everyone knows this but I thought I'd jump in.Both float and double are equally "real numbers" too.

Which is to say, not real numbers at all. (-:Yes, but float and double are computer science terms. The mistake was treating "real" as having the same heritage as those two types. The progression becomes inappropriate, especially with the mathematical definiton of "real" being so clear. It looks like "real" was used to describe a hardware register size... Perhaps this was a clumsy moniker that Intel choose? I don't know for sure.

I'm not sure if "real" is used in D right now, but "float" is appropriately non-committal. Since there are an infinite number of real values between any two real numbers, you can never truly express them in a computer. The astute reader is now thinking that there are an infinite number of integers as well, but we have "int". As it turns out we should probably have avoided "int" and stuck with the computer science terms "float" and "fixed" for real and integer. In both cases you are simply trying to use an allotted number of bits to express a slice of an infinite number. For integers you can used a "fixed" notation - base 2 - that is in the range [-(2^n)/2 - 1, (2^n)/2]. This turns out very useful, although it can't really handle any integer, and the user has to pick bigger "fixed" notations (8-bit, 32-bit) if he needs them. For reals you can use a mixed notation that holds the exponent and an integer, such as 4.301 x 10^23. You store 4301 like a fixed number in some of the bits, then the exponent also. Special math co-processors can handle this mixed style quickly. Notice that you can only have so much precision (4301) but you give up bits for the exponent so you can "float" it up and down the number scale (10^-5 means .0004301). Also note that the larger (positive or negative) the number, the less accuracy there is between each two consecutive numbers you can represent. Again, not a real number, but a good representation for many uses and again you can use more bits if a program needs it. Phew. Just remembering a day when specific things meant specific things.

Feb 10 2005

Charlie Patterson wrote:Both float and double are equally "real numbers" too.

Which is to say, not real numbers at all. (-:

How does "sample approximations of" feel for you ? :-) Otherwise you'd soon be saying that the image I'm seeing is not real and the sound I'm hearing is not real either. (since they're just samples of the continuous reality...) http://en.wikipedia.org/wiki/Image:MagrittePipe.jpg --anders PS. As a side note, Mac OS X is using float for sounds now and will be using float RGB values for images in 10.4. It's really good when working with lots of filters, since the loss is *much* smaller than with integers... http://www.apple.com/macosx/features/audio/ http://www.apple.com/macosx/tiger/coreimage.html (at this rate, Apple is *got* to start paying me soon!)

Feb 10 2005

"Anders F Björklund" <afb algonet.se> wrote in message news:cugpih$6j1$1 digitaldaemon.com...Charlie Patterson wrote:Both float and double are equally "real numbers" too.

Which is to say, not real numbers at all. (-:

How does "sample approximations of" feel for you ? :-) Otherwise you'd soon be saying that the image I'm seeing is not real and the sound I'm hearing is not real either. (since they're just samples of the continuous reality...)

Heh. I'm not aware of image or sound being scientifically specific terms like real and integer are.

Feb 11 2005

Norbert Nemec wrote:Warming up the old topic once again:

Here is the old thread, just in case anyone else is searching for it: http://www.digitalmars.com/d/archives/28044.html (21 Apr 2004)The old excusion 'Everyone is free to use aliases' does not count here. The language specs sets standards that people will follow. If every library defines their own aliases, confusion will be complete. It they don't that means, that I have to real 'creal' and 'ireal' when I read docs or code written by other people which will simply hurt my eyes.

The "old solution" was: alias real extended; alias creal complex; alias ireal imaginary; What ever happened to the simple : "cextended" and "iextended" ? As in:Real Numbers: float // 32-bit single precision (about 6 digits) double // 64-bit double precision (about 15 digits) extended // 64/80/128-bit extended precision (platform) ifloat // \ idouble // imaginary versions of the above iextended // / cfloat // \ cdouble // complex (both real and imaginary parts) cextended // /

Kinda sad that this war has been going on for almost two years ? (I'm not sure if that is longer than the Boolean War, but still) --anders

Feb 10 2005

Kinda sad that this war has been going on for almost two years ? (I'm not sure if that is longer than the Boolean War, but still)

It's not!

Feb 10 2005

Here is the revised list of type aliases and names: TYPE ALIAS // RANGE Floating Point: (std.stdfloat) float // 32-bit single precision (about 6 digits) double // 64-bit double precision (about 15 digits) extended real // 64/80/128-bit extended precision (platform) ifloat // \ idouble // imaginary versions of the above iextended imaginary // / cfloat // \ cdouble // complex (both real and imaginary parts) cextended complex // / This way, Walter can avoid the "extended" name that he doesn't like, while D can avoid looking silly... Thank heavens the DMD code only talks about: TOKfloat32 TOKfloat64 TOKfloat80 And avoids the religously colored words, mostly. Note that extended==double, on PowerPC and Sparc. --anders Implementation:module std.stdfloat; /* floating point types */ alias extended real; alias iextended imaginary; alias cextended complex;

Feb 10 2005

Anders F Björklund wrote:Thank heavens the DMD code only talks about: TOKfloat32 TOKfloat64 TOKfloat80

Actually, I would prefer that kind of naming for all the types. If the specs define the various integer and floating point types by the bit-length, it would be the clearest if the original names for the types did reflect this (int8, int16, int32, uint8, uint16, uint32, float32, float64, ...) The only uglyness of that comes in with complex, where it is not completely obvious whether complex64 means on complex made up of two float64 or one complex that has a total of 64 bits. All the other names like int, long, float, double and so on could then be defined as aliases depending on the taste of the library author. The language specs would be simpler and more definite. (It might be up to the implementation whether certain types exist, but not what they mean.) And there would be less confusion with C/C++, where the definitions of the types are usually similar but not platform independent. Anyhow, at this point I really did not want to touch this old subject in its entirety, but restrict myself to the killer absurdities: 'creal' and 'ireal'

Feb 11 2005

Norbert Nemec wrote:Actually, I would prefer that kind of naming for all the types. If the specs define the various integer and floating point types by the bit-length, it would be the clearest if the original names for the types did reflect this (int8, int16, int32, uint8, uint16, uint32, float32, float64, ...)

There are *already* perfectly usable int alternatives, in std.stdint ? std.stdfloat could add: float32_t, float64_t, float80_t (where "80" is not always the bit size) real32_t, real64_t, real80_t (same as "float") imag32_t, imag32_t, imag80_t (for "imaginary") comp32_t, comp64_t, comp80_t (for "complex") As you saw in the table I posted, I suggested doing the same for UTF...The only uglyness of that comes in with complex, where it is not completely obvious whether complex64 means on complex made up of two float64 or one complex that has a total of 64 bits.

I think this is pretty straightforward, that is uses two of the original types. Complex is not even a single literal, but made up from one real and one imaginary that is then added together at runtime. (1.0 + 1.0i)All the other names like int, long, float, double and so on could then be defined as aliases depending on the taste of the library author. The language specs would be simpler and more definite. (It might be up to the implementation whether certain types exist, but not what they mean.) And there would be less confusion with C/C++, where the definitions of the types are usually similar but not platform independent.

I think the opposite is path of least resistance, would work the same? And since everyone else on the planet is using "extended" (well, except C that uses "long double" but anyway)- why couldn't D just use the same? For ultimate coherence, could even offer "single" as a name for float ?Anyhow, at this point I really did not want to touch this old subject in its entirety, but restrict myself to the killer absurdities: 'creal' and 'ireal'

Yes, those two have *got* to die... "cereal" and "irreal" ? I can't imagine how Walter kept a straight face while posting:So, I'm thinking of renaming and adding a few types: extended = no longer a keyword real = 80 bit floating point creal = complex real ireal = imaginary real

As in: "a complex real is made from a real real and an imaginary real" ? --anders

Feb 11 2005

"Norbert Nemec" <Norbert Nemec-online.de> wrote in message news:cugjt3$8f$1 digitaldaemon.com...Anders F Björklund wrote:ireal // /

creal // /

[ I don't really expect this rant to be taken serious by anyone, but sorry, I just cannot be silent about the issue... ] Warming up the old topic once again: I still think these two names are absolutely ridiculous. Mathematically speaking, 'imaginary' is the exact opposite of 'real', so talking of a 'ireal' which translates to "imaginary real" is a perfect oxymoron. 'complex' on the other hand is a sum of a 'real' and an 'imaginary' number, so 'creal' is another strange construction leading to the suspicion that the creator of the word never really worked with complex mathematics personally. To make it short, the names 'creal' and 'ireal' will simply lead anyone with some background in mathematics laugh out loud and lead him to refuse taking D serious. My suggestion would still be the old one: rename 'creal' to 'complex' and 'ireal' to 'imaginary' (the latter is hardly ever used explicitely, so the long name won't matter)

Sounds ok to me. Are there any significant objections to this that Norbert's not seen??The old excusion 'Everyone is free to use aliases' does not count here. The language specs sets standards that people will follow. If every library defines their own aliases, confusion will be complete. It they don't that means, that I have to real 'creal' and 'ireal' when I read docs or code written by other people which will simply hurt my eyes.

It it looks daft to mathematicians, that's a con. If they're not in a position where there are some pros to spare, it may be the con that breaks the camel's back. Mr Metaphor Mixer

Feb 10 2005