Add 'e' to Floating typeclass

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Add 'e' to Floating typeclass

chessai .
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Brent Yorgey
Because it would cause a shadowing warning with every program that ever used the variable name 'e'.  This doesn't really seem worth it.

On Sat, Feb 16, 2019 at 11:14 PM chessai . <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Carter Schonwald
In reply to this post by chessai .
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 . <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Carter Schonwald
I meant shaddowing warning.  As Brent more correctly said. 

On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald <[hidden email]> 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 . <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

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
<[hidden email]> wrote:

>
> I meant shaddowing warning.  As Brent more correctly said.
>
> On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald <[hidden email]> 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 . <[hidden email]> 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
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
<[hidden email]> wrote:
>
> I meant shaddowing warning.  As Brent more correctly said.
>
> On Sun, Feb 17, 2019 at 10:39 AM Carter Schonwald <[hidden email]> 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 . <[hidden email]> 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
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Lennart Augustsson
In reply to this post by chessai .
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 . <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Yitzchak Gale
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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Carter Schonwald
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

chessai .
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 <[hidden email]> wrote:
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Carter Schonwald
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 . <[hidden email]> 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 <[hidden email]> wrote:
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

chessai .
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 <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> wrote:
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 . <[hidden email]> 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 <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> wrote:
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add 'e' to Floating typeclass

Levent Erkok
In reply to this post by chessai .
I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.

I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)

I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 10:32 AM chessai . <[hidden email]> 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 <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> wrote:
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

qualified exports , what would that mean Re: Add

Carter Schonwald
hey Levent,
I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)

its definitely an interesting idea, and i certainly dont have clarity on what the implications would be

On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <[hidden email]> wrote:
I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.

I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)

I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 10:32 AM chessai . <[hidden email]> 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 <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> wrote:
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Evan Laforge
> On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <[hidden email]> wrote:
>>
>> I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.
>>
>> I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)
>>
>> I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald
<[hidden email]> wrote:
>
> hey Levent,
> I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)
>
> its definitely an interesting idea, and i certainly dont have clarity on what the implications would be

If I interpret it correctly, I think what it becomes is that some
symbols can never be imported unqualified.  Or maybe that the default
"import all unqualified" actually means "everything except these
things."  So it would just be an extra rule for what `import` brings
into scope.  Python has such a mechanism, if you have an `__all__ =
[x, y, z]` then `from m import *` will just get you x, y, and z.

That said, to me it seems like too many ways to do it.  The user can
already get a qualified import if they want it.  When you write an
unqualified "import *", the price you pay is losing control over your
namespace, and that's a known cost.  A bit more finesse on what
exactly is imported won't change the basic tradeoff.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Levent Erkok
Evan: I liked how you put it: "A bit more finesse on what exactly is imported won't change the basic tradeoff." But still seems to me that Haskells exporting mechanism can be improved. (Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants. But that's a whole another can of worms.)

I think there's design space here to be explored; in the end, it's the end-users who will have to judge what's useful and what's not.

On Thu, Feb 21, 2019 at 12:46 PM Evan Laforge <[hidden email]> wrote:
> On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <[hidden email]> wrote:
>>
>> I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.
>>
>> I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)
>>
>> I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald
<[hidden email]> wrote:
>
> hey Levent,
> I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)
>
> its definitely an interesting idea, and i certainly dont have clarity on what the implications would be

If I interpret it correctly, I think what it becomes is that some
symbols can never be imported unqualified.  Or maybe that the default
"import all unqualified" actually means "everything except these
things."  So it would just be an extra rule for what `import` brings
into scope.  Python has such a mechanism, if you have an `__all__ =
[x, y, z]` then `from m import *` will just get you x, y, and z.

That said, to me it seems like too many ways to do it.  The user can
already get a qualified import if they want it.  When you write an
unqualified "import *", the price you pay is losing control over your
namespace, and that's a known cost.  A bit more finesse on what
exactly is imported won't change the basic tradeoff.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

export control (Was: Add 'e' to Floating typeclass)

Henning Thielemann
In reply to this post by Levent Erkok

On Thu, 21 Feb 2019, Levent Erkok wrote:

> I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import
> qualified," why not "export qualified" some names, which means if you simply import the module the name will
> still be available qualified. (You can of course always import qualified.)
>
> I haven't thought too much about the implications of this, but it might be an easy solution to this problem.
> Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add
> it to GHC?

Why not providing two modules: One that exports all identifiers and one
that exports only identifiers that are likely not to clash with others.
The first module would export 'e' and the second one would not. The first
module would preferably be imported with qualification and the second one
without.

However, unrestricted unqualified imports (like for the second module) are
most oftenly not what you want because you have to restrict the imported
package to a specific minor version then (according to PVP).
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Lennart Augustsson
In reply to this post by Carter Schonwald
Qualified exports seem very unproblematic to me.  And they should be easy to implement. It’s just an extra flag on each exported entity that tells compiler if the unqualified name should be entered into the symbol table or not. 

  — Lennart

On Thu, Feb 21, 2019 at 11:04 Carter Schonwald <[hidden email]> wrote:
hey Levent,
I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)

its definitely an interesting idea, and i certainly dont have clarity on what the implications would be

On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <[hidden email]> wrote:
I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.

I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)

I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 10:32 AM chessai . <[hidden email]> 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 <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> wrote:
either way, we're not gonna add e :) 

On Wed, Feb 20, 2019 at 8:30 AM Yitzchak Gale <[hidden email]> 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
<[hidden email]> 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 . <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: qualified exports , what would that mean Re: Add

Bryan Richter-2
In reply to this post by Levent Erkok
> Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants

I believe you are in luck. Since 7.8.1, GHC supports "unidirectional pattern synonyms", as described somewhere in this section: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PatternSynonyms


On Thu, 21 Feb 2019, 23.13 Levent Erkok, <[hidden email]> wrote:
Evan: I liked how you put it: "A bit more finesse on what exactly is imported won't change the basic tradeoff." But still seems to me that Haskells exporting mechanism can be improved. (Another pet peeve: Export constructors but only for pattern matching purposes, i.e., elimination; not for construction--we'd export smart constructors for the latter which would ensure invariants. But that's a whole another can of worms.)

I think there's design space here to be explored; in the end, it's the end-users who will have to judge what's useful and what's not.

On Thu, Feb 21, 2019 at 12:46 PM Evan Laforge <[hidden email]> wrote:
> On Thu, Feb 21, 2019 at 1:42 PM Levent Erkok <[hidden email]> wrote:
>>
>> I think Carter outlined really good reasons for not including `e`; but it's hard not to sympathize with the request. I often felt shy of adding similar definitions in my libraries for fear that they would pollute the name space. But their absence is rather annoying. The classic solution is to put it in a library, internal module etc, and make a new class if necessary; which is often overkill and misses the simplicity sought in the first place.
>>
>> I often wonder if Haskell can have a "qualified export" feature for these cases. Just like we can "import qualified," why not "export qualified" some names, which means if you simply import the module the name will still be available qualified. (You can of course always import qualified.)
>>
>> I haven't thought too much about the implications of this, but it might be an easy solution to this problem. Would love to hear thoughts on this; is there any language that has this feature? How costly would it be to add it to GHC?

On Thu, Feb 21, 2019 at 11:04 AM Carter Schonwald
<[hidden email]> wrote:
>
> hey Levent,
> I can't claim to have thought about it that deeply, but naively, it seems like a qualified export approach might not play nice with certain approaches to seperate compilation (not that GHC does it that much), because the names qualifications wouldn't match possible import modules, Or at least the qualified names in scope wouldn't match what you see from the import lines, and thus you'd have a harder time supporting good quality error messages? (i could be totally wrong)
>
> its definitely an interesting idea, and i certainly dont have clarity on what the implications would be

If I interpret it correctly, I think what it becomes is that some
symbols can never be imported unqualified.  Or maybe that the default
"import all unqualified" actually means "everything except these
things."  So it would just be an extra rule for what `import` brings
into scope.  Python has such a mechanism, if you have an `__all__ =
[x, y, z]` then `from m import *` will just get you x, y, and z.

That said, to me it seems like too many ways to do it.  The user can
already get a qualified import if they want it.  When you write an
unqualified "import *", the price you pay is losing control over your
namespace, and that's a known cost.  A bit more finesse on what
exactly is imported won't change the basic tradeoff.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12