Barend Gehrels wrote:
- It is working in practice, as I justed described on that new web-page and in the post yesterday.
Perhaps it is at least as far as you've tested it since fixing some of the issues found in the review. The casting bits both explicit and implicitly in things like less<double>/greater<double> are still there and would mean your GMP types are cast to double for these predicates.
- The GMP/CLN approach was implemented in various algorithms, and it is tested there - It was not implemented in *all *algoritms, as I mailed on this list before, including the reason for that - the only thing I did yesterday was that I added it to intersection and union as well. This is not submitted to not confuse the review process, however, it is available for people who want it
As I said above (and please everyone, don't take my word for it.. do a search for 'double' on the project), the locations of these instances would seem to pollute much of the core algorithms which are likely interdependent.
- that 1e-10 tolerance occurs only once in the whole code, at a place setting a boolean flag is often set anyway. That is noted there - furthermore we compare : integer with ==, FP with epsilon (like in Boost.Test) and GMP or CLN with == . See ggl/util/math.hpp
Yes, I agree there was only one instance of this, but it is relevant nonetheless.
- there is nothing concocted on the fly of this review, besides maybe things really not implemented (as our answer to Pierre about infinity), but they are not presented as being there or already planned
I would consider changing the things I have mentioned as being concocted on the fly. How can you claim that GGL works with GMP when you have code that casts it to a double internally? I consider this point to be incontrovertible. Brandon