From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jay Belanger Newsgroups: gmane.emacs.bugs Subject: bug#10554: 24.0.92; No units specified (dimensionless quantities in Emacs Calc) Date: Fri, 20 Jan 2012 10:48:39 -0600 Message-ID: <8739bajp5k.fsf@gmail.com> 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> Reply-To: jay.p.belanger@gmail.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327078203 3902 80.91.229.12 (20 Jan 2012 16:50:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2012 16:50:03 +0000 (UTC) Cc: 10554@debbugs.gnu.org To: "Roland Winkler" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 20 17:49:59 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 1RoHf4-0008RK-N7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Jan 2012 17:49:58 +0100 Original-Received: from localhost ([::1]:39729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoHf4-0007yB-9m for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Jan 2012 11:49:58 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:56658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoHew-0007y0-PJ for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 11:49:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoHeq-0008Qn-UE for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 11:49:50 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoHeq-0008Qj-Nb for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 11:49:44 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RoHg6-0004c6-KW for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 11:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jay Belanger Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Jan 2012 16:51: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.132707822117673 (code B ref 10554); Fri, 20 Jan 2012 16:51:02 +0000 Original-Received: (at 10554) by debbugs.gnu.org; 20 Jan 2012 16:50:21 +0000 Original-Received: from localhost ([127.0.0.1]:36876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoHfQ-0004ax-LR for submit@debbugs.gnu.org; Fri, 20 Jan 2012 11:50:21 -0500 Original-Received: from mail-yw0-f44.google.com ([209.85.213.44]:48195) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoHfK-0004ak-Kt for 10554@debbugs.gnu.org; Fri, 20 Jan 2012 11:50:18 -0500 Original-Received: by yhnn12 with SMTP id n12so312666yhn.3 for <10554@debbugs.gnu.org>; Fri, 20 Jan 2012 08:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:reply-to:cc:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=SGkxlTno3ORwh0p/BNFNBXVTnQluBVoEYe9JBW+27Cs=; b=meUZoK32Bj+CuOvRMdIwW1rTKh7/ozp1qpxFKmk+A0Xl1nN/szwXdXDVduxNCnSnKL 7+z/QZGMylOuHkWbC6daB9w067Fxljr16Q6wEQQazFaoB3EjWZkSFNvRJUgd+HiPuew+ xTmJytrgedxb0jogpFILFFyjqVol4hdseBLe8= Original-Received: by 10.236.76.201 with SMTP id b49mr47708055yhe.11.1327078136045; Fri, 20 Jan 2012 08:48:56 -0800 (PST) Original-Received: from belanger-home (184-155-95-203.cpe.cableone.net. [184.155.95.203]) by mx.google.com with ESMTPS id j16sm9515176anm.9.2012.01.20.08.48.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 08:48:55 -0800 (PST) In-Reply-To: <20249.10002.733142.491623@gargle.gargle.HOWL> (Roland Winkler's message of "Fri, 20 Jan 2012 02:34:26 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) 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:55872 Archived-At: > I would always consider the concept of "converting part of a units > expression" to be not the main rule to follow here, If 45 mi/hr is on the stack, and "u c" is called with new units km, what should happen? > but the exception if nothing else works because it is, in general, not > unique which unit should be used for the remainder, if one converts, > say, pc^2 into gal. If volume is converted to volume, there should be no remainder. > On the other hand, if an expression can be converted to a > dimensionless number, this involves no ambiguity. But what if you ask Calc to convert a units expression into a dimensionless number when it can't be so converted? Using a system name ("si", "cgs", etc.) as an output unit, as you did before, solves this problem. If the expression is dimensionless, then all units will cancel out. If the expression is not unitless, then any left over units will be given in the requested unit system. >> I suppose you mean /try/ to obtain a dimensionless number. >> Calc could have a command that will convert an expression to a >> dimensionless number, if possible, or leave it unchanged, if it cannot >> be converted to a dimensionless number. I'm not sure that "u c" should >> do such branching, but then I'm not sure this behavior is what you >> meant. > > I assume that currently "u c" needs to branch already if this > command needs to perform a partial conversion in the sense discussed > above. Perhaps I used the wrong word when I said "branch", I meant that Calc would have to look at the result it computes, and then decide whether to return that or return the original expression. Currently Calc doesn't do anything like that when it converts units. > Calc already defines the dimensionless fine structure constant alpha > as a unit. If one has the expression "7 eV / J", one can convert it > to alphas via "u c alpha". Yet if one first simplifies this with > "u s", one just gets a dimensionless number 1.21e-18. This number > cannot be converted anymore to alphas because Calc is missing an old > unit. If you try to convert it to alpha, you can use "1" as a default old unit and you can give it "alpha" as a new unit. (Since "1" can't be used as an output unit, it isn't obvious that it can be used an an input unit. Perhaps that's what this discussion is about.) > This illustrates to me once more that it would be most natural to > interpret dimensionless numbers as quantities that have the unit > "1", though this unit is not spelled out explicitly. That makes sense, and is what happens when you use "1" as the old (input) unit when converting a plain number to alphas. The problem with using "1" as a new (output) unit is that to be consistent with how it treats other units, choosing an output unit of "1" should be a no-op. Going back to converting 45 mi/hr with new units "km", what currently happens is that (mi/hr)/km is converted to 1.609344 / hr, so the result of the entire conversion will be 45*(1.609344 / hr)*km. If instead the new units are "1", then all that will happen is the expression on the stack will be divided by 1 and multiplied by 1. It doesn't seem to me that the dimensionless unit "1" should be handled differently than other units. (Granted, currently an output unit of 1 does give an error, but since it would be a no-op I doubt the user intended to give it anyhow.) > Then plain numbers can be converted to alphas without problem. If, > on the other hand, one wanted to convert a plain number to some > "dimensional unit" like "m", the concept of partial conversion > implies that the expression remains unchanged because we would get > something like "m / m". Note that conversion of "7 alpha" to "m" > already gives the dimensionless number 0.051. Right. That's how it currently works, and plain numbers can be converted to alphas. Jay