In an ultimately vain attempt to make plotting fast but still allow
plots with bounds that have very few flonums in them, Plot used to try
to detect when each axis's bounds had enough flonums in it and switch to
flonum-only math. There are two problems with this:
* It was trying to determine whether *future computations* would have
enough precision, which is very difficult to know for sure, so it
only *usually* worked. (Example fail: contour-intervals3d with 0 and
+max.0 endpoints. Half the isobands weren't drawn.)
* It caused extra conversions between flonums and exact rationals,
which are very slow.
Here's the new approach:
1. Always send exact rationals to user functions (e.g. the lambda
arguments to `function' and `contour-intervals3d').
2. Immediately convert user-given plot coordinates to exact
rationals (if rational; e.g. not +nan.0)
3. Always represent normalized coordinates (e.g. in [0,1]^2 for 2D
plots and [-1/2,1/2]^3 for 3D plots) using flonums.
4. Reduce the number of exact operations as much as possible.
IOW, plot coordinates, which can be incredibly huge or tiny and don't
always fit in flonums, are always exact internally. Normalized, view,
and device coordinates, which are used only internally, always have
bounds with plenty of flonums in them, so Plot uses flonums.
Doing #4 accounts for most of the changes; e.g. to the marching
squares and marching cubes implementations, and axial plane clipping.
Most plots' speeds seem to be unaffected by the changes. Surfaces and
contour intervals are sometimes faster. Isosurfaces are a tad slower
in some cases and faster in others. Points are about 50% slower,
partly undoing the speedup from a recent commit. Plots with axis
transforms can be much slower (4x), when long, straight lines are
subdivided many times. Plots with bounds outside flonum range seem
to be about 3x faster.
The following should look as expected now:
* Intersecting or adjacent surfaces, isosurfaces, lines and paths,
even if they're sampled at different intervals.
* Rectangles that aren't spaced regularly on the x,y plane (e.g.
sideways histograms; the rectangles I plot to debug Dr. Bayes).
In general, the rendering should be robust enough to draw arbitrary
3D scenes, and it still produces high-quality PDFs.
Drawing 3D plots still has the same time complexity and seems to be
about as fast as before. Thanks to the fact that sorting objects by
view distance is an O(n) BSP tree walk, rotating 3D plots in
DrRacket is probably a little faster.
This update also adds direct support for connected lines, and
includes a fix that makes contour lines easy to see, even when
plotted on top of a non-contour-interval surface. (This wasn't
possible before.) Further, the 3D plot area no longer requires a
"grid center" vertex by which to sort grid-aligned shapes, making
the rendering API friendlier, and closer to ready for public use.
