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

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

[Roland Winkler]

In Calc type

'e T m^2 / hbar

Convert this to SI units with u c si RET
- That's perfect. We get a dimensionless number.
Let's try again. In Calc type (more my range of numbers)

'e T nm^2 / hbar

Now when we type again u c, Calc remembers what we did before.
So as a unit it offers "default 1". Let's take this default.
So just type RET

Error: No units specified

In other words: if an expression with units simplifies to a
dimensionless number, Calc does not accept the unit "1", though it
even offers this unit as a default for calc-convert-units.


In GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-12-14 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.10706000

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

[Jay Belanger]

> In Calc type
...
> Convert this to SI units with u c si RET
> - That's perfect. We get a dimensionless number.
...
> Now when we type again u c, Calc remembers what we did before.
> So as a unit it offers "default 1".

Calc should probably offer "si" as the default in this case.

> Let's take this default.
> So just type RET
>
> Error: No units specified
>
> In other words: if an expression with units simplifies to a
> dimensionless number, Calc does not accept the unit "1", though it
> even offers this unit as a default for calc-convert-units.

Calc shouldn't offer "1" as a default; I'll fix it so that it doesn't
do that anymore.

I'll also change it so that Calc can offer unit systems and composite
units as default units, but that should probably wait until after 24.1
comes out.

Jay

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

[Roland Winkler]

On Thu Jan 19 2012 Jay Belanger wrote:
> 
> > In Calc type
> ...
> > Convert this to SI units with u c si RET
> > - That's perfect. We get a dimensionless number.
> ...
> > Now when we type again u c, Calc remembers what we did before.
> > So as a unit it offers "default 1".
> 
> Calc should probably offer "si" as the default in this case.

Yes: If previously one explicitly used "si" as an arg to
calc-convert-units, then it would be reasonable if
calc-convert-units remembered this choice, independent of the actual
SI unit that calc-convert-units obtained at the end of the previous
calculation.

> I'll also change it so that Calc can offer unit systems and composite
> units as default units, but that should probably wait until after 24.1
> comes out.

Agreed. This is nothing urgent.

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. I'd say that "1" appears to be a
natural choice in order to express the fact that Calc should obtain
a dimensionless number.

Or is there some other recommended way to do this that I have
overlooked?

Roland

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

[Jay Belanger]

>> I'll also change it so that Calc can offer unit systems and composite
>> units as default units, but that should probably wait until after 24.1
>> comes out.
>
> Agreed. This is nothing urgent.

Good; then this part will be taken care of as soon as 24.1 comes out.

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

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

Jay

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

[Roland Winkler]

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
not.

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.

Roland

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

[Jay Belanger]

> I would always consider the concept of "converting part of a units
> expression" to be not the main rule to follow here,

If 45 mi/hr is on the stack, and "u c" is called with new units km, what
should happen?  

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

If volume is converted to volume, there should be no remainder.

> On the other hand, if an expression can be converted to a
> dimensionless number, this involves no ambiguity.

But what if you ask Calc to convert a units expression into a
dimensionless number when it can't be so converted?
Using a system name ("si", "cgs", etc.) as an output unit, as you did
before, solves this problem.  If the expression is dimensionless, then
all units will cancel out.  If the expression is not unitless, then any
left over units will be given in the requested unit system.

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

Perhaps I used the wrong word when I said "branch", I meant that Calc
would have to look at the result it computes,  and then decide whether
to return that or return the original expression.  Currently Calc doesn't
do anything like that when it converts 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.

If you try to convert it to alpha, you can use "1" as a default old
unit and you can give it "alpha" as a new unit.  (Since "1" can't be
used as an output unit, it isn't obvious that it can be used an
an input unit.  Perhaps that's what this discussion is about.)

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

That makes sense, and is what happens when you use "1" as the old
(input) unit when converting a plain number to alphas.  The problem with
using "1" as a new (output) unit is that to be consistent with how it
treats other units, choosing an output unit of "1" should be a no-op.  
Going back to converting 45 mi/hr with new units "km", what currently
happens is that (mi/hr)/km is converted to 1.609344 / hr, so the result
of the entire conversion will be 45*(1.609344 / hr)*km.  If instead the
new units are "1", then all that will happen is the expression on the
stack will be divided by 1 and multiplied by 1.  It doesn't seem to me
that the dimensionless unit "1" should be handled differently than other
units.  (Granted, currently an output unit of 1 does give an error, but
since it would be a no-op I doubt the user intended to give it anyhow.)

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

Right.  That's how it currently works, and plain numbers can be
converted to alphas.

Jay

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

[Roland Winkler]

On Fri Jan 20 2012 Jay Belanger wrote:
> 
> > I would always consider the concept of "converting part of a units
> > expression" to be not the main rule to follow here,
> 
> If 45 mi/hr is on the stack, and "u c" is called with new units km, what
> should happen?  

Here the user is posing a problem with no uniquely defined answer.
The answer could be expressed in km/hr but also in km/s or in km eV/hbar.
This scenario I would always give the lowest priority.

> > 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.
> 
> If volume is converted to volume, there should be no remainder.

pc^2 specifies an area: 1 pc^2 is converted to 2.5e35 gal/m

> But what if you ask Calc to convert a units expression into a
> dimensionless number when it can't be so converted?

again: I'd give this scenario the lowest priority.

I'd say: most often the requested output unit does not match the
dimension of the input because one made whatever mistake either in
the expression to be converted or in the unit selected for the
output.

> If you try to convert it to alpha, you can use "1" as a default old
> unit and you can give it "alpha" as a new unit.  (Since "1" can't be
> used as an output unit, it isn't obvious that it can be used an
> an input unit.  Perhaps that's what this discussion is about.)

If I have a plain number on the stack and want it to be converted to
alpha, I'll be asked for the old unit. - You are right: here one can
specify "1" as the old unit.

My problem is here that from my perspective as a Calc user (not
worrying about any internals of Calc) the treatment of the unit "1"
sticks out in various ways.

In physics I'd call "1" a unit like all the other ones. In that sense
it would be great if Calc could treat it that way, too.

> (Granted, currently an output unit of 1 does give an error, but
> since it would be a no-op I doubt the user intended to give it
> anyhow.)

This is the point where I want to argue the other way round:

For me, it's perfectly valid and it would be great if one could use
it like any other unit.

> > Note that conversion of "7 alpha" to "m" already gives the
> > dimensionless number 0.051.
> 
> Right.  That's how it currently works,

I'd say that this example illustrates once more that any "partial
conversion" is most often meaningless and not what the user might
have intended.

Roland

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

[Jay Belanger]

>> > I would always consider the concept of "converting part of a units
>> > expression" to be not the main rule to follow here,
>>
>> If 45 mi/hr is on the stack, and "u c" is called with new units km, what
>> should happen?
>
> Here the user is posing a problem with no uniquely defined answer.
> The answer could be expressed in km/hr but also in km/s or in km eV/hbar.

But what /should/ happen?  Would you like an error signaled?  Otherwise,
the current behavior is the most reasonable.

>> But what if you ask Calc to convert a units expression into a
>> dimensionless number when it can't be so converted?
>
> again: I'd give this scenario the lowest priority.

I'm not sure what you mean by giving it low priority. 
Either it happens or it doesn't, and Calc needs to do something if it
happens.

> In physics I'd call "1" a unit like all the other ones. In that sense
> it would be great if Calc could treat it that way, too.

Calc does that; it looks to me as if you want it treated special.

It seems to me as if you want to get rid of Calc's ability to deal with
inconsistent units, but that's pretty established Calc behavior.

Jay

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

[Roland Winkler]

On Fri Jan 20 2012 Jay Belanger wrote:
> > Here the user is posing a problem with no uniquely defined answer.
> > The answer could be expressed in km/hr but also in km/s or in km eV/hbar.
> 
> But what /should/ happen?  Would you like an error signaled?  Otherwise,
> the current behavior is the most reasonable.

I would, indeed, consider it quite OK if an error was signaled. Say,
if there was an option calc-throw-error-if-units-mismatch, I'd bind
it to t.

> >> But what if you ask Calc to convert a units expression into a
> >> dimensionless number when it can't be so converted?
> >
> > again: I'd give this scenario the lowest priority.
> 
> I'm not sure what you mean by giving it low priority. Either it
> happens or it doesn't, and Calc needs to do something if it
> happens.

I guess we can have the following scenarios that can be handled as
follows:

(1) If the old expression and the new unit have the same dimension,
    "1" should be treated like any other unit.

    So this means: 

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

    - similarly: if the old expression is just a number (i.e., unit
      "1"), this can be converted to other dimensionless units such
      as "alpha" without being asked for the old unit.

      (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.)

(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.

    (this would be quite consistent with how Calc already treats the
    case that the old expression is something like "7 m", and the
    new unit is "alpha".)

(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

    (again, this would be quite consistent with how Calc already
    treats the case that the old expression is something like
    "7 alpha", where conversion to any other unit gives a
    dimensionless number.

Did I miss another possibility? If yes, I am sure that it has a
reasonable solution, too.

(Even if Calc handled dimensionless quantities this way, I would
bind calc-throw-error-if-units-mismatch to t because in my work a
unit mismatch between old and new means a mismatch between what I
have and what I expect to get.)

Roland

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

[Jay Belanger]

>> But what /should/ happen?  Would you like an error signaled?  Otherwise,
>> the current behavior is the most reasonable.
>
> I would, indeed, consider it quite OK if an error was signaled. Say,
> if there was an option calc-throw-error-if-units-mismatch, I'd bind
> it to t.

Having such an option shouldn't be too hard to take care of, after 24.1
comes out.  By default, though, the current behavior shouldn't change,
and so the option should have default value nil.

Jay

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

[Roland Winkler]

On Fri Jan 20 2012 Jay Belanger wrote:
> > I would, indeed, consider it quite OK if an error was signaled. Say,
> > if there was an option calc-throw-error-if-units-mismatch, I'd bind
> > it to t.
> 
> Having such an option shouldn't be too hard to take care of, after 24.1
> comes out.  By default, though, the current behavior shouldn't change,
> and so the option should have default value nil.

Great, thanks! Do you also see a possiblity to implement the other
scheme I suggested (attached below once more)? That would be
wonderful!

Roland


I guess we can have the following scenarios that can be handled as
follows:

(1) If the old expression and the new unit have the same dimension,
    "1" should be treated like any other unit.

    So this means: 

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

    - similarly: if the old expression is just a number (i.e., unit
      "1"), this can be converted to other dimensionless units such
      as "alpha" without being asked for the old unit.

      (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.)

(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.

    (this would be quite consistent with how Calc already treats the
    case that the old expression is something like "7 m", and the
    new unit is "alpha".)

(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

    (again, this would be quite consistent with how Calc already
    treats the case that the old expression is something like
    "7 alpha", where conversion to any other unit gives a
    dimensionless number.

Did I miss another possibility? If yes, I am sure that it has a
reasonable solution, too.

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

[Jay Belanger]

> Great, thanks! Do you also see a possiblity to implement the other
> scheme I suggested (attached below once more)? That would be
> wonderful!
...
>     - 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.

>     - similarly: if the old expression is just a number (i.e., unit
>       "1"), this can be converted to other dimensionless units such
>       as "alpha" without being asked for the old unit.

This I'm not too sure about.  The current behavior allows the user to
convert units without having the units explicit in the expression, so for
example
  45 u c mi/hr RET km/hr
would convert 45 mi/hr to km/hr.  This, I believe, was put in as a
feature, not a bug.

>       (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.

> (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.

>     (this would be quite consistent with how Calc already treats the
>     case that the old expression is something like "7 m", and the
>     new unit is "alpha".)
>
> (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.

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

[Roland Winkler]

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

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

[Jay Belanger]

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

Right, so if the user wants the units simplified, they can call
calc-simplify-units.  If the user wants to convert units, they can call
calc-convert-units.

> So every plain, dimensionless number in Calc can be converted to
> ones. "7" becomes "7 one",

There is no need for that.  "7" is fine.

Jay

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

[Roland Winkler]

On Sat Jan 21 2012 Jay Belanger wrote:
> > So every plain, dimensionless number in Calc can be converted to
> > ones. "7" becomes "7 one",
> 
> There is no need for that.  "7" is fine.

But this implies that internally Calc must interpret "7" as if it
was "7 one". Only then can one convert "7" to other dimensionless
units such as the "e T nm^2 / hbar" that appeared in my original bug
report. 

Currently the latter unit conversion does require the superfluous
step that one tells Calc in one or the other way that "7" means "7 one".
I suggest that this superfluous step should not be required.

Roland

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

[Jay Belanger]

> Currently the latter unit conversion does require the superfluous
> step that one tells Calc in one or the other way that "7" means "7 one".
> I suggest that this superfluous step should not be required.

Interesting point.
(In your case, by the way, when the "target units must match the current
units" option is chosen, the old units will never be prompted for, and
"7" will automatically mean "7 one".)

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

[Jay Belanger]

> 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",

This will automatically be done when "exact output units" option is
chosen.

>   Calc should interpret dimensionless numbers such as "7" equivalent
>   to "7 one" without the need to explicitly make this trivial
>   conversion in either direction.
...
> - If Calc finds a dimensionless number "7" on the stack, for unit
>   conversions it gets interpreted as "7 one"

This would break current convert-units behavior, where a dimensionless
number can be interpreted by the user as any unit.  This is why when the
user asks to convert a plain number, Calc asks for the old units.  Calc
was written that way on purpose, and is a feature of Calc's units
handling.

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

[Roland Winkler]

On Sat Jan 21 2012 Jay Belanger wrote:
> > - If Calc finds a dimensionless number "7" on the stack, for unit
> >   conversions it gets interpreted as "7 one"
> 
> This would break current convert-units behavior, where a dimensionless
> number can be interpreted by the user as any unit.  This is why when the
> user asks to convert a plain number, Calc asks for the old units.  Calc
> was written that way on purpose, and is a feature of Calc's units
> handling.

That's why I said later in the email you are quoting:

  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

Roland

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

[Roland Winkler]

I should add:

For me, Calc is one of the greatest tools in Emacs, and the unit
converter is a wonderful tool within Calc.

Thanks a lot for maintaining this package!!

Roland

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

[Jay Belanger]

> In Calc type
>
> 'e T m^2 / hbar
>
> Convert this to SI units with u c si RET
> - That's perfect. We get a dimensionless number.
> Let's try again. In Calc type (more my range of numbers)
>
> 'e T nm^2 / hbar
>
> Now when we type again u c, Calc remembers what we did before.
> So as a unit it offers "default 1". Let's take this default.
> So just type RET
>
> Error: No units specified
>
> In other words: if an expression with units simplifies to a
> dimensionless number, Calc does not accept the unit "1", though it
> even offers this unit as a default for calc-convert-units.

The version of Calc in bzr Emacs will no longer offer "1" as a default.