Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2009-03-03 11:37:37
On Tue, Mar 3, 2009 at 4:29 AM, Bruno Lalande <bruno.lalande_at_[hidden]> wrote:
> Hi Michael,
>> What types of things does the kernel encompass? If the data types are
>> user-defined and the algorithms simply work over types that match
>> particular concepts, what is left? It's all user defined types and
>> algorithms...or do you mean the kernel is all the concepts and
>> tag-dispatching machinery?
> This is the good question, precisely. I think you guessed well in your
> last sentence. Kernel could be a bunch of concepts with a ready-made
> tag dispatching mechanism (or any other generic mechanism(s)). It can
> seem very virtual, but if you look at the time we've already spent on
> it and the number of discussions around that, it's far from being
> trivial. And until an "official" library states all that, geometry
> developers will continue to reinvent everything everywhere and work
> with there do-it-all point classes.
I really like where you're headed if that's the case. A core set of
concepts and tags that are generic and flexible enough to be used
across closely related domains seems like a great thing. Stopping all
the reinvention would be awesome!
> In addition, I'd see a few algorithms on point. You can do what you
> want, if you don't have points and basic arithmetics on them, you have
> nothing, whatever the application domain. Things like dot and cross
> product (wedge product if dimension-agnostic?) would also be included.
> I find it pretty stupid to see programmers constantly rewriting such
> widely used mathematical tools.
I'd almost not even want to see those algorithms included. It seems
really elegant to me to have a set of concepts and tags that a bunch
of domain specific algorithms can use. I think dot product and cross
product belong in a linear algebra extension. You could, however,
ship the library with a few extensions already included. I think GIL
did that with the goal of adding more later.
> But as I was saying to Barend, finding the frontier is the hard part.
> Do intersection algorithms belong in the kernel, and if yes, which
See above. As a side note: I don't think kernel is really the best
term for this piece of the library. I know it's central, but it isn't
the central computing mechanism of the library since it doesn't really
> Anyway, it doesn't sound ridiculous to me to have a very tiny (though
> result of a long work) kernel. But again, is that kernel is not
> validated by lots of algorithms in a wide range of specific domains,
> it's worthless.
>> I'm ambivalent as to whether they would be separate libraries or
>> simply extensions to a Boost.Geometry library as long as they work
> This is something I had thought about. I was wondering if all the
> library authors could produce a kernel together, and continue to work
> separately but on this same kernel. And the kernel would be proposed
> as Boost.Geometry before any other more specific work. But I have to
> elaborate all this, it's a bit unclear to me for now...
I think this is a good direction to take. I know both parties will be
reluctant since they have invested so much time and effort, but surely
it would be better for the community.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk