Proposal: Add log1p and expm1 to GHC.Float.Floating

[Henning Thielemann]

Am 24.04.2014 06:46, schrieb Gershom Bazerman:
> Let me try to be a bit concrete here.
>
> Are there _any_ implementations of Floating outside of base that we know
> of, which we are _concretely_ worried will not implement log1p and thus
> cause algos to lose precision? If anybody knows of these
> implementations, let them speak!

There are libqd bindings, I have implementations of arbitrary precision 
arithmetic based on Rational and lazy lists of digits. However you 
wanted to know examples of libraries where log1p and expm1 might not be 
implemented and I assume that if we knew such a library, then we would 
be one step closer to fixing it.

> Also, in general, I don't care what happens to Floating, because it is a
> silly class with a hodgepodge of methods anyway (plenty of which
> potentially apply to things that aren't 'floating point' in any
> meaningful sense), although RealFloat is even sillier. (By the way did
> you know that RealFloat has a defaulted "atan2" method? Whatever we do,
> it won't be worse than that).

I follow the discussion in order to find out what to do with 
numeric-prelude. I might add log1p and expm1 methods to the 
Transcendental class. However I could do this completely independent 
from 'base' by calling log1p and expm1 from glib or gsl.


> Anyway, +1 for the original proposal, and also +1 for adding this to
> RealFloat instead if that's acceptable, because I'm sure everyone could
> agree that class couldn't possibly get much worse, and there's precedent
> there anyway.


RealFloat would exclude the Complex instance.


> Also, I should add, as a rule, I think it is near-impossible to write
> numerical code where you genuinely care both about performance and
> accuracy in such a way as to be actually generic over the concrete
> representations involved.

That's certainly true, thus a new Fused class might not be the worst 
solution. As I understood such classes already exist in Hackage packages.