From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-10 18:09:24
>> >yet. There are very valid reasons that the size of a coordinate set
>> >should be specified at compile time for cases other than 2 or 3.
>> You would not be using my library with these types, ...
>Well then maybe I should back out of this discussion, I am interested
>a generic geometry library that will provide me with a framework to
>write algorithms that work with any (or many) external opensource,
>commercial, or legacy geometry libraries.
>If that is not an aim of GTL then I appologize for the noise :-)
That is the aim. I don't want you to back out of the discussion.
Instead of an n-d point concept, which provides you relatively little,
why not extend the library to have explicit quaternians and homogeneous
point concepts and algorithms specific to such geometry? Wouldn't that
serve you better? It isn't my aim to provide those, because they are
not used in my domain, but I do want to provide a framework that can be
extended to include geometry that I don't personally need.
Another example of compatibility is graph representations. I have an
algorithm that computes the connectivity graph of polygons. Right now
it is modeling the graph it populates in a fairly rudimentary and
restrictive way. It would be better to make it compatible with boost
graph's graph concept (if not directly use it.)
I am looking at these compatibility issues and I want people to bring
them to my attention so I don't overlook something just because it isn't
relevant to my own domain.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk