From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Roland Winkler" Newsgroups: gmane.emacs.bugs Subject: bug#10554: 24.0.92; No units specified (dimensionless quantities in Emacs Calc) Date: Sat, 21 Jan 2012 03:24:42 -0600 Message-ID: <20250.33882.89017.12372@gargle.gargle.HOWL> References: <8762g8i7s6.fsf@niu.edu> <87bopz5pt8.fsf@gmail.com> <20248.39483.716850.185512@gargle.gargle.HOWL> <87d3afdlfz.fsf@gmail.com> <20249.10002.733142.491623@gargle.gargle.HOWL> <8739bajp5k.fsf@gmail.com> <20249.43656.150957.30947@gargle.gargle.HOWL> <8739bab36p.fsf@gmail.com> <20249.52946.931367.162775@gargle.gargle.HOWL> <87lip29jsn.fsf@gmail.com> <20249.58980.778477.37221@gargle.gargle.HOWL> <87r4yt9b6g.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1327137910 27398 80.91.229.12 (21 Jan 2012 09:25:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Jan 2012 09:25:10 +0000 (UTC) Cc: 10554@debbugs.gnu.org To: jay.p.belanger@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 21 10:25:06 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RoXC5-0001PR-Mn for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jan 2012 10:25:05 +0100 Original-Received: from localhost ([::1]:55992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoXC5-0001pn-4i for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jan 2012 04:25:05 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:54581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoXC2-0001ob-Hd for bug-gnu-emacs@gnu.org; Sat, 21 Jan 2012 04:25:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoXC1-0006OH-3l for bug-gnu-emacs@gnu.org; Sat, 21 Jan 2012 04:25:02 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoXC1-0006OD-0s for bug-gnu-emacs@gnu.org; Sat, 21 Jan 2012 04:25:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RoXC2-0003Y3-AU for bug-gnu-emacs@gnu.org; Sat, 21 Jan 2012 04:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Roland Winkler" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Jan 2012 09:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10554 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10554-submit@debbugs.gnu.org id=B10554.132713789613627 (code B ref 10554); Sat, 21 Jan 2012 09:25:02 +0000 Original-Received: (at 10554) by debbugs.gnu.org; 21 Jan 2012 09:24:56 +0000 Original-Received: from localhost ([127.0.0.1]:38142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoXBv-0003Xk-U3 for submit@debbugs.gnu.org; Sat, 21 Jan 2012 04:24:56 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:39354 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoXBs-0003Xa-Ua for 10554@debbugs.gnu.org; Sat, 21 Jan 2012 04:24:54 -0500 Original-Received: from 82.red-80-32-229.staticip.rima-tde.net ([80.32.229.82]:52370 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RoXBp-0003RU-4t; Sat, 21 Jan 2012 04:24:50 -0500 In-Reply-To: <87r4yt9b6g.fsf@gmail.com> X-Mailer: VM 8.2 trial under 24.0.92.1 (x86_64-unknown-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:55885 Archived-At: On Fri Jan 20 2012 Jay Belanger wrote: > > - if the old expression has units that cancel completely (e.g., > > as in my orginal bug report) or it has a unit like "alpha", > > one can specify "1" as the new unit and the unit conversion > > returns a plain number. > > If the "error if the units don't match" option is chosen, I would think > this would naturally be the default. If partial conversions are > allowed, I don't think "1" as a unit should trigger an error, but I > think it should still be a no-op. If the old expression was "7 in / m" and the new unit is "1", this should be converted to 0.178, - This is already the answer we get from calc-simplify-units. - For an explicitly defined new trivial unit "one" (see below), conversion of "7 in / m" to "one" already gives "0.178 one". (A purist might even argue that something like "0.178 one" should be the answer to be returned by calc-simplify-units.) So this is all quite consistent. This has nothing to do with the value of a new user option calc-need-matching-units. > > (Yes, I am irritated if calc-convert-units asks me about the > > old unit if there is just a plain number on the stack. So > > backward compatibility would probably require a variable such > > as calc-treat-numbers-as-dimensional, bound to nil by > > default.) > > An option might be reasonable, with the current behavior the default. > But this would only be useful when changing a number to a dimensionless > quantity, like alpha, it seems. No, I don't see a need to further distiguish here, see below my discussion of an explicitly defined trivial unit "one". If the old expression is just a plain number, Calc should do the same thing it is doing currently if the old expression is given the unit "one" instead. In that sense, I am essentially requesting that these cases should be handled more consistently. > > (2) The old expression is not dimensionless such as "7 m", the new > > unit is "1". Here I suggest that partial conversion means to > > return the old expression without any unit conversion. > > Basically the current behavior (without the error). But with the "need > matching units", this should give an error. Exactly. > > (3) The old expression is a dimensionless number, the requested new > > unit is something like "m": > > > > Here I suggest to just return the old expression unmodified > > Unless the "need matching units" option is chosen, in which case this > would give an error. Exactly. Everything I am suggesting here is consistent / equivalent with the existing behavior of Calc for complete or partial conversion of units, independent of the value of a new user option calc-need-matching-units, in the following way: We can define a trivial unit (add-to-list 'math-additional-units '(one "1" "One")) So every plain, dimensionless number in Calc can be converted to ones. "7" becomes "7 one", in much the same way "7" becomes "960 alpha". Then the exisiting Calc code is already properly converting "7 one" to other units, both completely or partially. Likewise, "one" can be choosen as a new unit of an expression with whatever units. So I suggest: Calc should interpret dimensionless numbers such as "7" equivalent to "7 one" without the need to explicitly make this trivial conversion in either direction. In other words, "one" becomes an "invisible" unit for dimensionless numbers. That means: - If Calc finds a dimensionless number "7" on the stack, for unit conversions it gets interpreted as "7 one" - The string "1" should consistently become a valid short-hand notation for specifying the invisible unit "one" when calling something like calc-convert-units. If such a behavior gets implemented it immediately covers the cases (1) - (3) in my previous email including all their subcases. - There is no ambiguity in this concept. - It is fully consistent with Calc's current treatment of an explcit definition of the trivial unit "one". All this has nothing to do with what value is chosen for a user option calc-need-matching-units. Just use again the behavior one may expect in either case for an explicitly defined unit "one". As discussed already, backward compatibility will require a user variable calc-treat-numbers-as-dimensional, bound to nil by default. There might be other situations where the requested treatment of dimensionless numbers implies a deviation from the current behavior so that this might require another user option. However all in all, these changes will make the treatment of units more consistent within Calc and also more consistent with how units are used elsewhere. (Though I have a physicist's perspective, I hope that engineers and other disciplines will not disagree here.) Roland