Re: [boost] [Review][PQS] Review deadline

From: Andy Little (andy_at_[hidden])
Date: 2006-06-08 14:06:39

"Michael Fawcett" wrote
> On 6/8/06, Andy Little wrote:
>> Hi Michael,
>>
>> > -----Original Message-----
>> > From: Michael Fawcett [mailto:michael.fawcett_at_[hidden]]
>> > Sent: 08 June 2006 15:49
>> > To: andy_at_[hidden]
>> > Subject: Re: [boost] [Review][PQS] Review deadline
>>
>> > > A goal of pqs is to be useable in that sort of situation. To be
>> > really effective
>> > > it will need a lot of supporting classes ( matrix, vector, quat) though.
>> >
>> > Did you plan on using Boost::uBLAS for this, along with
>> > Boost::quaternion?  This seemed tangential enough to the PQS
>> > discussions that I didn't want to clutter up the mailing list, but I
>> > am defeinitely curious.
>>
>> FWIW Its extremely important. I think it would be worth  asking on the list.
>> I dont think many people realise! I have discussed it in various replies but
>> no one has asked me the direct question:
>>
>> Neither of those libraries above will work with other than numeric types
>> AFAIK. IOW where T is a type (simplifying and ignoring e.g floating point
>> promotion etc), it must satisfy:
>>
>> T result = T() + T();
>> T result = T() * T();
>>
>> (among others)
>>
>> If T is a physical quantity, the second requirement never can be true.
>> Quantity Compatible library must be written something like:
>>
>> Where Op is  +,-,*,/, ==, etc ...
>>
>> typeof( T1() Op T1() ) result =  T1() Op T2();
>
> This was a private e-mail discussion but Andy thought it important to
> be bruoght up on the list.  FWIW, my own current
> matrix/vector/quaternion code does what you are asking for (with
> boost's help), but I had been looking at changing all my stuff over to
> uBLAS/quaternion for some time.  As an example:
>
> blas::vec3<float> a(1, 0, 0);
> blas::vec3<double> b(0, 1, 0);
> blas::vec3<double> result = cross_product(a, b); // returns vec3<double>!
>
> I accomplished this using what I think never became a boost library
> (from the sandbox maybe? Did MPL::transform consume this
> functionality?) result_of which was used something like:
>
> template <typename LHS, typename RHS>
> typename boost::result_of_plus<LHS, RHS>::type
> operator +(const LHS &lhs, const RHS &rhs)
> {
> typename boost::result_of_plus<LHS, RHS>::type nrv(lhs);
> nrv += rhs;
> return nrv;
> }
>
> I would hope some solution could be found where you didn't have to
> implement all new matrix/vector/quaternion classes and their
> corresponding functionality, rather, just ensure the return type from
> the operation follows normal promotion rules (this is actually what I
> thought the promotion traits library was going to do).

OK, what I was going onto say was that this is only the beginning of the 
complexities involved in strong type checking on physical quantities .

A transformation matrix can perform the operations of translation and scaling.

Translation of an entity(lets say a position vector implemented as length 
quantities) is basically an addition. Therefore the translation part of the 
matrix must be comprised of length quantities. However scaling of a quantity can 
only be performed by a numeric type. We can deduce from this that some elements 
of the transformation matrix must be numeric, and some length quantities.

In fact  the type makeup of a matrix for 2d transforms ends up looking like the 
following:

where N is a numeric, Q is a quantity and R is the reciprocal of the quantity or 
1/Q

 (    N N R )
 (    NN  R )
 (   QQ N )

The 3D transform version is similar except with the extra row and column of 
course.

The problem is that this is quite a heavy modification to ask of a numeric 
matrix library, especially when most users will be using it for numeric values. 
(Incidentallly numerics work in the above of course. they just all resolve to 
N).

The point of all this is that the price of strong type checking (ie using PQS 
rather than numerics) may be discarding all your current libraries, which are 
based on the assumption of numerics. That is quite a high price!.

I dont know any solution to this problem( except to exit the strong type 
checking) but basically there it is.

regards
Andy Little