Add 'e' to Floating typeclass

[Carter Schonwald]

this is a math education problem, not a library design issue.

i'm asking for examples for why you expected/wanted to use e, could you
please share some? :)

i'm genuinely confused about where its use rather than exp happens.

On Thu, Feb 21, 2019 at 1:32 PM chessai . <chessai1996 at gmail.com> wrote:

> asymmetry in presence, not use.
>
> When I was first learning Haskell, the absence of e along with the
> presence of pi in Floating confused me. It is not a disservice to users to
> note this asymmetry in documentation and why it is not there.
>
> On Thu, Feb 21, 2019, 1:22 PM Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> i dont see it as an assymetry, theres a lot of very simple volume / area
>> / probability /geometry calculations  where pi comes up,
>> i dont know any for e that aren't just exp. can you share some?
>>
>> On Wed, Feb 20, 2019 at 10:50 PM chessai . <chessai1996 at gmail.com> wrote:
>>
>>> Yeah, I think it probably shouldn't be added to the typeclass then.
>>>
>>> The asymmetry should probably be mentioned in the report though.
>>>
>>>
>>> On Wed, Feb 20, 2019, 9:22 PM Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> either way, we're not gonna add e :)
>>>>
>>>> On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <gale at sefer.org> wrote:
>>>>
>>>>> Lennart's question "Is it really worth it?" is the most important one.
>>>>> And no, probably it isn't.
>>>>>
>>>>> But Chessai is correct that this is a weird asymmetry in the Floating
>>>>> class. My own experience is that I user neither e nor pi very much,
>>>>> but neither one more than the other.
>>>>>
>>>>> Branch cuts of inverse trig functions are not relevant. The report
>>>>> doesn't explicitly state this, but it's clear that these functions are
>>>>> expected to return the standard ranges of values as in other
>>>>> programming languages. You can be quite certain that acos (-1) is pi
>>>>> in Haskell. And in fact, we have (at least on my computer)
>>>>>
>>>>> Prelude> acos (-1) == pi
>>>>> True
>>>>>
>>>>> So there isn't any more or less reason to have e than pi as a separate
>>>>> class member.
>>>>>
>>>>> On Sun, Feb 17, 2019 at 10:15 PM Lennart Augustsson
>>>>> <lennart at augustsson.net> wrote:
>>>>> >
>>>>> > Is it really worth it?  How frequent are uses of e, except used like
>>>>> exp?  On the other hand, pi has more frequent standalone use cases.
>>>>> > Also, e has a simple definition (exp 1), whereas pi is somewhat more
>>>>> involved.
>>>>> >
>>>>> > The logp1 and expm1 functions where added for good numerical
>>>>> reasons.  The same would not be true for e.
>>>>> >
>>>>> > On Sat, Feb 16, 2019 at 21:14 chessai . <chessai1996 at gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> We have the 'pi' constant in the floating typeclass and some
>>>>> trigonometric functions, as well as things like exp/log/expm1/log1p.
>>>>> >>
>>>>> >> Why not provide an 'e' constant?
>>>>> >>
>>>>> >> A default implementation could just be 'exp 1'.
>>>>> >> _______________________________________________
>>>>> >> Libraries mailing list
>>>>> >> Libraries at haskell.org
>>>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>> >
>>>>> > _______________________________________________
>>>>> > Libraries mailing list
>>>>> > Libraries at haskell.org
>>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190221/954f3aab/attachment.html>