cgal/Packages/Cartesian_kernel/TODO

Stuff to look at, as time permits:
----------------------------------

- New NT requirement about greatest common divisor.

- Have unique global functions calling the kernel traits function objects,
  instead of the contrary.

- Mariette would like Circle intersection.

- Triangle-Triangle instersection (and predicate) :
    Tomas Möller. A fast triangle-triangle intersection test. Journal of
    Graphics Tools, 2(2):25-30, 1997
              A Fast Triangle-Triangle Intersection Test,  tompa@clarus.se

- det3x3_by_formula speeds up T3D a lot when it's inline.
  CGAL_KERNEL_MEDIUM_INLINE should be settable to inline from the outside...

- Stefan voudrait un tag :
  > > > As for the tag, I would like to distinguish the tag used to trigger
  > > > the
  > > > so-called advanced kernel and the tag used to distinguish coordinate
  > > > rep.

  > > > I asekd for this long time ago, and that time, I got no reply ... :)

  > > I see... :)  When was it ?  As you know, I'm back to work since october,
  > > so.
  ..
  > > I am not aware of that question.
  > > Do you have some actual code to propose for that ?
  >
  > It was long time ago, end of spring, beginning of summer.

- Remove all global function usage, and replace by common code for all kernels.
  The backward compatible layer could look like :

// Another idea : write a backward compatible wrapper for any kernel,
// say, Backward<R> using only the kernel traits R, and giving the additional
// interface to get an "old kernel interface" from it.
// So in particular, we would have :
template <class R>
Backward
{
  typedef CGAL::Point_2<Backward<R> > Point_2;
};
// Backward<R> would also be a valid kernel traits, but with
// R::Point_2 != Backward<R>::Point_2.
 
------------------------

- Tests :
  - GCOV
  - Write a Checker for full kernels, like Pm_traits_checker.h ?
  - Advanced kernel, Cd.

- Filtered_exact kernel :
  - we can attack the problem by having the .x() and co return a
    Lazy_exact_nt(), then implement the necessary higher level
    constructions/predicates on top of that.

- Handles :
  - http://www.uni-giessen.de/faq/archiv/c++-faq.part1-9/msg00005.html
    [16.22] How do I provide reference counting with copy-on-write
            semantics for a hierarchy of classes?
  - Having a proper Handle_for_virtual<> is becoming important...
    - It must have the same interface than Handle_for<> [due, it can't !]
    - Must use the allocator, see Stefan's mail. [due, impossible !]
    - Ok, after reflexion : it can't use STL allocators, however we can do
      something clean by looking at auto_ptr<>, I think.
    - It would also be nice if we could remove the ref-counting mecanism
      easily, like for Handle_for<>. [low priority, but would be nice to
      get the right interface able to do that]
      Update : it is not possible to have it since we cannot copy this object
      as we don't know its exact type !
    - Apply them to Aff_transformations, then Lazy_exact_nt<>, then... :)

- Advanced Kernel :
  - Rename CGAL_CFG_NO_ADVANCED_KERNEL to CGAL_USE_ADVANCED_KERNEL, definable
    on the command line, and not in config.h... ?
  - Have a separate (top-level) kernel for the advanced cartesian ? 

- Remove operator!=() definitions, and use STL ?
- Move include/CGAL/Kernel_common_traits.h to
  include/CGAL/Kernel/common_traits.h ?
- Use CGAL_TYPENAME_MSVC_NULL where needed.
  Only in the template parameters depending on a template parameter, right ?
  See empirically where it breaks with VC++.
