Kernel.** (pow operator)

131 views
Skip to first unread message

w.m.w...@student.rug.nl

unread,
Mar 27, 2016, 3:49:11 PM3/27/16
to elixir-lang-core
I just created Pull Request #4436, but it was closed since it implemented a proposal that was not discussed in the mailing list first.

I propose to add a new operator, **, to Elixir. 

The default implementation in Kernel.**/2 will be arithmetic exponentiation. In this way, it will work similar to the ** in Python, Ruby, Haskell and a multitude of other languages.


When working with integers, the result will be calculated using the Exponentiation by Squaring algorithm, returning an integer. (or a float when using negative powers)


When working with floats, erlang's :math.pow/2 function is used, which returns a float. This second case can also be used to calculate roots (i.e. 2 ** 0.5).


As :math.pow() is not inside erlang's BIN functions (as well as the integer-implementation being built with functions, not macros), it is impossible to use the Kernel.**/2 in guard clauses.



I believe this to be a useful addition to the language. What do you think?

Onorio Catenacci

unread,
Mar 27, 2016, 4:01:24 PM3/27/16
to elixir-lang-core

I don't think this needs to be added to Kernel.  Build a math library if you care to and put it on Hex.pm.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/7873e9d7-26f0-4eb3-a6d4-7e1147f72d66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

w.m.w...@student.rug.nl

unread,
Mar 28, 2016, 3:17:13 AM3/28/16
to elixir-lang-core, Cate...@ieee.org
I believe that exponentiation is common enough to add to the standard library. In fact, there are at least four places in the stdlib that use it right now.

Also, regardless of if the implementation should be part of the standard library, I strongly believe that ** is the proper operator to use for this.
Having used Ruby, Python and Haskell before, I actually expected the behaviour to be there (and I don't believe I am the only one; Many other languages such as PHP, F#, Ada, Bash, Mercury, CoffeeScript, OCaml, Fortran, and more).

Because ** is not yet defined as a possible infix operator by the Elixir parser, this is a change that can only happen if Elixir is updated to allow it.

José Valim

unread,
Mar 28, 2016, 4:00:34 AM3/28/16
to elixir-l...@googlegroups.com
I believe we had previous discussions about this in this mailing list. Right now, :math.pow is the way to go. If we are going to add our own implementation, I believe it should be integer based while :math.pow is left with float support.

In any case, I don't think we should add this implementation because, as you said, it won't work on guard clauses anyway. If someone really needs an integer based pow or a more accessible pow, I would rather add them to Integer/Float than to Kernel.



José Valim
Skype: jv.ptec
Founder and Director of R&D

w.m.w...@student.rug.nl

unread,
Mar 28, 2016, 4:32:28 AM3/28/16
to elixir-lang-core, jose....@plataformatec.com.br
It being impossible to use in guard clauses is indeed a strong argument against implementing it in Kernel.

As for the difference between integer exponentiation and floating-point exponentiation: it might indeed be better to make this difference more explicit. 


You have convinced me that it is better to put an implementation in a separate math library. However, I'd still like to see the Elixir parser accept ** as an define-able infix operator.


Have a wonderful day, :-)

~W.M.

José Valim

unread,
Mar 28, 2016, 4:37:07 AM3/28/16
to w.m.w...@student.rug.nl, elixir-lang-core
It actually was a definable operator but we removed it before 1.0 because one day we may implement ** and it would break everyone's usage of it. Generally it is risky to leave operators we would like to use in the future available because, when we eventually use them, it will break code.



José Valim
Skype: jv.ptec
Founder and Director of R&D

Alexei Sholik

unread,
Mar 28, 2016, 5:33:15 AM3/28/16
to elixir-lang-core
I believe that exponentiation is common enough to add to the standard library. In fact, there are at least four places in the stdlib that use it right now.

I have maybe used it a few times in my ~3 years of using Elixir, only in coding exercises though, never at work. Some people may be using it more frequently, but we don't know for sure. You could make a survey with two questions: 1) how many months/years have you been using Elixir? 2) how many times did you use exponentiation? That should help clear things up.

w.m.w...@student.rug.nl

unread,
Mar 28, 2016, 6:45:11 AM3/28/16
to elixir-lang-core, w.m.w...@student.rug.nl, jose....@plataformatec.com.br
It actually was a definable operator but we removed it before 1.0 because one day we may implement ** and it would break everyone's usage of it. Generally it is risky to leave operators we would like to use in the future available because, when we eventually use them, it will break code.

I see... that is indeed something to carefully consider.

Another possibility would be to allow the operator to be used, but have the implementation inside the Integer or Float libraries, similar as to the Bitwise-module defines many of the otherwise 'free' operators.

Onorio Catenacci

unread,
Mar 28, 2016, 8:20:07 AM3/28/16
to elixir-lang-core
W. M.  my experience agrees with that of Alexei--I've been working with Elixir for a while (not as long as Alexei but certainly more than 2 years or so) and I don't think I've needed exponentiation even once.  Not for toy code or demo code or for any purpose.  Perhaps Alexei and I are atypical but since yours is one of the first requests I can recall to add exponentiation to the standard library, I don't think we're that different from the typical user of Elixir.



--
Onorio




For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages