Re: [boost] [geometry] area, length, centroid, behavior

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
> ones?...

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
compute anything.

> 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.

Agreed, wholeheartedly.

>> I'm ambivalent as to whether they would be separate libraries or
>> simply extensions to a Boost.Geometry library as long as they work
>> together.
>
> 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.

--Michael Fawcett