www.digitalmars.com         C & C++   DMDScript  

D - complex, imaginary, and extended

reply "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>?
Jan 21 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
what about parameterising them

float => float(32)/real(32)   or even float(1,8,23)
double => float(64)
extended => float(80)
cdouble => complex( float(32 ) ) will be a pair of float(32) and
imaginary( float(32) )

or is this too verbose

I do think complex should be parameterised.
complex( float ), complex( double ), complex( real )

etc;
fixed 16:16 might be a nice type to add too, it useful for fast inaccurate
maths, the Tao intent VM has it as a type
and fixed16:16 * fixed16:16 can be a pain
not all C compilers get what you trying to do when you type __int64 = (int *
int) >>16; so can introduce int->__int64 (long long) promotions before the
multiply etc.



"Walter" <walter digitalmars.com> wrote in message
news:b0j4mv$2e1v$1 digitaldaemon.com...

 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>?
Jan 21 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b0j5oc$2eke$1 digitaldaemon.com...

 what about parameterising them

 float => float(32)/real(32)   or even float(1,8,23)
 double => float(64)
 extended => float(80)
 cdouble => complex( float(32 ) ) will be a pair of float(32) and
 imaginary( float(32) )


A lot of people like the idea of adding the number of bits to the keyword in
one form or another. While it's a practical suggestion, I just don't like
the way it looks.


 or is this too verbose

 I do think complex should be parameterised.
 complex( float ), complex( double ), complex( real )


Then it's inconsistent with the way ints and uints are done.


 etc;
 fixed 16:16 might be a nice type to add too, it useful for fast inaccurate
 maths, the Tao intent VM has it as a type
 and fixed16:16 * fixed16:16 can be a pain
 not all C compilers get what you trying to do when you type __int64 = (int


*

 int) >>16; so can introduce int->__int64 (long long) promotions before the
 multiply etc.


Ak!
Jan 21 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
A lot of people like the idea of adding the number of bits to the keyword in
one form or another. While it's a practical suggestion, I just don't like
the way it looks.


Hmm, well, you admit that it's practical and lots of people like it but it
offends your fashion sense so out it goes! <g>  Oh well.  You are the Dictator
of D and rightly so since you are doing all the work and we're just talkers.

Given that constraint, maybe RealReduced, Real, RealEnhanced, ComplexReduced,
Complex, ComplexEnhanced.  Nice and vague, no CPU dependencies, no numbers.
Reduced = single precision, Enhanced = extended precision, default = double
precision.

M.
Jan 21 2003
parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:b0kar8$2h6$1 digitaldaemon.com...

A lot of people like the idea of adding the number of bits to the keyword




in

one form or another. While it's a practical suggestion, I just don't like
the way it looks.


 Hmm, well, you admit that it's practical and lots of people like it but it
 offends your fashion sense so out it goes! <g>  Oh well.  You are the


Dictator

 of D and rightly so since you are doing all the work and we're just


talkers.

Check out stdint.d which has those aliases for people who prefer them.
Jan 21 2003
prev sibling parent reply "Carlos" <carlos8294 msn.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> escribió en el mensaje
news:b0j5oc$2eke$1 digitaldaemon.com...
| what about parameterising them
|
| float => float(32)/real(32)   or even float(1,8,23)
| double => float(64)
| extended => float(80)
| cdouble => complex( float(32 ) ) will be a pair of float(32) and
| imaginary( float(32) )
|
|

I'm not quite sure if I agree or disagree. If I look forward, then I have to
say yes. Because in my future there's the real world where (at least so I
think) you want to have everything you might need. But if I look back, I
have to say no. Because I'm still a student and my friends are students. I
didn't have much problem learning C because I was already familiar to
programming, but for them having C has their first language was painful
as... as it is :-).
What I'm trying to say is it'd be good for experts, but not so good for
beginners. Experts will love it: having the exact amount of space they need.
But beginners will drop D in less than a week.

As for complexes, if D has a good implementation of complexes (I haven't
checked), they should be supported in the language. I mean... Fortran has
them. But if (as many claim) complexes need more special features, then they
shouldn't be a part of the language.

—————————————————————————
Carlos Santander
http://carlos3.netfirms.com/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.445 / Virus Database: 250 - Release Date: 2003-01-21
Jan 21 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Carlos wrote:

 "Mike Wynn" <mike.wynn l8night.co.uk> escribi=F3 en el mensaje
 news:b0j5oc$2eke$1 digitaldaemon.com...
 | what about parameterising them
 |
 | float =3D> float(32)/real(32)   or even float(1,8,23)
 | double =3D> float(64)
 | extended =3D> float(80)
 | cdouble =3D> complex( float(32 ) ) will be a pair of float(32) and
 | imaginary( float(32) )
 |
 |
=20
 I'm not quite sure if I agree or disagree. If I look forward, then I ha=


ve to

 say yes. Because in my future there's the real world where (at least so=


 I

 think) you want to have everything you might need. But if I look back, =


I

 have to say no. Because I'm still a student and my friends are students=


=2E I

 didn't have much problem learning C because I was already familiar to
 programming, but for them having C has their first language was painful=



 as... as it is :-).
 What I'm trying to say is it'd be good for experts, but not so good for=



 beginners. Experts will love it: having the exact amount of space they =


need.

 But beginners will drop D in less than a week.


Women would hate it. But why beginners? When I was a Delphi beginner=20
(=3Dabsolute beginner), i liked one part of the type system and hated=20
another. There are types, which are assumed to be the most optimal for a =

machine, whatever machine it is. On 32-bit Intel:
  - Integer: a 32-bit signed integer; (well done!)
  - Cardinal: same as Integer, but unsigned; (fine concept, stupid name!)=

These two are "generic" types, which should be used when no matter.

And then a mess of fixed-size types:
  - Byte: it is what it is, unsigned; (well done!)
  - Word: it is what it is, unsigned; (well done!)
  - ShortInt: signed byte; (nonsense name!)
  - SmallInt: signed word; (always mix up these two!)
  - LongInt: a signed doubleword; (not much better)

And as for FP, there was no generic type. Only "Single", "Double",=20
"Extended", and a couple of obscure types for extended-encoded integers=20
and alike, completely purposeless when operator overloading exists.

To my opinion, C type names were as nonsense as Delphi as I learned=20
them. *You shouldn't expect a novice to be unable to count, but rather=20
to be confused by absense of a system. Someone who can't count shouldn't =

programme anyway!* It is good when types contain a measure. I could=20
already take a 2^num back then, and this would be my guide for a range.

IMO, a unsigned generic type is not really requiered, but might be OK.

So, there should be at least "generic" types representing the following:
  - signed integer;
  - extended real;
  - extended imaginary;
  - extended complex.
Possibly a unsigned integer, although i think "unsigned" belogs rather=20
into the space considerations, and hence is not necessarily requiered as =

a generic.

A notation with parenthesis makes sense, as it enables a use in=20
templates with integral parameters.

Another question is what to be a parameter: number of bits (high visual=20
contrast), or the number of bytes (easy to count with)? I find the=20
second appropriate. Else you could also do something like:
typedef bit[32] int;
and then overload all operations :>

BTW, this might be an idea when taken seriously, so that a bit aray is=20
an arbitrary-size integer. ;) Well, it makes the language too obscure,=20
but who cares, we've got C, Perl and OCaml and maybe even Befunge guys=20
over here. :>

IMO, the Windows type naming convention is, when not taken further with=20
those P... and FP... types is rather okay. It has "byte", "word",=20
"dword", and "qword" (cont. would be "hword"), all are signed, and=20
unsigned variations exist. In the beginning i found anything beyond=20
"word" pretty awful though.

"Single", "double", and "extended" are OK for FP values (though hardly=20
natural unless you know that they are X precision IEEE blah blah blah),=20
and "real" should denote a generic FP type, it's a very natural name for =

it, especially when complex support is native.

OK, so i've shared my impressions.
-i.




 As for complexes, if D has a good implementation of complexes (I haven'=


t

 checked), they should be supported in the language. I mean... Fortran h=


as

We're discussing a concept, not implementation. But Walter makes good=20
implementations, and complex support is trusty and comes directly from=20
his C compiler.


 them. But if (as many claim) complexes need more special features, then=


 they

 shouldn't be a part of the language.


Do they need? Why shouldn't they just be? Well, with a "var" type=20
support they would become not really much more efficient than a library=20
implementation, but better keep them.


=20
 =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=


=97

 Carlos Santander
 http://carlos3.netfirms.com/
=20
=20
 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.445 / Virus Database: 250 - Release Date: 2003-01-21
=20
=20
Jan 21 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 IMO, the Windows type naming convention is, when not taken further with
 those P... and FP... types is rather okay. It has "byte", "word",
 "dword", and "qword" (cont. would be "hword"), all are signed, and
 unsigned variations exist. In the beginning i found anything beyond
 "word" pretty awful though.


Word is a dangerous `word`; not all architectures use the win32/x86 16 bit
word convention;
on the Arm CPU's the types are
byte (as ever 8 bits)
word ( 32 bits )
halfword( 16bits )
doubleword( 64 bits )

there is an Arm linux (I know of one machine the strong arm netwinders) and
Arm CE, and I see Palm are moving from 68k to Arm based arch in their PDA's

getting the language architecturally neutral to me would be a good thing
Jan 21 2003
prev sibling parent reply Antti Sykari <jsykari gamma.hut.fi> writes:
 Carlos wrote:

 "Mike Wynn" <mike.wynn l8night.co.uk> escribió en el mensaje
 news:b0j5oc$2eke$1 digitaldaemon.com...
 | what about parameterising them
 |
 | float => float(32)/real(32)   or even float(1,8,23)
 | double => float(64)
 | extended => float(80)
 | cdouble => complex( float(32 ) ) will be a pair of float(32) and
 | imaginary( float(32) )




I'd like to propose the question: Are the basic types really worth
parameterizing?  There are not so many of them that can be implemented
in a straightforward manner.  Those would be integers of size 8, 16,
32 and 64 on current architectures.  And those we already have,
although in my opinion it would be rational to name them just int8,
int16, int32 and int64.  (uints similarly.)  And reserve int128, etc.,
if someone decides to introduce them one day.

Integers of variable sizes (with any amount of bits)
- are not needed often
- introduce unnecessary burden for the implementor
- can be implemented as a separate type and are hence unnecessary
- have to be introduced to novices in an awkward way ("here are the
integer types; you should only use integer types of these special
sizes if you want that accessing and counting with them is efficient")

They would be useful in bitfields, though, but seems to me a special
case which would of use mostly in low-level structs, and can hence be
handled by other means.

And then again, a general-purpose integer (which is 32 bits now,
possibly 8 bits on a microwave, 16 bits on an MC68000 based system and
64 bits in a couple of years) should be simply called "int".

Or "Int" if one believes that consistency with capitalized type names
is really really important.

I believe that the reason that there are no bit sizes spelled out in
the basic types is legacy.  After all, at the time when C was designed
there were some pretty peculiar machines around, including ones with
36 bit words, so having things like int8 (or even byte, since a byte
could have been from 6 to 12 bits), int16 and int32 wouldn't have been
probably reasonable.

After that, everybody's been plagiarizing the C names, so as a result,
we have int, short, long and even monstrosities such as "unsigned long
long"...

But now we can pretty much assume that everything is a power of two,
even on small embedded devices. (I think -- if someone knows of some
really weird processor, please enlighten us.)

Ilya Minkov <midiclub 8ung.at> writes:

 And then a mess of fixed-size types:
   - Byte: it is what it is, unsigned; (well done!)


'byte' (as in 8-bits, or 'officially' octet) is a Good Thing to have
in a language; it's probably here to stay.


   - Word: it is what it is, unsigned; (well done!)


But of 'word' I don't think of so kindly, because it can (as has been
pointed out) mean practically anything.  Besides, word sounds a
microsoftism (because of its usage in DWORD and what you have in the
Windows APIs).  Yech ;)


 So, there should be at least "generic" types representing the following:
   - signed integer;
   - extended real;
   - extended imaginary;
   - extended complex.
 Possibly a unsigned integer, although i think "unsigned" belogs rather
 into the space considerations, and hence is not necessarily requiered
 as a generic.


Unsigned can also serve as documentation, in which it's pretty much
the same as the precondition (x >= 0) but more terse; consider:

interface TForwardIterator
{
  T get();
  void advance() { advance(1); }
  void advance(uint steps);
  bool valid();
}

as opposed to

interface TForwardIterator
{
  T get();
  void advance() { advance(1); }
  in { assert(steps >= 0); }
  void advance(int steps);
  bool valid();
}

(Note the shameless usage of code inside an interface ;)

In addition, I prefer doing my bit operations on unsigned integers
although this might be just old C superstition.  Hmm.  You might not
have meant what I assumed -- I considered your proposal to be
"dropping the whole concept of unsigned from the language", which
might have been wrong :)

-Antti
Jan 22 2003
next sibling parent Ilya Minkov <midiclub tiscali.de> writes:
Antti Sykari wrote:

Carlos wrote:


 I'd like to propose the question: Are the basic types really worth
 parameterizing?  There are not so many of them that can be implemented
 in a straightforward manner.  Those would be integers of size 8, 16,
 32 and 64 on current architectures.  And those we already have,
 although in my opinion it would be rational to name them just int8,
 int16, int32 and int64.  (uints similarly.)  And reserve int128, etc.,
 if someone decides to introduce them one day.


The only use is in conjunction with int-parametrized templates.


 Integers of variable sizes (with any amount of bits)
 - are not needed often
 - introduce unnecessary burden for the implementor


There exists a "simplified" implementation, which is easy, limited to 
sizes which make sense.


 - can be implemented as a separate type and are hence unnecessary
 - have to be introduced to novices in an awkward way ("here are the
 integer types; you should only use integer types of these special
 sizes if you want that accessing and counting with them is efficient")


They don't need to be introduced to novices, novices are to be 
introduced the generic types. Do you think a nothing-meaning name would 
say a novice: "Here you may only put numbers in range from .. to .."?
How long is unsigned long long? As long as its name or even longer? :>

These simplified names are only OK for FP, where you can (more or less) 
always assume you have enough range, but you need more or less precision 
- it doesn't affect too much.


 They would be useful in bitfields, though, but seems to me a special
 case which would of use mostly in low-level structs, and can hence be
 handled by other means.


They are already taken care of, with bitarray. But bitarrays of cerain 
sizes might mutate to integers :>


 And then again, a general-purpose integer (which is 32 bits now,
 possibly 8 bits on a microwave, 16 bits on an MC68000 based system and
 64 bits in a couple of years) should be simply called "int".


Right!


 Or "Int" if one believes that consistency with capitalized type names
 is really really important.


The Emperor is do decide that.


 I believe that the reason that there are no bit sizes spelled out in
 the basic types is legacy.  After all, at the time when C was designed
 there were some pretty peculiar machines around, including ones with
 36 bit words, so having things like int8 (or even byte, since a byte
 could have been from 6 to 12 bits), int16 and int32 wouldn't have been
 probably reasonable.


Do you call this "words"? My fist computer is now as old as I am - 
twenty. I got it 12 years ago, and since i've read its manual back then 
i'm pretty much sure a "word" in a general sense is 2 bytes. Though it 
wasn't the "processor's word", which was 8. That's what leads to 
confusion, is that "word" has 2 meanings. And no, there was no Microsoft 
back then.


 After that, everybody's been plagiarizing the C names, so as a result,
 we have int, short, long and even monstrosities such as "unsigned long
 long"...
 
 But now we can pretty much assume that everything is a power of two,
 even on small embedded devices. (I think -- if someone knows of some
 really weird processor, please enlighten us.)


That's what systems D is created for. D is not supposed to support some 
less-than-32-bit wizardry.


 Unsigned can also serve as documentation, in which it's pretty much
 the same as the precondition (x >= 0) but more terse; consider:


Right, but novices are not concerned.


 In addition, I prefer doing my bit operations on unsigned integers
 although this might be just old C superstition.  Hmm.  You might not
 have meant what I assumed -- I considered your proposal to be
 "dropping the whole concept of unsigned from the language", which
 might have been wrong :)


Well, a MUL is a bit faster than IMUL. And shifts become non-ambiguous. 
It is good to use unsigned when you know what to use it for, just as 
with width-named integers. You don't leave unsigned out when you don't 
make it available as "generic". It just stays with width-named types.

BTW, I think that FP numbers have to have vague names, because their 
precision and range are not so bit-critical as with integers. Like 
single, double, extended.

-i.


 
 -Antti
Jan 22 2003
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Antti Sykari" <jsykari gamma.hut.fi> wrote in message
news:86el75o7mw.fsf hoastest1-8c.hoasnet.inet.fi...

 Carlos wrote:

 "Mike Wynn" <mike.wynn l8night.co.uk> escribió en el mensaje
 news:b0j5oc$2eke$1 digitaldaemon.com...
 | what about parameterising them
 |
 | float => float(32)/real(32)   or even float(1,8,23)
 | double => float(64)
 | extended => float(80)
 | cdouble => complex( float(32 ) ) will be a pair of float(32) and
 | imaginary( float(32) )




 I'd like to propose the question: Are the basic types really worth
 parameterizing?  There are not so many of them that can be implemented
 in a straightforward manner.  Those would be integers of size 8, 16,
 32 and 64 on current architectures.  And those we already have,
 although in my opinion it would be rational to name them just int8,
 int16, int32 and int64.  (uints similarly.)  And reserve int128, etc.,
 if someone decides to introduce them one day.


at first I though you disiked int(32)/int32 and int(16)/16
but realised you mean allowing int(3) or int(6)
that was not my plan,
int(n) where n is 8*(2^N) where N 0..3 (or bigger) (auto promotion to
phobos::bn ?)


 Integers of variable sizes (with any amount of bits)
 - are not needed often
 - introduce unnecessary burden for the implementor
 - can be implemented as a separate type and are hence unnecessary
 - have to be introduced to novices in an awkward way ("here are the
 integer types; you should only use integer types of these special
 sizes if you want that accessing and counting with them is efficient")

 They would be useful in bitfields, though, but seems to me a special
 case which would of use mostly in low-level structs, and can hence be
 handled by other means.

 And then again, a general-purpose integer (which is 32 bits now,
 possibly 8 bits on a microwave, 16 bits on an MC68000 based system and
 64 bits in a couple of years) should be simply called "int".


no, not back to an int is not longer than a long and no short than a short!
fixed sizes are much much better (allowing a version to detect the CPU int
size is OK for those who care about how efficient operations that do not
require fixed widths, of can be perfroms more efficiently with longer ints)


 Or "Int" if one believes that consistency with capitalized type names
 is really really important.

 I believe that the reason that there are no bit sizes spelled out in
 the basic types is legacy.  After all, at the time when C was designed
 there were some pretty peculiar machines around, including ones with
 36 bit words, so having things like int8 (or even byte, since a byte
 could have been from 6 to 12 bits), int16 and int32 wouldn't have been
 probably reasonable.

 After that, everybody's been plagiarizing the C names, so as a result,
 we have int, short, long and even monstrosities such as "unsigned long
 long"...

 But now we can pretty much assume that everything is a power of two,
 even on small embedded devices. (I think -- if someone knows of some
 really weird processor, please enlighten us.)


I have heard tails of a 17 bit CPU, (the history was the original designers
put a 17bit memory bus to allow parity checking, the management said, if its
got 17 bits, it should use them all parity is a waste (so they put in a 17
bit alu))

not idea about the addressing or if it had byte support.


 Ilya Minkov <midiclub 8ung.at> writes:

 And then a mess of fixed-size types:
   - Byte: it is what it is, unsigned; (well done!)


 'byte' (as in 8-bits, or 'officially' octet) is a Good Thing to have
 in a language; it's probably here to stay.


   - Word: it is what it is, unsigned; (well done!)


 But of 'word' I don't think of so kindly, because it can (as has been
 pointed out) mean practically anything.  Besides, word sounds a
 microsoftism (because of its usage in DWORD and what you have in the
 Windows APIs).  Yech ;)


 So, there should be at least "generic" types representing the following:
   - signed integer;
   - extended real;
   - extended imaginary;
   - extended complex.
 Possibly a unsigned integer, although i think "unsigned" belogs rather
 into the space considerations, and hence is not necessarily requiered
 as a generic.


 Unsigned can also serve as documentation, in which it's pretty much
 the same as the precondition (x >= 0) but more terse; consider:

 interface TForwardIterator
 {
   T get();
   void advance() { advance(1); }
   void advance(uint steps);
   bool valid();
 }

 as opposed to

 interface TForwardIterator
 {
   T get();
   void advance() { advance(1); }
   in { assert(steps >= 0); }
   void advance(int steps);
   bool valid();
 }

 (Note the shameless usage of code inside an interface ;)

 In addition, I prefer doing my bit operations on unsigned integers
 although this might be just old C superstition.  Hmm.  You might not
 have meant what I assumed -- I considered your proposal to be
 "dropping the whole concept of unsigned from the language", which
 might have been wrong :)


Java has no unsigned int values (well char is an unsigned storage value,
causes zero extension to int)
90% of the time its ok;
checking that x >= 0 and x <= range(unsigned) can not be coded as (
(unsigned)x < range )
and you have a put a few &0xFFFF 's places

what about the following

int32 i;
int16 smaller = -1;

 i = j + k;   // always signed operations;
i = j & foo;  // always unsigned operations
i = smaller;  // signed extension
i = unsigned( smaller ); // i will now be 0x0000FFFF same effect as writing
i = smaller & 0xFFFF;

i = smaller & 0xFF000000; (& is unsigned so will be 0x00000000 if smaller
is -1)
i = cast(int32)smaller & 0xFF000000 ( promotes to int32 signed so i =
0xFF000000);
i = smaller + 2 ( promotes to int32 signed so i = 1);
i = unsigned(int32)smaller + 2 ( promotes to int32 unsigned so i =
0x00010001);

smaller = cast(int16)i;  // smaller loaded with the lower 16bits (so sign
change may occur)


if ( i < j ) // signed extension if reqd

if ( i unsigned(<) j ) // zero extension if reqd




 -Antti
Jan 22 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 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


Hell yes.


 cfloat =  complex float
 cdouble = complex double
 creal = complex real
 ifloat = imaginary float
 idouble = imaginary double
 ireal = imaginary real


complex hasn't been used enough yet.  Adding to it violates your rule of 
never adding a feature that isn't actually necessary.
Jan 21 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b0jaqq$2gro$1 digitaldaemon.com...

 complex hasn't been used enough yet.  Adding to it violates your rule of
 never adding a feature that isn't actually necessary.


Complex and imaginary are part of standard C99.
Jan 21 2003
parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:b0jaqq$2gro$1 digitaldaemon.com...
 

complex hasn't been used enough yet.  Adding to it violates your rule of
never adding a feature that isn't actually necessary.


 
 Complex and imaginary are part of standard C99.


The C pre-processor is part of standard C99.
Jan 21 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3E2DD8CB.4060308 users.sourceforge.net...

 Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:b0jaqq$2gro$1 digitaldaemon.com...

complex hasn't been used enough yet.  Adding to it violates your rule of
never adding a feature that isn't actually necessary.


 Complex and imaginary are part of standard C99.


 The C pre-processor is part of standard C99.


Ouch!
Jan 22 2003
parent Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:3E2DD8CB.4060308 users.sourceforge.net...
 

Walter wrote:


"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b0jaqq$2gro$1 digitaldaemon.com...


complex hasn't been used enough yet.  Adding to it violates your rule of
never adding a feature that isn't actually necessary.


Complex and imaginary are part of standard C99.


The C pre-processor is part of standard C99.


 
 
 Ouch!


Don't take it personally, but we have operator overloading and good 
complex constants syntax.  The only things float/double complex would 
provide in D would be storage, some syntax, and builtin array 
arithmetic: there would be four more types to support for the array 
arithmetic operations, six if you accept user demand for these 
operations being as efficient as possible and put in a separate mode for 
operating on a complex array with a real.

It's not much of a complicating factor, but it'd certainly take a lot 
more code to support than, for example, generic argument lists.  ;-)
Jan 22 2003
prev sibling next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
Well you can dig up my naming ideas from many moons ago <g>.  Real32, Real64,
RealCPUMax, Complex32, Complex64, ComplexCPUMax.  Something like that. 

Mark
Jan 21 2003
parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:b0k7v6$dq$1 digitaldaemon.com...

 Well you can dig up my naming ideas from many moons ago <g>.  Real32,


Real64,

 RealCPUMax, Complex32, Complex64, ComplexCPUMax.  Something like that.


With what, 7000 messages here now (!), I'm sure I overlook things already
posted. Sorry.
Jan 21 2003
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 ifloat = imaginary float
 idouble = imaginary double
 ireal = imaginary real


I wonder about these. How often does one work with in the pure imaginary
numbers for more than a single operation or two? I would get by just fine
with just the other 6 (pure real and complex of different precisions). Does
any other language have pure imaginary types? I don't know off-hand.

