Re: [boost] Re: proposal for efficient geom. vector class

From: Vygis D. (vygis_d_at_[hidden])
Date: 2003-05-22 07:01:29

>I n my opinion you are wrong. For me there is no difference between a 
>vector
>in a mathematical sense and in a geometrical sense and vector calculations
>are provided by uBlas which are not in a sense of a container.
>For me a geometrical primitives are something else, e.g. points, lines,
>planes (which could be represented by (a) vector(s)), cubics, conics (which
>could have different representations, e.g. matrices) and other things.
>I agree that it would be nice to have a library for calculations with
>geometric entities, but I do not believe it would be a good idea to move
>away from uBlas.

No, I've never said that moving away from uBLAS is a good idea not suggested 
that,
I just pointed out that uBLAS is not that useful in certain contexts and 
analogically
I'm very well sure that uBLAS works greatly for what it is aimed for.

> > I was thinking of creating a library that supported 2D, 3D, 4D and nD
> > variants of the following:
> >
> > boost::geometric::point - represents a location
> >    point = point +/- vector
> >    and variants
> >    NOTE: cannot do point * point (does not make sense mathematically)
>
>hmm, see above: point+vector makes no sense to me, but point+point could.
>point*point could make sense if you, e.g. regard complex numbers same as
>like 2D-Coordinates. I do not know for quaternions nor for octanios.

perhaps vector * vector could be a dot product, after all according by c++
standartds it's not possible to overload dot operator.

[snips & comments]

Yes, the only thing I can see pointed out, that there're _many_ libraries 
that
aim to fulfish niche for geometical primitives, but there's one thing about 
these
libraries - they usually tend to be nonportable (a la nvidia's fast math 
lib) and/or
optimized for certain compiler (usually MSVC).

As for myself, I use vectors, lines (or line_segments), and other primitives 
for some
specific computations. As far as my experience shows - almost everything 
there depends
on how are vectors/matrix implemented.

I've also noticed, that we can easily find implementations for 3d, 2d hom. 
vectors
and usually their components are floats, but for gods sake - for some 
specific calculations
we can possibly need 7d vector with complex components.

I wonder even if some programmers, that write / use vectors in their 
per-daily-basis work,
know that cross product can be calculated not only for 3d vectors :) Joke.

This is my rationale of proposing vectors to boost - there's simply a need 
for standardised, efficient and (perhap a bit) STL compatible hom. vectors 
library. Hom. matrices would be nice there too, I think.

Repect,
Justinas Vygintas D.

_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis ! 
http://www.msn.fr/msger/default.asp