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

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

[Roland Winkler]

start emacs -Q
start Calc
type 'k K / eV RET u c

expected result: either Emacs will ask me 'New units:' (as with
                 Emacs 23) or something else meaningful,
                 allowing me to convert 'k K / eV' to the units
                 of my choice

actual result: Calc returns 'k K / eV' expression unmodified



In GNU Emacs 24.2.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9)
 of 2013-01-10 on lukas
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
System Description:	Ubuntu 8.04.4 LTS

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

[Jay Belanger]

> start emacs -Q
> start Calc
> type 'k K / eV RET u c

Oops; Calc is inelegantly distinguishing between expressions with no
units and expressions where the units cancel.
I'll fix that as soon as I get to a computer I can commit from.

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

[Jay Belanger]

Also, what's happening here is that since the units all cancel in the
given expression, Calc simply returns the expression, with the units
simplified.  (That it doesn't properly simplify that particular
expression is a bug to be fixed, but it isn't a regression.)

The given example should probably be handled like an expression
which has no units (either simply simplify it or prompt for "Old units"
and "New units").  The Emacs 23 behavior, where new units were
prompted for but essentially ignored, doesn't seem right.
The overall fix depends on a non-regression fix (otherwise, it is
replacing one wrong behavior for another).  I'll make the fix in the
trunk when I get to a computer I can commit from, but I don't know if
the old behavior should be put back into the emacs-24 branch.

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

[Jay Belanger]

> start emacs -Q
> start Calc
> type 'k K / eV RET u c
>
> expected result: either Emacs will ask me 'New units:' (as with
>                  Emacs 23) or something else meaningful,

This has been fixed in bzr.

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

[Roland Winkler]

On Wed Jan 30 2013 Jay Belanger wrote:
> 
> > start emacs -Q
> > start Calc
> > type 'k K / eV RET u c
> >
> > expected result: either Emacs will ask me 'New units:' (as with
> >                  Emacs 23) or something else meaningful,
> 
> This has been fixed in bzr.

I am sorry, I do not understand the new behavior: Why does
calc-convert-units ask now

  (The expression is unitless when simplified) Old Units: 

if the expression is dimensionless? In physics "unitless" is
different from "dimensionless", it is quite common to use
dimensionless units. In other words, I do not quite understand what
the change in calc-convert-units was supposed to fix or improve
here. calc-convert-units should take such dimensionless expressions
from the stack as it used to with any such expressions (expressions
with dimensions or dimensionless expressions). The old behavior was
fine in that respect.

From a different perspective: calc-convert-units in the pretest
branch is still broken, I just installed 24.2.93.1 which still shows
the bug. The current behavior is a regression as compared with
previous emacs versions and rather annoying for me.

Roland

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

[Jay Belanger]

> I am sorry, I do not understand the new behavior: Why does
> calc-convert-units ask now
>
>   (The expression is unitless when simplified) Old Units: 
>
> if the expression is dimensionless? 

It says unitless, not dimensionless.  They are not the same thing.

> From a different perspective: calc-convert-units in the pretest
> branch is still broken,

Not that I can see.  If there are units (whether dimensionless or not),
it will work with those.  If there are not units to convert, it will ask
what units you intended.

For example, 
convert:
 3
There are no units here, so Calc asks for the old units.  This behavior
is as old as Calc.
convert:
 3 ft/in
This is simply 36.  There are no units here, so Calc asks for the old
units.  Since someone might wonder why Calc is asking for units, there
is a message pointing out the expression doesn't have any.
convert:
 3 rad
This is dimensionless but not unitless.  Since there is a unit to work
with, Calc doesn't ask for one.  

Which behavior do you consider buggy?

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

[Roland Winkler]

On Thu Feb 7 2013 Jay Belanger wrote:
> Which behavior do you consider buggy?

Please see my original bug report. Nothing has changed with GNU
Emacs 24.2.93.1.

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

[Jay Belanger]

> Please see my original bug report.

I did.  That bug has been fixed.  I tried it again to make sure. 
If you have a new bug to report, please give the details.

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

[Roland Winkler]

On Thu Feb 7 2013 Jay Belanger wrote:
> 
> > Please see my original bug report.
> 
> I did.  That bug has been fixed.  I tried it again to make sure. 
> If you have a new bug to report, please give the details.

You changed the trunk, but not the pretest branch.

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

[Roland Winkler]

On Thu Feb 7 2013 Jay Belanger wrote:
> convert:
>  3 ft/in
> This is simply 36.  There are no units here, so Calc asks for the old
> units.  Since someone might wonder why Calc is asking for units, there
> is a message pointing out the expression doesn't have any.

Please recognize the difference between dimensionless and unitless.
3 ft/in is dimensionless, but it has the unit "ft/in". 
As calc-convert-units is about converting units and (I suppose)
nothing else, there is no need to ask the user here. If the user
entered "kg" as the old unit of "3 ft / in" this makes no sense.

Please, trust the user she knows what she wants. The new behavior is
a regression.

Roland

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

[Jay Belanger]

> You changed the trunk, but not the pretest branch.

The old behavior was buggy, and the pretest behavior is buggy. 
I'd be happy to put a fix in the pretest branch, but I think currently
there are only supposed to be bugfixes in the pretest branch for
regressions, and I'm not sure this counts as one. 

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

[Jay Belanger]

> Please recognize the difference between dimensionless and unitless.
> 3 ft/in is dimensionless, but it has the unit "ft/in". 

"The expression is unitless when simplified"

> If the user entered "kg" as the old unit of "3 ft / in" this makes no
> sense.

Of course it does, and Calc has supported this behavior for years.
When Calc asks for Old Units:...  New Units:...,
it is regarding the expression on the stack as the coefficient of the
old units. 

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

[Glenn Morris]

Jay Belanger wrote:

> The old behavior was buggy, and the pretest behavior is buggy. 

Sounds like something that does not need fixing in emacs-24 then.

> I'd be happy to put a fix in the pretest branch, but I think currently
> there are only supposed to be bugfixes in the pretest branch for
> regressions, and I'm not sure this counts as one. 

If you are absolutely convinced the patch is safe, you can put it in
emacs-24 if you like.

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

[Roland Winkler]

On Thu Feb 7 2013 Jay Belanger wrote:
> > Please recognize the difference between dimensionless and unitless.
> > 3 ft/in is dimensionless, but it has the unit "ft/in". 
> 
> "The expression is unitless when simplified"

I am sorry, this is a rather unique interpretation of the concept of
"dimensions" vs "units" in physics.  Is there no other physicist
reading this?

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

[Jay Belanger]

>> > Please recognize the difference between dimensionless and unitless.
>> > 3 ft/in is dimensionless, but it has the unit "ft/in". 
>> 
>> "The expression is unitless when simplified"
>
> I am sorry, this is a rather unique interpretation of the concept of
> "dimensions" vs "units" in physics.

I honestly have no idea what you are talking about, but you certainly
aren't addressing what I am saying.  Please respond to what I write.
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.

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

[Roland Winkler]

On Thu Feb 7 2013 Jay Belanger wrote:
> 
> >> > Please recognize the difference between dimensionless and unitless.
> >> > 3 ft/in is dimensionless, but it has the unit "ft/in". 
> >> 
> >> "The expression is unitless when simplified"
> >
> > I am sorry, this is a rather unique interpretation of the concept of
> > "dimensions" vs "units" in physics.
> 
> I honestly have no idea what you are talking about, but you
> certainly aren't addressing what I am saying. Please respond to
> what I write. 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.

I give up

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

[Jay Belanger]

Glenn Morris <rgm@gnu.org> writes:

> Jay Belanger wrote:
>
>> The old behavior was buggy, and the pretest behavior is buggy. 
>
> Sounds like something that does not need fixing in emacs-24 then.

Okay, then. 
Particular since:
  * the difference between the old behavior and the pretest behavior is
    that one bug was fixed, making it easier to see another bug which
    had been around a while (the pretest buggy behavior wasn't new),
  * the changes since the pretest have been simple, but not trivial,
I'll leave the pretest alone.

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

[Glenn Morris]

Jay Belanger wrote:

>   * the difference between the old behavior and the pretest behavior is
>     that one bug was fixed, making it easier to see another bug which
>     had been around a while (the pretest buggy behavior wasn't new),
>   * the changes since the pretest have been simple, but not trivial,
> I'll leave the pretest alone.

Sounds like the right call to me.

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

[Eli Zaretskii]

> Date: Thu, 7 Feb 2013 14:55:37 -0600
> From: "Roland Winkler" <winkler@gnu.org>
> Cc: 13580@debbugs.gnu.org
> 
> On Thu Feb 7 2013 Jay Belanger wrote:
> > > Please recognize the difference between dimensionless and unitless.
> > > 3 ft/in is dimensionless, but it has the unit "ft/in". 
> > 
> > "The expression is unitless when simplified"
> 
> I am sorry, this is a rather unique interpretation of the concept of
> "dimensions" vs "units" in physics.  Is there no other physicist
> reading this?

I am, but AFAIU this is not an issue whether dimensionless and
unitless are the same (they are not).  The issue is how this
makes a difference in relevant use cases with Calc.

So I suggest that you show several examples where the new behavior is
not what the user will want, and propose a better behavior in those
cases.  Up until now, the discussion here didn't show enough clear
examples for me to make up my mind on this issue; perhaps Jay is
unconvinced for the same reason.

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

[Eli Zaretskii]

> From: Jay Belanger <jay.p.belanger@gmail.com>
> Date: Thu, 07 Feb 2013 15:11:58 -0600
> 
> 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):

  In dimensional analysis, a dimensionless quantity or quantity of
  dimension one is a quantity without an associated physical
  dimension. It is thus a "pure" number, and as such always has a
  dimension of 1. [...]

  Even though a dimensionless quantity has no physical dimension
  associated with it, it can still have dimensionless units. To show the
  quantity being measured (for example mass fraction or mole fraction),
  it is sometimes helpful to use the same units in both the numerator
  and denominator (kg/kg or mol/mol). The quantity may also be given as
  a ratio of two different units that have the same dimension (for
  instance, light years over meters). This may be the case when
  calculating slopes in graphs, or when making unit conversions. Such
  notation does not indicate the presence of physical dimensions, and is
  purely a notational convention. Other common dimensionless units are
  % (= 0.01),  ‰ (= 0.001), [...] and angle units (degrees, radians, grad).

Therefore, "dimensionless" and "unitless" is not the same, and you see
above prominent examples of such dimensionless units.

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.

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? 

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

[Eli Zaretskii]

> From: Jay Belanger <jay.p.belanger@gmail.com>
> Cc: 13580@debbugs.gnu.org
> CC: jay.p.belanger@gmail.com
> Date: Fri, 08 Feb 2013 08:30:43 -0600
> 
> > He is talking about this (see
> > http://en.wikipedia.org/wiki/Dimensionless_quantity):
> 
> I've indicated that I know what dimensionless means

Sorry about that.  I wanted to make sure everyone is on the same page
in this regard.

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

I'd rather hope that Roland will suggest the alternative behavior he
would like to see instead.

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

[Jay Belanger]

>> I've indicated that I know what dimensionless means
>
> Sorry about that.  I wanted to make sure everyone is on the same page
> in this regard.

Thanks; that's a good idea.

>> Perhaps Calc should stick to (1), and let the user deal with the
>> simplified expression. 
>> 
>> Or: What do you suggest? 
>
> I'd rather hope that Roland will suggest the alternative behavior he
> would like to see instead.

A concrete suggestion would be nice, but should take into account the
different uses for expressions where the units cancel.

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

[Jay Belanger]

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

This behavior was inconsistent, by the way.
That might be related to a simplification bug I mentioned earlier in
this thread; I'll look into that.

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

[Roland Winkler]

On Fri Feb 8 2013 Eli Zaretskii wrote:
> > > He is talking about this (see
> > > http://en.wikipedia.org/wiki/Dimensionless_quantity):
> > 
> > I've indicated that I know what dimensionless means
> 
> Sorry about that.  I wanted to make sure everyone is on the same page
> in this regard.

This wikipedia page is about "dimensionless quantities", and that's
very different from dimensionless units. Distance, mass, energy,
they can all be expressed in dimensionless units. Such dimensionless
units are used all the time in physics. Strangely, I can give you
zillions of references in (more advanced) textbooks that use them.
But nobody bothers to explain this concept in general terms.

> I'd rather hope that Roland will suggest the alternative behavior he
> would like to see instead.

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"

The above is a very consistent scheme as it corresponds to equality
transformations: if previously the left-hand-side of one of these
equations was on the Calc stack, it gets replaced by an "equal"
expression, very similar to

  10 = 8#12 = 16#A

Equations (3) and (4) correspond to "dimensionless" expressions: we
do have units (which do NOT cancel), but the dimensions of these
units cancel on each side of these equations. (The dimension of "m"
is "length", for "s" it is "time", for "mph" it is "velocity".) But
conceptually there is really no difference between Eqs. (1) - (4).

Now where is the problem?

- (1) and (2) are fine with old (GNU Emacs 23) and more recent
  (24.2.93 and 24.3.50) versions of Emacs

- (3) is essentially fine with Emacs 23 ("1" is not recognized as
  new unit, but calc-convert-units requires that the new unit is
  specified as "si", which, I believe, in this case boils down to
  "simplify". - Not prefect, but ok. The final result is correct).

  With (3) and 24.2.93, calc-convert-units does not do anything,
  an annoying regression.

  With (3) and 24.3.50, calc-convert-units requests an "old unit",
  which can be something like "kg". 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. It is like having a command for converting
  octal numbers into decimal numbers, which, during the conversion,
  also get multiplied by some factor 42.

  I just noticed: With (3) and old unit chosen as "kg",
  calc-convert-units offers as default for the new unit again "kg".
  Accepting this default gives "0.44704" (dimensionless).
  Here I do not understand the rationale either.

- (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. [In my own work, a
  conversion of type (4) rarely comes up, so it has been less
  annoying for me that it is not properly implemented. Still it is
  inconsistent.]

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. 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. But
there should be a Calc option to disable this, thus implementing a
conversion algorithm that is consistently based on proper
equalities. Please, trust the user she knows what she wants when
performing conversions (1) - (4).

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. Most often, the problem was really a
typo earlier in the calculation that can be detected by a warning
about inconsistent dimensions.

Roland

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

[Jay Belanger]

"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

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

[Roland Winkler]

On Sat Feb 9 2013 Jay Belanger wrote:
> > 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.

I suggest to give Calc a user option that completely disables the
question about an "old unit". If this pops up sometimes, but there
is no need for this in a consistent work flow, such a question can
be very distracting. (As you surely have noticed by now: I use
calc-convert-units all the time!)

> Thanks for pointing them out; I will work on them.

Thanks,

Roland

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

[Jay Belanger]

"Roland Winkler" <winkler@gnu.org> writes:
...
>> Okay.  The user can do it that way, or ignore the "Old unit:" part and
>> get the classic behavior.  Whatever the user wants.
>
> I suggest to give Calc a user option that completely disables the
> question about an "old unit".

Okay; if the variable `calc-allow-units-as-numbers' is nil, then that
is disabled.

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

[Roland Winkler]

On Sat Feb 9 2013 Jay Belanger wrote:
> Okay; if the variable `calc-allow-units-as-numbers' is nil, then that
> is disabled.

Thanks. - Shouldn't the name be reversed: calc-allow-numbers-as-units?
As a physicist, I would really prefer calc-allow-dimensionless-units.

Roland

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

[Jay Belanger]

>> Okay; if the variable `calc-allow-units-as-numbers' is nil, then that
>> is disabled.
>
> Thanks. - Shouldn't the name be reversed: calc-allow-numbers-as-units?

Well, there's a lot of information to be put into a variable name, but I
thought of it as short for
 "Allow (expressions involving) units (to be treated) as numbers (in certain
  situations ...)"
But ideally, the variable will probably be ignored or set once and then
ignored.