Spheres in 2D, 3D, and dD

[afabri]

Spheres in 2D (that is circles) and 3D are represented by center, squared radius, and orientation.
dD spheres in Cartesian_d are represented by d+1 points. The orientation is defined by the orientation of the points.
Spheres in Epick_d are represented by center, squared radius, and looking at their implementation I would say they are not oriented.

This is somehow messy, and this discussion has the goal to unify if this was possible, and to define the unified API.
Questions are if we want to phase out Cartesian_d. Which package uses it?
Similarly, who uses the orientation of a Circle_2 and Sphere_3. If none of the existing CGAL packages uses it, we might deprecate it. The thing is that we have no algorithms operating on spheres.

[afabri]

@mglisse, Marc, what is your opinion on this as you are the author of Epick_d.

A package using orientation is probably the circular and spherical kernel.

[mglisse]

(I am guessing, I didn't look deeply at the code)

• The implicit representation in Cartesian_d looks like a way to write code that looks like it does a construction, but internally just remembers the arguments, so that when applying a predicate to it it can be computed directly from the original input and be exact. OTOH, Cartesian_d does not have filters, so that cannot be the reason (I guess a determinant is still numerically more stable than computing the circumcenter). It also feels like an ad hoc version of Lazy (it has a cache where it can store the center if it has already computed it).
• The orientation makes sense for the implicit representation, and I guess the 2d/3d case inherited it? The whole notion and vocabulary looks a lot like what is used inside Triangulation_23 (but without Sphere_3). A boolean inside the sphere object to remember if the notions of inside and outside should be swapped seems strange without that context, like something a user should handle separately.
• For Epick_d I went to the simplest and didn't really look much at the other versions in CGAL...
• Nobody uses those types? side_of_oriented_sphere takes as input d+1 points instead of a sphere, triangulations represent spheres as simplicial "cells", etc. It is also kind of a duplicate of Weighted_point_23d (weighted points are often drawn as circles in textbooks).
• So on the one hand the sphere is a basic geometric object that looks natural to provide (even if we don't have any algorithm working on it), and on the other hand the places where we do use a sphere want better control and don't use the kernel sphere object.

Ok, all that to say I don't have a strong opinion. I'd tend to leave that mess alone and spend effort elsewhere, unless someone comes up with a good plan for what spheres should be used for. But if you want to try deprecating it, that's ok with me.

[afabri]

It's not about deprecating Sphere_3 but that it has an orientation.