Here's the start to a general solution, feedback welcome ...

vector2{64} v;  // A two dimensional vector. Each component is 64 bits wide.

// Example vector component access.
v.(0) = 1.0;
v.(1) = 1.0;

// A syntax error the preprocessor could pick up ...
v.(2) = 1.0;  // Syntax error - the vector is only two dimensional ...

Indirect access ...
uint{64} index = 1;

v.(index) = 1.0;



So, we can represent a 64 bit precision complex number as :-

vector2{64} c;

A quaternion ...

vector4{64} q;

A high precision location in 3 dimensional space ... vector3{128} p;

.. etc ...

Taking this idea forwards, we can tidy up the whole mess of somebody having to get out a thesaurus every time we need a wider int or float data type.

Examples ...
uint{8} my_byte;
int{32} my_signed_number;
int{128} big_one;
float{128} f;
float{1024} not_yet;

.. etc ...

.. Additionally, native matrix support should be added.

E.g. matrix34{64} m; // 3x4 matrix with 64 bit floating point scalar components.

// Example component access :-
m.(3,1) = 0.0;

.. again, the preprocessor could pick up some invalid accesses.

It is important to implement vector and matrix datatypes and operations in the language to enable the compiler to acheive optimal parallelization. A library implementation is not the optimal solution here.

Comments welcome ...

- Steve.

Additionally, to complete the picture ...

ivector2{32} v;  // A two dimensional vector consisting of two 32 bit signed integer components.

uivector2{32} v;  // A two dimensional vector consisting of two 32 bit unsigned integer components.

imatrix21{8}; // A 2x1 matrix, each component is an signed byte ... uimatrix21{16}; // A 2x1 matrix, each component is an unsigned 16 bit integer ..

Remember, it is *very* important that these higher dimensional data types are implementated within the language to enable the compiler to generate highly parallelized code on modern cpus ... Support for these features in the language and a halfway decent compiler implementation would be reason enough to move from C++ to D.




In article <avrruv$160s$1@digitaldaemon.com>, Steve says...
>
>Here's the start to a general solution, feedback welcome ...
>
>vector2{64} v;  // A two dimensional vector. Each component is 64 bits wide.
>
>// Example vector component access.
>v.(0) = 1.0;
>v.(1) = 1.0;
>
>// A syntax error the preprocessor could pick up ...
>v.(2) = 1.0;  // Syntax error - the vector is only two dimensional ...
>
>Indirect access ...
>uint{64} index = 1;
>
>v.(index) = 1.0;
>
>
>
>So, we can represent a 64 bit precision complex number as :-
>
>vector2{64} c;
>
>A quaternion ...
>
>vector4{64} q;
>
>A high precision location in 3 dimensional space ... vector3{128} p;
>
>.. etc ...
>
>Taking this idea forwards, we can tidy up the whole mess of somebody having to get out a thesaurus every time we need a wider int or float data type.
>
>Examples ...
>uint{8} my_byte;
>int{32} my_signed_number;
>int{128} big_one;
>float{128} f;
>float{1024} not_yet;
>
>.. etc ...
>
>.. Additionally, native matrix support should be added.
>
>E.g. matrix34{64} m; // 3x4 matrix with 64 bit floating point scalar components.
>
>// Example component access :-
>m.(3,1) = 0.0;
>
>.. again, the preprocessor could pick up some invalid accesses.
>
>It is important to implement vector and matrix datatypes and operations in the language to enable the compiler to acheive optimal parallelization. A library implementation is not the optimal solution here.
>
>Comments welcome ...
>
>- Steve.
>
>

You're already starting down the "bad" path by integrating the vector types and sizes into your identifiers.

You need something more like template syntax probably;  something like:

typedef vector(int(32), 2) ipoint32;
typedef vector(float(64), 4) doublequaternion;

But why have vector when we already have arrays that are really nice?

typedef int{32}[2] ipoint32;
typedef float{64}[4] doublequaternion;

In all actuality these types really represent algebras and as such need new operators (unless the compiler is smart enough to know how to multiply your types automatically;  I don't think this is possible since there's so many ways to define a multiplication).  Hopefully D operator overloading allows you to make free module scope operators taking any two arbitrary types.

It seems likely you'd also want to be able to do something like this:

struct doublequaternion : float(64)[4]
{
    doublequaternion(float(64)[3] axis, float(64) angleradians)
    {
        ...
    }
}

But this would be nicer and cleaner using decorators probably.  Not sure if decorators will ever make it into D.

Sean

"Steve" <Steve_member@pathlink.com> wrote in message news:avrt3d$1f3v$1@digitaldaemon.com...
> Additionally, to complete the picture ...
>
> ivector2{32} v;  // A two dimensional vector consisting of two 32 bit
signed
> integer components.
>
> uivector2{32} v;  // A two dimensional vector consisting of two 32 bit
unsigned
> integer components.
>
> imatrix21{8}; // A 2x1 matrix, each component is an signed byte ... uimatrix21{16}; // A 2x1 matrix, each component is an unsigned 16 bit
integer
> ..
>
> Remember, it is *very* important that these higher dimensional data types
are
> implementated within the language to enable the compiler to generate
highly
> parallelized code on modern cpus ... Support for these features in the
language
> and a halfway decent compiler implementation would be reason enough to
move from
> C++ to D.
>
>
>
>
> In article <avrruv$160s$1@digitaldaemon.com>, Steve says...
> >
> >Here's the start to a general solution, feedback welcome ...
> >
> >vector2{64} v;  // A two dimensional vector. Each component is 64 bits
wide.
> >
> >// Example vector component access.
> >v.(0) = 1.0;
> >v.(1) = 1.0;
> >
> >// A syntax error the preprocessor could pick up ...
> >v.(2) = 1.0;  // Syntax error - the vector is only two dimensional ...
> >
> >Indirect access ...
> >uint{64} index = 1;
> >
> >v.(index) = 1.0;
> >
> >
> >
> >So, we can represent a 64 bit precision complex number as :-
> >
> >vector2{64} c;
> >
> >A quaternion ...
> >
> >vector4{64} q;
> >
> >A high precision location in 3 dimensional space ... vector3{128} p;
> >
> >.. etc ...
> >
> >Taking this idea forwards, we can tidy up the whole mess of somebody
having to
> >get out a thesaurus every time we need a wider int or float data type.
> >
> >Examples ...
> >uint{8} my_byte;
> >int{32} my_signed_number;
> >int{128} big_one;
> >float{128} f;
> >float{1024} not_yet;
> >
> >.. etc ...
> >
> >.. Additionally, native matrix support should be added.
> >
> >E.g.
> >matrix34{64} m; // 3x4 matrix with 64 bit floating point scalar
components.
> >
> >// Example component access :-
> >m.(3,1) = 0.0;
> >
> >.. again, the preprocessor could pick up some invalid accesses.
> >
> >It is important to implement vector and matrix datatypes and operations
in the
> >language to enable the compiler to acheive optimal parallelization. A
library
> >implementation is not the optimal solution here.
> >
> >Comments welcome ...
> >
> >- Steve.
> >
> >
>
>

"Sean L. Palmer" <seanpalmer@directvinternet.com> escreveu na mensagem news:avro2k$v0m$1@digitaldaemon.com...
> Type complex is really just an array of two real numbers with some overloaded operators attached.
>
> That can be done in the library, or should be able to be.  ;)
>
> Complex numbers are just the tip of the iceberg.  Are you going to add quaternions, octonions, etc?
>
> Even complex should have variants matching the available machine floating point precisions.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:avqr6s$2l66$1@digitaldaemon.com...
> >
> > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:avkgcl$20i4$1@digitaldaemon.com...
> > > That's not a very good reason to add something to a language spec.
Sure
> > it
> > > makes sense to add it to DMD, but not D necessarily.
> >
> > The good reason is for it to be an upgrade from C. One design goal of D
is
> > to not take away any C features without a really strong reason. I also happened to like type complex <g>.
>
>

Hi,

    Complex numbers *may* be represented as an array of two real numbers
with overloaded operators attached, but they carry their own semantics
baggage. I don't always want to store a complex number as an real/imaginary
pair, sometimes it's better to store it as an radius/theta pair. Cartesian
form is better for addition and subtraction, but multiplication, division,
power and roots are faster when done in polar form. If I write:


complex res = 0;
for (int i = 0; i < values.length; i++) {
    res *= values[i];
}


    I don't to have lot's of extraneous operations needed to make all the
multiplications in cartesian form. So I would require a complex(cartesian)
or complex(polar) types for my specific usages (in this case values would
contain complex(polar) numbers).
    Quaternions and octonions are other types that should be carefully
