This page is no longer maintained — Please continue to the home page at www.scala-lang.org

exponential operator

6 replies
Antoras
Joined: 2010-05-23,
User offline. Last seen 1 year 19 weeks ago.

I asked myself why Scala hasn't an exponential operator like '^' or '**'
as many other languages have.

I noticed that Scalas precedence rules will not work very well with such
operators because '^' has low precedence and '**' has the same
precedence than '*' and '/'.

Therefore I want to know if would be a good design decision to introduce
such an operator to the language (either to the libs as an implicit
conversion or as a built-in operator).

What yo you think? Do you appreciate such an operator or do you think
that there will be more problems than advantages?

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: exponential operator
I brought this topic up two or three years ago. You are correct about the precedence issues, and I don't think there is a simple solution. After thinking about it, I realized that a general exponentiation operator is not very important. In practice, the exponent is nearly always two (squaring) or, less often, three (cubing), so you can just write these trivial functions:
    def sqr(x: Int) = x * x    def cube(x: Int) = x * x * x
    def sqr(x: Double) = x * x    def cube(x: Double) = x * x * x
In the rare case when you need an exponent other than two or three, just use the "pow" function.
I think the "sqr" and "cube" functions should be added to the standard math package for convenience.
--Russ P.

On Thu, Dec 22, 2011 at 11:10 AM, Antoras <mail [at] antoras [dot] de> wrote:
I asked myself why Scala hasn't an exponential operator like '^' or '**' as many other languages have.

I noticed that Scalas precedence rules will not work very well with such operators because '^' has low precedence and '**' has the same precedence than '*' and '/'.

Therefore I want to know if would be a good design decision to introduce such an operator to the language (either to the libs as an implicit conversion or as a built-in operator).

What yo you think? Do you appreciate such an operator or do you think that there will be more problems than advantages?





--
http://RussP.us
d_m
Joined: 2010-11-11,
User offline. Last seen 35 weeks 2 days ago.
Re: exponential operator

On Thu, Dec 22, 2011 at 08:10:50PM +0100, Antoras wrote:
> I asked myself why Scala hasn't an exponential operator like '^' or
> '**' as many other languages have.
>
> I noticed that Scalas precedence rules will not work very well with
> such operators because '^' has low precedence and '**' has the same
> precedence than '*' and '/'.
>
> Therefore I want to know if would be a good design decision to
> introduce such an operator to the language (either to the libs as an
> implicit conversion or as a built-in operator).
>
> What yo you think? Do you appreciate such an operator or do you
> think that there will be more problems than advantages?

The following ASCII characters have higher precedence than *:

# (# is unavailable, ## is used for hashing)
@ (@ is unavailable)
? (unused afaik)
\ (\ is used with xml and maybe other places?)
~ (unused afaik)

Any of these can be used to build an exponentiation operator with the
right precedence. You can test this in the REPL:

implicit def xyz(d:Double) = new { def ~**(e:Double) = math.pow(d, e) }
2.0 * 3.0 ~** 4.0 * 5.0

This will return 810.0 like you'd expect (incorrect operator precedence
might result in 6480.0, 6.973568802E9 or 3.656158440062976E15).

I really miss this operator from other language and wish Scala included
it. Besides the fact that I resent having to type math.pow, I
especially hate using it with Int (the most common case in my opinion)
as I have to convert back to Int from Double. Compare:

math.pow(3, 5).toInt // scala

with

3 ** 5 # python

Python is just plain better than us here. The Scala example contains so
much noise, I have a hard time visually parsing out what is actually
happening. At a minimum I'd like to see math.pow provide interfaces for
Int and Long. Ideally we'd see the introduction of an exponentiation
operator.

While it's not mentioned specifically in the proposal Tom Switzer and I
are working on, I really feel that Scala could be improved by going
beyond the "Java bare minimum" of numeric operators and types. There's
no reason we can't do as well as Python (especially since our primitive
types have better performance).

Nate Nystrom 2
Joined: 2011-01-28,
User offline. Last seen 42 years 45 weeks ago.
Re: exponential operator

On Thursday, December 22, 2011 at 21:03, Erik Osheim wrote:

