+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: Temperature Conversion (/thread-560.html)
Pages: 1 2
Temperature Conversion - jgreenb2 - 01-28-2014 06:26 PM
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 !!
RE: Temperature Conversion - Paul Berger (Canada) - 01-28-2014 08:17 PM
Try (−13_°F)▶_°C [enter] if you put the negative value inside round brackets it works as expected.
RE: Temperature Conversion - jgreenb2 - 01-29-2014 11:09 AM
Paul,
Thanks -- I do know how to work around the problem. Still, does anyone think it should work the way it does?
RE: Temperature Conversion - toml_12953 - 01-29-2014 01:01 PM
(01-28-2014 06:26 PM)jgreenb2 Wrote: Don't know if this is a bug, but's it's dissapointing anyway.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!
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]
Tom Lake
Malone, NY USA
RE: Temperature Conversion - Tugdual - 01-29-2014 01:14 PM
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...
RE: Temperature Conversion - eried - 01-29-2014 02:26 PM
(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)RE: Temperature Conversion - Han - 01-29-2014 02:46 PM
(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.
RE: Temperature Conversion - eried - 01-29-2014 03:08 PM
(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
RE: Temperature Conversion - Miguel Toro - 01-29-2014 03:46 PM
(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
RE: Temperature Conversion - Han - 01-29-2014 04:00 PM
(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...
RE: Temperature Conversion - Tim Wessman - 01-29-2014 04:12 PM
(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.
RE: Temperature Conversion - jgreenb2 - 01-29-2014 04:31 PM
(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
RE: Temperature Conversion - Miguel Toro - 01-29-2014 04:49 PM
(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.
RE: Temperature Conversion - Han - 01-29-2014 05:23 PM
(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.
RE: Temperature Conversion - Manolo Sobrino - 01-29-2014 06:01 PM
(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.
RE: Temperature Conversion - jgreenb2 - 01-29-2014 07:01 PM
(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.
RE: Temperature Conversion - Han - 01-29-2014 07:37 PM
(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).
RE: Temperature Conversion - Tugdual - 01-29-2014 09:19 PM
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.
RE: Temperature Conversion - CR Haeger - 01-29-2014 10:23 PM
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
RE: Temperature Conversion - John Colvin - 01-30-2014 12:58 AM
(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.