Add 'e' to Floating typeclass

[Carter Schonwald]

While I understand the intent of your point yitzchak, inverse sine is less
intrinsically uniquely defined than exp.  in at least the sense that it’s
not uniquely defined  in two senses

1)inverse sine and inverse cosine only are defined over the interval -1
through +1, a domain restriction that can’t be modeled all that well

2) we are usually talking about the “branch cut” of solutions in the
closed/open interval [0,2pi),  but the set of numbers pi *(1+2n), for n an
integer are all valid solutions.  A similar issue comes up with the natural
logarithm when we look at things over the complex numbers

There’s no such holes or gaps in relating e and exp.

You do raise a good point about computing ... and the answer I think
depends on whether the data type of interest has a static or dynamic
character to its precision in representation.  And or the precision /
compute tradeoffs thereof.  Let alone anything with explicit support for
computer algebra fun!


On Sun, Feb 17, 2019 at 2:34 PM Yitzchak Gale <gale at sefer.org> wrote:

> Shaddowing of 'e' is not a reason not to do this - it's only a reason
> not to call it 'e'. There has never been a shortage of bikeshedding
> skills in this community. I'm sure we could come up with something if
> we decide to do it. At least as good as things like
> "GHC.Float.log1mexp" that have already been added to this typeclass.
>
> I think Carter's remarks about exp 1 are more to the point. Can we
> assume that every implentation special cases exp 1, or is computing
> exp 1 once and sharing it really satisfactory? And if so - then what's
> so much worse about 2 * asin 1?
>
> On Sun, Feb 17, 2019 at 5:41 PM Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> >
> > I meant shaddowing warning.  As Brent more correctly said.
> >
> > On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
> >>
> >> There’s at least  two reasons why I think this would be a bad idea
> >>
> >> 1) everyone uses e as a local variable name, or at least it happens
> often enough. This would breaklots of code
> >>
> >> 2 ) I’m not sure if there’s ever a better definition than exp 1.  Is
> there?
> >>
> >> 3) more strongly , does every instance in the Wild give a full ish
> precision exact up to representation limits answer at exp 1,?
> >>
> >> I only thought of the name space issue after I stated writing this
> email , but I think that kills it.. but I am genuinely curious : can we
> treat exp 1 as being the actual definition for any all quality instances ?
> >>
> >> On Sun, Feb 17, 2019 at 12:14 AM 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190217/fbbd4b44/attachment.html>