On Mon, Oct 1, 2012 at 1:26 PM, Neil Toronto <neil.toro...@gmail.com> wrote: > 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.
FWIW, this particular contract can be written as a dependent contract. > * 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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