-Ben
Jan 21 2003
next sibling parent Mark Evans <Mark_member pathlink.com> writes:
I wonder about them too.  They seem to violate the principle of minimalism in
the language design.

Sometimes one must lop off numerical errors when a complex result is known to be
pure real or imaginary, confident in the knowledge that any (small) residual is
roundoff error.  That is easy enough with complex numbers.  As long as D offers
polar and rectangular complex numbers, I am happy and don't need pure
imaginaries.

Mark

Ben Hinkle says...

 ifloat = imaginary float
 idouble = imaginary double
 ireal = imaginary real


I wonder about these.
Jan 21 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:b0kq0v$blh$1 digitaldaemon.com...

 ifloat = imaginary float
 idouble = imaginary double
 ireal = imaginary real


 I wonder about these. How often does one work with in the pure imaginary
 numbers for more than a single operation or two? I would get by just fine
 with just the other 6 (pure real and complex of different precisions).


Does

 any other language have pure imaginary types? I don't know off-hand.


Imaginary numbers as a distinct type are necessary if you're going to do
complex arithmetic without weird errors. See Prof. Kahan's paper on it.

http://www.cs.berkeley.edu/~wkahan/Curmudge.pdf

(Thanks to Mark Evans for digging up the url.)
Feb 12 2003
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
The thing about imaginary numbers is that if you multiply two imaginary
numbers together, the sign is the opposite what you'd get if they were real
numbers (correct me if I'm wrong).

Sean

----- Original Message -----
From: "Walter" <walter digitalmars.com>
Newsgroups: D
Sent: Wednesday, February 12, 2003 1:23 AM
Subject: Re: complex, imaginary, and extended



 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:b0kq0v$blh$1 digitaldaemon.com...

 ifloat = imaginary float
 idouble = imaginary double
 ireal = imaginary real


 I wonder about these. How often does one work with in the pure imaginary
 numbers for more than a single operation or two? I would get by just




fine

 with just the other 6 (pure real and complex of different precisions).


 Does

 any other language have pure imaginary types? I don't know off-hand.


 Imaginary numbers as a distinct type are necessary if you're going to do
 complex arithmetic without weird errors. See Prof. Kahan's paper on it.

 http://www.cs.berkeley.edu/~wkahan/Curmudge.pdf

 (Thanks to Mark Evans for digging up the url.)
Feb 12 2003
prev sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
Digging around it seems like pure imaginary types are useful for
distinguishing -0i from +0i, but I don't see why you can't have values
0+(-0)i and 0+(+0)i and the complex arithmetic works out to exactly the same
thing as the purely-imaginary arithmetic. Kahan's complaint about Fortran
complex types is (I think) that it ignores -0 and +0 quantities (either in
the real or imaginary part). I haven't read the rationale behind adding it
to C99, though, so there could be problems with trying to put -0 and +0 into
complex arithmetic. If it's really impossible then adding pure imaginary
types makes sense.

-Ben


"Walter" <walter digitalmars.com> wrote in message
news:b2d40k$2jjn$1 digitaldaemon.com...

 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:b0kq0v$blh$1 digitaldaemon.com...

 ifloat = imaginary float
 idouble = imaginary double
 ireal = imaginary real


 I wonder about these. How often does one work with in the pure imaginary
 numbers for more than a single operation or two? I would get by just




fine

 with just the other 6 (pure real and complex of different precisions).


 Does

 any other language have pure imaginary types? I don't know off-hand.


 Imaginary numbers as a distinct type are necessary if you're going to do
 complex arithmetic without weird errors. See Prof. Kahan's paper on it.

 http://www.cs.berkeley.edu/~wkahan/Curmudge.pdf

 (Thanks to Mark Evans for digging up the url.)
Feb 13 2003
prev sibling parent "Bjornar Svingen" <bjornar.svingen ktv.no> writes:
 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


The "real" for extended sounds a bit strange. I would prefer something like
real32
real64
realMAX
complex32
complex64
complexMAX
imaginary32
imaginary64
imaginaryMAX

This will be consistent IMO. Anyway, as long as the keywords are there, the
names doesnt really matter. With the array handling, attributes and these
keywords along with the nice grammar in general, it looks like D could be
THE choice for numerical programming (if the speed is up that is).
Mar 02 2003