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>?

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>?
>
>

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.

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

"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!

"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

Well you can dig up my naming ideas from many moons ago <g>.  Real32, Real64, RealCPUMax, Complex32, Complex64, ComplexCPUMax.  Something like that.

Mark

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

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

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

Women would hate it. But why beginners? When I was a Delphi beginner (=absolute beginner), i liked one part of the type system and hated 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", "Extended", and a couple of obscure types for extended-encoded integers and alike, completely purposeless when operator overloading exists.

To my opinion, C type names were as nonsense as Delphi as I learned them. *You shouldn't expect a novice to be unable to count, but rather 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 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 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 templates with integral parameters.

Another question is what to be a parameter: number of bits (high visual contrast), or the number of bytes (easy to count with)? I find the 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 an arbitrary-size integer. ;) Well, it makes the language too obscure, but who cares, we've got C, Perl and OCaml and maybe even Befunge guys over here. :>

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.

"Single", "double", and "extended" are OK for FP values (though hardly natural unless you know that they are X precision IEEE blah blah blah), 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 has

We're discussing a concept, not implementation. But Walter makes good implementations, and complex support is trusty and comes directly from 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 support they would become not really much more efficient than a library implementation, but better keep them.

> 
> —————————————————————————
> 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
> 
>