Kernel_23d: Add a Bbox class with dimension as parameter

[afabri]

Summary of Changes

For the upcoming Frechet Distance package we need a dD bounding box. We do not have that in Kernel_d, and there is such a class in ign's Distributed Delaunay Triangulation package to come (link). This PR copies it to the Kernel package (with the ok of @mbredif), but in the CGAL namespace.

This draft pull request is to get a discussion started.

• In the initial version even the number type is a template parameter. Do we want to keep that?
• Do we want to make Bbox_2/3 a typedef of this new class?
• We have to go through the API and probably enrich it with what Bbox_2 offers additionally.
• Do we have to add functions in Kernel_d?

Release Management

• Affected package(s): Kernel_23
• Feature/Small Feature (if any): tbd
• Link to compiled documentation (obligatory for small feature) wrong link name to be changed
• License and copyright ownership: LGPL , owned by IGN

[afabri]

@mglisse I am also wondering why there is no bounding box class in Epick_d etc. Apparently there is no need for it so far, but would you like to see it integrated? With functors etc.

[mglisse]

The assertion allows min_values.size() == 0 and dim != 0, but then min_values[i] is read 😕

[mbredif]

That's wrong indeed.
min_values.size()==0 happens for a default constructed Bbox with a dynamic dimension, which models an empty bbox. In this case, values should just be copied from bbox to this.

[afabri]

@mbredif do I have to make you collaborator, or is this already the case?

[mglisse]

@mglisse I am also wondering why there is no bounding box class in Epick_d etc.

I remember thinking about it, maybe discussing it, but I don't remember the content...

Apparently there is no need for it so far,

That may have played a big role 😉 (it doesn't seem to be part of the Kernel_d concept)

but would you like to see it integrated? With functors etc.

If you have a use for it, we probably should.
To be sure I understand: the current bbox_23 always use double, whatever the kernel, making them not really kernel objects. Is the plan the same for the new bbox, i.e. ignore the generality offered by the template parameter and only use it with double (otherwise it becomes Iso_rectangle_2/Iso_cuboid_3)?
It looks like the kernel integration can be done later in a separate PR (this one adds the class), which gives me a bit of time to think about how that fits with the design of NewKernel_d.

[mglisse]

It seems a bit wasteful to use 2 containers of size d instead of one of size 2*d, but that's an implementation detail so it doesn't matter now.

[afabri]

Bbox_2/3 first print lower left and then upper right.

[afabri]

I find it surprising that for a Bbox with non-dynamic dimension I have to pass parameter d.

[mbredif]

that was to offer a common API whatever the dimension dynamics

[afabri]

We also need a constructor taking an iterator range of coordinates. And maybe also for a range of pairs of coordinates.
The former is needed when constructing a bbox from a point with floating point coordinates. The latter when constructing
it from exact coordinates transformed to a std::pair<double,double> using CGAL::to_double().

I just realize that this would correspond more to what you do for the I/O operators. But do we want a constructor for a range of low and a second range for high? Seems not intuitive.

[afabri]

As Epick_d may have a dynamic and a static dimension, depending on a template parameter, the functor Epick_d::Construct_bbox_d() must return either a bbox type with dynamic and static dimension, respectively.

[sloriot]

Kernel_23 failing in CGAL-6.0-Ic-284

[sloriot]

Kernel_23 tests are failing in CGAL-6.0-Ic-295.
See for example here and there.