
Boost : 
From: Vygis D. (vygis_d_at_[hidden])
Date: 20030522 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 2DCoordinates. 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
perdailybasis 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk