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

On Mon, Oct 1, 2012 at 2:26 PM, Neil Toronto <neil.toronto at gmail.com> wrote:

>  * 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?)

PR 13098 isn't really fixable, in some sense.  There's just more data
there with broader types, so it will always take longer than for more
specific types. All of the things I'd do to fix the problem would
speed up both the slow and the fast case, without really affecting the
gap between them.

>  * `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'.

Why aren't you able to do this?

>  * 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.

There's no way around this at the moment.
-- 
sam th
samth at ccs.neu.edu