exponential operator

Kubitz wrote:
>
> Is the no exponential operator in scala??
>
> var z=3.0 ^ 2.0 // ‘^ is not a member of Double
>
On integral types, ^ is defined as the exclusive or operator, so it
wouldn't make sense to be otherwise on Double. There is Math.pow(3.0, 2.0).

Now. Very much annoying, imho.

On Mon, Nov 16, 2009 at 7:02 AM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

Is the no exponential operator in scala??

 

var z=3.0 ^ 2.0 // ‘^ is not a member of Double

--
Daniel C. Sobral

Veni, vidi, veterni.

Yeah, very anoying. I cant even define it for my classes since “^”  has the wrong precedence AND also the wrong Evaluation direction.

 

Obvious scala is some sort of an ANTI-MATHEMATICS language. L

 

Von: Daniel Sobral [mailto:dcsobral@gmail.com]
Gesendet: Montag, 16. November 2009 14:04
An: Kubitz, Jörg
Cc: scala-user@listes.epfl.ch
Betreff: Re: [scala-user] exponential operator

 

Now. Very much annoying, imho.

On Mon, Nov 16, 2009 at 7:02 AM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

Is the no exponential operator in scala??

 

var z=3.0 ^ 2.0 // ‘^ is not a member of Double

Not anti-mathematics, just inadequate for some of its notations, unless you are willing to be liberal with parenthesis. It's the price of freedom, I'm afraid.

On Mon, Nov 16, 2009 at 11:24 AM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

Yeah, very anoying. I cant even define it for my classes since “^”  has the wrong precedence AND also the wrong Evaluation direction.

 

Obvious scala is some sort of an ANTI-MATHEMATICS language. L

 

Von: Daniel Sobral [mailto:dcsobral@gmail.com]
Gesendet: Montag, 16. November 2009 14:04
An: Kubitz, Jörg
Cc: scala-user@listes.epfl.ch
Betreff: Re: [scala-user] exponential operator

 

Now. Very much annoying, imho.

On Mon, Nov 16, 2009 at 7:02 AM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

Is the no exponential operator in scala??

 

var z=3.0 ^ 2.0 // ‘^ is not a member of Double

--
Daniel C. Sobral

Veni, vidi, veterni.

--
Daniel C. Sobral

Veni, vidi, veterni.

^ means both exponentiation and xor, depending on the language you use.  In Scala, it's xor (suggesting, I suppose, the use of bitwise integers over interesting floating-point math).  However, if you want nicer syntax for powers, you can have it:

scala> class EmpoweredDouble(d:Double) {
     |   def ~^(e:Double) = Math.pow(d,e)
     | }
defined class EmpoweredDouble

scala> implicit def empowerMyDouble(d:Double) = new EmpoweredDouble(d)
empowerMyDouble: (d: Double)EmpoweredDouble

scala> 2.0 ~^ 3.0                                                    
res0: Double = 8.0

scala> 1.0 + 2.0 ~^ 3.0 * 4.0
res1: Double = 33.0

Not highest-performance due to the implicit, but you get your syntax with only an extra ~ in the way.  (~ was chosen so exponentiation has higher precedence than +-*/.)

  --Rex


On Mon, Nov 16, 2009 at 8:29 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

Not anti-mathematics, just inadequate for some of its notations, unless you are willing to be liberal with parenthesis. It's the price of freedom, I'm afraid.

On Mon, Nov 16, 2009 at 11:24 AM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

Yeah, very anoying. I cant even define it for my classes since “^”  has the wrong precedence AND also the wrong Evaluation direction.

I'm almost returning to my matrix library. :-)

On Mon, Nov 16, 2009 at 1:59 PM, Rex Kerr <ichoran@gmail.com> wrote:

^ means both exponentiation and xor, depending on the language you use.  In Scala, it's xor (suggesting, I suppose, the use of bitwise integers over interesting floating-point math).  However, if you want nicer syntax for powers, you can have it:

scala> class EmpoweredDouble(d:Double) {
     |   def ~^(e:Double) = Math.pow(d,e)
     | }
defined class EmpoweredDouble

scala> implicit def empowerMyDouble(d:Double) = new EmpoweredDouble(d)
empowerMyDouble: (d: Double)EmpoweredDouble

scala> 2.0 ~^ 3.0                                                    
res0: Double = 8.0

scala> 1.0 + 2.0 ~^ 3.0 * 4.0
res1: Double = 33.0

Not highest-performance due to the implicit, but you get your syntax with only an extra ~ in the way.  (~ was chosen so exponentiation has higher precedence than +-*/.)

  --Rex


On Mon, Nov 16, 2009 at 8:29 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

Not anti-mathematics, just inadequate for some of its notations, unless you are willing to be liberal with parenthesis. It's the price of freedom, I'm afraid.

On Mon, Nov 16, 2009 at 11:24 AM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

Yeah, very anoying. I cant even define it for my classes since “^”  has the wrong precedence AND also the wrong Evaluation direction.

--
Daniel C. Sobral

Veni, vidi, veterni.

On Mon, 2009-11-16 at 14:24 +0100, Kubitz, Jörg wrote:
> Yeah, very anoying. I cant even define it for my classes since “^”
> has the wrong precedence AND also the wrong Evaluation direction.
>
Is there no chance of a ** operator for exponentiation?

That would have the 'wrong' precedence. E.g., 3 * 2 ** 2 would yield
36, not 12.

2009/11/16 Russel Winder :
> On Mon, 2009-11-16 at 14:24 +0100, Kubitz, Jörg wrote:
>> Yeah, very anoying. I cant even define it for my classes since “^”
>> has the wrong precedence AND also the wrong Evaluation direction.
>>
> Is there no chance of a ** operator for exponentiation?
>
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      Partner
>                                            xmpp: russel@russel.org.uk
> Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder@ekiga.net
> London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
>

On Tue, 2009-11-17 at 11:26 +0000, Ricky Clarkson wrote:
> That would have the 'wrong' precedence. E.g., 3 * 2 ** 2 would yield
> 36, not 12.

Pity, all other programming languages that offer ** have its priority
higher than that of *.

Changing the priority of ** would break some existing code, and make
Scala's precedence rules more complex than they currently are.

And practically no code would use it.

2009/11/17 Russel Winder :
> On Tue, 2009-11-17 at 11:26 +0000, Ricky Clarkson wrote:
>> That would have the 'wrong' precedence.  E.g., 3 * 2 ** 2 would yield
>> 36, not 12.
>
> Pity, all other programming languages that offer ** have its priority
> higher than that of *.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      Partner
>                                            xmpp: russel@russel.org.uk
> Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder@ekiga.net
> London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
>

Ricky,

On Tue, 2009-11-17 at 11:42 +0000, Ricky Clarkson wrote:
> Changing the priority of ** would break some existing code, and make
> Scala's precedence rules more complex than they currently are.

As far as I know, and Programming in Scala tells me, ** is only
currently defined for Sets. So isn't defining ** for numbers
introducing a new operator, which can have its own priority?

A system should be "as simple as possible, but not simpler" (original
attributed to A Einstein). So if complexity is needed then it should be
added.

> And practically no code would use it.

I am not convinced by that as an argument for or against.
Exponentiation is an important operator in much numerical work, which is
why most languages that purport to support numeric computation have it,
usually expressed as **. Not having the operator and making people use
Math.power seems like an implicit statement that numeric computing is of
no interest as an application of Scala.

Clearly one does not introduce code breakages in bug fix releases, but
in minor or major releases such things must be allowable -- the extent
depending on the revision type. Otherwise languages are defined solely
by their first release and/or you end up with situations such as the
fiasco that is type erasure for JVM generics.

> 2009/11/17 Russel Winder :
> > On Tue, 2009-11-17 at 11:26 +0000, Ricky Clarkson wrote:
> >> That would have the 'wrong' precedence. E.g., 3 * 2 ** 2 would yield
> >> 36, not 12.
> >
> > Pity, all other programming languages that offer ** have its priority
> > higher than that of *.

If no code would use it how could the change break code??

-----Ursprüngliche Nachricht-----
Von: Ricky Clarkson [mailto:ricky.clarkson@gmail.com]
Gesendet: Dienstag, 17. November 2009 12:43
An: Russel Winder
Cc: Kubitz, Jörg; Daniel Sobral; scala-user@listes.epfl.ch
Betreff: Re: AW: [scala-user] exponential operator

Changing the priority of ** would break some existing code, and make
Scala's precedence rules more complex than they currently are.

And practically no code would use it.

2009/11/17 Russel Winder :
> On Tue, 2009-11-17 at 11:26 +0000, Ricky Clarkson wrote:
>> That would have the 'wrong' precedence.  E.g., 3 * 2 ** 2 would yield
>> 36, not 12.
>
> Pity, all other programming languages that offer ** have its priority
> higher than that of *.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      Partner
>                                            xmpp: russel@russel.org.uk
> Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder@ekiga.net
> London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
>

Virtually no code would use ** to mean what Math.pow means. It would
break existing code because code exists that uses ** to mean something
else.

2009/11/17 Kubitz, Jörg :
> If no code would use it how could the change break code??
>
> -----Ursprüngliche Nachricht-----
> Von: Ricky Clarkson [mailto:ricky.clarkson@gmail.com]
> Gesendet: Dienstag, 17. November 2009 12:43
> An: Russel Winder
> Cc: Kubitz, Jörg; Daniel Sobral; scala-user@listes.epfl.ch
> Betreff: Re: AW: [scala-user] exponential operator
>
> Changing the priority of ** would break some existing code, and make
> Scala's precedence rules more complex than they currently are.
>
> And practically no code would use it.
>
> 2009/11/17 Russel Winder :
>> On Tue, 2009-11-17 at 11:26 +0000, Ricky Clarkson wrote:
>>> That would have the 'wrong' precedence.  E.g., 3 * 2 ** 2 would yield
>>> 36, not 12.
>>
>> Pity, all other programming languages that offer ** have its priority
>> higher than that of *.
>>
>> --
>> Russel.
>> =============================================================================
>> Dr Russel Winder      Partner
>>                                            xmpp: russel@russel.org.uk
>> Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
>> 41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder@ekiga.net
>> London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
>>
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky.clarkson@gmail.com
> Google Wave: ricky.clarkson@googlewave.com
>

>> Changing the priority of ** would break some existing code, and make
>> Scala's precedence rules more complex than they currently are.
>
> As far as I know, and Programming in Scala tells me, ** is only
> currently defined for Sets.  So isn't defining ** for numbers
> introducing a new operator, which can have its own priority?

No. Everyone is currently free to write their own methods, named **.

> A system should be "as simple as possible, but not simpler" (original
> attributed to A Einstein).  So if complexity is needed then it should be
> added.

It's clearly not *needed*, but desirable in some cases. Further
complicating the language, and breaking existing code, for a use case
that most language users will never care about, is, in my opinion, a
bad idea. Especially as the workaround is not ridiculous.

> Clearly one does not introduce code breakages in bug fix releases, but
> in minor or major releases such things must be allowable -- the extent
> depending on the revision type.  Otherwise languages are defined solely
> by their first release and/or you end up with situations such as the
> fiasco that is type erasure for JVM generics.

Yes, break compatibility, when it improves the language.

On Tuesday November 17 2009, Russel Winder wrote:
> Ricky,
>
> On Tue, 2009-11-17 at 11:42 +0000, Ricky Clarkson wrote:
> > Changing the priority of ** would break some existing code, and
> > make Scala's precedence rules more complex than they currently are.
>
> As far as I know, and Programming in Scala tells me, ** is only
> currently defined for Sets. So isn't defining ** for numbers
> introducing a new operator, which can have its own priority?

I can be defined again in disjoint classes, yes, but its precedence and
associativity are fixed by the grammar to match that of Java or, if
it's not a Java operator, to that of the Java operator that has the
same initial character. If that character does not correspond to a Java
operator, the highest precedence is used.

Operators whose right-most character is a colon are right-associative
and are interpreted as members of their right-hand operand applied to
their left-hand operand.

For all the details, see section 6.12 of the Scala Language
Specification Version 2.7.

Randall Schulz

>Virtually no code would use ** to mean what Math.pow means.

That’s your opinion. Applications with mathematic background do realy need an exponential operator since formulas with "pow(,)" look nasty if you have a lot of them. And we do have a lot of them.

In fact its typical for financial services to have an prototype written in Microsoft Excel that is later to be implemented into a typesafe language. So what mathematician typicly like to do is to copy & paste from Excel to Scala. And then they expect that it either gives a error message (that they can fix) or the same result as in excel. But as long as 2^3=1 in scala and 2^3=8 in Excel we are far away from that usage.

Table 5.3 of Programming in Scala lists operator precedence and states "all
other special characters" as higher than the standard ones. I suppose you
could use a unicode character that looks kind of exponential-like. However,
that seems like a pretty extreme solution.

Scala is leaps and bounds ahead of Java when it comes to expressing
mathematical concepts, but I do wish I could make an operator have higher
precedence in some cases (e.g. I've seen ^ used for cross product in some
libraries, but that also has precedence issues). I can live with that
limitation, however.

-Mark

On 11/16/09 7:28 AM, "Russel Winder" wrote:

> On Mon, 2009-11-16 at 14:24 +0100, Kubitz, Jörg wrote:
>> Yeah, very anoying. I cant even define it for my classes since ³^²
>> has the wrong precedence AND also the wrong Evaluation direction.
>>
> Is there no chance of a ** operator for exponentiation?
>

If one "needs" Operators in scala then because they are already used without scala. For example being common in scientific papers.
There we see
C = A x B
as the cross Product.
Which is typed C = A \cross B.
So it would be best if method \cross() could be set to the right precedence.
It's a nightmare if people start using arbitratry characters as operators in scala just because they have the right precedence.

-----Ursprüngliche Nachricht-----
Von: Bastian, Mark [mailto:mbastia@sandia.gov]
Gesendet: Dienstag, 17. November 2009 16:22
An: Russel Winder; Kubitz; Kubitz, Jörg
Cc: Daniel Sobral; scala-user@listes.epfl.ch
Betreff: Re: AW: [scala-user] exponential operator

Table 5.3 of Programming in Scala lists operator precedence and states "all
other special characters" as higher than the standard ones. I suppose you
could use a unicode character that looks kind of exponential-like. However,
that seems like a pretty extreme solution.

Scala is leaps and bounds ahead of Java when it comes to expressing
mathematical concepts, but I do wish I could make an operator have higher
precedence in some cases (e.g. I've seen ^ used for cross product in some
libraries, but that also has precedence issues). I can live with that
limitation, however.

-Mark

On 11/16/09 7:28 AM, "Russel Winder" wrote:

> On Mon, 2009-11-16 at 14:24 +0100, Kubitz, Jörg wrote:
>> Yeah, very anoying. I cant even define it for my classes since ³^²
>> has the wrong precedence AND also the wrong Evaluation direction.
>>
> Is there no chance of a ** operator for exponentiation?
>

I checked out numpy, a Python numeric library, and found that 0.52% of
its lines of code contained **. I have to say, that's more than I
expected, but it's a numeric library, hardly a usual application. I
also checked out the Scala and IDEA codebases (ok, I happened to have
them around), and my work's codebase, and searched for Math.pow.

IDEA has 7 uses of Math.pow. 7 more than I expected, but still not significant.

Scala has 5, and 2 of those are direct copies of 2 others.

My work's codebase has 2, and both of those really really should be bit-shifts.

Like I said, virtually no code uses ** to mean what Math.pow means.
Thank you and good night.

2009/11/17 Kubitz, Jörg :
>
>>Virtually no code would use ** to mean what Math.pow means.
>
> That’s your opinion. Applications with mathematic background do realy need an exponential operator since formulas with "pow(,)" look nasty if you have a lot of them. And we do have a lot of them.
>
> In fact its typical for financial services to have an prototype written in Microsoft Excel that is later to be implemented into a typesafe language. So what mathematician typicly like to do is to copy & paste from Excel to Scala. And then they expect that it either gives a error message (that they can fix) or the same result as in excel. But as long as 2^3=1 in scala and 2^3=8 in Excel we are far away from that usage.
>
>

One of the canonical ways to screw up a general purpose programming language
is to add features to make it appeal to mathematical programmers. The
results never please anyone, and inevitably weaken the language for general
purpose use.

--Dave Griffith

On Tuesday November 17 2009, Kubitz, Jörg wrote:
> If one "needs" Operators in scala then because they are already used
> without scala. For example being common in scientific papers. There
> we see
> C = A x B
> as the cross Product.
> Which is typed C = A \cross B.
> So it would be best if method \cross() could be set to the right
> precedence. It's a nightmare if people start using arbitratry
> characters as operators in scala just because they have the right
> precedence.

Why complain about things that are beyond your control?

Arbitrarily reassigning operator precedence, fixity and associativity is
a parsing challenge, to say the least, and that's in languages that
have uniform treatment of any given operator throughout a program. When
you want to have a different set of operator definitions for every
class, _that's_ a nightmare.

