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,

 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

 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


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

offends your fashion sense so out it goes! <g> Oh well. You are the

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

Check out stdint.d which has those aliases for people who prefer them.
Jan 21 2003
prev sibling next 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=

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

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

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

 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 =

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

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

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=

 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=

 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 next sibling parent Ilya Minkov <midiclub tiscali.de> writes:
Antti Sykari wrote:
Carlos wrote:

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



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,

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

 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


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

 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


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

 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