Subject: Re: [boost] GGL Review
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-11-21 21:43:17
I tried to answer both to your current mail, and to the issues raised previously. I tried to answer your current mail straight and direct in the first part of the mail (so don't interpret the tone as unfriendly, its just meant to be clear and succinct), and then try to go into more detail of the issues raised previously.
> Michael Fawcett wrote:
> > Regardless, the point I was trying to make was that (to me) the
> > interface is more important than the implementation at this stage in
> > the library's life, and that I don't think it's fair to base
> > acceptance solely on whether the implementation is 100% robust and
> > numerically stable unless the documentation states says otherwise.
> This is a very important point in which many agree completely. This is
> an issue related to updating the Boost review process.
> The summary to me is that a proposed libary should not merit a Boost
> review if its scope doesn't match Boost goals (clearly stated at the
> beginning of the home page). It's for this reason that I argued
> strongly to Fernando that Boost.Polygon should be withdrawn to avoid
> setting a precedent (despite of other technical merits the library has!)
So you think the review process should be updated. Furthermore, you think Boost.Polygon should be withdrawn, because its scope doesn't match Boost goals.
Let's have a look at the review process then. The page
Steps for getting a library accepted by Boost:
* Learn about Boost
* Determine interest
* Preliminary submission
* Submission for review
* Formal Review
* Web site posting
* People page
The three steps "Determine interest", "Preliminary submission" and "Refinement" should be able to determine whether a proposed library matches Boost goals. Otherwise, the "Formal Review" would be quite a waste of time for all the reviewers, and even more a waste of time for the author of the proposed library. The decision that a library should be withdrawn after acceptance by "Formal Review" should certainly have better reasons than that it doesn't matches "Boost goals", and nobody noticed this earlier. It might happen that we are forced to withdraw a library because of license issues. I could also imaging that Boost.Numeric.Bindings (let's hope that it will even reach the "Formal Review" step) could be withdrawn after acceptance by "Formal Review", because the burden on the regression testing system might turn out to be intolerable.
See also Paul A. Bristow's remark on his own review
and David Abrahams' answer
to Michael Fawcett's review
However, the reason I answer to your "summary" is that you indicated "interested in your objective viewpoint" in a thread where I already stated "I don't think it is wise to make any statements in this thread".
> Hi Thomas, I apologized for some bad wordings on my side.
> Questioning the process is not an attack.
> I think I am more interested in your objective viewpoint (which is
> kind of hard to do in this thread), but you already provided it in
> your reply to me before and it was useful.
So, first of all I want to tell you that I really appreciate your apologies. And it will be OK even if you react heated to this reply. I was just unhappy that I was forced to add anything to that already unfortunate thread. And I'm not even sure whether my reply about "GENERIC GEOMETRY" set the unfortunate tone of that thread. That reply was from an unsent mail trying to explain why I don't like the name GGL and would prefer the name Boost.Geometry. (So be careful with shouting, otherwise you might be tempting people to reuse parts of unsent mails...)
Your writing about the unfair treatment of GGL and that boost polygon should be rewritten in terms of GGL gave me the impression that you are not fully appreciating the complicated situation:
> 4) The GGL library proposal, which had been iterating the design with
> input from boost, in my opinion received an unfair treatment
> in the way the schedule was managed.
> I think in this case it should be determined by at least two experts
> whether it is possible to have a generic library that can satisfy the
> multiple application domains, and if yes, then take GGL as the base,
> update the design and incorporate boost polygon algorithms as
> Boost.Polygon doesn't provide that base although it may have
> algorithms brilliantly implemented!.
> I am asking you to reconsider your decision and also provide your
> expert opinion so that GGL can be acceptable as a base where the
> Polygon algorithms can be included.
At that point I was still trying to evaluate GGL, so I certainly knew about the strong and weak points of Boost.Polygon, but I couldn't say much about the strengths and weaknesses of GGL. (Now I know that the main issue of GGL is that it is still unfinished!)
There are two types of issues for Boost.Polygon:
1) The design of the geometric concepts in Boost.Polygon is well drafted, but the implementation still has room for improvements. (But at least it is finished!) Fernando Cacciola's review gives a staggering overview of the implementation issues:
One could even classify the mediocre performance of the intersection algorithm as an implementation issue, because Luke knows exactly which part of the algorithm still uses a suboptimal implementation.
2) The other issue is floating-point. This one is really tough, because of all the subtly different opinions how the correct solution should look like. Some of us had even encouraged Luke to stay with fixed point, and only provide assistance to correctly convert floating-point to fixed point. (I guess both Fernando Cacciola and I were guilty of encouraging Luke to take that approach.) I don't even know whether the ones that reported a loss of accuracy simply made the mistake to use an arbitrary scaling factor instead of a power of two, or used the same scaling factor for both x- and y-coordinates. But it was exactly this fixed point approach which lead some reviewers to the conclusion that Boost.Polygon is only useful for PCB, VLSI and CAD.
The approach of GGL to the floating-point issue might receive more approval than the approach of Boost.Polygon, but Barend Gehrels' detailed answer to the robustness questions
(he references to http://geometrylibrary.geodan.nl/formal_review/robustness.html) shows that also GGL's approach is not without drawbacks.
So let's finally address the most difficult point. You don't like to have two incompatible boost geometry libraries (and don't see a good reason why it should not be possible to make them compatible). So you could have the idea to suggest to reject both libraries, and tell the authors that they have to agree on common concepts for the interface to the basic geometric objects at least in 2D. But you may not realize the amount of work this might imply, if the authors succeed to agree on common concepts at all. And rejecting a library means first of all that the library is not wanted in boost. (This is exactly the reason you gave why Boost.Polygon should be withdrawn: Because boost is the wrong place for it in your opinion.) And it would be a rejection for political reasons, not based on concrete technical deficiencies that could be fixed by just improving the library, like when Boost.Serialization was first rejected.
So perhaps I could help you a bit to appreciate that Fernando Cacciola's decision was not as wrong as it may seem. And please remember that it wasn't my decision. I'm just one of the reviewers that took part in both reviews, and I just tried to explain to you my personal point of view. And you will most certainly disagree with some parts of my view, and this is perfectly OK. And if you spend the time to read all this, let me also apologize that I didn't succeed in being more succinct. I hope my answer at least doesn't make you feel worse.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk