Fwd: exponential operator

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.

Ick. This is no weirder, but it adds to the memorization burden. Just use \* and ~* instead of **!

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.

Double-ick. a & b && c -- types don't match, but if they did, would you really expect a & (b && c)? I would expect the opposite. How about a ++ b + c with collections (with adding an element); do you really expect the collection-operation to be first?

** does not at all look to me like exponentiation anyway. I understand that it does for people with certain backgrounds, but there are plenty of other repeated operator symbols that do not obviously increase precedence.

Also: suppose u and v are vectors. What would u ** v be? Probably not exponentiation; if it meant anything, it'd be, akin to collections, either a dot product or matrix multiplication or somesuch.

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.

Ick. This is no weirder, but it adds to the memorization burden. Just use \* and ~* instead of **!

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.

Double-ick. a & b && c -- types don't match, but if they did, would you really expect a & (b && c)? I would expect the opposite. How about a ++ b + c with collections (with adding an element); do you really expect the collection-operation to be first?

** does not at all look to me like exponentiation anyway. I understand that it does for people with certain backgrounds, but there are plenty of other repeated operator symbols that do not obviously increase precedence.

Also: suppose u and v are vectors. What would u ** v be? Probably not exponentiation; if it meant anything, it'd be, akin to collections, either a dot product or matrix multiplication or somesuch.

I think one of x pow y, x ~^ y, x \^ y is the way to go.

I am all for a power method that does not send Ints to Double. Looking at the above, I preferx pow y. The \ operator has meaning in computational math (it is what matlab uses to solve Ax=b, ie.x = A\b.) and the ~^ operator looks too much like some sort of bit operation for my tastes. But yeah, I am not holding my breath for this one. There are far other more important problemsto solve with numbers and numeric for me to worry about this too much.

I should preface all this by saying that if someone were to add \* or
~* to the language tomorrow I would probably be pretty pleased. While
I'm arguing for the best I don't want to make it the enemy of the good.

[regarding hardcoding ** (and possibly other) precedence/associativity]
> Ick. This is no weirder, but it adds to the memorization burden. Just use
> \* and ~* instead of **!

It seems bad to have to invent a brand-new name for an old operation,
rather than using a common operator (more on this later).

[regarding extending precedence beyond the first char]
> Double-ick. a & b && c -- types don't match, but if they did, would you
> really expect a & (b && c)? I would expect the opposite. How about a ++ b
> + c with collections (with adding an element); do you really expect the
> collection-operation to be first?

I agree that my solution is a bit broad, especially when the targeted
solution of #1 would work just fine (and possibly give correct
associativity also). So... I guess I retract solution #2, although I
think it is consistent with the (perverse) spirit of the current
precedence rules.

> ** does not at all look to me like exponentiation anyway. I understand
> that it does for people with certain backgrounds, but there are plenty of
> other repeated operator symbols that do not obviously increase precedence.

I still stand by ** as the best operator available for exponentiation
(especially given that ^ is a non-starter in C-like languages).

I couldn't find any other operators used, except for D's ^^ which
doesn't have any advantages over ** (in fact its precedence is worse).
I hope this shows that ** wasn't just some random operator I chose to
appeal to a small group of people, or my own biases. My guess is that
almost all programmers have seen ** before.

It seems like there are three options:

1. Not having an exponentiation operator (e.g. the "Java bare minimum")
2. Using a non-standard name (e.g. ~^, \^, ~*, \*, \** or ~**)
3. Using ** with incorrect associativity and precedence

It is backwards to force a choice between 2 and 3. The specs choice of
using just the first character of symbolic methods to establish
precedence is arbitrary. Most languages hardcode these precedence and
associativity rules to make sure they are correct, and while it's nice
that Scala tries to generalize, in this generalization is not flexible
enough!

If "pow" could be wired up so that 2 * 3 pow 4 * 5 evaluated correctly
then I guess I would be fine with that. But I think this is even more
unlikely than either of the changes I proposed.

If the rules need to be amended or extended to support actual operators
that actual users are familiar with then that seems like the right
call. This is doubly-true given "operator soup" criticisms of the
language. We have a perfectly good operator (**) which is not being
invented by Scala--all we need to do is get it to behave properly,
something even the Perl community has been able to manage!

I should preface all this by saying that if someone were to add \* or
~* to the language tomorrow I would probably be pretty pleased. While
I'm arguing for the best I don't want to make it the enemy of the good.

I had intended to suggest ~^ or \^, by the way. ~* and \* look like multiplication. Not sure how I typoed that without noticing.

Languages not having an operator: C, C#, C++, Java, ... (i.e. all the languages from which Scala's syntax is derived). Worth bearing in mind.

I couldn't find any other operators used, except for D's ^^ which
doesn't have any advantages over ** (in fact its precedence is worse).
I hope this shows that ** wasn't just some random operator I chose to
appeal to a small group of people, or my own biases. My guess is that
almost all programmers have seen ** before.

I agree that it's somewhat familiar. But you didn't answer my "it already means something else in Scala" objection. Vector mathematics is no less important than raising something to a power. You need one multiplicative symbol to mean "element by element" and another to mean "matrix multiplication". The standard from Matlab for the former is .*, which obviously won't help anything in Scala. I certainly don't want my matrix multiplication operator to have higher precedence than normal and to be right-associative.

One could define ↑ (unicode up arrow) to be right-associative, and provide an ASCII alias. (May as well do the down arrow while at it.) This is, by the way, another standard, though not a very standard standard: Knuth uses this to define a hierarchy (*, ↑, ↑↑, ...) which can be used for, for example, Ackermann numbers.

It seems like there are three options:

1. Not having an exponentiation operator (e.g. the "Java bare minimum")

2. Using a non-standard name (e.g. ~^, \^, ~*, \*, \** or ~**)
3. Using ** with incorrect associativity and precedence

It is backwards to force a choice between 2 and 3. The specs choice of
using just the first character of symbolic methods to establish
precedence is arbitrary.

The choice of all symbols is arbitrary in a sense. The rules are chosen to be (1) Reasonably easy to remember (2) To do the right thing without needing memory in the vast majority of cases
Adding more rules for symbols that do not have a universally unambiguous interpretation invites error.

If the rules need to be amended or extended to support actual operators
that actual users are familiar with then that seems like the right
call. This is doubly-true given "operator soup" criticisms of the
language. We have a perfectly good operator (**) which is not being
invented by Scala--all we need to do is get it to behave properly,
something even the Perl community has been able to manage!

I disagree that it's perfectly good, unless you can tell me all of: - What is the exponentiation operator? - What is the dot product operator?
- What is the matrix multiplication operator?
- What is the element-by-element matrix multiplication operator? - What is the matrix exponentiation operator?
- What is the element-by-element matrix exponentiation operator? - What is the convolution operator? - What is the outer product operator?

These don't all need to be symbolic, but if exponentiation renders the rest unusable or all non-symbolic, I'm not terribly inclined to say that the change is supporting "actual operators that actual users are familiar with".

--Rex

P.S. My answers (not the only sensible choice, but internally consistent and reasonably consistent with the Scala collections library): \^ is the exponentiation operator.
** is the dot product operator (unless you have both row/col vectors), because
** is the matrix multiplication operator.
* is the element-by-element matrix multiplication operator (because + is element-by-element)
\^^ is the matrix exponentiation operator.
\^ is the element-by-element matrix exponentiation operator. |*| is the convolution operator. |*| is also the outer product operator.

Erik,
Two other "languages" that support actually both of ** and ^ for exponentiation (and
none of the tilde or slash alternatives) are:
Google's Search Bar
Apple's Spotlight Bar
Also supporting "^" but nothing else:
Microsoft Excel
Apple Numbers
Which I think supports the argument that many people, even outside of programming are familiar with "^" and "**" as the exponentiation operator.
Rex, after a cursory google search for :

- What is the dot product operator?
- What is the matrix multiplication operator?
- What is the element-by-element matrix multiplication operator?
- What is the matrix exponentiation operator?
- What is the element-by-element matrix exponentiation operator?
- What is the convolution operator?
- What is the outer product operator?

It seems Scala doesn't currently have any of these? I use them all the time in Mathematica, if they are hidden in Scala somewhere I'd love to use them (I needed element-wise vector multiplication just yesterday)....
If not, is it really fair to make arguments for the exponentiation operator depend on logical compatibility with a host of operators almost no general purpose language implements?
Ryan Richt

I should preface all this by saying that if someone were to add \* or
~* to the language tomorrow I would probably be pretty pleased. While
I'm arguing for the best I don't want to make it the enemy of the good.

I had intended to suggest ~^ or \^, by the way. ~* and \* look like multiplication. Not sure how I typoed that without noticing.

Languages not having an operator: C, C#, C++, Java, ... (i.e. all the languages from which Scala's syntax is derived). Worth bearing in mind.

I couldn't find any other operators used, except for D's ^^ which
doesn't have any advantages over ** (in fact its precedence is worse).
I hope this shows that ** wasn't just some random operator I chose to
appeal to a small group of people, or my own biases. My guess is that
almost all programmers have seen ** before.

I agree that it's somewhat familiar. But you didn't answer my "it already means something else in Scala" objection. Vector mathematics is no less important than raising something to a power. You need one multiplicative symbol to mean "element by element"
and another to mean "matrix multiplication". The standard from Matlab for the former is .*, which obviously won't help anything in Scala. I certainly don't want my matrix multiplication operator to have higher precedence than normal and to be right-associative.

One could define ↑ (unicode up arrow) to be right-associative, and provide an ASCII alias. (May as well do the down arrow while at it.) This is, by the way, another standard, though not a very standard standard: Knuth uses this to define a hierarchy (*, ↑,
↑↑, ...) which can be used for, for example, Ackermann numbers.

It seems like there are three options:

1. Not having an exponentiation operator (e.g. the "Java bare minimum")

2. Using a non-standard name (e.g. ~^, \^, ~*, \*, \** or ~**)
3. Using ** with incorrect associativity and precedence

It is backwards to force a choice between 2 and 3. The specs choice of
using just the first character of symbolic methods to establish
precedence is arbitrary.

The choice of all symbols is arbitrary in a sense. The rules are chosen to be
(1) Reasonably easy to remember
(2) To do the right thing without needing memory in the vast majority of cases
Adding more rules for symbols that do not have a universally unambiguous interpretation invites error.

If the rules need to be amended or extended to support actual operators
that actual users are familiar with then that seems like the right
call. This is doubly-true given "operator soup" criticisms of the
language. We have a perfectly good operator (**) which is not being
invented by Scala--all we need to do is get it to behave properly,
something even the Perl community has been able to manage!

I disagree that it's perfectly good, unless you can tell me all of:
- What is the exponentiation operator?
- What is the dot product operator?
- What is the matrix multiplication operator?
- What is the element-by-element matrix multiplication operator?
- What is the matrix exponentiation operator?
- What is the element-by-element matrix exponentiation operator?
- What is the convolution operator?
- What is the outer product operator?

These don't all need to be symbolic, but if exponentiation renders the rest unusable or all non-symbolic, I'm not terribly inclined to say that the change is supporting "actual operators that actual users are familiar with".

--Rex

P.S. My answers (not the only sensible choice, but internally consistent and reasonably consistent with the Scala collections library):
\^ is the exponentiation operator.
** is the dot product operator (unless you have both row/col vectors), because
** is the matrix multiplication operator.
* is the element-by-element matrix multiplication operator
(because + is element-by-element)
\^^ is the matrix exponentiation operator.
\^ is the element-by-element matrix exponentiation operator.
|*| is the convolution operator.
|*| is also the outer product operator.

This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled
to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and
all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.

All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto, including its
subsidiaries. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware".
Monsanto, along with its subsidiaries, accepts no liability for any damage caused by any such code transmitted by or accompanying
this e-mail or any attachment.

The information contained in this email may be subject to the export control laws and regulations of the United States, potentially
including but not limited to the Export Administration Regulations (EAR) and sanctions regulations issued by the U.S. Department of
Treasury, Office of Foreign Asset Controls (OFAC). As a recipient of this information you are obligated to comply with all
applicable U.S. export laws and regulations.

Erik,
Two other "languages" that support actually both of ** and ^ for exponentiation (and
none of the tilde or slash alternatives) are:
Google's Search Bar
Apple's Spotlight Bar
Also supporting "^" but nothing else:
Microsoft Excel
Apple Numbers
Which I think supports the argument that many people, even outside of programming are familiar with "^" and "**" as the exponentiation operator.
Rex, after a cursory google search for :

- What is the dot product operator?
- What is the matrix multiplication operator?
- What is the element-by-element matrix multiplication operator?
- What is the matrix exponentiation operator?
- What is the element-by-element matrix exponentiation operator?
- What is the convolution operator?
- What is the outer product operator?

It seems Scala doesn't currently have any of these? I use them all the time in Mathematica, if they are hidden in Scala somewhere I'd love to use them (I needed element-wise vector multiplication just yesterday)....
If not, is it really fair to make arguments for the exponentiation operator depend on logical compatibility with a host of operators almost no general purpose language implements?

Unlike Fortran, Scala is not a language designed solely for mathematical code. We should not need to make the standard library bigger. Scalala does support most of theseoperations though. I tend to just role my own. Wrapping Vector (or Array if you want to avoid boxing) and then defining thesemethods as appropriate. a .* b = a.zip(b).map(s => s._1 + s._2) for example..

I should preface all this by saying that if someone were to add \* or
~* to the language tomorrow I would probably be pretty pleased. While
I'm arguing for the best I don't want to make it the enemy of the good.

I had intended to suggest ~^ or \^, by the way. ~* and \* look like multiplication. Not sure how I typoed that without noticing.

Languages not having an operator: C, C#, C++, Java, ... (i.e. all the languages from which Scala's syntax is derived). Worth bearing in mind.

I couldn't find any other operators used, except for D's ^^ which
doesn't have any advantages over ** (in fact its precedence is worse).
I hope this shows that ** wasn't just some random operator I chose to
appeal to a small group of people, or my own biases. My guess is that
almost all programmers have seen ** before.

I agree that it's somewhat familiar. But you didn't answer my "it already means something else in Scala" objection. Vector mathematics is no less important than raising something to a power. You need one multiplicative symbol to mean "element by element"
and another to mean "matrix multiplication". The standard from Matlab for the former is .*, which obviously won't help anything in Scala. I certainly don't want my matrix multiplication operator to have higher precedence than normal and to be right-associative.

One could define ↑ (unicode up arrow) to be right-associative, and provide an ASCII alias. (May as well do the down arrow while at it.) This is, by the way, another standard, though not a very standard standard: Knuth uses this to define a hierarchy (*, ↑,
↑↑, ...) which can be used for, for example, Ackermann numbers.

It seems like there are three options:

1. Not having an exponentiation operator (e.g. the "Java bare minimum")

2. Using a non-standard name (e.g. ~^, \^, ~*, \*, \** or ~**)
3. Using ** with incorrect associativity and precedence

It is backwards to force a choice between 2 and 3. The specs choice of
using just the first character of symbolic methods to establish
precedence is arbitrary.

The choice of all symbols is arbitrary in a sense. The rules are chosen to be
(1) Reasonably easy to remember
(2) To do the right thing without needing memory in the vast majority of cases
Adding more rules for symbols that do not have a universally unambiguous interpretation invites error.

If the rules need to be amended or extended to support actual operators
that actual users are familiar with then that seems like the right
call. This is doubly-true given "operator soup" criticisms of the
language. We have a perfectly good operator (**) which is not being
invented by Scala--all we need to do is get it to behave properly,
something even the Perl community has been able to manage!

I disagree that it's perfectly good, unless you can tell me all of:
- What is the exponentiation operator?
- What is the dot product operator?
- What is the matrix multiplication operator?
- What is the element-by-element matrix multiplication operator?
- What is the matrix exponentiation operator?
- What is the element-by-element matrix exponentiation operator?
- What is the convolution operator?
- What is the outer product operator?

These don't all need to be symbolic, but if exponentiation renders the rest unusable or all non-symbolic, I'm not terribly inclined to say that the change is supporting "actual operators that actual users are familiar with".

--Rex

P.S. My answers (not the only sensible choice, but internally consistent and reasonably consistent with the Scala collections library):
\^ is the exponentiation operator.
** is the dot product operator (unless you have both row/col vectors), because
** is the matrix multiplication operator.
* is the element-by-element matrix multiplication operator
(because + is element-by-element)
\^^ is the matrix exponentiation operator.
\^ is the element-by-element matrix exponentiation operator.
|*| is the convolution operator.
|*| is also the outer product operator.

This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled
to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and
all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited.

All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto, including its
subsidiaries. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware".
Monsanto, along with its subsidiaries, accepts no liability for any damage caused by any such code transmitted by or accompanying
this e-mail or any attachment.

The information contained in this email may be subject to the export control laws and regulations of the United States, potentially
including but not limited to the Export Administration Regulations (EAR) and sanctions regulations issued by the U.S. Department of
Treasury, Office of Foreign Asset Controls (OFAC). As a recipient of this information you are obligated to comply with all
applicable U.S. export laws and regulations.

Erik,
Two other "languages" that support actually both of ** and ^ for exponentiation (and
none of the tilde or slash alternatives) are:
Google's Search Bar
Apple's Spotlight Bar
Also supporting "^" but nothing else:
Microsoft Excel
Apple Numbers

Yep. ^ is really the standard unless you expect to have bitwise xor.

Which I think supports the argument that many people, even outside of programming are familiar with "^" and "**" as the exponentiation operator.

^ yes; ** probably less so, but I'm not sure. (I see non-programmers write out x^y frequently in e.g. emails; I have yet to see a non-programmer write x**y.)

Rex, after a cursory google search for :

- What is the dot product operator?
- What is the matrix multiplication operator?
- What is the element-by-element matrix multiplication operator?
- What is the matrix exponentiation operator?
- What is the element-by-element matrix exponentiation operator?
- What is the convolution operator?
- What is the outer product operator?

It seems Scala doesn't currently have any of these? I use them all the time in Mathematica, if they are hidden in Scala somewhere I'd love to use them (I needed element-wise vector multiplication just yesterday)....

They're not included, but colliding with these frequently-used if not-actually-included operations is not a good design for a rarely-used mathematical operation (even if most people know what it is).

For reference, if your vector is a Scala collection and you don't care about performance, element-by-element stuff is (a,b).zipped.map(_ * _).

If not, is it really fair to make arguments for the exponentiation operator depend on logical compatibility with a host of operators almost no general purpose language implements?

It's potentially fair, because it is not obvious to me that these, collectively, are used much less than exponentiation is. If there's reasonably good data that exponentiation is considerably more common, and the double-operators-mean-collection thing is agreed to be not confusing, then I'd be happy with ** as exponentiation.

> ^ yes; ** probably less so, but I'm not sure. (I see non-programmers write
> out x^y frequently in e.g. emails; I have yet to see a non-programmer write
> x**y.)

I don't think the argument was that non-programmers normally use ** but
instead that many programmers are familiar with it. You're certainly
right that ^ would be ideal.

> It's potentially fair, because it is not obvious to me that these,
> collectively, are used much less than exponentiation is. If there's
> reasonably good data that exponentiation is considerably more common, and
> the double-operators-mean-collection thing is agreed to be not confusing,
> then I'd be happy with ** as exponentiation.

OK, fair enough. Sounds like it will take some time and energy to reach
consensus around an exponentiation operator's symbol/name! :)

I recently wasted some time by repeatedly using ^ and not knowing why I was getting these strange results back. If it had complained "What does ^ mean?" I would have resorted to Math.pow quicker, but instead it was giving me bitwise xor.