Post Reply 
Temperature Conversion
01-28-2014, 06:26 PM
Post: #1
Temperature Conversion
Don't know if this is a bug, but's it's dissapointing anyway.

As many of you know, it's been really, really cold in the US this winter.
I was trying to tell my European colleagues just how cold it was this morning:

−13_°F▶_°C [enter]
which unfortunately parses as:

-CONVERT(13.00_°F,0.00_°C)

instead of:

CONVERT(-13.00_°F,0.00_°C)

The difference between these two is > 35°C !!
Find all posts by this user
Quote this message in a reply
01-28-2014, 08:17 PM
Post: #2
RE: Temperature Conversion
Try (−13_°F)▶_°C [enter] if you put the negative value inside round brackets it works as expected.
Find all posts by this user
Quote this message in a reply
01-29-2014, 11:09 AM
Post: #3
RE: Temperature Conversion
Paul,

Thanks -- I do know how to work around the problem. Still, does anyone think it should work the way it does?
Find all posts by this user
Quote this message in a reply
01-29-2014, 01:01 PM
Post: #4
RE: Temperature Conversion
(01-28-2014 06:26 PM)jgreenb2 Wrote:  Don't know if this is a bug, but's it's dissapointing anyway.

As many of you know, it's been really, really cold in the US this winter.
I was trying to tell my European colleagues just how cold it was this morning:

−13_°F▶_°C [enter]
Well there's your problem! -13F is positively balmy when it's been -24 to -30 here (before wind chill factored in) If you want the calculator to work right, put in REAL cold temperatures! Smile

Tom Lake
Malone, NY USA

Tom L
Cui bono?
Find all posts by this user
Quote this message in a reply
01-29-2014, 01:14 PM
Post: #5
RE: Temperature Conversion
I already mentioned that conversions are not practical...
I guess the standard answer is do your own c*1.8+32=f program in basic.
The prime is a sledgehammer to squash flies...
Find all posts by this user
Quote this message in a reply
01-29-2014, 02:26 PM (This post was last modified: 01-29-2014 02:27 PM by eried.)
Post: #6
RE: Temperature Conversion
(01-29-2014 01:14 PM)Tugdual Wrote:  I already mentioned that conversions are not practical...
I guess the standard answer is do your own c*1.8+32=f program in basic.
The prime is a sledgehammer to squash flies...

not practical?

...so you will eventually have to re-implement the hundreds of possible unit combinations rather than just using this:
Code:
CONVERT(-13_°F,1_°C)

My website: ried.cl
Visit this user's website Find all posts by this user
Quote this message in a reply
01-29-2014, 02:46 PM
Post: #7
RE: Temperature Conversion
(01-29-2014 11:09 AM)jgreenb2 Wrote:  Paul,

Thanks -- I do know how to work around the problem. Still, does anyone think it should work the way it does?

Well, I do think that it is fair for the command to expect ()'s where needed. How would you expect the conversion to handle: 5_°F+13_°F▶_°C

Should the addition happen first or should the conversion happen first? In your original case, there is ambiguity in whether the negation should be attached to the Fahrenheit temperature or to the result after the conversion (though perhaps you may not have seen it that way). Your complaint is that the calculator cannot read your mind, and I would say your expectations make for one tall order.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
01-29-2014, 03:08 PM
Post: #8
RE: Temperature Conversion
(01-29-2014 02:46 PM)Han Wrote:  Well, I do think that it is fair for the command to expect ()'s where needed. How would you expect the conversion to handle: 5_°F+13_°F▶_°C

Your example makes a mess :O try to evaluate/simplify it to see what I mean

My website: ried.cl
Visit this user's website Find all posts by this user
Quote this message in a reply
01-29-2014, 03:46 PM (This post was last modified: 01-29-2014 03:47 PM by Miguel Toro.)
Post: #9
RE: Temperature Conversion
(01-29-2014 03:08 PM)eried Wrote:  
(01-29-2014 02:46 PM)Han Wrote:  Well, I do think that it is fair for the command to expect ()'s where needed. How would you expect the conversion to handle: 5_°F+13_°F▶_°C

Your example makes a mess :O try to evaluate/simplify it to see what I mean

...Which brings an interested observation: you cannot do calculation with temperature units????

5_⁰F+13_⁰F ==> Error: Invalid input

but

5_cm+13_cm ==> 18_cm

Is this a bug?

regards,

Miguel
Find all posts by this user
Quote this message in a reply
01-29-2014, 04:00 PM (This post was last modified: 01-29-2014 04:04 PM by Han.)
Post: #10
RE: Temperature Conversion
(01-29-2014 03:08 PM)eried Wrote:  
(01-29-2014 02:46 PM)Han Wrote:  Well, I do think that it is fair for the command to expect ()'s where needed. How would you expect the conversion to handle: 5_°F+13_°F▶_°C

Your example makes a mess :O try to evaluate/simplify it to see what I mean

Only have my Mac at the moment, and my calculator is not with me. My example was merely to point out the issues of ambiguity in precedence with an operator such as ▶. So out of curiosity, what exactly happens when one tries to implement the example?

Edit: Is ▶ really the "convert" operator? I thought it was for storing values into variables...

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
01-29-2014, 04:12 PM
Post: #11
RE: Temperature Conversion
(01-29-2014 03:46 PM)Miguel Toro Wrote:  5_⁰F+13_⁰F ==> Error: Invalid input

but

5_cm+13_cm ==> 18_cm

Is this a bug?

No, it is not. You cannot consistently handle operations with F and C temperature units. There was quite a nice discussion on this in the old HP museum forum, but I am not finding it right now.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
01-29-2014, 04:31 PM
Post: #12
RE: Temperature Conversion
(01-29-2014 02:46 PM)Han Wrote:  
(01-29-2014 11:09 AM)jgreenb2 Wrote:  Paul,

Thanks -- I do know how to work around the problem. Still, does anyone think it should work the way it does?

Well, I do think that it is fair for the command to expect ()'s where needed. How would you expect the conversion to handle: 5_°F+13_°F▶_°C

Should the addition happen first or should the conversion happen first? In your original case, there is ambiguity in whether the negation should be attached to the Fahrenheit temperature or to the result after the conversion (though perhaps you may not have seen it that way). Your complaint is that the calculator cannot read your mind, and I would say your expectations make for one tall order.

Wow…this is making things a bit more complex than needed. It's just a precedence issue -- '_' has precedence over binary '-' or '+' but it should NOT have precedence over unary '-'. For temperatures things are bit more complex because of the additive constant. See the HP48 User Manual Pg 10-11 for a description of one (IMHO sensible) solution.

But your specific example doesn't make sense to me. The answer to 5_°F+13_°F▶_°C is that it's an error since ▶ is simply a macro for CONVERT and 5_°F+((CONVERT(13_°F,0_°C)) won't parse. This has nothing to do with the expected behavior of

-13_°F▶_°C
Find all posts by this user
Quote this message in a reply
01-29-2014, 04:49 PM (This post was last modified: 01-29-2014 04:49 PM by Miguel Toro.)
Post: #13
RE: Temperature Conversion
(01-29-2014 04:31 PM)jgreenb2 Wrote:  
(01-29-2014 02:46 PM)Han Wrote:  Well, I do think that it is fair for the command to expect ()'s where needed. How would you expect the conversion to handle: 5_°F+13_°F▶_°C

Should the addition happen first or should the conversion happen first? In your original case, there is ambiguity in whether the negation should be attached to the Fahrenheit temperature or to the result after the conversion (though perhaps you may not have seen it that way). Your complaint is that the calculator cannot read your mind, and I would say your expectations make for one tall order.

Wow…this is making things a bit more complex than needed. It's just a precedence issue -- '_' has precedence over binary '-' or '+' but it should NOT have precedence over unary '-'. For temperatures things are bit more complex because of the additive constant. See the HP48 User Manual Pg 10-11 for a description of one (IMHO sensible) solution.

But your specific example doesn't make sense to me. The answer to 5_°F+13_°F▶_°C is that it's an error since ▶ is simply a macro for CONVERT and 5_°F+((CONVERT(13_°F,0_°C)) won't parse. This has nothing to do with the expected behavior of

-13_°F▶_°C

As per Tim comment, It may be more about the fact that 5_°F+13_°F will never get performed, so it never get converted:

(5_°F+13_°F)▶_°C ===> CONVERT((5_°F+13_°F),0_°C) ===> Error: Invalid input.
Find all posts by this user
Quote this message in a reply
01-29-2014, 05:23 PM (This post was last modified: 01-29-2014 05:24 PM by Han.)
Post: #14
RE: Temperature Conversion
(01-29-2014 04:49 PM)Miguel Toro Wrote:  
(01-29-2014 04:31 PM)jgreenb2 Wrote:  Wow…this is making things a bit more complex than needed. It's just a precedence issue -- '_' has precedence over binary '-' or '+' but it should NOT have precedence over unary '-'. For temperatures things are bit more complex because of the additive constant. See the HP48 User Manual Pg 10-11 for a description of one (IMHO sensible) solution.

But your specific example doesn't make sense to me. The answer to 5_°F+13_°F▶_°C is that it's an error since ▶ is simply a macro for CONVERT and 5_°F+((CONVERT(13_°F,0_°C)) won't parse. This has nothing to do with the expected behavior of

-13_°F▶_°C

As per Tim comment, It may be more about the fact that 5_°F+13_°F will never get performed, so it never get converted:

(5_°F+13_°F)▶_°C ===> CONVERT((5_°F+13_°F),0_°C) ===> Error: Invalid input.

I didn't write (5_°F+13_°F)▶_°C -- I wrote 5_°F+13_°F▶_°C without parentheses. I am now aware of the _other_ issues underlying this particular example. Ignoring the issues around temperature addition, my point was that without parentheses, this "shortcut" for the the CONVERT command is ambiguous because 5_°F+13_°F▶0_°C could be interpreted by one person as 5_°F+(13_°F▶0_°C) and by another person to mean (5_°F+13_°F)▶0_°C. Therefore, one cannot expect a machine to be able to magically decide the right answer for all users. Perhaps a better example of the point I am making would be someone typing:

5_°C+13_°F▶0_°C

Are they trying to add two different temps and wanting the result to be in °C? or are they trying to convert one temp (13_°F) into °C first, and then adding that result to 5_°C. Hence my point about adding parentheses where needed when one chooses to use an ambiguous "macro" over the non-ambiguous command.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
01-29-2014, 06:01 PM
Post: #15
RE: Temperature Conversion
(01-29-2014 04:12 PM)Tim Wessman Wrote:  No, it is not. You cannot consistently handle operations with F and C temperature units. There was quite a nice discussion on this in the old HP museum forum, but I am not finding it right now.

Maybe it was this one.
Find all posts by this user
Quote this message in a reply
01-29-2014, 07:01 PM (This post was last modified: 01-29-2014 07:07 PM by jgreenb2.)
Post: #16
RE: Temperature Conversion
(01-29-2014 05:23 PM)Han Wrote:  ... my point was that without parentheses, this "shortcut" for the the CONVERT command is ambiguous because 5_°F+13_°F▶0_°C could be interpreted by one person as 5_°F+(13_°F▶0_°C) and by another person to mean (5_°F+13_°F)▶0_°C. Therefore, one cannot expect a machine to be able to magically decide the right answer for all users. ...

By that reasoning the following expression should always require parenthesis:

5+3/4

As we all learned as children, however, there exists a convention for operator precedence that resolves the apparent ambiguity:

5+3/4 = 5 + (3/4)

There is no need for "magic" or "mind-reading" or any of the other pejoratives that are being injected into this conversation.

Nonetheless, the original post wasn't about adding or subtracting temperatures. It was just noting that an apparently sensible expression like:

−13_°F▶_°C

gives an unexpected result. It seems quite clear that this is an operator precedence issue that could be easily resolved.
Find all posts by this user
Quote this message in a reply
01-29-2014, 07:37 PM (This post was last modified: 01-29-2014 07:43 PM by Han.)
Post: #17
RE: Temperature Conversion
(01-29-2014 07:01 PM)jgreenb2 Wrote:  By that reasoning the following expression should always require parenthesis:

5+3/4

As we all learned as children, however, there exists a convention for operator precedence that resolves the apparent ambiguity:

5+3/4 = 5 + (3/4)

Your example is incorrect. There is no ambiguity in your example because division has higher precedence than addition. On the other hand, if you actually meant to add 5 and 3 first, you would need to use ()'s to specify that: (5+3)/4.

Quote:There is no need for "magic" or "mind-reading" or any of the other pejoratives that are being injected into this conversation.

I did not mean anything demeaning or offensive by "the calculator cannot read your mind"; I am sorry if it came off that way. My point was there is no algorithm that will choose the correct interpretation for all users.

Quote:Nonetheless, the original post wasn't about adding or subtracting temperatures. It was just noting that an apparently sensible expression like:

−13_°F▶_°C

gives an unexpected result. It seems quite clear that this is an operator precedence issue that could be easily resolved.

Somehow this part was not quoted when I responded. I see your point (and agree).

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
01-29-2014, 09:19 PM
Post: #18
RE: Temperature Conversion
Reason why you cannot do math on temps is because you don't convert a temperature difference the same way as a temperature.
On temps: C*1.8+32 = F
On delta temps: dC * 1.8 = dF

For that reason calculation with conversion cannot be easily done.
Find all posts by this user
Quote this message in a reply
01-29-2014, 10:23 PM
Post: #19
RE: Temperature Conversion
I'm hoping the Prime will eventually be as good with units as the 50G

13 +/- units temp degF leftshift degC --> -25 degC

13 +/- units temp degF 20 degF + --> +7 degF
Find all posts by this user
Quote this message in a reply
01-30-2014, 12:58 AM
Post: #20
RE: Temperature Conversion
(01-28-2014 06:26 PM)jgreenb2 Wrote:  Don't know if this is a bug, but's it's dissapointing anyway.

As many of you know, it's been really, really cold in the US this winter.
I was trying to tell my European colleagues just how cold it was this morning:

−13_°F▶_°C [enter]
which unfortunately parses as:

-CONVERT(13.00_°F,0.00_°C)

instead of:

CONVERT(-13.00_°F,0.00_°C)

The difference between these two is > 35°C !!

I do my temperature conversions in Home/rpn view with no problems.
Enter -13 and press the Units key.Then select Temperature->F and <Enter>, which
places -13_F on the stack. Enter 1 and do the same selecting C, which places
1_C on the stack. Press Units key again, select Tools->Convert then <Enter>.
After reading about all of the parsing issues using Convert with Temperatures in
CAS view, I would think it would be better to avoid CAS altogether for conversions.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)