> On Thu, Dec 22, 2011 at 08:10:50PM +0100, Antoras wrote:
> > I asked myself why Scala hasn't an exponential operator like '^' or
> > '**' as many other languages have.
> >
> > I noticed that Scalas precedence rules will not work very well with
> > such operators because '^' has low precedence and '**' has the same
> > precedence than '*' and '/'.
> >
> > Therefore I want to know if would be a good design decision to
> > introduce such an operator to the language (either to the libs as an
> > implicit conversion or as a built-in operator).
> >
> > What yo you think? Do you appreciate such an operator or do you
> > think that there will be more problems than advantages?
>
>
>
> The following ASCII characters have higher precedence than *:
>
> # (# is unavailable, ## is used for hashing)
> @ (@ is unavailable)
> ? (unused afaik)
> \ (\ is used with xml and maybe other places?)
> ~ (unused afaik)
>
> Any of these can be used to build an exponentiation operator with the
> right precedence. You can test this in the REPL:
>
> implicit def xyz(d:Double) = new { def ~**(e:Double) = math.pow(d, e) }
> 2.0 * 3.0 ~** 4.0 * 5.0
>
> This will return 810.0 like you'd expect (incorrect operator precedence
> might result in 6480.0, 6.973568802E9 or 3.656158440062976E15).
>
> I really miss this operator from other language and wish Scala included
> it. Besides the fact that I resent having to type math.pow, I
> especially hate using it with Int (the most common case in my opinion)
> as I have to convert back to Int from Double. Compare:
>
> math.pow(3, 5).toInt // scala
>
> with
>
> 3 ** 5 # python
>
> Python is just plain better than us here. The Scala example contains so
> much noise, I have a hard time visually parsing out what is actually
> happening. At a minimum I'd like to see math.pow provide interfaces for
> Int and Long. Ideally we'd see the introduction of an exponentiation
> operator.
>
> While it's not mentioned specifically in the proposal Tom Switzer and I
> are working on, I really feel that Scala could be improved by going
> beyond the "Java bare minimum" of numeric operators and types. There's
> no reason we can't do as well as Python (especially since our primitive
> types have better performance).
>

d_m
Joined: 2010-11-11,
User offline. Last seen 35 weeks 2 days ago.
Re: exponential operator

On Thu, Dec 22, 2011 at 09:21:12PM +0100, Nate Nystrom wrote:

> I'd much rather the operator be just 'pow' than something like ~**.
> It could easily be made an infix operator like max and min and be made
> to work on Int and Long. Annoyingly though, it's left associative
> rather than right, like in python, and defining an operator named pow_:
> kind of defeats the purpose.

The left associativity is a bummer but given the "colon requirement"
for right-associativity it's maybe more trouble than it's worth.

A certain (sick?) part of me could imagine using ~**: or ~^: to get the
right precedence and the right associativity. But it certainly won't
help fight the perception that Scala has too much symbolic operator
soup. [1]

I agree that an Int-aware pow (with wrong precedence/associativity) is
better than what we have now, although I personally think a symbolic
operator (with correct precedence but wrong associativity) is even
better.

Alex Cruise
Joined: 2008-12-17,
User offline. Last seen 2 years 26 weeks ago.
Re: exponential operator
On Thu, Dec 22, 2011 at 12:55 PM, Erik Osheim <erik [at] plastic-idolatry [dot] com> wrote:
[1] One of the worst-feeling places of the SLS is its handling of operator precedence and associativity. A lot of the weird symbolic
names we end up with (having to throw prefix/suffix symbols onto the
operator to get precedence/associativity right) are directly traceable
to this. I wonder if there was ever any consideration of adding an
exponent operator because there sure isn't obvious place in the
precedence table left for it. Given that the valid unary prefix
operators ended up getting hardcoded anyway (to +, -, ! and ~) it seems
a shame we couldn't do better.

Other than just giving up, or creating a weird operator like ~**:, I
could imagine two other ways forward (if I was the king of Scala):

1. Hardcode some fixed operators amidst the general precedence rules,
allowing things like ** to be higher priority than *, and to have the
correct associativity. This is weird, but no weirder than the hardcoded
precedence table, or the hardcoded list of unary prefix ops.

2. Generalize the current rules to use all non-letter/number
characters. For instance, ++ would be higher priority than + (which are
currently the same), and ** would be higher priority than * (which are
also currently the same). It's likely this would introduce problems in
practice but given that operators at the same precedence level
currently need to be grouped in some cases I expect this change would
simply change which situations required this.

I share your discomfort with the spec on precedence and fixity, associativity etc., and have a journeyman's  understanding of why they're not customizable now and would be extremely difficult to make customizable in the future, and I like both of these ideas.  -0xe1a
Chris Marshall
Joined: 2009-06-17,
User offline. Last seen 44 weeks 3 days ago.
RE: exponential operator
This is why Pierre Fermat's proof fit into the margin

Date: Thu, 22 Dec 2011 11:35:37 -0800
Subject: Re: [scala-debate] exponential operator
From: russ [dot] paielli [at] gmail [dot] com

I realized that a general exponentiation operator is not very important. In practice, the exponent is nearly always two (squaring) or, less often, three (cubing)

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland