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: Fri, 20 Jan 2012 14:30:10 -0600 Message-ID: <20249.52946.931367.162775@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> 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 1327091482 17594 80.91.229.12 (20 Jan 2012 20:31:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2012 20:31:22 +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 Fri Jan 20 21:31:18 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 1RoL7F-0004ec-Mr for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Jan 2012 21:31:17 +0100 Original-Received: from localhost ([::1]:53842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoL7F-0000W7-4y for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Jan 2012 15:31:17 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoL6s-0000UP-Ki for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 15:31:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoL6i-0007dX-7w for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 15:30:54 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoL6h-0007dB-HH for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 15:30:43 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RoL7y-0003MB-2D for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 15:32: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: Fri, 20 Jan 2012 20:32: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.132709150512874 (code B ref 10554); Fri, 20 Jan 2012 20:32:02 +0000 Original-Received: (at 10554) by debbugs.gnu.org; 20 Jan 2012 20:31:45 +0000 Original-Received: from localhost ([127.0.0.1]:36995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoL7h-0003La-BT for submit@debbugs.gnu.org; Fri, 20 Jan 2012 15:31:45 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:59126) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoL7f-0003LS-GA for 10554@debbugs.gnu.org; Fri, 20 Jan 2012 15:31:44 -0500 Original-Received: from 82.red-80-32-229.staticip.rima-tde.net ([80.32.229.82]:50872 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RoL6M-0006T0-8z; Fri, 20 Jan 2012 15:30:24 -0500 In-Reply-To: <8739bab36p.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:55876 Archived-At: On Fri Jan 20 2012 Jay Belanger wrote: > > Here the user is posing a problem with no uniquely defined answer. > > The answer could be expressed in km/hr but also in km/s or in km eV/hbar. > > But what /should/ happen? Would you like an error signaled? Otherwise, > the current behavior is the most reasonable. I would, indeed, consider it quite OK if an error was signaled. Say, if there was an option calc-throw-error-if-units-mismatch, I'd bind it to t. > >> But what if you ask Calc to convert a units expression into a > >> dimensionless number when it can't be so converted? > > > > again: I'd give this scenario the lowest priority. > > I'm not sure what you mean by giving it low priority. Either it > happens or it doesn't, and Calc needs to do something if it > happens. I guess we can have the following scenarios that can be handled as follows: (1) If the old expression and the new unit have the same dimension, "1" should be treated like any other unit. So this means: - 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. - similarly: if the old expression is just a number (i.e., unit "1"), this can be converted to other dimensionless units such as "alpha" without being asked for the old unit. (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.) (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. (this would be quite consistent with how Calc already treats the case that the old expression is something like "7 m", and the new unit is "alpha".) (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 (again, this would be quite consistent with how Calc already treats the case that the old expression is something like "7 alpha", where conversion to any other unit gives a dimensionless number. Did I miss another possibility? If yes, I am sure that it has a reasonable solution, too. (Even if Calc handled dimensionless quantities this way, I would bind calc-throw-error-if-units-mismatch to t because in my work a unit mismatch between old and new means a mismatch between what I have and what I expect to get.) Roland