From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christian Schlauer Newsgroups: gmane.emacs.devel Subject: Calc: `*' binds more strongly than `/' Date: Sat, 14 Apr 2007 13:57:18 +0200 Message-ID: <87y7kvxj6p.fsf@arcor.de> Reply-To: cs-usenet@arcor.de NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1176551965 3708 80.91.229.12 (14 Apr 2007 11:59:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 Apr 2007 11:59:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 14 13:59:16 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HcguS-0002q7-8R for ged-emacs-devel@m.gmane.org; Sat, 14 Apr 2007 13:59:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hcgyp-00036t-Jo for ged-emacs-devel@m.gmane.org; Sat, 14 Apr 2007 08:03:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hcgxx-0001p9-KK for emacs-devel@gnu.org; Sat, 14 Apr 2007 08:02:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hcgxu-0001ki-4h for emacs-devel@gnu.org; Sat, 14 Apr 2007 08:02:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hcgxs-0001kB-OU for emacs-devel@gnu.org; Sat, 14 Apr 2007 08:02:49 -0400 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HcgtU-0006Dr-Er for emacs-devel@gnu.org; Sat, 14 Apr 2007 07:58:16 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HcgtL-0004aL-5A for emacs-devel@gnu.org; Sat, 14 Apr 2007 13:58:07 +0200 Original-Received: from finn.gmane.org ([80.91.229.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 13:58:07 +0200 Original-Received: from cs-usenet by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Apr 2007 13:58:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 128 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: finn.gmane.org User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux) Cancel-Lock: sha1:HgvbRz3lh8lgQ6vmBgcIg7faPyY= X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:69436 Archived-At: 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