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

[Jay Belanger]

>> 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?