On Tue, Mar 3, 2009 at 4:29 AM, Bruno Lalande <bruno.lalande@gmail.com> 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