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

[Edward Kmett]

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 <ekmett at gmail.com> 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 <jwlato at gmail.com> wrote:
>
>> There's one part of this alternative proposal I don't understand:
>>
>> On Mon, Apr 21, 2014 at 5:04 AM, Edward Kmett <ekmett at gmail.com> 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 at gmail.com> wrote:
>>>
>>>> On 21 April 2014 09:38, John Lato <jwlato at 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
>>>> 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
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140423/df875a4d/attachment.html>