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: Fri, 08 Feb 2013 08:30:43 -0600 Message-ID: <87k3qi514c.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> 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 1360333934 11117 80.91.229.3 (8 Feb 2013 14:32:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Feb 2013 14:32:14 +0000 (UTC) Cc: 13580@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 08 15:32:34 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 1U3p0A-0006y8-ED for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Feb 2013 15:32:30 +0100 Original-Received: from localhost ([::1]:51585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3ozr-0008Dn-9i for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Feb 2013 09:32:11 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3ozo-0008DS-5h for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2013 09:32:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3ozj-0005mb-96 for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2013 09:32:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3ozj-0005mP-4z for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2013 09:32:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U3ozk-0007qK-Dj for bug-gnu-emacs@gnu.org; Fri, 08 Feb 2013 09:32:05 -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, 08 Feb 2013 14:32: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.136033387730094 (code B ref 13580); Fri, 08 Feb 2013 14:32:02 +0000 Original-Received: (at 13580) by debbugs.gnu.org; 8 Feb 2013 14:31:17 +0000 Original-Received: from localhost ([127.0.0.1]:43150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U3oyx-0007pK-Jl for submit@debbugs.gnu.org; Fri, 08 Feb 2013 09:31:16 -0500 Original-Received: from mail-ob0-f178.google.com ([209.85.214.178]:58596) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U3oyj-0007oo-7K for 13580@debbugs.gnu.org; Fri, 08 Feb 2013 09:31:09 -0500 Original-Received: by mail-ob0-f178.google.com with SMTP id wd20so3976846obb.9 for <13580@debbugs.gnu.org>; Fri, 08 Feb 2013 06:30:57 -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=vtEanh10mnwKxkVAzoI/u8pCBSLaeCWZ+keuGPoXzrY=; b=XFDM/IegkTPrpPihFr9XYj0m1Wl+k/d09VCnTexO2b8MXZa0qjZETuNQrmh+xyBtxd zugJu0X/MARz5lDZx1C1RUphfnsfhtXBVWZ/kySO971pckH0QC0DuXkwX7lC4pzP9asN QlFo7DmW443qU0uFL2SICsvvJA4H8z+mZso2Ty/14DOoUb0drWOl6fgxQ+ck0XOTiCeN YhiExnUGyGzpOv6LNnBJoLZStQuI0kDQOV4dVBFxj9sxSYoE4FI8myOwkdp+cvkBhl9a cOa5qAJp62FjAbZGlT4ruotUQvVwH4aW6tKIAM+mAV6DfvKmY60Bswk0hboKfwggCTRa B09g== X-Received: by 10.60.171.230 with SMTP id ax6mr4141350oec.25.1360333856866; Fri, 08 Feb 2013 06:30:56 -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 el2sm37791811obc.9.2013.02.08.06.30.53 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 08 Feb 2013 06:30:54 -0800 (PST) In-Reply-To: <83haln8ars.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Feb 2013 10:33:59 +0200") 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:70883 Archived-At: >> I've been consistently talking about units, not dimensions; I have given >> no interpretation of "dimensions" vs "units". The expression above has >> no units when simplified; that's a pretty straightforward statement. > > He is talking about this (see > http://en.wikipedia.org/wiki/Dimensionless_quantity): I've indicated that I know what dimensionless means; I've been consistently talking about unitless because that's what calc-convert-units works with. Whether something is dimensionless or not is irrelevant to Calc. > Therefore, "dimensionless" and "unitless" is not the same, That's pretty much a direct quote of what I said before. > IOW, removing dimensions of an expression as part of simplifying it > might sometimes lose information. E.g., dividing the length of a > circular arc by its radius will give you m/m, but the natural units of > this are radians or degrees, not lack of units, and talking about > "unitless" in this case might make little sense to a user who _knows_ > she is computing an angle. Sure, but if a user asks Calc to work with m/m, the classic Calc behavior was for Calc to ask for a new unit, then basically ignore it and cancel the units. If the user put in "3 m/m", "New units: rad", the result would not be "3", not "3 rad". (Behind the scenes the new unit would be introduced but then disappear.) It ended up just simplifying the units. Asking for unused information seems like a bug. This was changed so that it wouldn't ask for the essentially unused information. Since Calc then acts without informing the user, I added information and allowed the user to treat the expression as unitless. That is the way I would like to use it. But it seems like there are two reasonable behaviors when the units cancel: (1) Simplify the expression. (The 24 branch behavior.) (2) Treat it like a unitless expression. (The trunk behavior.) Changing from the classic behavior to (1) was fixing a bug; when I heard a complaint about the lack of information that (1) provided, I changed to (2). Perhaps Calc should stick to (1), and let the user deal with the simplified expression. Or: What do you suggest?