January 13, 2012
Oh, yeah, my bad. I've been at uni for too long: seeing subscripts as "^a"... I agree that an operator for this is unnecessary though. At least I have never felt the need to write "pow(,)" quicker than 6 symbols.

On another note, Octave (and I guess Matlab as well?) use D's precedence
for the pow operator. Bearophile stated earlier that Python does too. Those
seem like quite large audiences. I'm not saying agreeing with the masses
is the choice here, but if a mathematical environment sees it as fit, and
since as far as I'm concerned there's still no reason to prefer one over the
other, it should be either deprecated or left alone.

It will remain ambiguous to someone at some point, no matter how it's defined. Part of learning the language though.

On 13 January 2012 19:18, Manu <turkeyman@gmail.com> wrote:
> On 13 January 2012 19:41, Matej Nanut <matejnanut@gmail.com> wrote:
>>
>> I feel it should be left as is: it'll be ambiguous either way and why mess with how it's in mathematics? If anyone feels uncomfortable using it, just use std.math.pow. Many other languages don't have this operator so people coming from them won't know it exists anyway (like me until this post).
>
>
> Expecting all people who may be uncomfortable with it to use pow() doesn't
> help those who have to read others code containing the operator.
> It's NOT like it is in mathematics, there is no 'operator' in mathematics
> (maths uses a superscript, which APPEARS to be a unary operation). When
> using the operator, with spaces on either side, it looks like (and is) a
> binary operator.
> I think it's reasonable for any experienced programmer to expect that any
> binary operator will have a lower precedence than a unary operator.
> What I wonder is why this operator is necessary at all? With this ambiguity,
> it harms the readability, not improves it :/
January 13, 2012
    The logic is that the precedence in the language matches the
    precedence of a written equation.



  But the operator looks nothing like the written equation... nothing at all like the written equation.
  Perhaps D could support the unicode characters '²' '³' or 'ª' as kinda handy operators. But to me, the operator looks NOTHING like maths notation, and it would never have occurred to me that the operator was trying to emulate maths notation (and by extension, its precedence rules).
  I'd be interested to see a poll, and how many people see it one way or the other...

Beware... your statement has awoken an "Ancient Forum Lurker"! ;)

1. Google -5^2, result: -(5^2) = -25
2. Start ancient TI graphing calculator(which by the way has a special unary (-) minus operator).
-5^2 = -25
-5² = -25

The list can be extended by a great number of examples of prior convention for the pow operator(especially in mathemathical software)... not just Python... I have actually never even seen a valid counter example... changing this would greatly confuse people with mathematical background.


January 13, 2012
On 13 January 2012 20:46, Matej Nanut <matejnanut@gmail.com> wrote:

> On another note, Octave (and I guess Matlab as well?) use D's precedence
> for the pow operator. Bearophile stated earlier that Python does too. Those
> seem like quite large audiences. I'm not saying agreeing with the masses
> is the choice here, but if a mathematical environment sees it as fit, and
> since as far as I'm concerned there's still no reason to prefer one over
> the
> other, it should be either deprecated or left alone.
>

Fair call. I buy this argument. If there is a precedent set by (multiple) other languages towards this precedence (and none against), then so be it. If there were a vote though, I'd vote for it being deprecated on grounds of offering nothing to the language more than confusion.


January 13, 2012
Don:

> Originally it worked the other way, but bearophile complained about it, so it got changed to this way <g>.

If I port Python code to D I prefer the current design. I have opened this thread to see if there are ways to mitigate some of the future problems caused by that :-)

Of my past design decisions about D I regret of suggesting Walter the name "immutable". Its meaning is very clear and it's the correct word, but it's a bit too much long to type, and I am using it often :-| (but less often than const, fortunately). Maybe "imm" or "immu" was better :-)

---------------------

Manu:

> What I wonder is why this operator is necessary at all?

It's not necessary, like most other features in a language, like for loops. But it's handy and very useful, I am now using one power operator about every 40 or 50 lines of D2 code.

Instead of writing:
result = (complex expression) * (complex expression);

Or:

const aux = complex expression;
result = aux * aux;

You write:

result = (complex expression) ^^ 2;

And it gets better with cubes.

I think ^^ operator is currently lacking one overload still, it's discussed a bit in one of the Bugzilla answers written by Don, I think regarding BigInts.

--------------

Mail Mantis:

> Maybe it would be good to always require explicit parenthesis in such expressions?

Is this wise and good?

Bye,
bearophile
January 13, 2012
On 13 January 2012 21:24, Grue <Grue@nop.com> wrote:

> **
>
>
>  The logic is that the precedence in the language matches the
>> precedence of a written equation.
>>
>
> But the operator looks nothing like the written equation... nothing at all
> like the written equation.
> Perhaps D could support the unicode characters '²' '³' or 'ª' as kinda
> handy operators. But to me, the operator looks NOTHING like maths notation,
> and it would never have occurred to me that the operator was trying to
> emulate maths notation (and by extension, its precedence rules).
> I'd be interested to see a poll, and how many people see it one way or the
> other...
>
>
> Beware... your statement has awoken an "Ancient Forum Lurker"! ;)
>

Sweet! I have that effect :P


> 1. Google -5^2, result: -(5^2) = -25
> 2. Start ancient TI graphing calculator(which by the way has a special
> unary (-) minus operator).
> -5^2 = -25
> -5*²* = -25
>
> The list can be extended by a great number of examples of prior convention for the pow operator(especially in mathemathical software)... not just Python... I have actually never even seen a valid counter example... changing this would greatly confuse people with mathematical background.
>

In my prior post I agreed, though that said, I still maintain that none of
those exampled look sufficiently like -5 ^^ 2 by my mind to be considered
'the same thing'. The single ^ and your not using spaces on either side
distinguish it quite clearly...
If it weren't for participation in this debate, I would have never
clarified this in my mind personally, I can say that with confidence.
The ^ xor operator was already taken. Promotion of a 'common' (arguable...)
function to an operator can only be justified by improving code clarity...
I don't think there's any evidence that it does that.

It's funny, I've written a lot of maths code (mostly physics and/or
rendering/lighting), but I can probably count the number of times I've used
pow() on one hand. I use sqrt(), but I think that's a fairly well
established subset of pow(), and people would never use ^^ to perform a
sqrt. A function of that rarity possibly doesn't warrant a custom operator
:)

>


January 13, 2012
On 13 January 2012 21:31, bearophile <bearophileHUGS@lycos.com> wrote:

> > What I wonder is why this operator is necessary at all?
>
> It's not necessary, like most other features in a language, like for loops. But it's handy and very useful, I am now using one power operator about every 40 or 50 lines of D2 code.
>
> Instead of writing:
> result = (complex expression) * (complex expression);
>

What are you working on if I may ask? I do tend to write a lot of very maths-intensive code (physics, rendering, lighting), and I almost never find myself using any sort of pow, other than ^2, which I'm perfectly happy to type x*x.

Or:
>
> const aux = complex expression;
> result = aux * aux;
>
> You write:
>
> result = (complex expression) ^^ 2;
>

I'm more than happy with aux*aux, in fact, I think I prefer it (probably just through habit). Though I do sort of see your point.


> And it gets better with cubes.
>

Realistically, how often do you cube? It's extremely rare in my experience.


January 13, 2012
Manu:

> What are you working on if I may ask?

Bioinformatics, exploratory programing, simulations, data munging, hardening of slow scripts, data visualization, data mining, optimization of some tasks, faster routines for dynamic code written by other people, and more.


> I do tend to write a lot of very
> maths-intensive code (physics, rendering, lighting), and I almost never
> find myself using any sort of pow, other than ^2, which I'm perfectly happy
> to type x*x.

The problem is that often you don't have a "x", but a "long_named_variable", so you have to write long_named_variable * long_named_variable. And often you have to compute an expression to square, so if you don't want to use a temporary variable you have to duplicate the expression. This is bug-prone and noisy.

Other cases:

1 << 5  ==>  2 ^^ 5  (more readable)

sqrt(3.5)  ==>  3.5 ^^ 0.5
Sometimes better:
return ((p1.x - p2.x) ^^ 2 + (p1.y - p2.y) ^^ 2) ^^ 0.5;

10, 100, 1000, ... ==>  map!(p => 10 ^^ p)(iota(2, ...))

You are allowed to write matrix code that overloads ^^ too.

DMD replaces x^^2 and x^^3 with inlined x**x and x*x*x, so it's better than using pow efficiency-wise. DMD knows few other exponent rules that applies as tricks, that I think pow() doesn't use. And programmers usually don't use pow to square a variable, while D programmers feel natural to use ^^ to square. So comparing the use cases of pow with ^^ is wrong.

I suggest you to start using ^^ in your D2 code and you will find it more and more useful.

I have now counted about 730 distinct usages of ^^ operator in the D2 code I have written and I am keeping my hands on at the moment. The real number is probably over 800. You are not going to deprecate it.


> Realistically, how often do you cube? It's extremely rare in my experience.

^^3 is not common.

Bye,
bearophile
January 13, 2012
On 01/13/2012 07:18 PM, Manu wrote:
> On 13 January 2012 19:41, Matej Nanut <matejnanut@gmail.com
> <mailto:matejnanut@gmail.com>> wrote:
>
>     I feel it should be left as is: it'll be ambiguous either way and
>     why mess
>     with how it's in mathematics? If anyone feels uncomfortable using it,
>     just use std.math.pow. Many other languages don't have this operator so
>     people coming from them won't know it exists anyway (like me until this
>     post).
>
>
> Expecting all people who may be uncomfortable with it to use pow()
> doesn't help those who have to read others code containing the operator.

They surely can spend the 2 seconds worth of effort to become comfortable with it. This is an exceedingly trivial issue, and D has adapted a common convention.

> It's NOT like it is in mathematics, there is no 'operator' in
> mathematics (maths uses a superscript, which APPEARS to be a unary
> operation).

If an operation has two parameters, then it is a binary operation.

> When using the operator, with spaces on either side, it
> looks like (and is) a binary operator.

^ commonly means superscript. It simply cannot be argued that ^^ does not resemble ^ a lot. (no matter how many spaces anyone puts anywhere.)

> I think it's reasonable for any experienced programmer to expect that
> any binary operator will have a lower precedence than a unary operator.

It is reasonable for any 'experienced programmer' to be familiar with some language/calculator that has an exponentiation operator. Furthermore, I bet there are many 'experienced programmers' who would actually be surprised that -a*b is parsed as (-a)*b instead of -(a*b).

> What I wonder is why this operator is necessary at all?

Few handy language features are strictly 'necessary'. Having ^^ as a built-in means that the compiler can optimize it for common small constant exponents, like 2 or 3.

> With this ambiguity, it harms the readability, not improves it :/

There is no ambiguity. And yes, it improves readability:

sqrt((x1-x2)^^2+(y1-y2)^^2);

is better than

sqrt(pow(x1-x2,2)+pow(y1-y2,2));

or

sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2));


There is no contest.


January 13, 2012
"Manu" <turkeyman@gmail.com> wrote in message news:mailman.328.1326483521.16222.digitalmars-d@puremagic.com... On 13 January 2012 21:24, Grue <Grue@nop.com> wrote:
>>
>> Beware... your statement has awoken an "Ancient Forum Lurker"! ;)
>>
>
>Sweet! I have that effect :P

Arise!

>In my prior post I agreed, though that said, I still maintain that none of those exampled look sufficiently like -5 ^^ 2 by my mind to be considered 'the same thing'. The single ^ and your not using spaces on either side distinguish it quite clearly...

If that's the case, then what you're objecting to is almost exactly like:

2+3 * 4+1

But that's well-accepted. If the spaces throw you off, then just use them differently:

2 + 3*4 + 1
-5^^2

>It's funny, I've written a lot of maths code (mostly physics and/or
>rendering/lighting), but I can probably count the number of times I've used
>pow() on one hand. I use sqrt(), but I think that's a fairly well
>established subset of pow(), and people would never use ^^ to perform a
>sqrt. A function of that rarity possibly doesn't warrant a custom operator
>:)

Sounds like you're talking about game code, in which case it doesn't surprise me you haven't used it much. Game code needs to be real-time, so doing advanced math in code tends to be avoided whenever possible, even if it's at the expense of slight inaccuracy (since framerate and user experience are more important than perfect mathematical "correctness"). Other applications would be fairly different, like scientific computing.


January 13, 2012
On 13/01/2012 19:14, Manu wrote:
<snip>
> I think there's one very important point to realise in all your examples though...
> We're NOT writing -4x² + 3. We write -4 * x ^^ 2 + 4. That's not a polynomial expressions,
> it's source code.

What are you on about?  -4x² + 3 and -4 * x ^^ 2 + 3 are the exact same polynomial expression.  They're just written in different notations.

> I don't know about you, but the visual similarity is just not there for me. I can't see
> C/D/Java/whatever code as a direct transcription of mathematical notation no matter how
> hard I squint at it.
<snip>

But we mathematicians get used to the similarities in stuff like precedence rules.  We shouldn't have to remember that D works differently in ways that the compiler won't warn us if we forget.  Add to that that some of us may be migrating from something like Maple or Mathematica that bridges the gap between mathematical notation and program code.

And my points still apply.

x ^^ 3 - x ^^ 2 + 3
vs.
       - x ^^ 2 + 3

One shouldn't have to remember to add brackets to x ^^ 2 because removal of the x ^^ 3 term has changed the nature of the -.

Stewart.