[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10554: 24.0.92; No units specified (dimensionless quantities in Emac

From: Roland Winkler
Subject: bug#10554: 24.0.92; No units specified (dimensionless quantities in Emacs Calc)
Date: Fri, 20 Jan 2012 02:34:26 -0600

On Thu Jan 19 2012 Jay Belanger wrote:
> >>From a different perspective, I'd say that "dimensionless" is as
> > valid a unit as "kg" or "hbar / c". In that sense I'd say that there
> > should be a possibility to pass this unit "dimensionless" as an arg
> > to calc-convert-units, similar to any other unit that this function
> > should use for its final result.
> Currently, if Calc is asked to convert part of a units expression, it
> will leave any unrequested units unchanged; for example, if 45 mi/hr is
> on the stack and the units conversion is called with new units m, then
> only the mi will be changed; 45 mi/hr will be converted to 72420.48 m /
> hr.  To be consistent, I would think that converting to new units 1, all
> of the units in the stack expression would be left alone.

...This might depend on whom you ask  :-)
I am speaking from a physics point of view. Other people might look
at this from a different perspective.

I would always consider the concept of "converting part of a units
expression" to be not the main rule to follow here, but the
exception if nothing else works because it is, in general, not
unique which unit should be used for the remainder, if one converts,
say, pc^2 into gal. On the other hand, if an expression can be
converted to a dimensionless number, this involves no ambiguity.
Also, I'd say that in real life one usually knows which unit an
expression has.

> > I'd say that "1" appears to be a natural choice in order to express
> > the fact that Calc should obtain a dimensionless number.
> I suppose you mean /try/ to obtain a dimensionless number.
> Calc could have a command that will convert an expression to a
> dimensionless number, if possible, or leave it unchanged, if it cannot
> be converted to a dimensionless number.  I'm not sure that "u c" should
> do such branching, but then I'm not sure this behavior is what you
> meant.

I assume that currently "u c" needs to branch already if this
command needs to perform a partial conversion in the sense discussed
above. I would consider this branch the last resort. If Calc
discovers earlier that an expression can be interpreted as
a dimensionless number, it should do that conversion if the user
requested the unit "1".

I just discovered what I would likewise consider an inconsistency in
the current handling of units:

Calc already defines the dimensionless fine structure constant alpha
as a unit. If one has the expression "7 eV / J", one can convert it
to alphas via "u c alpha". Yet if one first simplifies this with
"u s", one just gets a dimensionless number 1.21e-18. This number
cannot be converted anymore to alphas because Calc is missing an old
unit. However, the result of a calculation should, of course, be
independent of whether the intermediate simplification is done or

This illustrates to me once more that it would be most natural to
interpret dimensionless numbers as quantities that have the unit
"1", though this unit is not spelled out explicitly.
Then plain numbers can be converted to alphas without problem. If,
on the other hand, one wanted to convert a plain number to some
"dimensional unit" like "m", the concept of partial conversion
implies that the expression remains unchanged because we would get
something like "m / m". Note that conversion of "7 alpha" to "m"
already gives the dimensionless number 0.051.

(Alternatively, such a partial conversion could explicitly give the
unit "m / m", similar to when we have "3 m" and "4 m", and we divide
one by the other, then Calc does not simplify that automatically,
but instead we get "0.75 m / m". But such a strategy would become
rather confusing if we converted to more complicated units like
"kg m^2 / s" thus giving "kg m^2 s / s m^2 kg".)

I am confident that most physicists will agree on this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]