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 02:34:26 -0600 Message-ID: <20249.10002.733142.491623@gargle.gargle.HOWL> References: <8762g8i7s6.fsf@niu.edu> <87bopz5pt8.fsf@gmail.com> <20248.39483.716850.185512@gargle.gargle.HOWL> <87d3afdlfz.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 1327048499 27106 80.91.229.12 (20 Jan 2012 08:34:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Jan 2012 08:34:59 +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 09:34:55 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 1Ro9vz-00085o-1z for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Jan 2012 09:34:55 +0100 Original-Received: from localhost ([::1]:53481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro9vy-0002KO-IP for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Jan 2012 03:34:54 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:59050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro9vr-0002KF-Pi for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 03:34:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ro9vq-0005Ht-Id for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 03:34:47 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ro9vq-0005Ho-D3 for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 03:34:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Ro9x4-00070I-9U for bug-gnu-emacs@gnu.org; Fri, 20 Jan 2012 03:36: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 08:36: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.132704855026897 (code B ref 10554); Fri, 20 Jan 2012 08:36:02 +0000 Original-Received: (at 10554) by debbugs.gnu.org; 20 Jan 2012 08:35:50 +0000 Original-Received: from localhost ([127.0.0.1]:36125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro9ws-0006zl-Bp for submit@debbugs.gnu.org; Fri, 20 Jan 2012 03:35:50 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:46315) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro9wq-0006zc-6M for 10554@debbugs.gnu.org; Fri, 20 Jan 2012 03:35:49 -0500 Original-Received: from u010774.lc.ehu.es ([158.227.8.163]:35384 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1Ro9va-0004gd-Pt; Fri, 20 Jan 2012 03:34:31 -0500 In-Reply-To: <87d3afdlfz.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:55868 Archived-At: On Thu Jan 19 2012 Jay Belanger wrote: > >>From a different perspective, I'd say that "dimensionless" is as > > valid a unit as "kg" or "hbar / c". In that sense I'd say that there > > should be a possibility to pass this unit "dimensionless" as an arg > > to calc-convert-units, similar to any other unit that this function > > should use for its final result. > > Currently, if Calc is asked to convert part of a units expression, it > will leave any unrequested units unchanged; for example, if 45 mi/hr is > on the stack and the units conversion is called with new units m, then > only the mi will be changed; 45 mi/hr will be converted to 72420.48 m / > hr. To be consistent, I would think that converting to new units 1, all > of the units in the stack expression would be left alone. ...This might depend on whom you ask :-) I am speaking from a physics point of view. Other people might look at this from a different perspective. I would always consider the concept of "converting part of a units expression" to be not the main rule to follow here, 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. On the other hand, if an expression can be converted to a dimensionless number, this involves no ambiguity. Also, I'd say that in real life one usually knows which unit an expression has. > > I'd say that "1" appears to be a natural choice in order to express > > the fact that Calc should obtain a dimensionless number. > > 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. I would consider this branch the last resort. If Calc discovers earlier that an expression can be interpreted as a dimensionless number, it should do that conversion if the user requested the unit "1". I just discovered what I would likewise consider an inconsistency in the current handling of 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. However, the result of a calculation should, of course, be independent of whether the intermediate simplification is done or not. 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. 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. (Alternatively, such a partial conversion could explicitly give the unit "m / m", similar to when we have "3 m" and "4 m", and we divide one by the other, then Calc does not simplify that automatically, but instead we get "0.75 m / m". But such a strategy would become rather confusing if we converted to more complicated units like "kg m^2 / s" thus giving "kg m^2 s / s m^2 kg".) I am confident that most physicists will agree on this. Roland