View mode: basic / threaded / horizontal-split · Log in · Help
April 16, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
Okay, here goes. I've collected together the basic functionality that 
would probably make a good starting point. As I've mentioned my code is 
very messy and has bits missing (e.g. I never had a use for the cross 
product but it's pretty important in general). I guess a good way to 
begin would be to write the pubic interfaces then start on the 
implementation.

Cubic Solvers:
General complex cubic solver with two algorithms (one requiring a 
complex cosine and and arcosine one using only +-*/ and roots). A 
special case cubic solver for the reduced cubic x^^3 + px - q = 0.

Quaternions:
opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise, 
Normalized, conjugate, conjugated, toEulerAngles*, fromEulerAngles, 
this(real,i,j,k), this(angle,axis), getAngle(), getAxis()

*Currently I've only got a quaternion->euler angles routine that works 
in the ZYZ convention but I have read a paper that generalises my method 
to all valid axis conventions. Will probably impliment as something like:
toEulerAngles(string convention="XYZ")()

Vectors:
opAdd, opSub, opMult(scalar), opMult(vector)*, cross**, Normalise, 
Normalized, Length

* dot product. Would this be better named as dot()?
** 3D vectors only. Perhaps defining a cross product on the

Matrices:
opAdd, opSub, opMult(scalar), opMult(vector), opMult(matrix)**, Invert, 
Inverted, Orthogonalize, Orthogonalized, Reorthogonalize***, 
Reorthogonalized***, Det, Transpose, Transposed, Dagger*, Daggered*, 
Eigenvalues****, Eigenvectors****

*The hermitian conjugate/conjugate transpose. Reduces to the transpose 
for a real matrix
** Matrix-matrix multiplication doesn't commute. Could this be a problem 
when using operator notation?
*** Othogonalize assuming the matrix is nearly orthogonal already 
(possibly using some quick, approximate method such as a Taylor series)
**** I have a eigenvalue/vector solver for 3x3 matrices which seems 
reasonably stable but needs more testing.

Free functions:
MatrixToQuaternion
QuaternionToMatrix
+ code to allow easy printing to stdout/streams and such.

Andrei Alexandrescu wrote:
> On 04/15/2010 01:49 PM, Gareth Charnock wrote:
>> As a side effect of my PhD project I've got a collection of mathematical
>> classes. I'd be happy to collect them together, tidy them up and donate
>> them to phobos the authors are interested in including them. Matrices
>> and vectors in particular get reinvented all the time so I'm sure users
>> of D will appreciate them being there. Quaternions are probably somewhat
>> more specialised; they are most often used for representing rotations
>> (they have different advantages and disadvantages to rotation matrices).
>> I've also written a solver for cubic equations.
>>
>> The matrix and vector classes are of the sort where the dimension is
>> known at compile time and will probably be most useful for modelling
>> geometry. High dimensional matrices and vectors are probably better left
>> to a scientific library (I remember there was talk that one might be
>> being proposed).
>>
>> Would this sort of functionality be useful for phobos? At the moment, I
>> can't promise anything, I'm just trying to judge the interest should I
>> find time to look into it.
>>
>> Gareth Charnock
> 
> I think it would. Could you please post a brief list of features so 
> people can take a look?
> 
> Andrei
April 16, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
Gareth Charnock <gareth.tpc@gmail.com> wrote:

> Quaternions:
> opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise,  
> Normalized, conjugate, conjugated, toEulerAngles*, fromEulerAngles,  
> this(real,i,j,k), this(angle,axis), getAngle(), getAxis()
[...]
> Vectors:
> opAdd, opSub, opMult(scalar), opMult(vector)*, cross**, Normalise,  
> Normalized, Length

Normalise and normalized seem to be inconsistent in their naming.
Please use only z or only s.

> * dot product. Would this be better named as dot()?

Yes please.

> ** 3D vectors only. Perhaps defining a cross product on the

Cross products are useful. Please add.

> Matrices:
> opAdd, opSub, opMult(scalar), opMult(vector), opMult(matrix)**, Invert,  
> Inverted, Orthogonalize, Orthogonalized, Reorthogonalize***,  
> Reorthogonalized***, Det, Transpose, Transposed, Dagger*, Daggered*,  
> Eigenvalues****, Eigenvectors****
>
> *The hermitian conjugate/conjugate transpose. Reduces to the transpose  
> for a real matrix
> ** Matrix-matrix multiplication doesn't commute. Could this be a problem  
> when using operator notation?

There should be no associated problems.

-- 
Simen
April 16, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
Gareth Charnock <gareth.tpc@gmail.com> wrote:
> Vectors:
> opAdd, opSub, opMult(scalar), opMult(vector)*, cross**, Normalise,  
> Normalized, Length

Oh, and perhaps add swizzling? Probably using opDispatch.

-- 
Simen
April 17, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
On 04/16/2010 04:25 PM, Gareth Charnock wrote:
> Okay, here goes. I've collected together the basic functionality that
> would probably make a good starting point. As I've mentioned my code is
> very messy and has bits missing (e.g. I never had a use for the cross
> product but it's pretty important in general). I guess a good way to
> begin would be to write the pubic interfaces then start on the
> implementation.
>
> Cubic Solvers:
> General complex cubic solver with two algorithms (one requiring a
> complex cosine and and arcosine one using only +-*/ and roots). A
> special case cubic solver for the reduced cubic x^^3 + px - q = 0.

This sounds a candidate for std.numeric. How popular/needed are cubic 
solvers?

> Quaternions:
> opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise,
> Normalized, conjugate, conjugated, toEulerAngles*, fromEulerAngles,
> this(real,i,j,k), this(angle,axis), getAngle(), getAxis()

Sounds good, but you'd need to convert the code to the new overloaded 
operators approach.

> *Currently I've only got a quaternion->euler angles routine that works
> in the ZYZ convention but I have read a paper that generalises my method
> to all valid axis conventions. Will probably impliment as something like:
> toEulerAngles(string convention="XYZ")()
>
> Vectors:
> opAdd, opSub, opMult(scalar), opMult(vector)*, cross**, Normalise,
> Normalized, Length

What is the representation of vectors? I'm afraid the design above would 
be too limited for what we need.

> * dot product. Would this be better named as dot()?

We already have dot product and normalization routines that work with 
general ranges.

http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct
http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#normalize

Generally I'd strongly suggest making operations free generic functions 
instead of members.

> ** 3D vectors only. Perhaps defining a cross product on the
>
> Matrices:
> opAdd, opSub, opMult(scalar), opMult(vector), opMult(matrix)**, Invert,
> Inverted, Orthogonalize, Orthogonalized, Reorthogonalize***,
> Reorthogonalized***, Det, Transpose, Transposed, Dagger*, Daggered*,
> Eigenvalues****, Eigenvectors****

What is the representation of matrices?

> *The hermitian conjugate/conjugate transpose. Reduces to the transpose
> for a real matrix

Transposition should also be handled in a static manner, e.g. define a 
transposed view of a matrix that doesn't actually move elements.

> ** Matrix-matrix multiplication doesn't commute. Could this be a problem
> when using operator notation?

Should be fine.

> *** Othogonalize assuming the matrix is nearly orthogonal already
> (possibly using some quick, approximate method such as a Taylor series)
> **** I have a eigenvalue/vector solver for 3x3 matrices which seems
> reasonably stable but needs more testing.
>
> Free functions:
> MatrixToQuaternion
> QuaternionToMatrix
> + code to allow easy printing to stdout/streams and such.

Sounds encouraging.

I think a good next step is to go through a community scrutiny process 
by dropping the code somewhere on the Web so people can review it.


Andrei
April 18, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
Andrei Alexandrescu wrote:
> On 04/16/2010 04:25 PM, Gareth Charnock wrote:
>> Okay, here goes. I've collected together the basic functionality that
>> would probably make a good starting point. As I've mentioned my code is
>> very messy and has bits missing (e.g. I never had a use for the cross
>> product but it's pretty important in general). I guess a good way to
>> begin would be to write the pubic interfaces then start on the
>> implementation.
>>
>> Cubic Solvers:
>> General complex cubic solver with two algorithms (one requiring a
>> complex cosine and and arcosine one using only +-*/ and roots). A
>> special case cubic solver for the reduced cubic x^^3 + px - q = 0.
> 
> This sounds a candidate for std.numeric. How popular/needed are cubic 
> solvers?

They're probably don't come up that frequently but they do they're 
rather fiddly. Lots of operations to get right. But the solution doesn't 
depend on anything but basic math operators so once it's written, it's 
written. I guess the question is whether Phobos is meant to be a small 
library or a kitchen sink library.

>> Quaternions:
>> opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise,
>> Normalized, conjugate, conjugated, toEulerAngles*, fromEulerAngles,
>> this(real,i,j,k), this(angle,axis), getAngle(), getAxis()
> 
> Sounds good, but you'd need to convert the code to the new overloaded 
> operators approach.

Fair enough, and this will be a good opportunity to show off why the new 
overloading scheme is more powerful (e.g. opAdd and opSub can be combined).

>> *Currently I've only got a quaternion->euler angles routine that works
>> in the ZYZ convention but I have read a paper that generalises my method
>> to all valid axis conventions. Will probably impliment as something like:
>> toEulerAngles(string convention="XYZ")()
>>
>> Vectors:
>> opAdd, opSub, opMult(scalar), opMult(vector)*, cross**, Normalise,
>> Normalized, Length
> 
> What is the representation of vectors? I'm afraid the design above would 
> be too limited for what we need.
A fixed sized array where V[0] ~ x, V[1] ~ y and V[2] ~ z. The field the 
vector is defined over is templated.

What other operators are needed? I'd defiantly want to add swizzling. 
http://www.ogre3d.org/docs/api/html/classOgre_1_1Vector3.html looks like 
it could be a good source of ideas.

>> * dot product. Would this be better named as dot()?

> We already have dot product and normalization routines that work with 
> general ranges.
> 
> http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct
> http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#normalize
> 
> Generally I'd strongly suggest making operations free generic functions 
> instead of members.

I've not really thought about operators as members vs operators as free 
functions. I just tend to put them as members because it feels more 
organised. But looking at other implementations, I seem to be in the 
minority.

>> ** 3D vectors only. Perhaps defining a cross product on the
>>
>> Matrices:
>> opAdd, opSub, opMult(scalar), opMult(vector), opMult(matrix)**, Invert,
>> Inverted, Orthogonalize, Orthogonalized, Reorthogonalize***,
>> Reorthogonalized***, Det, Transpose, Transposed, Dagger*, Daggered*,
>> Eigenvalues****, Eigenvectors****
> 
> What is the representation of matrices?
private:
  F[n*n] mat;
where F is the type of the field and n is the dimension of the matrix.

>> *The hermitian conjugate/conjugate transpose. Reduces to the transpose
>> for a real matrix
> 
> Transposition should also be handled in a static manner, e.g. define a 
> transposed view of a matrix that doesn't actually move elements.

Do you mean that a bool should be stored to count the number of 
transpositions or that there is a type that behaves like a matrix but 
actually just presents a view of another matrix e.g.

Matrix A;
...
Matrix B = A.Transposed();
//Changes to B now affect A

>> ** Matrix-matrix multiplication doesn't commute. Could this be a problem
>> when using operator notation?
> 
> Should be fine.
> 
>> *** Othogonalize assuming the matrix is nearly orthogonal already
>> (possibly using some quick, approximate method such as a Taylor series)
>> **** I have a eigenvalue/vector solver for 3x3 matrices which seems
>> reasonably stable but needs more testing.
>>
>> Free functions:
>> MatrixToQuaternion
>> QuaternionToMatrix
>> + code to allow easy printing to stdout/streams and such.
> 
> Sounds encouraging.
> 
> I think a good next step is to go through a community scrutiny process 
> by dropping the code somewhere on the Web so people can review it.
Couldn't agree more because I'm sure I'll miss tricks and conventions. I 
would have never thought of that funky swizzling idea.

I've also got another question: should matrices, vectors and quaternions 
be classes or structs? My gut reaction is that they should be structs 
and thus act like value types. But matrices might be too big and should 
be passed by reference which would imply they should be a class. Anyone 
know any rules of thumb that might apply?

Gareth Charnock
April 19, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
On Mon, Apr 19, 2010 at 01:11, Gareth Charnock <gareth.tpc@gmail.com> wrote:

> Couldn't agree more because I'm sure I'll miss tricks and conventions. I
> would have never thought of that funky swizzling idea.
>

Here is a first try with the new operator syntax:

http://lists.puremagic.com/pipermail/digitalmars-d/2010-April/074864.html

Maybe it can help you...

Cheers,


 Philippe
April 19, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation
Gareth Charnock Wrote:

> Andrei Alexandrescu wrote:
> > On 04/16/2010 04:25 PM, Gareth Charnock wrote:
> >> Okay, here goes. I've collected together the basic functionality that
> >> would probably make a good starting point. As I've mentioned my code is
> >> very messy and has bits missing (e.g. I never had a use for the cross
> >> product but it's pretty important in general). I guess a good way to
> >> begin would be to write the pubic interfaces then start on the
> >> implementation.
> >>
> >> Cubic Solvers:
> >> General complex cubic solver with two algorithms (one requiring a
> >> complex cosine and and arcosine one using only +-*/ and roots). A
> >> special case cubic solver for the reduced cubic x^^3 + px - q = 0.
> > 
> > This sounds a candidate for std.numeric. How popular/needed are cubic 
> > solvers?
> 
> They're probably don't come up that frequently but they do they're 
> rather fiddly. Lots of operations to get right. But the solution doesn't 
> depend on anything but basic math operators so once it's written, it's 
> written. I guess the question is whether Phobos is meant to be a small 
> library or a kitchen sink library.
> 
> >> Quaternions:
> >> opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise,
> >> Normalized, conjugate, conjugated, toEulerAngles*, fromEulerAngles,
> >> this(real,i,j,k), this(angle,axis), getAngle(), getAxis()
> > 
> > Sounds good, but you'd need to convert the code to the new overloaded 
> > operators approach.
> 
> Fair enough, and this will be a good opportunity to show off why the new 
> overloading scheme is more powerful (e.g. opAdd and opSub can be combined).
> 
> >> *Currently I've only got a quaternion->euler angles routine that works
> >> in the ZYZ convention but I have read a paper that generalises my method
> >> to all valid axis conventions. Will probably impliment as something like:
> >> toEulerAngles(string convention="XYZ")()
> >>
> >> Vectors:
> >> opAdd, opSub, opMult(scalar), opMult(vector)*, cross**, Normalise,
> >> Normalized, Length
> > 
> > What is the representation of vectors? I'm afraid the design above would 
> > be too limited for what we need.
> A fixed sized array where V[0] ~ x, V[1] ~ y and V[2] ~ z. The field the 
> vector is defined over is templated.
> 
> What other operators are needed? I'd defiantly want to add swizzling. 
> http://www.ogre3d.org/docs/api/html/classOgre_1_1Vector3.html looks like 
> it could be a good source of ideas.
> 
> >> * dot product. Would this be better named as dot()?
> 
> > We already have dot product and normalization routines that work with 
> > general ranges.
> > 
> > http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct
> > http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#normalize
> > 
> > Generally I'd strongly suggest making operations free generic functions 
> > instead of members.
> 
> I've not really thought about operators as members vs operators as free 
> functions. I just tend to put them as members because it feels more 
> organised. But looking at other implementations, I seem to be in the 
> minority.
> 
> >> ** 3D vectors only. Perhaps defining a cross product on the
> >>
> >> Matrices:
> >> opAdd, opSub, opMult(scalar), opMult(vector), opMult(matrix)**, Invert,
> >> Inverted, Orthogonalize, Orthogonalized, Reorthogonalize***,
> >> Reorthogonalized***, Det, Transpose, Transposed, Dagger*, Daggered*,
> >> Eigenvalues****, Eigenvectors****
> > 
> > What is the representation of matrices?
> private:
>    F[n*n] mat;
> where F is the type of the field and n is the dimension of the matrix.
> 
> >> *The hermitian conjugate/conjugate transpose. Reduces to the transpose
> >> for a real matrix
> > 
> > Transposition should also be handled in a static manner, e.g. define a 
> > transposed view of a matrix that doesn't actually move elements.
> 
> Do you mean that a bool should be stored to count the number of 
> transpositions or that there is a type that behaves like a matrix but 
> actually just presents a view of another matrix e.g.
> 
> Matrix A;
> ...
> Matrix B = A.Transposed();
> //Changes to B now affect A
> 
> >> ** Matrix-matrix multiplication doesn't commute. Could this be a problem
> >> when using operator notation?
> > 
> > Should be fine.
> > 
> >> *** Othogonalize assuming the matrix is nearly orthogonal already
> >> (possibly using some quick, approximate method such as a Taylor series)
> >> **** I have a eigenvalue/vector solver for 3x3 matrices which seems
> >> reasonably stable but needs more testing.
> >>
> >> Free functions:
> >> MatrixToQuaternion
> >> QuaternionToMatrix
> >> + code to allow easy printing to stdout/streams and such.
> > 
> > Sounds encouraging.
> > 
> > I think a good next step is to go through a community scrutiny process 
> > by dropping the code somewhere on the Web so people can review it.
> Couldn't agree more because I'm sure I'll miss tricks and conventions. I 
> would have never thought of that funky swizzling idea.
> 
> I've also got another question: should matrices, vectors and quaternions 
> be classes or structs? My gut reaction is that they should be structs 
> and thus act like value types. But matrices might be too big and should 
> be passed by reference which would imply they should be a class. Anyone 
> know any rules of thumb that might apply?

I definately think low-dimensional vectors/matrices must be structs.

The cost of writing/reading some float/double/real values sitting next in memory is nowhere near the cost of allocating such a new area for each opAdd. Structs can be pooled too, and referred by pointers.
April 19, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
Philippe Sigaud wrote:
> 
> 
> On Mon, Apr 19, 2010 at 01:11, Gareth Charnock <gareth.tpc@gmail.com 
> <mailto:gareth.tpc@gmail.com>> wrote:
> 
>     Couldn't agree more because I'm sure I'll miss tricks and
>     conventions. I would have never thought of that funky swizzling idea.
> 
> 
> Here is a first try with the new operator syntax:
> 
> http://lists.puremagic.com/pipermail/digitalmars-d/2010-April/074864.html
> 
> Maybe it can help you...

Yeah, opDispatch is really cool. :)  Here's an even earlier suggestion 
by Don, using inline assembler:

http://www.digitalmars.com/d/archives/digitalmars/D/Re_dynamic_classes_and_duck_typing_102407.html#N102410

(Note:  "opDynamic" was an early proposal.  It should be replaced with 
"opDispatch", which is what we have now.)

-Lars
April 19, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
Gareth Charnock wrote:
> Andrei Alexandrescu wrote:
>> On 04/16/2010 04:25 PM, Gareth Charnock wrote:
>>> Okay, here goes. I've collected together the basic functionality that
>>> would probably make a good starting point. As I've mentioned my code is
>>> very messy and has bits missing (e.g. I never had a use for the cross
>>> product but it's pretty important in general). I guess a good way to
>>> begin would be to write the pubic interfaces then start on the
>>> implementation.
>>>
>>> Cubic Solvers:
>>> General complex cubic solver with two algorithms (one requiring a
>>> complex cosine and and arcosine one using only +-*/ and roots). A
>>> special case cubic solver for the reduced cubic x^^3 + px - q = 0.
>>
>> This sounds a candidate for std.numeric. How popular/needed are cubic 
>> solvers?
> 
> They're probably don't come up that frequently but they do they're 
> rather fiddly. Lots of operations to get right. But the solution doesn't 
> depend on anything but basic math operators so once it's written, it's 
> written. I guess the question is whether Phobos is meant to be a small 
> library or a kitchen sink library.
> 
>>> Quaternions:
>>> opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise,
>>> Normalized, conjugate, conjugated, toEulerAngles*, fromEulerAngles,
>>> this(real,i,j,k), this(angle,axis), getAngle(), getAxis()
>>
>> Sounds good, but you'd need to convert the code to the new overloaded 
>> operators approach.
> 
> Fair enough, and this will be a good opportunity to show off why the new 
> overloading scheme is more powerful (e.g. opAdd and opSub can be combined).
> 
>>> *Currently I've only got a quaternion->euler angles routine that works
>>> in the ZYZ convention but I have read a paper that generalises my method
>>> to all valid axis conventions. Will probably impliment as something 
>>> like:
>>> toEulerAngles(string convention="XYZ")()
>>>
>>> Vectors:
>>> opAdd, opSub, opMult(scalar), opMult(vector)*, cross**, Normalise,
>>> Normalized, Length
>>
>> What is the representation of vectors? I'm afraid the design above 
>> would be too limited for what we need.
> A fixed sized array where V[0] ~ x, V[1] ~ y and V[2] ~ z. The field the 
> vector is defined over is templated.
> 
> What other operators are needed? I'd defiantly want to add swizzling. 
> http://www.ogre3d.org/docs/api/html/classOgre_1_1Vector3.html looks like 
> it could be a good source of ideas.
> 
>>> * dot product. Would this be better named as dot()?
> 
>> We already have dot product and normalization routines that work with 
>> general ranges.
>>
>> http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct
>> http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#normalize
>>
>> Generally I'd strongly suggest making operations free generic 
>> functions instead of members.
> 
> I've not really thought about operators as members vs operators as free 
> functions. I just tend to put them as members because it feels more 
> organised. But looking at other implementations, I seem to be in the 
> minority.
> 
>>> ** 3D vectors only. Perhaps defining a cross product on the
>>>
>>> Matrices:
>>> opAdd, opSub, opMult(scalar), opMult(vector), opMult(matrix)**, Invert,
>>> Inverted, Orthogonalize, Orthogonalized, Reorthogonalize***,
>>> Reorthogonalized***, Det, Transpose, Transposed, Dagger*, Daggered*,
>>> Eigenvalues****, Eigenvectors****
>>
>> What is the representation of matrices?
> private:
>   F[n*n] mat;
> where F is the type of the field and n is the dimension of the matrix.
> 
>>> *The hermitian conjugate/conjugate transpose. Reduces to the transpose
>>> for a real matrix
>>
>> Transposition should also be handled in a static manner, e.g. define a 
>> transposed view of a matrix that doesn't actually move elements.
> 
> Do you mean that a bool should be stored to count the number of 
> transpositions or that there is a type that behaves like a matrix but 
> actually just presents a view of another matrix e.g.
> 
> Matrix A;
> ...
> Matrix B = A.Transposed();
> //Changes to B now affect A
> 
>>> ** Matrix-matrix multiplication doesn't commute. Could this be a problem
>>> when using operator notation?
>>
>> Should be fine.
>>
>>> *** Othogonalize assuming the matrix is nearly orthogonal already
>>> (possibly using some quick, approximate method such as a Taylor series)
>>> **** I have a eigenvalue/vector solver for 3x3 matrices which seems
>>> reasonably stable but needs more testing.
>>>
>>> Free functions:
>>> MatrixToQuaternion
>>> QuaternionToMatrix
>>> + code to allow easy printing to stdout/streams and such.
>>
>> Sounds encouraging.
>>
>> I think a good next step is to go through a community scrutiny process 
>> by dropping the code somewhere on the Web so people can review it.
> Couldn't agree more because I'm sure I'll miss tricks and conventions. I 
> would have never thought of that funky swizzling idea.
> 
> I've also got another question: should matrices, vectors and quaternions 
> be classes or structs? My gut reaction is that they should be structs 
> and thus act like value types. But matrices might be too big and should 
> be passed by reference which would imply they should be a class. Anyone 
> know any rules of thumb that might apply?

IMO, general vectors/matrices should be structs wrapping a pointer to 
the data:

  struct Vector(T)
  {
     T* ptr;
     size_t length;
     size_t stride;
  }

Low-dimensional fixed-size vectors should probably be value types.

-Lars
April 19, 2010
Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver
On 19-apr-10, at 01:11, Gareth Charnock wrote:

> Andrei Alexandrescu wrote:
>> On 04/16/2010 04:25 PM, Gareth Charnock wrote:
>>> Okay, here goes. I've collected together the basic functionality  
>>> that
>>> Quaternions:
>>> opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise,
>>> Normalized, conjugate, conjugated, toEulerAngles*, fromEulerAngles,
>>> this(real,i,j,k), this(angle,axis), getAngle(), getAxis()
>> Sounds good, but you'd need to convert the code to the new  
>> overloaded operators approach.
>
> Fair enough, and this will be a good opportunity to show off why the  
> new overloading scheme is more powerful (e.g. opAdd and opSub can be  
> combined).

About the overloading of opIndex still think that having just an  
opIndexLhs might have been a little bit cleaner (you basically pick up  
all overloading of the underlying type without any extra code), but as  
overloading has become extremely easy it is not a big issue.
1 2 3
Top | Discussion index | About this forum | D home