<div><div dir="auto">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 </div></div><div dir="auto"><br></div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto">There’s no such holes or gaps in relating e and exp. </div><div dir="auto"><br></div><div dir="auto">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!</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 17, 2019 at 2:34 PM Yitzchak Gale <<a href="mailto:gale@sefer.org">gale@sefer.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Shaddowing of 'e' is not a reason not to do this - it's only a reason<br>
not to call it 'e'. There has never been a shortage of bikeshedding<br>
skills in this community. I'm sure we could come up with something if<br>
we decide to do it. At least as good as things like<br>
"GHC.Float.log1mexp" that have already been added to this typeclass.<br>
<br>
I think Carter's remarks about exp 1 are more to the point. Can we<br>
assume that every implentation special cases exp 1, or is computing<br>
exp 1 once and sharing it really satisfactory? And if so - then what's<br>
so much worse about 2 * asin 1?<br>
<br>
On Sun, Feb 17, 2019 at 5:41 PM Carter Schonwald<br>
<<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br>
><br>
> I meant shaddowing warning.  As Brent more correctly said.<br>
><br>
> On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br>
>><br>
>> There’s at least  two reasons why I think this would be a bad idea<br>
>><br>
>> 1) everyone uses e as a local variable name, or at least it happens often enough. This would breaklots of code<br>
>><br>
>> 2 ) I’m not sure if there’s ever a better definition than exp 1.  Is there?<br>
>><br>
>> 3) more strongly , does every instance in the Wild give a full ish precision exact up to representation limits answer at exp 1,?<br>
>><br>
>> 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 ?<br>
>><br>
>> On Sun, Feb 17, 2019 at 12:14 AM chessai . <<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@gmail.com</a>> wrote:<br>
>>><br>
>>> We have the 'pi' constant in the floating typeclass and some trigonometric functions, as well as things like exp/log/expm1/log1p.<br>
>>><br>
>>> Why not provide an 'e' constant?<br>
>>><br>
>>> A default implementation could just be 'exp 1'.<br>
>>> _______________________________________________<br>
>>> Libraries mailing list<br>
>>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>