[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 ⊥