
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
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
wrote: I meant shaddowing warning. As Brent more correctly said.
On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald <
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
3) more strongly , does every instance in the Wild give a full ish
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
On Sun, Feb 17, 2019 at 12:14 AM chessai .
wrote:
We have the 'pi' constant in the floating typeclass and some
carter.schonwald@gmail.com> wrote: there? precision exact up to representation limits answer at exp 1,? treat exp 1 as being the actual definition for any all quality instances ? 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries