[racket] Math library ready for testing

From: Michael Wilber (mwilber at uccs.edu)
Date: Fri Dec 7 21:31:30 EST 2012

This is such an exciting time to be a Racket programmer! Thanks for all
your work, Neil.

During winter break once I'm finished with grad school apps, I'll
convert my final Signals and Systems Matlab project to racket/math to
get a feel for the library.

One note off-hand: I really don't like the (array #[#[#[...]]]) syntax.
In Matlab, a 2D array is just:
    [1 2; 3 4]
That's 10 characters. In Python, the equivalent array is (including whitespace):
    [[1, 2], [3, 4]]
But in Racket, the equivalent array is:
    (array #[#[1 1] #[3 4]])
This syntax, especially the visual weight of all the hash marks #[#[,
makes it harder for me to visually scan the line and see the actual
array values. To see this, note that I miscopied one of the numbers
when I wrote the racket array. How many seconds did it take you to find
my mistake? Now imagine doing that at 3AM when drunk and you get an idea
of my reason for saying this. This is the kind of syntax that will trip
up undergraduates who are trying to debug their programs.

Another syntax might be something akin to vectors: #[[1 2] [3 4]]

Or just (array (1 2) (3 4))

Or maybe using a : or something to separate rows for 2D arrays?
(array 1 2 : 3 4)

(array 1 0 0 0 0 0
     : 0 1 0 0 0 0
     : 0 0 1 0 0 0
     : 0 0 0 1 0 0
     : 0 0 0 0 1 0
     : 0 0 0 0 0 1)

All of these feel much less "racket-y," but they would eliminate all the
visual cruft.


Neil Toronto <neil.toronto at gmail.com> writes:
> I've just pushed the last commits that make the new math library ready
> for wider testing. Almost everything ready for use is documented, the
> tests keep passing, and everything *seems* to work.
>
> We (the Racket development team) need people to use the heck out of it,
> to find the majority of the remaining logic and design errors before the
> next release. This is a big chunk of new code - ~20k lines in ~100
> nontrivial files - so the more eyes, the better.
>
> If all you have time for is checking documentation, we'll take it. The
> latest docs are here:
>
>      http://pre.racket-lang.org/docs/html/math/
>
> The nightly builds are here:
>
>      http://pre.racket-lang.org/installers/
>
> For Windows and Mac, the nightlies should include two new libraries used
> by `math/bigfloat': libgmp and libmpfr. Linux users almost certainly
> already have them; many packages (e.g. gcc) depend on libmpfr.
>
> If you prefer to build from source, clone the git repository here:
>
>      https://github.com/plt/racket
>
> If you're building on Windows or Mac, you can download pre-built libgmp
> and libmpfr from here:
>
>      http://download.racket-lang.org/libs/10/
>
> ************
>
> Once you have a pre-release build, do (require math), and away you go!
>
> Well, it's probably not obvious where to start. The following are the
> modules that `math' re-exports, and for some, what needs testing. Please
> feel free to skim. In decreasing order of attention they need:
>
> (require math/array)
>
>    NumPy/SciPy/Repa-like arrays, Typed-Racket-style. Provides a
>    covariant `Array' type and several mutable subtypes, array literals,
>    functional constructors, pointwise operations with automatic
>    broadcasting in SciPy/NumPy or permissive mode, slicing, indexing
>    tricks, folds, easy arbitrary transformations, and parallel FFT.
>
>    This one needs a lot of usability testing. In particular...
>
>    We're trying something that's been done only once before, in
>    Haskell's Repa: by default, arrays' elements are *non-strict*,
>    meaning that they're recomputed when referenced. Cool things about
>    this: pretty much everything can in principle be parallelized, and
>    most intermediate arrays use almost no memory. But it requires more
>    thought from users about when arrays should be made strict (computed
>    and stored all at once). If it totally sucks, we can change it. If
>    it's a worthwhile imposition, we'll leave it. If it's a wash, we
>    could parameterize the default behavior.
>
>    Also, I've been considering allowing negative axis numbers and row
>    indexes. Need feedback on how helpful it would be vs. confusing and
>    error-hiding.
>
>    Lastly, I'm looking for a dual of `array-axis-reduce' (a kind of
>    fold) that makes it easy to write `list-array->array', the inverse of
>    the existing `array->list-array'. If you're into functional design
>    puzzles, give this one a shot.
>
> (require math/bigfloat)
>
>    Floating-point numbers with arbitrarily large precision and
>    large exponents. Also elementary and special functions, whose results
>    are proved to be correct in many theses and dissertations. This is a
>    Racket interface to MPFR (www.mpfr.org).
>
>    This module needs platform-specific testing.
>
>    I think we've verified that `math/bigfloat' works on all the
>    supported 64-bit platforms, but not whether it works on supported
>    32-bit platforms. It should. ;)
>
>    There's an error in the current nightly build, which causes an
>    infinite loop when libmpfr isn't installed and a bigfloat function is
>    applied. I just pushed a fix; it should fail properly tomorrow.
>
> (require math/distributions)
>
>    Probability distributions: discrete, integer-valued and real-valued.
>    Distribution objects can compute pdfs, cdfs and inverse cdfs,
>    optionally in log space, and for cdfs and inverse cdfs, optionally
>    for upper tails. They can also generate samples.
>
>    Design ideas are welcome. More distributions are planned. Let me know
>    which you need, and I'll concentrate on those first.
>
>    Watch out, R. Our gamma cdf is more accurate.
>
> (require math/special-functions)
>
>    Non-elementary functions like gamma, erf, zeta, Lambert W, and
>    incomplete gamma and beta integrals. Most of these should be fairly
>    accurate; i.e. they compute answers with apparently < 5 ulps error
>    for the majority of their domains. But floating-point domains are
>    huge, so the more use, the better.
>
> (require math/number-theory)
>
>    Number theory! Chinese Remainder solutions, coprimality and primality
>    testing, factorization, congruence arithmetic parameterized on a
>    current modulus, integer nth roots, multiplicative functions, common
>    number sequences (Bernoulli, Eulerian, tangent, etc.), combinatorics,
>    primitive roots, and more.
>
>    Please thank Jens Axel Søgaard, who wrote this module, for his
>    excellent work.
>
> (require math/statistics)
>
>    Functions to compute summary values for collections of data, and to
>    manage weighted samples. Every function for which it makes sense
>    accepts weighted values, including the O(1)-space running statistics
>    update.
>
>    I'm in the middle of documenting this. I'll get around to documenting
>    correlation, kth-value order statistics (via quickselect), and
>    counting/binning at least by Dec. 18.
>
> (require math/flonum)
>
>    Re-exports `racket/flonum' along with many more floating-point
>    goodies. If you're a floating-point nut, you'll love it. If you're
>    not, at least check out `flsum'. If you're doing statistics, look
>    into log-space arithmetic (`lg+' and friends).
>
> (require math/base)
>
>    Re-exports `racket/math'; also exports some more constants like
>    gamma.0 (Euler-Mascheroni), a bit more float-complex support, inverse
>    hyperbolic functions, large random numbers, error measurement.
>
> Lastly, there's `math/matrix', which is currently not re-exported by
> `math' because I haven't reviewed it yet. This is more from Jens Axel,
> and if it's like his other fine work, it's correct and well-tested. I'll
> probably get to it by Christmas.
>
> To sum up, there are 8 modules that need pounding on, and we need YOU to
> do some pounding. If you're not terribly busy, please pick one that
> looks interesting/fun/useful, and try it out.
>
> Thanks!
>
> Neil ⊥
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users


Posted on the users mailing list.