Scala is a general-purpose language. That doesn't mean it's ideal for
every use (it couldn't be), but that it can be used for most purposes.
If you want complete freedom to define input languages, you have the
option of writing an external DSL. Scala's combinator parser library is
quite nice.

Interestingly enough, I believe that a parsing scheme such as combinator
parsers that does not build a state machine in advance is fairly
amenable to dynamic operator (re-)definition, though I've yet to try my
had at it. But as I said above, if those operator definitions are
contextualized to a given class, it's much harder. At the very least it
seems it would admit ambiguous parses.

Randall Schulz

On Tue, Nov 17, 2009 at 2:59 PM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

>Virtually no code would use ** to mean what Math.pow means.

That’s your opinion. Applications with mathematic background do realy need an exponential operator since formulas with "pow(,)" look nasty if you have a lot of them. And we do have a lot of them.

In fact its typical for financial services to have an prototype written in Microsoft Excel that is later to be implemented into a typesafe language. So what mathematician typicly like to do is to copy & paste from Excel to Scala. And then they expect that it either gives a error message (that they can fix) or the same result as in excel. But as long as 2^3=1 in scala and 2^3=8 in Excel we are far away from that usage.

Given this use case, have you considered using scala's parser library (as already suggested) to interpret excel formulas?
Or at least, a suitable subset of excel formulas...

If you make it an open source library as well, then I'm willing to bet that you'd easily find others willing to contribute, it could be a generally useful thing.
Alternatively, I believe that apache POI (amongst others) has support for parsing excel formulas, maybe you can wrap the library for use within scala.  Again, I'd advocate going open source for this.

I have not played with scala's parser library yet since I always thought it would parse at runtime. Doesn’t it?

 We need a code compiled not a runtime interpreter. If the parser library can compile the idea sounds good.  

 

Von: Kevin Wright [mailto:kev.lee.wright@googlemail.com]
Gesendet: Dienstag, 17. November 2009 17:17
An: Kubitz, Jörg
Cc: Ricky Clarkson; Russel Winder; Daniel Sobral; scala-user@listes.epfl.ch
Betreff: Re: AW: [scala-user] exponential operator

 

 

On Tue, Nov 17, 2009 at 2:59 PM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

>Virtually no code would use ** to mean what Math.pow means.

That’s your opinion. Applications with mathematic background do realy need an exponential operator since formulas with "pow(,)" look nasty if you have a lot of them. And we do have a lot of them.

In fact its typical for financial services to have an prototype written in Microsoft Excel that is later to be implemented into a typesafe language. So what mathematician typicly like to do is to copy & paste from Excel to Scala. And then they expect that it either gives a error message (that they can fix) or the same result as in excel. But as long as 2^3=1 in scala and 2^3=8 in Excel we are far away from that usage.

 

Given this use case, have you considered using scala's parser library (as already suggested) to interpret excel formulas?

Or at least, a suitable subset of excel formulas...

 

 

If you make it an open source library as well, then I'm willing to bet that you'd easily find others willing to contribute, it could be a generally useful thing.

 

Alternatively, I believe that apache POI (amongst others) has support for parsing excel formulas, maybe you can wrap the library for use within scala.  Again, I'd advocate going open source for this.

You can build a Scala parser to parse the Excel, then use the expression tree you've built to generate Scala (or Java or C++ or Fortran or whatever else is most useful to you) and compile it as a second step.

If you do it that way, you don't have all the annoying $b$42 cell reference stuff to fix by hand, either.

Or you could just live with an extra ~ character, as in the example I gave (replace all ^ with ~^).  This gives the same precedence and order of operations as Excel, as far as I can tell.  (2^3^3 = 2^9 = 512, I think, not 2^3^3 = 2^(3^3) = 2^27 = ~130M.)

It is, I agree, somewhat annoying to have to choose characters based upon precedence (or for the precedence to be wrong), but I understand the difficulty of allowing user-defined precedence, and I understand the confusion caused when one cannot tell by looking at the code what the precedence is.  (Best coding practices in such a case would be "use parens everywhere", which rather defeats the point of having precedence anyway.)

You could choose \ also, by the way, if that's easier to interpret (or \^ or ~^ or etc.):

implicit def doubleHasPower(d:Double) = new {
  def \(e:Double) = Math.pow(d,e)
}

scala> 1.0+2.0\5.0*2
res0: Double = 65.0

  --Rex


On Tue, Nov 17, 2009 at 11:31 AM, Kubitz, Jörg <jkubitz@zeb.de> wrote:

I have not played with scala's parser library yet since I always thought it would parse at runtime. Doesn’t it?

 We need a code compiled not a runtime interpreter. If the parser library can compile the idea sounds good.  

That is true. This works:   class Power[N](n: N)(implicit num: Numeric[N]) {
  import num._
  def \u2191(exp: Int) = (1 to exp).foldLeft(one)((acc, _) => acc * n) // can be improved, sure
}   implicit def toPower[N : Numeric](n: N) = new Power(n)
scala> 2 * 3 ↑ 2
res39: Int = 18   The \u2191 is Unicode's up-arrow, which is very appropriate. I'm not sure if it will show up on the example or not -- that will depend on your e-mail client, your browser, my browser, etc. :-)
On Tue, Nov 17, 2009 at 1:22 PM, Bastian, Mark <mbastia@sandia.gov> wrote:

Table 5.3 of Programming in Scala lists operator precedence and states "all
other special characters" as higher than the standard ones. I suppose you
could use a unicode character that looks kind of exponential-like. However,
that seems like a pretty extreme solution.

Scala is leaps and bounds ahead of Java when it comes to expressing
mathematical concepts, but I do wish I could make an operator have higher
precedence in some cases (e.g. I've seen ^ used for cross product in some
libraries, but that also has precedence issues). I can live with that
limitation, however.

-Mark

On 11/16/09 7:28 AM, "Russel Winder" <russel.winder@concertant.com> wrote:

> On Mon, 2009-11-16 at 14:24 +0100, Kubitz, Jörg wrote:
>> Yeah, very anoying. I cant even define it for my classes since ³^²
>> has the wrong precedence AND also the wrong Evaluation direction.
>>
> Is there no chance of a ** operator for exponentiation?
>

--
Daniel C. Sobral

Veni, vidi, veterni.