to be simpler and clearer
This caused bug #6's counterexample to change
because the unification algorithm no longer calls
∨ so we have to find a different way to call it
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.
Commit 92b0e86ed1 turns
out to have been the wrong approach, because there was no mysterious
performance problem with TR. Instead, TR's `define` expanded to new
code that interacted poorly with a macro used in the math docs.
I've kept the refactoring from that commit because I think it still
makes the code clearer, but I've removed the now extraneous comment.
After commit 3d177e454e
running the main `math.scrbl` file would show peak memory
usage of around 600-700MB when before it was around 400MB.
The proximal cause appears to be the expansion of TR
definitions, which added an extra `begin` in some cases,
combined with redefinitions at the top-level. I don't
know the core cause yet.
Thanks to Matthew for pointing out the issue and to
Vincent for helping with debugging.
self-contained (and then don't call type-check anymore
from the benchmark scripts)
this fixes a problem in the let-poly models, since some
of the bugs there cause the type-checker to raise an error
The new test case in this commit shows the bad behavior;
the fix was to replace the regexp #rx".*[^0-9]([0-9]+)$"
with #rx"([0-9]+)$", ie make the regexp work properly in
the empty case (since regexps promise to find longest matches
anyway).
Also, Rackety
The reverted commit assumed that all pkgs were in either (get-pkgs-search-dirs)
or (find-user-pkgs-dir), which is a bogus assumption
This reverts commit b600dcc7bc.
Improve the "can unbox test" to include patterns that were already covered
by the more restrictive "can unbox without disturbing N registers" test
(which is always tried first, but the weaker test recurs within patterns
that the stronger test does not recognize).
