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.