[racket-dev] Math library initial commit almost ready; comments on issues welcome
I think I'm about a week away from having the math library's initial
commit ready. It just needs some more docs and test cases.
Here are the high-level issues, for which I'm soliciting comments,
suggestions, questions, and answers:
* Compile time. It currently takes 1m20s to compile `math' without
docs on my beefy laptop. That's down from 2m30s, with the reduction from
replacing general functions with flonum-specific functions in over half
of the flonum code (e.g. replacing `+' with `fl+'). I think I can get it
down to 45s or so by doing that in the rest of the files, maybe further
if I use fixnum-specific ops on indexes and counters.
That task is mind-numbing and takes time. Does anybody mind if I check
the code in before doing it? (Maybe let the TR team take a crack at PR
13098 first, which is about this issue?)
* flvectors don't print nicely, which puts them at odds with their new
complex-valued counterpart, fcvectors:
> (require math/vector racket/flonum)
> (fcvector 1.0+0.0i 2.0+0.0i)
(fcvector 1.0+0.0i 2.0+0.0i)
> (flvector 1.0 2.0)
#<flvector>
I looked at the C code for printing flvectors, and changing it is beyond
me right now. Also, are there serious objections to making flvectors
print in constructor style?
* `math/base' re-exports `racket/math', but with extra constants (like
`phi.0') and functions (like `power-of-two?'). It also exports improved
hyperbolic functions, such as a new `sinh' that's much more accurate
near zero: in the worst case, 2e-16 relative error (which is great)
instead of 0.5 (which is really bad). But its type in `math/base' is
(case-> (Zero -> Zero)
(Flonum -> Flonum)
(Real -> Real)
(Float-Complex -> Float-Complex)
(Complex -> Complex))
I haven't been able to give it a type as specific as the type of the
`sinh' exported from `racket/math'.
* It makes sense to me to have `racket/math' re-export `math/base',
but `case->' types with one arity (like that of `sinh') can't be
converted to contracts.
* Another typed/untyped barrier issue: certain functions are actually
macros so that TR can optimize around their expansions. (Example: by
making `fcvector-ref' a macro, (+ (fcvector-ref xs 0) (fcvector-ref ys
0)) operates entirely on unboxed Float-Complex values.) I really don't
want to make an `untyped/math' library to expose the function versions,
but I can't think of a way around it.
I'm pretty sure none of this is bikeshedding, but I apologize in advance
if I'm wrong about that. :)
Neil ⊥