bug#13580: 24.2.92; regression in calc-convert-units

["Roland Winkler" <winkler@gnu.org>]

On Fri Feb 8 2013 Eli Zaretskii wrote:
> > > He is talking about this (see
> > > http://en.wikipedia.org/wiki/Dimensionless_quantity):
> > 
> > I've indicated that I know what dimensionless means
> 
> Sorry about that.  I wanted to make sure everyone is on the same page
> in this regard.

This wikipedia page is about "dimensionless quantities", and that's
very different from dimensionless units. Distance, mass, energy,
they can all be expressed in dimensionless units. Such dimensionless
units are used all the time in physics. Strangely, I can give you
zillions of references in (more advanced) textbooks that use them.
But nobody bothers to explain this concept in general terms.

> I'd rather hope that Roland will suggest the alternative behavior he
> would like to see instead.

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"

The above is a very consistent scheme as it corresponds to equality
transformations: if previously the left-hand-side of one of these
equations was on the Calc stack, it gets replaced by an "equal"
expression, very similar to

  10 = 8#12 = 16#A

Equations (3) and (4) correspond to "dimensionless" expressions: we
do have units (which do NOT cancel), but the dimensions of these
units cancel on each side of these equations. (The dimension of "m"
is "length", for "s" it is "time", for "mph" it is "velocity".) But
conceptually there is really no difference between Eqs. (1) - (4).

Now where is the problem?

- (1) and (2) are fine with old (GNU Emacs 23) and more recent
  (24.2.93 and 24.3.50) versions of Emacs

- (3) is essentially fine with Emacs 23 ("1" is not recognized as
  new unit, but calc-convert-units requires that the new unit is
  specified as "si", which, I believe, in this case boils down to
  "simplify". - Not prefect, but ok. The final result is correct).

  With (3) and 24.2.93, calc-convert-units does not do anything,
  an annoying regression.

  With (3) and 24.3.50, calc-convert-units requests an "old unit",
  which can be something like "kg". 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. It is like having a command for converting
  octal numbers into decimal numbers, which, during the conversion,
  also get multiplied by some factor 42.

  I just noticed: With (3) and old unit chosen as "kg",
  calc-convert-units offers as default for the new unit again "kg".
  Accepting this default gives "0.44704" (dimensionless).
  Here I do not understand the rationale either.

- (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. [In my own work, a
  conversion of type (4) rarely comes up, so it has been less
  annoying for me that it is not properly implemented. Still it is
  inconsistent.]

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. 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. But
there should be a Calc option to disable this, thus implementing a
conversion algorithm that is consistently based on proper
equalities. Please, trust the user she knows what she wants when
performing conversions (1) - (4).

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. Most often, the problem was really a
typo earlier in the calculation that can be detected by a warning
about inconsistent dimensions.

Roland