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
>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
I just pointed out that uBLAS is not that useful in certain contexts and
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
aim to fulfish niche for geometical primitives, but there's one thing about
libraries - they usually tend to be nonportable (a la nvidia's fast math
optimized for certain compiler (usually MSVC).
As for myself, I use vectors, lines (or line_segments), and other primitives
specific computations. As far as my experience shows - almost everything
on how are vectors/matrix implemented.
I've also noticed, that we can easily find implementations for 3d, 2d hom.
and usually their components are floats, but for gods sake - for some
we can possibly need 7d vector with complex components.
I wonder even if some programmers, that write / use vectors in their
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.
Justinas Vygintas D.
MSN Messenger : discutez en direct avec vos amis !
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk