Calc: `*' binds more strongly than `/'

Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Hello!

This is something I just feel I have to mention before the release, as
it is very confusing, IMHO: `*' binds more strongly than `/' in M-x
calc.

The following is a table which allows you to do calculations:

| Value | Percentage |
|-------+------------|
|    17 |            |
|    56 |            |
|    42 |            |
#+TBLFM: $2=$1/65*100

The line below the table contains formulas for the table columns, I
think you can figure out what it means -- the steps to reproduce the
confusing behaviour are:

1. M-x orgtbl-mode RET

,----[ C-h f orgtbl-mode RET ]
| The `org-mode' table editor as a minor mode for use in other modes.
`----

2. Put point in an empty table cell below `Percentage' and press `C-u
   C-c C-c', which will recompute the table:

,----[ C-h k C-c C-c ]
| C-c C-c runs the command orgtbl-ctrl-c-ctrl-c
| With prefix arg, also recompute table.
`----

What you get is this:

| Value | Percentage |
|-------+------------|
|    17 |  2.6154e-3 |
|    56 |  8.6154e-3 |
|    42 |  6.4615e-3 |
#+TBLFM: $2=$1/65*100

What I expected to get is:

| Value | Percentage |
|-------+------------|
|    17 |     26.154 |
|    56 |     86.154 |
|    42 |     64.615 |
#+TBLFM: $2=($1/65)*100

Note the    ^     ^ extra parentheses.

But in order to get the expected result, I have to put the `/'
operation in parenthesis as Calc does not calculate `from left to
right' in this case.

So when one uses orgtbl-mode (or org-mode) for table calculations
(which in turn uses Calc for the calculations), one has to know that
`*' binds more strongly than `/' -- well, I didn't know and asked
Carsten Dominik, the author of org-mode. He explained that this is a
feature of Calc. He also put a sentence in the org-mode manual:

,----[ (info "(org)Formula syntax for Calc") ]
| Note that `calc' has the slightly non-standard convention that `/'
| has lower precedence than `*', so that `a/b*c' is interpreted as
| `a/(b*c)'.
`----

Later, I also found it in the Calc manual:

,----[ (info "(calc)Algebraic Tutorial") ]
|    Algebraic formulas use the operators `+', `-', `*', `/', and `^'.
| You can use parentheses to make the order of evaluation clear.  In the
| absence of parentheses, `^' is evaluated first, then `*', then `/',
| then finally `+' and `-'.  For example, the expression
| 
| [...]
| 
|    Calc's order of evaluation is the same as for most computer
| languages, except that `*' binds more strongly than `/', as the above
| example shows.  As in normal mathematical notation, the `*' symbol can
| often be omitted:  `2 a' is the same as `2*a'.
| 
|    Operators at the same level are evaluated from left to right, except
| that `^' is evaluated from right to left.  Thus, `2-3-4' is equivalent
| to `(2-3)-4' or -5, whereas `2^3^4' is equivalent to `2^(3^4)' (a very
| large integer; try it!).
`----

I believe (but I do not know) that Calc's behaviour is (too) far from
what `ordinary' people (like me ;-) would expect: I ran into this
feature in my first table and wondered what was going on. I thought
that Org-mode calculates `wrong'.

I don't know if it is possible to change the current behaviour, but I
think it would be better. My arguments:

- I learned in school that `*' and `/' bind more than `+' and `-'. I
  don't remember any `finer graduation' between the operators. Even
  the Calc manual says that this feature is an exception. Carsten
  Dominik calls it a `slightly non-standard convention' in the
  Org-mode manual.

- MATLAB works as I expect it, and I'd guess that GNU Octave does so
  too, but I don't have it installed. Gnumeric 1.7.0 works as I expect
  it, too.

- With the inclusion of Calc (and Org-mode) in Emacs 22, Org-mode's
  spreadsheet capabilities and Calc will be used by a wider audience.
  But they will easily run into this feature and might get wrong
  results (without discovering it). Org-mode mentions the feature
  directly in the beginning of the section of the manual that deals
  with spreadsheet calculations, but in Calc I had to dig into the
  manual to find out about this, especially as I was completely
  unfamiliar with Calc. What I would expect, however, is a kind of a
  warning on the first page of the manual that Calc does not work as
  `one' might expect (depending on `one').

The Calc manual mentions `Operators at the same level are evaluated
from left to right', so Calc could treat `*' and `/' as equal, it
seems. The current behaviour was surely chosen for a reason, but I
really wonder if it is (no offence, Calc seems to be great otherwise)
suitable for a `wider' audience.

Regards,

Christian Schlauer

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
...
> This is something I just feel I have to mention before the release, as
> it is very confusing, IMHO: `*' binds more strongly than `/' in M-x
> calc.
...
> Later, I also found it in the Calc manual:
...
> I believe (but I do not know) that Calc's behaviour is (too) far from
> what `ordinary' people (like me ;-) would expect:
...
> I don't know if it is possible to change the current behaviour,

I agree with what you've said, and it wouldn't be hard to change the
behavior, but, as you say,

> The current behaviour was surely chosen for a reason,

I'm not sure what the reason was, and I'm not sure the behavior should
change without knowing why the unusual behavior was put in place to
begin with.

Jay

Re: Calc: `*' binds more strongly than `/'

[Chong Yidong]

Jay Belanger <belanger@truman.edu> writes:

>> This is something I just feel I have to mention before the release, as
>> it is very confusing, IMHO: `*' binds more strongly than `/' in M-x
>> calc.
> ...
>> Later, I also found it in the Calc manual:
> ...
>> I believe (but I do not know) that Calc's behaviour is (too) far from
>> what `ordinary' people (like me ;-) would expect:
> ...
>> I don't know if it is possible to change the current behaviour,
>
> I agree with what you've said, and it wouldn't be hard to change the
> behavior, but, as you say,
>
>> The current behaviour was surely chosen for a reason,
>
> I'm not sure what the reason was, and I'm not sure the behavior should
> change without knowing why the unusual behavior was put in place to
> begin with.

I added a strong note to the calc manual, in the tutorial section on
algebraic entry, about this point.  (There are already multiple other
places in the Calc manual that re-iterate this).

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

> I added a strong note to the calc manual, in the tutorial section on
> algebraic entry, about this point.  (There are already multiple other
> places in the Calc manual that re-iterate this).

After Emacs-22, we should probably just change the precedence to be the
"normal" one.


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Randal L. Schwartz]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I added a strong note to the calc manual, in the tutorial section on
>> algebraic entry, about this point.  (There are already multiple other
>> places in the Calc manual that re-iterate this).

Stefan> After Emacs-22, we should probably just change the precedence to be the
Stefan> "normal" one.

No, not normal for mathemeticians (and me on a bad day), who expect A*B/C*D to
be the same as (A*B)/(C*D).

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

> No, not normal for mathemeticians (and me on a bad day), who expect
> A*B/C*D to be the same as (A*B)/(C*D).

My math specialty is logic rather than calculus, but I've always learned to
parse "A*B/C*D" as "((A*B)/C)*D".  Your point is valid when you use the
juxtaposition notation rather than *: A B / C D is indeed (A*B)/(C*D).
And it's also valid when you use the horizontal bar, of course.

But for "A*B/C*D" I have a difficult time believing that some "standard math
notation" would parse it as you suggest.  I.e. do you have any reference to
concrete data to back up this hypothesis?


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> No, not normal for mathemeticians (and me on a bad day), who expect
>> A*B/C*D to be the same as (A*B)/(C*D).

> But for "A*B/C*D" I have a difficult time believing that some "standard math
> notation" would parse it as you suggest.  I.e. do you have any reference to
> concrete data to back up this hypothesis?

Yes, if you read it as

   A * B
   -----
   C * D

then it is obvious where the parentheses should be.

So it depends on how to interpret / in calc.

I (and I believe the calc author) interpret it as above 
(which I find very convenient!!)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

>>> No, not normal for mathemeticians (and me on a bad day), who expect
>>> A*B/C*D to be the same as (A*B)/(C*D).

>> But for "A*B/C*D" I have a difficult time believing that some "standard math
>> notation" would parse it as you suggest.  I.e. do you have any reference to
>> concrete data to back up this hypothesis?

> Yes, if you read it as

>    A * B
>    -----
>    C * D

> I (and I believe the calc author) interpret it as above 

I don't think so.

Theorem: the "/" is *not* a horizontal bar.
Proof:

  What parse tree do you expect from A+B/C+D?

  Is it the same as the one you expect from

    A + B
    -----
    C + D

QED.


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Davis Herring]

> I don't think so.
>
> Theorem: the "/" is *not* a horizontal bar.
> Proof:
>
>   What parse tree do you expect from A+B/C+D?
>
>   Is it the same as the one you expect from
>
>     A + B
>     -----
>     C + D
>
> QED.

The "/" there can certainly be considered a horizontal bar: under the B,
and over the C.

     B
A + --- + D
     C

Consider that no one would read y=x^2/2 as

      2
 y = x
-------
   2

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Calc: `*' binds more strongly than `/'

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

"Davis Herring" <herring@lanl.gov> writes:

>> I don't think so.
>>
>> Theorem: the "/" is *not* a horizontal bar.
>> Proof:
>>
>>   What parse tree do you expect from A+B/C+D?
>>
>>   Is it the same as the one you expect from
>>
>>     A + B
>>     -----
>>     C + D
>>
>> QED.
>
> The "/" there can certainly be considered a horizontal bar: under the B,
> and over the C.
>
>      B
> A + --- + D
>      C
>
> Consider that no one would read y=x^2/2 as
>
>       2
>  y = x
> -------
>    2

Tell that to TeX.  It renders $$y = x^2\over 2$$ as


[-- Attachment #2: $$y = x^2\over 2$$ --]
[-- Type: image/png, Size: 1089 bytes --]

[-- Attachment #3: Type: text/plain, Size: 51 bytes --]


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Calc: `*' binds more strongly than `/'

[Davis Herring]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

>> Consider that no one would read y=x^2/2 as
>>
>>       2
>>  y = x
>> -------
>>    2
>
> Tell that to TeX.  It renders $$y = x^2\over 2$$ as

TeX does not count; $x^23$ becomes the attached.  Never mind its, er,
unique tokenization rules, etc.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

[-- Attachment #2: x^23.png --]
[-- Type: image/png, Size: 314 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

>> I don't think so.
>> 
>> Theorem: the "/" is *not* a horizontal bar.
>> Proof:
>> 
>> What parse tree do you expect from A+B/C+D?
>> 
>> Is it the same as the one you expect from
>> 
>> A + B
>> -----
>> C + D
>> 
>> QED.

> The "/" there can certainly be considered a horizontal bar: under the B,
> and over the C.

>      B
> A + --- + D
>      C

Then we're back to precedence and the question becomes why don't you
consider A*B/C*D as

        B
   A * --- * D
        C

In any case, I still haven't heard any concrete reason why the non-standard
behavior of calc is preferred to the more common behavior.  Neither is
perfect because there is no such thing, but one of them is sufficiently
surprising to deserve big warnings in the Calc doc and the Org doc, whereas
the other would be "business as usual".


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Randal L. Schwartz]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> In any case, I still haven't heard any concrete reason why the
Stefan> non-standard behavior of calc is preferred to the more common
Stefan> behavior.

"Backward compatibility" is not a concrete reason?  Calc has been around for a
*very* long time.  Do not needlessly break it.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

Stefan> In any case, I still haven't heard any concrete reason why the
Stefan> non-standard behavior of calc is preferred to the more common
Stefan> behavior.

> "Backward compatibility" is not a concrete reason?

Well, of course, there's this one.  But I was looking for one that justifies
choosing the current behavior in the first place.

> Calc has been around for a *very* long time.  Do not needlessly break it.

I cannot judge that.  I just know that big warnings in the doc about
unexpected behavior should usually better be fixed by changing the behavior
(when possible).  If there are too many existing calc-scripts that would be
broken by such a change, fine, but if this only mostly affects interactive
use, then changing it would make a lot of sense.


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
...
> If there are too many existing calc-scripts that would be
> broken by such a change, fine, but if this only mostly affects interactive
> use, then changing it would make a lot of sense.

While several people have said the current behavior is convenient for
interactive use, I would hope (and expect) that there aren't any
calc-scripts depending on this behavior.  But it'd be nice to know for
sure. 
Perhaps after the release I could add a customizable variable,
`calc-multiplication-has-precedence' (default t), and then anyone that
wants to can set it to nil and try out the different behavior.

Jay

Re: Calc: `*' binds more strongly than `/'

[Miles Bader]

Jay Belanger <belanger@truman.edu> writes:
> While several people have said the current behavior is convenient for
> interactive use, I would hope (and expect) that there aren't any
> calc-scripts depending on this behavior.  But it'd be nice to know for
> sure. 

In any case, while there are clearly some people which know about and
like the current behavior -- so any change would unfortunately cause
_some_ pain -- I suspect even more people get screwed up by calc's
deviation from standard practice (and often probably don't realize it
until they detect later than their calculation turned out wrong for some
reason).

-Miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Miles Bader <miles@gnu.org> writes:

> In any case, while there are clearly some people which know about and
> like the current behavior -- so any change would unfortunately cause
> _some_ pain -- I suspect even more people get screwed up by calc's
> deviation from standard practice (and often probably don't realize it
> until they detect later than their calculation turned out wrong for some
> reason).

Full ACK. As the splash screen says: GNU Emacs comes with ABSOLUTELY
NO WARRANTY. But imagine one of NASA's space missions failing because
some guy/girl likes to use Emacs... that's no good advertising for us.

Regards,

Christian

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Jay Belanger <belanger@truman.edu> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> ...
>> If there are too many existing calc-scripts that would be
>> broken by such a change, fine, but if this only mostly affects interactive
>> use, then changing it would make a lot of sense.
>
> While several people have said the current behavior is convenient for
> interactive use, I would hope (and expect) that there aren't any
> calc-scripts depending on this behavior.  But it'd be nice to know for
> sure. 

You are the maintainer of Calc -- do you have any contact to package
authors or users of packages that make use of Calc? I only know about
Org-mode, see below. What about table.el?

The tables in Org-mode use Calc. That is a non-interactive use of
Calc, isn't it:

| Value | Percentage |
|-------+------------|
|    17 |            |
|    56 |            |
|    42 |            |
#+TBLFM: $2=$1/65*100

The `#+TBLFM:' line is a Calc-script, and some of them would break, if
they rely on the precedence of multiplication, like this example. But
nevertheless I think Calc's behaviour could (and should) be changed,
because:

- Existing tables aren't automatically recalculated when you open the
  file, you have to do `C-u C-c C-c' in the table. So there is no
  `immediate' damage. But even better:

- Org-mode could keep the existing Calc behaviour for existing tables
  but use the `new' more standards-conforming Calc behaviour when the
  script line `#+TBLFM:' starts with `#+TBLFMv2:' or something
  similar, which could be Org-mode's new default as soon as Calc has
  been modified.

So regarding Org-mode, nothing will break, I think.

> Perhaps after the release I could add a customizable variable,
> `calc-multiplication-has-precedence' (default t), and then anyone that
> wants to can set it to nil and try out the different behavior.

Rather make the default nil so that new users can use Calc and Org
like *any* pocket calculator or *any* spreadsheet...

WDYT?

Regards,

Christian

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

> Jay Belanger <belanger@truman.edu> writes:
...
>> While several people have said the current behavior is convenient for
>> interactive use, I would hope (and expect) that there aren't any
>> calc-scripts depending on this behavior.  But it'd be nice to know for
>> sure.
>
> You are the maintainer of Calc -- do you have any contact to package
> authors or users of packages that make use of Calc? 

No; I'd just ask on this list and on the newsgroups.

> The tables in Org-mode use Calc. That is a non-interactive use of
> Calc, isn't it:
>
> | Value | Percentage |
> |-------+------------|
> |    17 |            |
> |    56 |            |
> |    42 |            |
> #+TBLFM: $2=$1/65*100

I suppose so, but in this case I wouldn't really say that Org-mode is
depending on the behavior of Calc but rather that the Org-mode user is
depending on it.  So this would be a problem for changing the Calc behavior.

> The `#+TBLFM:' line is a Calc-script, and some of them would break, if
> they rely on the precedence of multiplication, like this example. But
> nevertheless I think Calc's behaviour could (and should) be changed,
> because:
...
> - Org-mode could keep the existing Calc behaviour for existing tables
>   but use the `new' more standards-conforming Calc behaviour when the
>   script line `#+TBLFM:' starts with `#+TBLFMv2:'

That sounds tricky...

>> Perhaps after the release I could add a customizable variable,
>> `calc-multiplication-has-precedence' (default t), and then anyone that
>> wants to can set it to nil and try out the different behavior.
>
> Rather make the default nil so that new users can use Calc and Org
> like *any* pocket calculator or *any* spreadsheet...
>
> WDYT?

I think that anyone using a new program should at least glance at the
manual, and the Calc manual makes its behavior pretty clear.
Continuing users should be able to expect not so radical changes.
At any rate, my comment above was to enable people to check the new
behavior on their packages and make sure the new behavior is viable.

Jay

Re: Calc: `*' binds more strongly than `/'

[Jason Rumney]

Christian Schlauer wrote:
>> Perhaps after the release I could add a customizable variable,
>> `calc-multiplication-has-precedence' (default t), and then anyone that
>> wants to can set it to nil and try out the different behavior.
>>     
>
> Rather make the default nil so that new users can use Calc and Org
> like *any* pocket calculator or *any* spreadsheet...
>   

I agree. It would help flush out any problems with other packages that 
rely on calc's unusual precedence, and if we found that it caused too 
much trouble we have plenty of time to switch it back for the next release.

Re: Calc: `*' binds more strongly than `/'

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Christian Schlauer wrote:
>>> Perhaps after the release I could add a customizable variable,
>>> `calc-multiplication-has-precedence' (default t), and then anyone that
>>> wants to can set it to nil and try out the different behavior.
>>>     
>>
>> Rather make the default nil so that new users can use Calc and Org
>> like *any* pocket calculator or *any* spreadsheet...
>>   
>
> I agree. It would help flush out any problems with other packages that
> rely on calc's unusual precedence, and if we found that it caused too
> much trouble we have plenty of time to switch it back for the next
> release.

I seem to be the only one who have spoken in favour of the current
precedence rule, but I'm only a casual user of calc, so my opinion
shouldn't matter here!

I'd be just as happy with the "standard" precedence.

Besides, I usually add () to mixtures of / and * anyway (for clarity
and/or to dictate a specific evaluation order to get maximum precision
in the result).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

storm@cua.dk (Kim F. Storm) writes:
...
> I seem to be the only one who have spoken in favour of the current
> precedence rule, but I'm only a casual user of calc, so my opinion
> shouldn't matter here!

You must have missed a few messages; you are by no means the only one
in favor of the current rule.

> Besides, I usually add () to mixtures of / and * anyway (for clarity
> and/or to dictate a specific evaluation order to get maximum precision
> in the result).

Well, I think that's the proper way of doing it; even though there are
rules for interpreting expressions like a*b/c*d, that doesn't mean
writing the expression that way is a good thing to do -- it's just bad
form.  I don't think there is any difference between Calc's current
precedence rule and the more standard one for properly written
expressions.

Jay

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Jay Belanger <belanger@truman.edu> writes:

> storm@cua.dk (Kim F. Storm) writes:
> ...
>> I seem to be the only one who have spoken in favour of the current
>> precedence rule, but I'm only a casual user of calc, so my opinion
>> shouldn't matter here!
>
> You must have missed a few messages; you are by no means the only one
> in favor of the current rule.

I checked the thread and Randal L. Schwartz, Daniel Brockman and Kim
F. Storm backed up the current behaviour. Carsten Dominik likes the
current behaviour, too.

Stefan Monnier, Miles Bader, Jason Rumney and me "prefer" a change of
the current behaviour.

>> Besides, I usually add () to mixtures of / and * anyway (for clarity
>> and/or to dictate a specific evaluation order to get maximum precision
>> in the result).
>
> Well, I think that's the proper way of doing it; even though there are
> rules for interpreting expressions like a*b/c*d, that doesn't mean
> writing the expression that way is a good thing to do -- it's just bad
> form.  I don't think there is any difference between Calc's current
> precedence rule and the more standard one for properly written
> expressions.

I did some more `research', and a*b/c*d is not bad form, and it is a
properly written expression, see Wikipedia. Let me cite from
<http://en.wikipedia.org/wiki/Order_of_operations#Examples_from_arithmetic>:

,----
| 3. Evaluate multiplications and divisions, starting from the left:
| 
| 8/2*3 = [8/2]*3 = [4*3] = 12
`----

Further down on the same page:

"Since multiplication and division are of the same rank, [...]"

and further on (emphasis added by me):

,----
| Warning: Multiplication and division are of *equal precedence*, and
| addition and subtraction are of *equal precedence*. Using any of the
| above rules in the order addition first, subtraction afterward would
| give the wrong answer to
| 
| 10 - 3 + 2
| 
| The correct answer is 9, which is best understood by thinking of the
| problem as the sum of positive ten, negative three, and positive
| two.
| 
| It is usual, wherever you need to calculate operations of equal
| precedence to work *from left to right*. The following rules of
| thumb are useful:
| 
| First: perfom any calculations inside parentheses (brackets)
| 
| Second: Next perform all multiplication and division, working from
| *left to right*
| 
| Third: Lastly perform all addition and subtraction, working from
| *left to right*
`----

So besides Excel, Gnumeric, MATLAB, all pocket calculators, Wikipedia
agrees with me, too.

Calc's current behaviour is simply wrong, I'd say.

Regards,

Christian

P.S.: I have not edited the Wikipedia article.

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
> Jay Belanger <belanger@truman.edu> writes:
...
>> Well, I think that's the proper way of doing it; even though there are
>> rules for interpreting expressions like a*b/c*d, that doesn't mean
>> writing the expression that way is a good thing to do -- it's just bad
>> form.  I don't think there is any difference between Calc's current
>> precedence rule and the more standard one for properly written
>> expressions.
>
> I did some more `research', and a*b/c*d is not bad form, and it is a
> properly written expression, see Wikipedia. Let me cite from
> <http://en.wikipedia.org/wiki/Order_of_operations#Examples_from_arithmetic>:

As I said, there are rules for interpreting the above expressions.  
I also said that avoiding the parentheses is bad form; note that the
wikipedia article also says:

  Proper use of parentheses and other grouping symbols

  When restricted to using a straight text editor, parentheses (or
  more generally "grouping symbols") must be used generously to make
  up for the lack of graphics, like square root symbols. Here are some
  rules for doing so: 

  1) Whenever there is a fraction formed with a slash, put the
  numerator (the number on top of the fraction) in one set of
  parentheses, and the denominator (the number on the bottom of the
  fraction) in another set of parentheses. This is not required for
  fractions formed with underlines: 
    y = (x+1)/(x+2)
  ...
  5) An exception to the rules requiring parentheses applies when only
  one character is present. While correct either way, it is more
  readable if parentheses around a single character are omitted: 

    y = (3)/(x) or y = 3/x

    y = (3)/(2x) or y = 3/(2x)

> So besides Excel, Gnumeric, MATLAB, all pocket calculators, Wikipedia
> agrees with me, too.

Well, wikipedia also says

  Calculators

  Different calculators follow different orders of operations.

and gives several examples.

The reason for Calc's current behavior is because Dave Gillespie,
Calc's author, thought of "a b / c d" as representing 
  a b
  ---
  c d
To have it represent "a(b/c)d", the parentheses can (and, according to
wikipedia, should be) put in.  For those that really don't like
parentheses, an option to allow the user to decide for themselves the
relative precedence of * and / in Calc will be added, of course.

Jay

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

> The reason for Calc's current behavior is because Dave Gillespie,
> Calc's author, thought of "a b / c d" as representing 

I expect the reason is slightly different: it's that the same rule is used
for "a * b / c * d" as for "a b / c d".  The "juxtaposition operator" is
traditionally assumed to have the highest precedence, so it of course parses
as "(a b)/(c d)".


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The reason for Calc's current behavior is because Dave Gillespie,
>> Calc's author, thought of "a b / c d" as representing
>>  a b
>>  ---
>>  c d

This is what Dave said when I asked him about it.  (He actually said
he thought of the first version as an alternate way of writing the
second.)

> I expect the reason is slightly different: it's that the same rule is used
> for "a * b / c * d" as for "a b / c d".

Exactly; the motivation was for the implicit multiplication, but he
didn't want to give implicit and explicit multiplication different
precedences.

> The "juxtaposition operator" is traditionally assumed to have the
> highest precedence, so it of course parses as "(a b)/(c d)".

I hadn't realized that before, but it does seem pretty standard (but
not quite universal -- I read that the TI-85 and TI-86 treat
juxtaposition differently).  How interesting.

Jay

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

> Exactly; the motivation was for the implicit multiplication, but he
> didn't want to give implicit and explicit multiplication different
> precedences.

And that's where he went wrong IMNSHO.


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Exactly; the motivation was for the implicit multiplication, but he
>> didn't want to give implicit and explicit multiplication different
>> precedences.
>
> And that's where he went wrong IMNSHO.

I agree with Stefan -- it seems that implicit multiplication a.k.a.
the `juxtaposition operator' is assumed by default, even when a `*' is
given as in `y = 3/2*x'. Calc sort of strips the `*' and calculates `y
= 3/(2x)'.

I'm glad you found the root of the `feature'!

Re: Calc: `*' binds more strongly than `/'

[Davis Herring]

>> I expect the reason is slightly different: it's that the same rule is
>> used
>> for "a * b / c * d" as for "a b / c d".
>
> Exactly; the motivation was for the implicit multiplication, but he
> didn't want to give implicit and explicit multiplication different
> precedences.

For what it's worth, Mathematica (one of the few other programs with the
"implicit multiplication" operator) gives implicit and explicit
multiplication and division equal precedence: a b/c d puts d in the
numerator, as does a*b/c*d.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Calc: `*' binds more strongly than `/'

[Stefan Monnier]

> For what it's worth, Mathematica (one of the few other programs with the
> "implicit multiplication" operator) gives implicit and explicit
> multiplication and division equal precedence: a b/c d puts d in the
> numerator, as does a*b/c*d.

Hmm... that does come as unintuitive to me.


        Stefan

Re: Calc: `*' binds more strongly than `/'

[Luc Teirlinck]

Stefan Monnier wrote:

   > For what it's worth, Mathematica (one of the few other programs with the
   > "implicit multiplication" operator) gives implicit and explicit
   > multiplication and division equal precedence: a b/c d puts d in the
   > numerator, as does a*b/c*d.

   Hmm... that does come as unintuitive to me.

No.  Because b/c can be interpreted as an individual rational number,
rather than the result of an operation (division).  This is especially
true when you are using software that implements rational numbers.
This is actually one of the main reasons that / usually has precedence
over *: a*b/c*d can be considered as `a' times the rational number
`b/c' times `d'; / can also be considered as an operation and a,b,c,d
as four distinct numbers.  If you give / higher precedence as *, you
do not have to worry about which interpretation is "correct", since it
does not make any difference.

2/3 * 5/7 = 10/21, in either interpretation _assuming_ / has higher
precedence than *.

Of course, provoking discussions like this is one of the many reasons
why the Devil invented infix notation.  If you have to use it, then
the best way to defeat his brilliant but evil scheme is to always
write explicitly (a*b)/(b*c) or a*(b/c)*d, to leave no doubt whatsoever.

Sincerely,

Luc.

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> This is actually one of the main reasons that / usually has precedence
> over *:

Luc, I only wanted `/' to be treated equal as `*', not less than `*'
as it is at the moment, but not necessarily more ;-)

> Of course, provoking discussions like this is one of the many
> reasons why the Devil invented infix notation. If you have to use
> it, then the best way to defeat his brilliant but evil scheme is to
> always write explicitly (a*b)/(b*c) or a*(b/c)*d, to leave no doubt
> whatsoever.

,----[ <http://en.wikipedia.org/wiki/Infix_notation> ]
| In infix notation, unlike in prefix or postfix notations,
| parentheses surrounding groups of operands and operators are
| necessary to indicate the intended order in which operations are to
| be performed. *In the absence of parentheses*, certain precedence
| rules determine the order of operations. These are explained in the
| order of operations article.
`----

Christian

Re: Calc: `*' binds more strongly than `/'

[Luc Teirlinck]

Christian Schlauer wrote:

   Luc, I only wanted `/' to be treated equal as `*', not less than `*'
   as it is at the moment, but not necessarily more ;-)

Yes, but given left-associativity, the _result_ of giving them equal
precedence is actually to give, in an expression containing only `*' and
`/', `/' higher precedence, is it not?  The important consequence of
that is that in a product of rational numbers devoid of parentheses,
the rational numbers get actually recognized and treated as rational
numbers, in as far as the result is concerned, regardless of how the
actual algorithm achieves this (precedence or left-associativity).

Sincerely,

Luc.

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

[...]

>> I did some more `research', and a*b/c*d is not bad form, and it is a
>> properly written expression, see Wikipedia. Let me cite from
>> <http://en.wikipedia.org/wiki/Order_of_operations#Examples_from_arithmetic>:
>
> As I said, there are rules for interpreting the above expressions.  
> I also said that avoiding the parentheses is bad form; note that the
> wikipedia article also says:
>
>   Proper use of parentheses and other grouping symbols
>
>   When restricted to using a straight text editor, parentheses (or
>   more generally "grouping symbols") must be used generously to make
>   up for the lack of graphics, like square root symbols. Here are some
>   rules for doing so: 
>
>   1) Whenever there is a fraction formed with a slash, put the
>   numerator (the number on top of the fraction) in one set of
>   parentheses, and the denominator (the number on the bottom of the
>   fraction) in another set of parentheses. This is not required for
>   fractions formed with underlines: 
>     y = (x+1)/(x+2)
>   ...
>   5) An exception to the rules requiring parentheses applies when only
>   one character is present. While correct either way, it is more
>   readable if parentheses around a single character are omitted: 
>
>     y = (3)/(x) or y = 3/x
>
>     y = (3)/(2x) or y = 3/(2x)

I saw those examples, too, but didn't read the text of that section,
as all examples there use `+', and then of course one needs
parentheses -- otherwise it is *really* wrong. But the last line I
cite from you is exactly what Calc is ignoring and what I `complain'
about:

y = 3/(2x)

So despite the `juxtaposition operator' (I had to check what this
means, <http://en.wiktionary.org/wiki/juxtaposition> says "An absence
of multiplication symbols, `ab' instead of `a times b'"), they suggest
to write the denominator with parentheses to bind the `x' to `2'.
Let's ignore for a moment the `juxtaposition operator' and use `*': in
the current Calc you can write `y = 3/2*x' when what you want Calc to
do is `y = 3/(2*x)', and *that* is really not what I'd expect from
mathematics software after reading the Wikipedia article -- because
according to what you cite above from Wikipedia, the `x' in `y =
3/2*x' does definitely not belong to the denominator. But in Calc, it
does. :-(

If you want, let Calc interpret `y = 3/2x' as `y = 3/(2x)', in order
to let the `juxtaposition operator' have precedence -- but `y = 3/2*x'
should _never_ be treated in that way.

>> So besides Excel, Gnumeric, MATLAB, all pocket calculators, Wikipedia
>> agrees with me, too.
>
> Well, wikipedia also says
>
>   Calculators
>
>   Different calculators follow different orders of operations.
>
> and gives several examples.

But these examples refer to only two cases:

1) Cheaper calculators without a stack work left to right without any
   priority given to different operators, for example giving

   1+2*3=9

   while more sophisticated calculators will use a more standard
   priority, for example giving

   1+2*3=7.

2) Two different TI models that differ in the interpretation of a^b^c:
   one sees it as (a^b)^c, the other as a^(b^c).

That the TI models differ concerning a^b^c is unfortunate, but on the
basis of this Wikipedia article I still say that

- all pocket calculators _that consider the order of operators_ treat
  / and * as equal and evaluate from left to right in the absence of
  parentheses and

- the behaviour of pocket calculators starts to differ with
  expressions like a^b^c, which some evaluate left-to-right, as they
  do with other operators, while others (the better ones, IMO -- Calc
  included, see (info "(calc)Algebraic Tutorial"): `2^3^4' is
  equivalent to `2^(3^4)') evaluate this from right-to-left.

> For those that really don't like parentheses, an option to allow the
> user to decide for themselves the relative precedence of * and / in
> Calc will be added, of course.

That sounds good, but what will be the default? I really think that
the Wikipedia article has more than enough evidence against Calc's
current behaviour.

Regards,

Christian

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

[from wikipedia]
>>   Proper use of parentheses and other grouping symbols
...
> I saw those examples, too, but didn't read the text of that section,

The key thing from that section, I think, is the statement that
parentheses should be used generously, and 
   6) Whenever anything can be interpreted multiple ways, put the part
   to be done first in parentheses, to make it clear.

>> Well, wikipedia also says
>>
>>   Calculators
>>
>>   Different calculators follow different orders of operations.
>>
>> and gives several examples.
>
> But these examples refer to only two cases:

The examples weren't meant to be comprehensive, but only to make the
point that different calculators do things differently.

>> For those that really don't like parentheses, an option to allow the
>> user to decide for themselves the relative precedence of * and / in
>> Calc will be added, of course.
>
> That sounds good, but what will be the default?

Calc's current behavior will be the default.  It is Calc's established
behavior.  It has its detractors, but it also has its proponents and
its advantages.  I also feel that in any expression where it matters
(whether it's being typed into Calc, Gnumeric or anything else)
the parentheses should be included.  Leaving them out is, in my
opinion, bad style.  (I've been using the word "form"; "style" is
probably a better word.) Anyone who insists on avoiding the
parentheses and wants the alternate behavior can change the option
(which I'll add as soon as changes in Emacs are allowed ...)

Jay

Re: Calc: `*' binds more strongly than `/'

[Davis Herring]

> P.S.: I have not edited the Wikipedia article.

So you paid someone else to do it, right? ;)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Jay Belanger <belanger@truman.edu> writes:
...
> Perhaps after the release I could add a customizable variable,
> `calc-multiplication-has-precedence' (default t), and then anyone that
> wants to can set it to nil and try out the different behavior.

This has been done.

Jay

Re: Calc: `*' binds more strongly than `/'

[Kim F. Storm]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> Jay Belanger <belanger@truman.edu> writes:
> ...
>> Perhaps after the release I could add a customizable variable,
>> `calc-multiplication-has-precedence' (default t), and then anyone that
>> wants to can set it to nil and try out the different behavior.
>
> This has been done.

I see that you have committed the change, but haven't had time to play with it.

According to the doc, setting calc-multiplication-has-precedence to nil gives
precedence to / over *.

IIRC, the objection was that people expected equal precedence with
left to right evaluation (as in C).  Giving / precedence over *
doesn't fix that - it just gives another "wrong" result.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

storm@cua.dk (Kim F. Storm) writes:
...
> According to the doc, setting calc-multiplication-has-precedence to nil gives
> precedence to / over *.
>
> IIRC, the objection was that people expected equal precedence with
> left to right evaluation (as in C).  Giving / precedence over *
> doesn't fix that - it just gives another "wrong" result.

When would it give the "wrong" result?

At any rate, setting calc-multiplication-has-precedence to nil should
probably give equal precedence for aesthetic reasons; that's a trivial
fix that I'll make this afternoon.

Jay

Re: Calc: `*' binds more strongly than `/'

[Luc Teirlinck]

Kim Storm wrote:

   IIRC, the objection was that people expected equal precedence with
   left to right evaluation (as in C).  Giving / precedence over *
   doesn't fix that - it just gives another "wrong" result.

and Jay Belanger wrote:

   At any rate, setting calc-multiplication-has-precedence to nil should
   probably give equal precedence for aesthetic reasons; that's a trivial
   fix that I'll make this afternoon.

I guess I must be missing something obvious, but given
left-associativity, can you give me any example where giving /
precedence over * gives a different result than giving them equal
precedence (as opposed to merely using a different algorithm to
compute the same result, in which case I would guess that only the
relative speed of the two algorithms would matter).

Sincerely,

Luc.

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
...
> I guess I must be missing something obvious, but given
> left-associativity, can you give me any example where giving /
> precedence over * gives a different result than giving them equal
> precedence

I can't offhand; that's what I asked about.
However, people might be more comfortable seeing "equal precedence" in
the documentation, and it can change the display some:  
if division has precedence, "a*b/c" will display as "(a b)/c";
if they have equal precedence, "a*b/c" will display as "a b/c".

Jay

Re: Calc: `*' binds more strongly than `/'

[Kim F. Storm]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> ...
>> I guess I must be missing something obvious, but given
>> left-associativity, can you give me any example where giving /
>> precedence over * gives a different result than giving them equal
>> precedence
>
> I can't offhand; that's what I asked about.

I guess I was mistaken on that aspect -- because the doc string
indicated it would be different from "equal precedence".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Calc: `*' binds more strongly than `/'

[Luc Teirlinck]

Jay Belanger wrote:

   I can't offhand; that's what I asked about.

It can never make any difference in an expression containing only *
and /.

Indeed, what happens with equal precedence and left associativity in
an expression without parentheses containing only * and / is that any
`* a' (`/ a'. resp.) anywhere in the expression results in the final
result being bigger by (smaller by, resp.) a factor of a.  Giving /
higher precedence results in exactly the same.

Things do make a difference if a third "multiplicative type operator",
say mod, is involved.  If you give / and * equal precedence, then you
can be consistent and give these other ones exactly the same
precedence, and use left associativity (this is exactly what most
mathematical software I know of does with `mod', _unless_ they
_require_, as many do, explicit parentheses do disambiguate and throw
an error if these parentheses are missing).  But if you give / higher
precedence than *. then you have to decide which relative precedence
these other operators get.  Of course, that same problem occurs just
as much if you give * higher precedence than /, as Calc did up to know
and still does by default now (unless I misunderstood).

I do not know what preference Calc gives to mod, relative to / and *,
for either value of `calc-multiplication-has-precedence'.

Sincerely,

Luc.

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
...
> if you give * higher precedence than /, as Calc did up to know
> and still does by default now (unless I misunderstood).

That's right.

> I do not know what preference Calc gives to mod, relative to / and *,
> for either value of `calc-multiplication-has-precedence'.

In Calc, the precedence of the mod operator "%" is equal to that of
"/", and so is normally less than that of "*", but "%", "/" and "*"
all have equal precedence if `calc-multiplication-has-precedence' is
nil.  (Parentheses are still a good idea, of course, but not
required.)  Note that the mod operator "mod", which creates modulo
forms, is different than the mod operator "%", which computes
remainders.   10 mod 4 = 2 mod 4, and 10 % 4 = 2. "mod" has a much
higher precedence. 

Jay

Re: Calc: `*' binds more strongly than `/'

[Jay Belanger]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Stefan> After Emacs-22, we should probably just change the precedence to be the
> Stefan> "normal" one.
>
> No, not normal for mathemeticians (and me on a bad day), who expect A*B/C*D to
> be the same as (A*B)/(C*D).

Really?  If I saw A*B/C*D, the main thing I'd be thinking is "Gee, I
wish parentheses were put in."  

> I suggest it not be changed.  It will break old code (Calc has been around for
> almost two decades), it's a minor thing, and people have eventually stumbled
> on it, and it's well (over?) documented.

Is there any old code that relies on the current order of operations?

I just tried out 2*3/4*5 on a TI-86 and HP48; they both gave me 7.5.
I don't have a TI myself, so I used a student's.  There were several
grad students around, most of whom will eventually teach high school.
When I asked them what "2*3/4*5" should mean, I had a hard time getting an
answer.  They kept saying "You're missing parentheses" or "what are
you trying to write?"; when I finally asked how they would interpret
it if they saw it on a paper, one student said "I'd write 'minus one,
bad notation'".  I think she's right.
Traditionally, I think * and / are supposed to have identical
precedence, and when mixed should be performed left to right.  But
I think writing A*B/C*D when you mean A*(B/C)*D is poor notation.  I
also think writing A*B/C*D when you mean (A*B)/(C*D) is poor notation,
but a couple of people have said that it's a convenient shortcut that
saves the trouble of typing in parentheses.  So perhaps there's
something to be said for the current behavior.

Jay

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Hello Jay and others,

thanks for discussing this.

Jay Belanger <belanger@truman.edu> writes:

[...]

> Really?  If I saw A*B/C*D, the main thing I'd be thinking is "Gee, I
> wish parentheses were put in."  

You write `saw' here, I'll come back to that later...

[...]

> I just tried out 2*3/4*5 on a TI-86 and HP48; they both gave me 7.5.

So does my Casio fx-115, and so did my previous Casio bought around
1990.

> I don't have a TI myself, so I used a student's. There were several
> grad students around, most of whom will eventually teach high
> school. When I asked them what "2*3/4*5" should mean, I had a hard
> time getting an answer. They kept saying "You're missing
> parentheses" or "what are you trying to write?"

I think you found a very good example: it's about what one /writes/
and /sees/ on paper and, on the other hand, what one /types/ on a
pocket calculator (or in a spreadsheet). Writing 2*3/4*5 might be
unclear when written on paper, but that is exactly what I'd _type_ in
the calculator when I write/see on paper

2 * 3
----- * 5
  4

and when I write on paper

2 * 3
-----
4 * 5

I _know_ I have to enter it as 2*3/(4*5), because my Casio and your HP
and the TIs (and OpenOffice.org's spreadsheet...) evaluate from left
to right. M-x quick-calc is made for such small calculations, but »M-x
quick-calc RET 2*3/4*5 RET« gives

Result: 2 3 / 4 5 => 0.3

which, interestingly, skips the `*' and thus looks exactly like what
Stefan called the `juxtaposition notation':

,----
| Your point is valid when you use the juxtaposition notation rather
| than *: A B / C D is indeed (A*B)/(C*D).
`----

So does quick-calc try to give a hint here to the user what it has
done by omitting the `*'? I'm not sure I would understand that hint.

> But I think writing A*B/C*D when you mean A*(B/C)*D is poor
> notation.

Writing on paper, yes, but typing it in a pocket calculator, it is
okay. I'm not sure how I'd write it in a spreadsheet program, for
legibility reasons. But if I'd encounter it in someone else's code I
knew how to `parse' it, from left to right. And so do the spreadsheet
programs. And that is the heavy argument in my opinion: spreadsheets
treat * and / equal and evaluate from left to right.

> I also think writing A*B/C*D when you mean (A*B)/(C*D) is poor
> notation, but a couple of people have said that it's a convenient
> shortcut that saves the trouble of typing in parentheses.

But then I say that writing A/B*C and interpreting it like (A/B)*C
saves me the trouble of typing in parentheses and moreover, Calc would
behave like the OpenOffice.org spreadsheet, Gnumeric, Excel, MATLAB,
... simply the things most people nowadays are used too.

I didn't know that Calc has been around for a long time. I'm just
curious how both `sides' could get their favourite behaviour (after
the release): you mentioned that this could be made configurable --
what should be the default behaviour then? Compatibility with the old
behaviour, or `behave as spreadsheets do'? I guess for safety reasons
it should be compatibility ...

Regards,

Christian Schlauer

Re: Calc: `*' binds more strongly than `/'

[Daniel Brockman]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

> But then I say that writing A/B*C and interpreting it like (A/B)*C
> saves me the trouble of typing in parentheses

Not really.  You could just type that as A*C/B.

The point is that the reduced precedence of `/' allows you
to always put all numerator factors before the slash and all
denominator factors after it, which is often very convenient.

(You could make the same argument for `+' and `-' --- i.e.,
that `A-B+C' should mean `A-(B+C)'.  However, this is not as
natural because one usually does not think of sums as units.
Writing `A-B-C' is completely natural, but `A/B/C' is not
completely natural --- in fact, it is a little confusing.)

I think this is good notation, but I also think that it
would be a good idea to warn the user and make sure that
they know what they are doing when entering such things.

Just make the warning easy to disable and all is well?

Those are my two cents.

-- 
Daniel Brockman <daniel@brockman.se>

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

Daniel Brockman <daniel@brockman.se> writes:

> Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:
>
>> But then I say that writing A/B*C and interpreting it like (A/B)*C
>> saves me the trouble of typing in parentheses
>
> Not really.  You could just type that as A*C/B.

Yes. But I don't have to think about such things /at all/ in /all
other programs/ I use, because they use the common syntax, and I don't
see the benefit of Emacs having its own rules.

> The point is that the reduced precedence of `/' allows you
> to always put all numerator factors before the slash and all
> denominator factors after it, which is often very convenient.

Your convenient behaviour does neither work in Excel, OpenOffice.org
spreadsheet, or MATLAB, nor on a TI, HP or Casio pocket calculator.
What do you win with that convenient behaviour compared to that it
confuses people that also use other, more common spreadsheets (or
MATLAB) besides Emacs? /They/ can get wrong results. You safe some
keystrokes.

> (You could make the same argument for `+' and `-' --- i.e.,
> that `A-B+C' should mean `A-(B+C)'.  However, this is not as
> natural because one usually does not think of sums as units.
> Writing `A-B-C' is completely natural, but `A/B/C' is not
> completely natural --- in fact, it is a little confusing.)

Here I don't follow you -- except for that you can write `A/B/C' in
Calc or any other software, and you will get the same result
*everywhere*, even in Calc. (But I wouldn't write it that way either.)

> I think this is good notation, but I also think that it
> would be a good idea to warn the user and make sure that
> they know what they are doing when entering such things.

I fully agree with Stefan:

,----
| In any case, I still haven't heard any concrete reason why the
| non-standard behavior of calc is preferred to the more common
| behavior. Neither is perfect because there is no such thing, but one
| of them is sufficiently surprising to deserve big warnings in the
| Calc doc and the Org doc, whereas the other would be "business as
| usual".
`----

Regards,

Christian

Re: Calc: `*' binds more strongly than `/'

[Daniel Brockman]

Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

> I don't have to think about such things /at all/ in /all
> other programs/ I use, because they use the common syntax,
> and I don't see the benefit of Emacs having its own rules.

Well, Emacs is better than all other programs in _many_ ways. :-)

> What do you win with that convenient behaviour compared to that it
> confuses people that also use other, more common spreadsheets [...]?

Apart from saving keystrokes, we'll provide good notation
that lets users type mathematical expressions involving
fractions more like the way they normally think about them.

There is a reason why mathematicians write

                            A B
                            ---
                            C D

instead of

                         A B / (C D).

