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

[Jay Belanger <jay.p.belanger@gmail.com>]

"Roland Winkler" <winkler@gnu.org> 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