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

24 Apr 2014

      Ah.  Indeed, that was not what I thought you meant.  But the user may not
be compiling DodgyFloat; it may be provided via apt/rpm or similar.

Could you clarify one other thing?  Do you think that \x -> log (1+x)
behaves the same as log1p?

On Wed, Apr 23, 2014 at 5:08 PM, Edward Kmett  wrote:
...
I think you may have interpreted me as saying something I didn't try to
say.
To clarify, what I was indicating was that during the compilation of your
'DodgyFloat' supplying package a bunch of warnings about unimplemented
methods would scroll by.
-Edward
On Wed, Apr 23, 2014 at 8:06 PM, Edward Kmett  wrote:
...
This does work.
MINIMAL is checked based on the definitions supplied locally in the
instance, not based on the total definitions that contribute to the
instance.
Otherwise we couldn't have the very poster-chid example of this from the
documentation for MINIMAL
class Eq a where
    (==) :: a -> a -> Bool
    (/=) :: a -> a -> Bool
    x == y = not (x /= y)
    x /= y = not (x == y)
    {-# MINIMAL (==) | (/=) #-}
On Wed, Apr 23, 2014 at 7:57 PM, John Lato  wrote:
...
There's one part of this alternative proposal I don't understand:
On Mon, Apr 21, 2014 at 5:04 AM, Edward Kmett  wrote:
...
* If you can compile sans warnings you have nothing to fear. If you do
get warnings, you can know precisely what types will have degraded back to
the old precision at *compile* time, not runtime.
I don't understand the mechanism by which this happens (maybe I'm
misunderstanding the MINIMAL pragma?).  If a module has e.g.
...
import DodgyFloat (DodgyFloat) -- defined in a 3rd-party package,
doesn't implement log1p etc.
x = log1p 1e-10 :: DodgyFloat
I don't understand why this would generate a warning (i.e. I don't
believe it will generate a warning).  So the user is in the same situation
as with the original proposal.
John L.
...
On Mon, Apr 21, 2014 at 5:24 AM, Aleksey Khudyakov <
alexey.skladnoy@gmail.com> wrote:
...
...
I was just wondering, why not simply numerically robust algorithms as
defaults for these functions?  No crashes, no errors, no loss of
On 21 April 2014 09:38, John Lato  wrote:
precision,
...
everything would just work.  They aren't particularly complicated,
so the
performance should even be reasonable.
I think it's best option. log1p and exp1m come with guarantees
about precision. log(1+p) default makes it impossible to depend in such
guarantees. They will silenly give wrong answer