I've noticed that Clojure is missing several math functions that come
standard with most programming languages, especially other
Schemes/Lisps.  Many of these functions are available in java's math
library, but only for doubles.

I am attaching a file that tries to "do the right thing" for Clojure's
other numeric types, for inclusion in the contribs, or possibly the
core.  I have sent in a contributor agreement, but am unfamiliar with
the submission process.  Do I just attach the file here, or is there
somewhere I'm supposed to upload them?  Are there standards for
documenting and including test cases that I need to follow?

I started with expt, because the lack of expt was the biggest nuisance
for me.  If you give it an exact number (i.e., not a floating point),
and an integer exponent, it will give you a precise result, otherwise
it calls Java's double version of pow.  I posted this the other day,
but it is included again here, with a couple minor tweaks.

Next, I did floor, ceiling, and round.  All of these functions yield
an integer if the input is an exact number, otherwise they do whatever
Java's double version does (Java's floor and ceiling yield doubles,
and round yields an integer or the max int if out of range).  round is
a round-up to mimic Java's behavior (I think that in Scheme, round is
usually a round-to-even, so this is a potential gotcha to be aware
of).

Those are the additions that I consider most essential.

While I was at it, I added implementations for abs and mod, which are
standard in most languages, and gcd which is standard in Scheme.

Also, I added a version of sqrt that gives an exact answer whenever
there is an exact answer (works on integers, decimals, and fractions),
otherwise it gives you whatever Java's sqrt produces.  I don't know
how generally useful this is, but it's the behavior I've come to
expect from working with Scheme.

I hope everyone finds these functions as useful as I do.

P.S.  While writing these functions, I really liked working with
Clojure's multimethod system, and found it very intuitive to set up
functions that do the right things.  For example, expressing a custom
version of expt when the base is "exact" and the power is "some kind
of integer type" was a snap.

math.clj 5K Download

Seriously, handy code -- many thanks!  I should check with someone
whether sqrt(a/b) -> sqrt(a)/sqrt(b) is a fair assumption.  Would you
find a sqrt that returns complex numbers for negative inputs (it would
be the appropriate branch of the sqrt function in order to make it
single-valued) useful?

mfh

As for taking square roots involving complex numbers, I've been
considering that as well, but I think it might be a bad idea to have
it as a part of the normal sqrt function.  In the majority of
situations, taking the square root of a negative number is a bad thing
and probably shouldn't be allowed.  An alternative sqrt associated
with complex numbers could be appropriate instead.

On Jan 3, 10:06 pm, "Mark H." <mark.hoem...@gmail.com> wrote:

http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/6127.html

mfh