defined. I don't think we should have all these built-in the language. IMO D
may provide us a better way to write these as libraries without loss of
efficiency or expressiveness.

    Best regards,
    Daniel Yokomiso.

"Sodium and Chloride are both dangerous to humans. Therefore any combination of sodium and chloride will be dangerous to humans."


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002

"Steve" <Steve_member@pathlink.com> escreveu na mensagem news:avrt3d$1f3v$1@digitaldaemon.com...
> Additionally, to complete the picture ...
>
> ivector2{32} v;  // A two dimensional vector consisting of two 32 bit
signed
> integer components.
>
> uivector2{32} v;  // A two dimensional vector consisting of two 32 bit
unsigned
> integer components.
>
> imatrix21{8}; // A 2x1 matrix, each component is an signed byte ... uimatrix21{16}; // A 2x1 matrix, each component is an unsigned 16 bit
integer
> ..
>
> Remember, it is *very* important that these higher dimensional data types
are
> implementated within the language to enable the compiler to generate
highly
> parallelized code on modern cpus ... Support for these features in the
language
> and a halfway decent compiler implementation would be reason enough to
move from
> C++ to D.
>
>
>
>
> In article <avrruv$160s$1@digitaldaemon.com>, Steve says...
> >
> >Here's the start to a general solution, feedback welcome ...
> >
> >vector2{64} v;  // A two dimensional vector. Each component is 64 bits
wide.
> >
> >// Example vector component access.
> >v.(0) = 1.0;
> >v.(1) = 1.0;
> >
> >// A syntax error the preprocessor could pick up ...
> >v.(2) = 1.0;  // Syntax error - the vector is only two dimensional ...
> >
> >Indirect access ...
> >uint{64} index = 1;
> >
> >v.(index) = 1.0;
> >
> >
> >
> >So, we can represent a 64 bit precision complex number as :-
> >
> >vector2{64} c;
> >
> >A quaternion ...
> >
> >vector4{64} q;
> >
> >A high precision location in 3 dimensional space ... vector3{128} p;
> >
> >.. etc ...
> >
> >Taking this idea forwards, we can tidy up the whole mess of somebody
having to
> >get out a thesaurus every time we need a wider int or float data type.
> >
> >Examples ...
> >uint{8} my_byte;
> >int{32} my_signed_number;
> >int{128} big_one;
> >float{128} f;
> >float{1024} not_yet;
> >
> >.. etc ...
> >
> >.. Additionally, native matrix support should be added.
> >
> >E.g.
> >matrix34{64} m; // 3x4 matrix with 64 bit floating point scalar
components.
> >
> >// Example component access :-
> >m.(3,1) = 0.0;
> >
> >.. again, the preprocessor could pick up some invalid accesses.
> >
> >It is important to implement vector and matrix datatypes and operations
in the
> >language to enable the compiler to acheive optimal parallelization. A
library
> >implementation is not the optimal solution here.
> >
> >Comments welcome ...
> >
> >- Steve.
> >
> >
>
>

Hi,

    If we start defining multi-dimensional primitives in the languages,
where do we stop. Vector and matrices are just two steps in generic tensors:
we have scalars, vectors, matrices, tensors, just in the first 4 dimensions.
Some people will need higher-order dimensions, with dimensional slices,
strides, etc.. Also a quaternion isn't a vector4, because a vector4 can be
used to represent a (x,y,z,t) position in a system, and this have different
algebraic operations from a quaternion IIRC. There's more than one way to
multiply a pair of vector3, it's context sensitive.
    Lot's of smart people spent man-years working on these problems and they
usually don't agree with each other. If every D compiler developer is
required to write code to deal with all these operations (hey I want
everything defined in Blitz++ for my tensors) we'll have buggier compilers,
hard to get semantics of types (how should matrices work with volatile
access?) and less people interested in writing those. Just check the number
of correct C++ compiler implementations versus the correct anything else
compiler implementations. And C++ doesn't have all this types built-in.
    With standard libraries for these types (templatized
classes/structs/whatever) with some basic implementations in D source code,
we can develop and deploy faster. If you need a faster implementation, your
compiler provider can make these standard types built-in as it's unique
selling point.

    Best regards,
    Daniel Yokomiso.

"Sanity is the playground for the unimaginative."


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 31/12/2002