Stefan's suggestion that `A / B C' and `A / B * C' mean
different things is interesting, however.

>> (You could make the same argument for `+' and `-' --- i.e.,
>> that `A-B+C' should mean `A-(B+C)'.  However, this is not as
>> natural because one usually does not think of sums as units.
>> Writing `A-B-C' is completely natural, but `A/B/C' is not
>> completely natural --- in fact, it is a little confusing.)
>
> Here I don't follow you -- except for that you can write `A/B/C' in
> Calc or any other software, and you will get the same result
> *everywhere*, even in Calc. (But I wouldn't write it that way either.)

I was just pointing out that `/' and `-' are different beasts
(anticipating an argument that they should work analoguously).

>> I think this is good notation, but I also think that it
>> would be a good idea to warn the user and make sure that
>> they know what they are doing when entering such things.
>
> I fully agree with Stefan:
>
> | In any case, I still haven't heard any concrete reason
> | why the non-standard behavior of calc is preferred to
> | the more common behavior.

I have presented at least one concrete reason.  (See above.)

> | Neither is perfect because there is no such thing,

There is such a thing as `better', though.

> | but one of them is sufficiently surprising to deserve
> | big warnings in the Calc doc and the Org doc, whereas
> | the other would be "business as usual".

Granted.

I think the feature is worth the warnings.

-- 
Daniel Brockman <daniel@brockman.se>

RE: Calc: `*' binds more strongly than `/'

[Drew Adams]

I really have not followed this thread, but, viewed from 3000 m, it sounds
as if different people have different preferences. Couldn't Emacs just offer
a few precedence options, so users could choose the behavior they want?
(Then, of course, you could argue over the default value ;-).)

Re: Calc: `*' binds more strongly than `/'

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> I really have not followed this thread, but, viewed from 3000 m, it
> sounds as if different people have different preferences. Couldn't
> Emacs just offer a few precedence options, so users could choose the
> behavior they want?  (Then, of course, you could argue over the
> default value ;-).)

Personal preference options for a _language_ don't make much sense.
They would keep programs from working everywhere.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Calc: `*' binds more strongly than `/'

[Drew Adams]

> > I really have not followed this thread, but, viewed from 3000 m, it
> > sounds as if different people have different preferences. Couldn't
> > Emacs just offer a few precedence options, so users could choose the
> > behavior they want?  (Then, of course, you could argue over the
> > default value ;-).)
>
> Personal preference options for a _language_ don't make much sense.
> They would keep programs from working everywhere.

Well, I won't argue - as I said, I haven't followed the discussion closely.

But I did think this was about preferences for entering (typing) arithmetic
expressions. I see no reason that a calculator couldn't let users choose
different precedence rules for entering expressions, or even let users
switch between infix and reverse Polish notation, or,... I wouldn't be
surprised if some calculators let you do that, but I'm no expert on this.

Re: Calc: `*' binds more strongly than `/'

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > I really have not followed this thread, but, viewed from 3000 m, it
>> > sounds as if different people have different preferences. Couldn't
>> > Emacs just offer a few precedence options, so users could choose the
>> > behavior they want?  (Then, of course, you could argue over the
>> > default value ;-).)
>>
>> Personal preference options for a _language_ don't make much sense.
>> They would keep programs from working everywhere.
>
> Well, I won't argue - as I said, I haven't followed the discussion
> closely.
>
> But I did think this was about preferences for entering (typing)
> arithmetic expressions. I see no reason that a calculator couldn't
> let users choose different precedence rules for entering
> expressions, or even let users switch between infix and reverse
> Polish notation, or,... I wouldn't be surprised if some calculators
> let you do that, but I'm no expert on this.

Calc has a large variety of import and export languages including most
computer languages, of course respecting the respective precedences.

But it also has its own, internal expression syntax.

Have you actually ever used calc yourself?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Calc: `*' binds more strongly than `/'

[Richard Stallman]

    I added a strong note to the calc manual, in the tutorial section on
    algebraic entry, about this point.  (There are already multiple other
    places in the Calc manual that re-iterate this).

Thanks.

Re: Calc: `*' binds more strongly than `/'

[Randal L. Schwartz]

>>>>> "Christian" == Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> writes:

Christian> I believe (but I do not know) that Calc's behaviour is (too) far from
Christian> what `ordinary' people (like me ;-) would expect: I ran into this
Christian> feature in my first table and wondered what was going on. I thought
Christian> that Org-mode calculates `wrong'.

You mean from what *programmers* think.  Keep in mind that Calc was designed
by a mathematician, and it's much more natural in math to have * have higher
precedence than /.  There's no promise that the order of operations is like
programmer-think.  I got used to it quite quickly when I was playing with Calc
during its initial development.

I suggest it not be changed.  It will break old code (Calc has been around for
almost two decades), it's a minor thing, and people have eventually stumbled
on it, and it's well (over?) documented.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Calc: `*' binds more strongly than `/'

[Christian Schlauer]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Christian" == Christian Schlauer
>>>>>> <cs-muelleimer-rubbish.bin@arcor.de> writes:
>
> Christian> I believe (but I do not know) that Calc's behaviour is
> Christian> (too) far from what `ordinary' people (like me ;-) would
> Christian> expect: I ran into this feature in my first table and
> Christian> wondered what was going on. I thought that Org-mode
> Christian> calculates `wrong'.
>
> You mean from what *programmers* think. Keep in mind that Calc was
> designed by a mathematician, and it's much more natural in math to
> have * have higher precedence than /. There's no promise that the
> order of operations is like programmer-think. I got used to it quite
> quickly when I was playing with Calc during its initial development.

Hm. I'm an engineer, not a programmer ;-) I can only say that Calc
seems to be a fantastic tool, especially when one is on a computer
where the `heaviest' math tool installed is some spreadsheet.

But I wouldn't recommend it to an engineer as it doesn't work in the
way I (and spreadsheet-users) am used to, that is left-to-right
evaluation in absence of parentheses.

I didn't think that my expectation of the order of operations is like
programmers think. I learned in school that when I write on paper

2 * 3
-----
4 * 5

I have to enter it in my pocket calculator (Casio) as 2*3/(4*5), and
it seems that Jay found the same behaviour with other brands. So it
starts with the school kids, not with programmers.

> I suggest it not be changed. It will break old code (Calc has been
> around for almost two decades)

That's the risk. I'm surprised: am I the first one to complain about
this feature? In 20 years? But then, Calc hasn't been bundled with
Emacs until now.

> it's a minor thing

I don't agree. When I write a formula for a table in Org-mode, I
always have to check it carefully as Calc does not work like Gnumeric,
Openoffice's spreadsheet, MATLAB, Excel, ... I simply have a bad
feeling when typing the formula due to this feature and the fact that
it makes using Calc more error-prone for me (and for all those
familiar with the spreadsheet programs mentioned before).

> and people have eventually stumbled on it, and it's well (over?)
> documented.

It is well-documented, but it is an unnecessary trap, IMO.

Regards,

Christian Schlauer