[racket-dev] Math library initial commit almost ready; comments on issues welcome

On Mon, Oct 1, 2012 at 1:26 PM, Neil Toronto <neil.toronto at 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