cgal/Packages/Cartesian_kernel/TODO

127 lines
6.0 KiB
Plaintext

Stuff to look at, as time permits:
----------------------------------
- Tests :
- GCOV
- G++ 2.97.
- Write a Checker for full kernels, like Pm_traits_checker.h ?
- Handles :
- Having a proper Handle_for_virtual<> is becoming important...
- It must have the same interface than Handle_for<>
- Must use the allocator, see Stefan's mail.
- Aff_transformations :
- Finish merging .C files in corresponding .h files.
- Use Handle_for_virtual<>.
- 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 ?
- Pierre reported that the operator>>() should test for empty stream,
something like :
diff -ru CGAL-2.3-I-6/include/CGAL/SimpleCartesian/CircleS2.h CGAL-2.3-I-6-new/include/CGAL/SimpleCartesian/CircleS2.h
--- CGAL-2.3-I-6/include/CGAL/SimpleCartesian/CircleS2.h Fri Oct 27 16:48:01 2000
+++ CGAL-2.3-I-6-new/include/CGAL/SimpleCartesian/CircleS2.h Tue Oct 31 11:15:41 2000
@@ -333,7 +333,7 @@
cerr << "Stream must be in ascii or binary mode" << std::endl;
break;
}
- c = CircleS2<FT>(center, squared_radi, (Orientation)o);
+ if (is) c = CircleS2<FT>(center, squared_radi, (Orientation)o);
return is;
}
#endif // CGAL_NO_ISTREAM_EXTRACT_CIRCLES2
- Fix problems with VC++ like Dima suggested : put ctors definitions in the
class body.
- Use CGAL_TYPENAME_MSVC_NULL instead of "#define typename".
Only in the template parameters, right ?
- 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)
- ::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()));
}
- 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.
- 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...)
- Test Advanced Kernel, Cd.
- 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.
- Bonne remarque de Mariette :
question subsidiaire sur le noyau :
sais tu pourquoi Point_2<R> (dans sa version actuelle)
redefinis les functions qu'elle pouurait silpement heriter de
R::Point_2_base.
Y a t il une ruse, un workaround, une subtilite,
un truc d'efficacite la dedans?
ou alors c'est juste pour avoir l'interface des classes utilisateurs plus
lisible ?
Notes:
------
- To run the test-suite, download the Kernel_test package, and add the correct
"-I../../../Cartesian_kernel/include" line in the makefile.