www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [suggestion] std type aliases

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
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
next sibling parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
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
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
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 
 
 :~)
 
 


I believe that mathematicians already have a (different) meaning 
for surreal numbers.
Feb 15 2005
prev sibling next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
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
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
parent reply John Reimer <brk_6502 yahoo.com> writes:
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
parent reply "Charlie Patterson" <charliep1 excite.com> writes:
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
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
parent "Charlie Patterson" <charliep1 excite.com> writes:
"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
prev sibling next sibling parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


 Warming up the old topic once again:



 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.


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
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 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
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
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
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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