bug#10554: 24.0.92; No units specified (dimensionless quantities in Emacs Calc)

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

On Fri Jan 20 2012 Jay Belanger wrote:
> >     - if the old expression has units that cancel completely (e.g.,
> >       as in my orginal bug report) or it has a unit like "alpha",
> >       one can specify "1" as the new unit and the unit conversion
> >       returns a plain number.
> 
> If the "error if the units don't match" option is chosen, I would think
> this would naturally be the default.  If partial conversions are
> allowed, I don't think "1" as a unit should trigger an error, but I
> think it should still be a no-op.

If the old expression was "7 in / m" and the new unit is "1", this
should be converted to 0.178, 

- This is already the answer we get from calc-simplify-units.

- For an explicitly defined new trivial unit "one" (see below),
  conversion of "7 in / m" to "one" already gives "0.178 one".

  (A purist might even argue that something like "0.178 one" should
  be the answer to be returned by calc-simplify-units.)

So this is all quite consistent.

This has nothing to do with the value of a new user option
calc-need-matching-units.

> >       (Yes, I am irritated if calc-convert-units asks me about the
> >       old unit if there is just a plain number on the stack. So
> >       backward compatibility would probably require a variable such
> >       as calc-treat-numbers-as-dimensional, bound to nil by
> >       default.)
> 
> An option might be reasonable, with the current behavior the default.
> But this would only be useful when changing a number to a dimensionless
> quantity, like alpha, it seems.

No, I don't see a need to further distiguish here, see below my
discussion of an explicitly defined trivial unit "one". If the old
expression is just a plain number, Calc should do the same thing it
is doing currently if the old expression is given the unit "one"
instead. In that sense, I am essentially requesting that these cases
should be handled more consistently.

> > (2) The old expression is not dimensionless such as "7 m", the new
> >     unit is "1". Here I suggest that partial conversion means to
> >     return the old expression without any unit conversion.
> 
> Basically the current behavior (without the error).  But with the "need 
> matching units", this should give an error.

Exactly.

> > (3) The old expression is a dimensionless number, the requested new
> >     unit is something like "m":
> >
> >     Here I suggest to just return the old expression unmodified
> 
> Unless the "need matching units" option is chosen, in which case this
> would give an error.

Exactly.

Everything I am suggesting here is consistent / equivalent with the
existing behavior of Calc for complete or partial conversion of
units, independent of the value of a new user option
calc-need-matching-units, in the following way:

We can define a trivial unit

(add-to-list 'math-additional-units '(one "1" "One"))

So every plain, dimensionless number in Calc can be converted to
ones. "7" becomes "7 one", in much the same way "7" becomes "960
alpha". Then the exisiting Calc code is already properly converting
"7 one" to other units, both completely or partially. Likewise,
"one" can be choosen as a new unit of an expression with whatever
units.

So I suggest:

  Calc should interpret dimensionless numbers such as "7" equivalent
  to "7 one" without the need to explicitly make this trivial
  conversion in either direction.

  In other words, "one" becomes an "invisible" unit for dimensionless
  numbers.

That means:

- If Calc finds a dimensionless number "7" on the stack, for unit
  conversions it gets interpreted as "7 one"

- The string "1" should consistently become a valid short-hand
  notation for specifying the invisible unit "one" when calling
  something like calc-convert-units.

If such a behavior gets implemented it immediately covers the cases
(1) - (3) in my previous email including all their subcases. 

- There is no ambiguity in this concept.

- It is fully consistent with Calc's current treatment of an explcit
  definition of the trivial unit "one".

All this has nothing to do with what value is chosen for a user
option calc-need-matching-units. Just use again the behavior one may
expect in either case for an explicitly defined unit "one".

As discussed already, backward compatibility will require a user
variable calc-treat-numbers-as-dimensional, bound to nil by default.
There might be other situations where the requested treatment of
dimensionless numbers implies a deviation from the current behavior
so that this might require another user option.

However all in all, these changes will make the treatment of units
more consistent within Calc and also more consistent with how units
are used elsewhere. (Though I have a physicist's perspective, I hope
that engineers and other disciplines will not disagree here.)

Roland