- Iso_rectangleC2 should store a twotuple of _non_ ref-counted points ?
  whereas now it's a twotuple of ref-counted points, which is a pure lost.
  (all local, temporary objects don't need any ref-counting)
  Well, when you ask for the point outside, you get a handled point, so...
  Same thing for Circle/Sphere, BTW.
- Why can't we simply have : typedef Iso_rectangleC2<double> Bbox_2;  ?
  - Iso_rectangleC2 stores a Twotuple<Point_2>, which means they are
    ref-counted, which is sub-optimal...  See above.
- ::bbox() robustness issues : it's not robust, since basically, we use
  to_double().
  The homogeneous kernel uses an epsilon to get this right, in the case
  to_double() returns an error < 1 ulp().
  I would propose to use the intervals, and require the NTs to have a
  to_interval().  For most of the current ones, it's already done, so...
  Ask Stefan and the list about that.  For PointH2::bbox(), we would have:
{
  Interval_base x = CGAL::to_interval(hx());
  Interval_base y = CGAL::to_interval(hy());
  Interval_base w = CGAL::to_interval(hw());
  // The following can be slightly optimized using the advanced class.
  return Bbox_2(Interval_nt<>(x)/Interval_nt<>(w),
                Interval_nt<>(y)/Interval_nt<>(w));
}
  And PointC2::bbox():
{
  return Bbox_2(CGAL::to_interval(x()), CGAL::to_interval(y()));
}
- Orientation of Circle_2 and Sphere_3.  I wonder if it's used anywhere.
  Wouldn't it have been better if the kernel circles and spheres were not
  oriented, and if someone needs an orientation, he will be able to build one
  using the kernel's as a base or something.  Because right now, Weighted_point
  need to be defined in regular triangulations (check if it's the same
  representation, square_radius wise...)...  It seems even more strange in 3D.
  Maybe it's too late for a change, but maybe not ?
  Or maybe worth having a separate Non_oriented_Circle in the kernel ?
  (the oriented one using code from the non-oriented one...)
- Put the predicates that are marked /*CGAL_NO_FILTER*/ in a separate file,
  say <predicates/no_filter_kernel_ftC2.h> ?  This will simplify the script
  somehow, but how will it work for those damn static filters ?
  They have to be filtered for the filtered constructions kernel though.
  And they do not depend on the other predicates... yes some do !
  [ why compare_angle_with_x_axisC2() is not filtered,
    while orientationC2() is ???!!!??? ]
  Currently, there are 10/27 like that for C2, and 10/21 for C3.
  This definitely must be cleaned up.  Maybe after some work on the filtered
  kernel ?
- There are still a few predicates and constructions that are not FT-based,
  but mainly they are the simple ones, just needing to compute an opposite or
  something.  I need to think about what to do with these, it's painful to have
  a 3-stage calling sequence for not that much...
- Merge Intersection package ?  What about Conic ?
- Cd must come back to life somehow...  Currently, I've disabled it ~totally
  in Cartesian.h.  Same thing for Conics...
- line_get_pointC2() could take "i" as "const FT&" directly, not "int", it
  will avoid several constructions.  Also, propagating that to the higher
  level will also bring more functionality at the top level...
  Seems like a stupid design choice at the beginning ?
  Or did I miss something ?
  Do we want to allow that for other implementations ?
  Maybe there are other similar places.
- Homogeneous' Point_2 has member functions :
    // and for efficiency in the predicates:
    const RT&     hx_ref() const;
    const RT&     hy_ref() const;
    const RT&     hw_ref() const;
  Probably a good idea ?  Or is it worse with doubles ?  Let's try.
  Why do Point.x(), y(), hx(), hy(), hw() return FT instead of a "const FT &" ?
- Status of the test/ directories in the old C2, C3, Cartesian_basic ?
  What's in it ?  Should it be kept or thrown ?
- include/CGAL/smallest_radiusC2.h should use the kernel code.
  Check if it's ok (correct and as efficient), and tell Frank to do so.
  The name of this file doesn't have anything to do with what is inside anyway.
- Herve complains that the design of the CGAL kernel is too
  cartesian/homogeneous oriented, whereas it could be made more general (think
  polar kernel).  Anyone with a concrete proposal ? :)

Notes:
------
- To run the test-suite, go in the Kernel_test package, and add the correct
  "-I../../../Cartesian_kernel/include" line in the makefile.