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 ⊥
_________________________
 Racket Developers list:
 http://lists.racket-lang.org/dev

Reply via email to