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#13580: 24.2.92; regression in calc-convert-units Date: Sat, 09 Feb 2013 09:08:53 -0600 Message-ID: <876221zfqy.fsf@gmail.com> References: <87y5fdq72z.fsf@lukas.physics.niu.edu> <87y5fau50b.fsf@truman.edu> <20755.59013.344289.873545@gargle.gargle.HOWL> <87liazq4su.fsf@gmail.com> <20756.3431.129502.895875@gargle.gargle.HOWL> <87liazn9ir.fsf@gmail.com> <20756.5321.329711.746535@gargle.gargle.HOWL> <878v6z3k2p.fsf@gmail.com> <83haln8ars.fsf@gnu.org> <87k3qi514c.fsf@gmail.com> <834nhm97y9.fsf@gnu.org> <20757.55102.322862.769049@gargle.gargle.HOWL> Reply-To: jay.p.belanger@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360423111 5740 80.91.229.3 (9 Feb 2013 15:18:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Feb 2013 15:18:31 +0000 (UTC) Cc: 13580@debbugs.gnu.org To: "Roland Winkler" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 09 16:18:52 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U4CCa-0001Ow-1v for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Feb 2013 16:18:52 +0100 Original-Received: from localhost ([::1]:60074 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4CCG-0000Gq-Rr for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Feb 2013 10:18:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4CCD-0000Gj-M7 for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2013 10:18:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4CCC-0002mE-7G for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2013 10:18:29 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4C3t-00017j-De for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2013 10:09:53 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U4C42-0007aT-2E for bug-gnu-emacs@gnu.org; Sat, 09 Feb 2013 10:10: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: Sat, 09 Feb 2013 15:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13580 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13580-submit@debbugs.gnu.org id=B13580.136042256229112 (code B ref 13580); Sat, 09 Feb 2013 15:10:02 +0000 Original-Received: (at 13580) by debbugs.gnu.org; 9 Feb 2013 15:09:22 +0000 Original-Received: from localhost ([127.0.0.1]:46657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4C3M-0007ZV-TH for submit@debbugs.gnu.org; Sat, 09 Feb 2013 10:09:21 -0500 Original-Received: from mail-ob0-f177.google.com ([209.85.214.177]:37846) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U4C3J-0007ZM-8x for 13580@debbugs.gnu.org; Sat, 09 Feb 2013 10:09:19 -0500 Original-Received: by mail-ob0-f177.google.com with SMTP id wc18so4745639obb.8 for <13580@debbugs.gnu.org>; Sat, 09 Feb 2013 07:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:reply-to:cc:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=g/wbHTPPtqH0QBSJbpw3svWoetDVuC0gE0WjQmRoYiM=; b=AO93tluMlDvfEoY8M+1WdmDepyozDdIlfqJkTlbl2xQCZWYUdHw5W3fn74prIbWoJK 6TdCKtbGv4QohPGvSygHYBufept/R7PJHaMePkcWze0xwf5vbeFvhGwPxvuThqnjM9pH /OACTHkUmrKghBtK3rhnzE0HVuQVyeoaPLeYYHkFD33DXTeTRbsto0neVhn43+chZ7aI YrdZhJkKEmnlTeY7UXJBEE5OHkRKLlA74/teDVi09e0Xe9eAuX+lqevG1vpo7B4XyFmZ 4icA/kLf2aONSLtpDoZrzy1lpo70Xxf3CjeqnuoGn428JEKQtZB12+Uohx1nmJPdVwUc Fi9A== X-Received: by 10.60.172.237 with SMTP id bf13mr6911860oec.83.1360422547207; Sat, 09 Feb 2013 07:09:07 -0800 (PST) Original-Received: from belanger-home (184-155-88-117.cpe.cableone.net. [184.155.88.117]) by mx.google.com with ESMTPS id vs4sm41815307obb.14.2013.02.09.07.09.04 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 09 Feb 2013 07:09:05 -0800 (PST) In-Reply-To: <20757.55102.322862.769049@gargle.gargle.HOWL> (Roland Winkler's message of "Fri, 8 Feb 2013 22:57:34 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (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.x 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:70950 Archived-At: "Roland Winkler" writes: ... > Let's focus on what calc-convert-units should do (and mostly has > been doing previously): > > Consider the equality > > 1 mph = 0.44704 m / s (1) > > which we can read as a task for calc-convert-units: > > converting "1 mph" to the new unit "m / s" gives "0.44704 m / s" > > We can manipulate Eq. (1) in lots of ways so that it is once again > an equality that we can interpret as a different task for > calc-convert-units, for example > > 1 mph s = 0.44704 m (2) > converting "1 mph s" to the new unit "m" gives "0.44704 m" > > 1 mph s / m = 0.44704 (3) > converting "1 mph s / m" to the new unit "1" gives "0.44704" > > 1 = 0.44704 m / (s mph) (4) > converting "1" to the new unit "m/(s mph)" gives "0.44704" ... > Equations (3) and (4) correspond to "dimensionless" expressions: we > do have units (which do NOT cancel), The expression is unitless when simplified. mph s / m is equal to 0.44704, which has no units, and can easily be regarded as another way of writing 0.44704. The user can regard it either way. > - (1) and (2) are fine with old (GNU Emacs 23) and more recent > (24.2.93 and 24.3.50) versions of Emacs Okay. > With (3) and 24.3.50, calc-convert-units requests an "old unit", > which can be something like "kg". Right; as mentioned above, some might wish to interpret the expression as simply a number. Ignoring the "Old inputs:" (say, by hitting return) will bring about the GNU Emacs 23 behavior. I would think giving users the choice is good. > If the new unit is chosen as "si" (to keep things simple), > calc-convert-units returns "0.44704 kg". Clearly, the new expression > on the stack is not equal to the old expression on the stack before > calc-convert-units was cold. That's very irritating for a command > that is supposed to perform a conversion. This is also how emacs 23 works and has probably been around for a while; it isn't anything new. But I'll look into it. > I just noticed: With (3) and old unit chosen as "kg", > calc-convert-units offers as default for the new unit again "kg". That's when you do the same thing a second time, after the first time you (implicitly) said that you wanted your mass units in kg. The check to make sure that the new unit isn't the same as the old unit probably breaks because you the new units were previously given as "si" and not "kg" directly. I'll look into that. > - (4) fails with old and new versions of Emacs. If the old > expression has no units at all, calc-convert-units asks for an old > unit ("1"), then for a new unit ("m / (s mph)"), but then it > simply returns "1" without any conversion. The unit conversions does some simplifications, and 0.44704 m / (s mph) simplifies to 1. This is old behavior. > So what am I proposing for calc-convert-units? > > There should be a way to perform the conversions (1) - (4) as > described above such that each time the conversion corresponds to an > equality. The only one which doesn't work is (4), which has never worked. I'll look into it. > If some people like that in case (3) or (4) they can > specify an extra unit for the old expression on the stack instead of > dealing with dimensionless expressions, that's fine with me. Okay. The user can do it that way, or ignore the "Old unit:" part and get the classic behavior. Whatever the user wants. > Please, trust the user she knows what she wants when That's what happens. > In a Deluxe version of calc-convert-units, the user could also get > informed about the dimension of the original expression (length, > time, energy, etc.) so that she can choose the new unit accordingly. > There could also be a warning / error message if the dimension of > the old expression and the dimension of the new unit do not match. > I know that Calc has been able to work around such inconsistent > dimensions. However, I do not consider this a feature, but more a > source of errors in daily life. It's a way of trusting the user to do what she wants. But an option to at least check that the units match up was previously put in, at your request. Anyhow, the issues in the trunk are old issues which were previously unnoticed (or simply not reported), but should be taken care of. Thanks for pointing them out; I will work on them. Jay