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: Re: Calc: `*' binds more strongly than `/' Date: Thu, 26 Apr 2007 23:07:45 +0200 Message-ID: References: <87y7kvxj6p.fsf@arcor.de> <87odlrkn74.fsf@truman.edu> <87tzvhcul9.fsf@stupidchicken.com> <863b2z2mma.fsf@blue.stonehenge.com> <55350.128.165.123.18.1176926533.squirrel@webmail.lanl.gov> <86ps5zuwmi.fsf@blue.stonehenge.com> <87ps5zi1h2.fsf@truman.edu> <462C8EA2.9090003@gnu.org> <87ejmbdr1x.fsf@truman.edu> <87d51sqinn.fsf@gmail.com> 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 1177622137 13633 80.91.229.12 (26 Apr 2007 21:15:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 Apr 2007 21:15:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 26 23:15:35 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 1HhBJJ-00039q-Hm for ged-emacs-devel@m.gmane.org; Thu, 26 Apr 2007 23:15:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HhBP4-0004N8-Lr for ged-emacs-devel@m.gmane.org; Thu, 26 Apr 2007 17:21:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HhBOp-0004I2-9w for emacs-devel@gnu.org; Thu, 26 Apr 2007 17:21:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HhBOn-0004GB-OO for emacs-devel@gnu.org; Thu, 26 Apr 2007 17:21:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HhBOn-0004G7-Ft for emacs-devel@gnu.org; Thu, 26 Apr 2007 17:21:09 -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 1HhBIz-0005BT-7q for emacs-devel@gnu.org; Thu, 26 Apr 2007 17:15:10 -0400 Original-Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HhBIs-0005cX-4U for emacs-devel@gnu.org; Thu, 26 Apr 2007 23:15:02 +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 ; Thu, 26 Apr 2007 23:15:02 +0200 Original-Received: from cs-usenet by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Apr 2007 23:15:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 110 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.98 (gnu/linux) 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:70208 Archived-At: Jay Belanger writes: > Christian Schlauer 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 >> : > > 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, 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