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

[John Lato]

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 <ekmett at gmail.com> 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 <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/4279a7ea/attachment.html>