HP Forums

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

Try (−13_°F)▶_°C [enter] if you put the negative value inside round brackets it works as expected.

Paul,

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

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

Tom Lake
Malone, NY USA

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

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

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

(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

(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

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

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

(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

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

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

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

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

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

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.

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

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