ROUND instruction not working as expected
|
04-24-2016, 10:59 PM
Post: #1
|
|||
|
|||
ROUND instruction not working as expected
I am using the ROUND instruction in a program. This is my code:
QmFlow1:=ROUND(QmFlow1,0); Yes, I realize I am writing back over my original value, which is intended. This code no longer appears to work in the virtual emulator, ver. 10077. It worked in the previous version. Is this the intended behavior? Thanks, rcf |
|||
04-25-2016, 05:13 AM
Post: #2
|
|||
|
|||
RE: ROUND instruction not working as expected
Hello,
Can you give numerical example (ie, what is the value of the variable when you call ROUND) so that we can check? Cyrille Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP. |
|||
04-25-2016, 03:33 PM
Post: #3
|
|||
|
|||
RE: ROUND instruction not working as expected
Follwing up here, I've tried the combinations I can think of and have not been able to reproduce this. Could you please post (or private message me, or email calchelp at hp.com) your source for that program if you are still having a problem?
TW Although I work for HP, the views and opinions I post here are my own. |
|||
04-25-2016, 11:22 PM
Post: #4
|
|||
|
|||
RE: ROUND instruction not working as expected
You seem to be puzzled, so I went back and investigated further. My calculator is set to fix 4. When I display the number, I was expecting it to display 0 decimal places, (that's what help says it will do if the optional "places" parameter is used, and how the previous firmware version handled the number) but instead, it continued to display 4 decimal places. The number was rounded as expected to 0 decimal places (which I didn't catch until now).
Hope this helps. rcf |
|||
04-26-2016, 02:21 AM
Post: #5
|
|||
|
|||
RE: ROUND instruction not working as expected
How are you viewing or printing the number?
If I understand correctly, you are rounding properly but then when it is printed in some way you see .0000 on the end of your number or something? TW Although I work for HP, the views and opinions I post here are my own. |
|||
05-01-2016, 01:57 AM
Post: #6
|
|||
|
|||
RE: ROUND instruction not working as expected
My virtual calculator is set to fix 4 as the display setting. I was displaying the rounded value in an INPUT statement, but this code displays the rounded value the same way as the INPUT statement.
This is the code: EXPORT roundfail() BEGIN LOCAL fail; fail:=1.23456; fail:=ROUND(fail,2); END; In the above example: The previous firmware version would display 1.23 The present version firmware displays 1.2300 Hope this makes it more clear. rcf |
|||
05-01-2016, 03:33 AM
(This post was last modified: 05-01-2016 03:43 AM by informach.)
Post: #7
|
|||
|
|||
RE: ROUND instruction not working as expected
Hi!, Bob Frazze:
Round: Rounds value, to decimal places. Also accepts, complex numbers. ROUND(value,places) ROUND can also round, to a number, of significant digits, if places, is a negative integer (as shown in the second example below). Examples: ROUND(7.8676,2) returns 7.87 ROUND(0.0036757,-3) returns 0.00368 If you configure FIX 4 decimal's, the result is with 4 decimals, but, the ROUND, rounded the number, but not determine, the number, of decimals. The ROUND criterion, is ... if the result, is < 1.2350, the final ROUND is 1.2300; however if is > 1.2350, the final ROUND is 1.2400. Kind Regards. informach. |
|||
05-01-2016, 04:27 AM
Post: #8
|
|||
|
|||
RE: ROUND instruction not working as expected
(05-01-2016 01:57 AM)Bob Frazee Wrote: Hope this makes it more clear. Just to be clear, you are displaying your number in an input form after you do the round? TW Although I work for HP, the views and opinions I post here are my own. |
|||
05-01-2016, 09:58 AM
Post: #9
|
|||
|
|||
RE: ROUND instruction not working as expected
(05-01-2016 01:57 AM)Bob Frazee Wrote: My virtual calculator is set to fix 4 as the display setting. Any chance that your previous firmware version "Number Format" happened to be set to "Standard," for this example? (That setting would truncate the trailing zeros). When "Number Format" is "Fixed" at some number of places, it seems like that many places should be visible, padded trailing zero's as necessary, from the ROUND() operation. (Maybe for display formatting purposes, for example). -Dale- |
|||
05-01-2016, 05:05 PM
Post: #10
|
|||
|
|||
RE: ROUND instruction not working as expected
(05-01-2016 01:57 AM)Bob Frazee Wrote: EXPORT roundfail() Hello, This is what is happening: In the old firmware, your results would be displayed always with STD on entry to the INPUT form regardless of your system settings. However, when you entered another number, or modified to one in there, it would parse and store the result string with the system setting. You observe this by this simple experiment: A:=123.456789 INPUT({A,B}) When you first enter, your values are shown as STD with all digits. Press EDIT and then ENTER to edit A again, and you'll note how A will now display in FIX 4. In other words, only on first entry did it show as STD - else it would follow your system settings. The new firmware corrects this arguably incorrect behavior. It follows your system settings just like everything else in the system. If you really would like it to show only 2, I'd recommend putting the display to FIX 2 before your start your INPUT, and restore it after. Does this make sense? Any further concerns? TW Although I work for HP, the views and opinions I post here are my own. |
|||
05-01-2016, 09:06 PM
Post: #11
|
|||
|
|||
RE: ROUND instruction not working as expected
Thankyou Tim for your explanation in Post#10.
My original statement (which was not very clear) was that the "places" part of the ROUND(value,places) instruction in v8151 was behaving differently in v10077. Now I understand why and why you changed it's behavior. It also appears the calculator help for this instruction needs to be updated. It didn't change from v8151, and doesn't appear to me to follow your explanation. Thanks again; rcf |
|||
05-02-2016, 04:23 PM
Post: #12
|
|||
|
|||
RE: ROUND instruction not working as expected
(05-01-2016 09:06 PM)Bob Frazee Wrote: My original statement (which was not very clear) was that the "places" part of the ROUND(value,places) instruction in v8151 was behaving differently in v10077. Now I understand why and why you changed it's behavior. We are still not connecting somewhere I think. Not sure why I am being so dense... :-( As far as I can tell, ROUND has not changed at all. Are you feeling part of the help for the ROUND command is the thing that is unclear? Or do you think the ROUND changed in some way? I am just not connecting with you... TW Although I work for HP, the views and opinions I post here are my own. |
|||
05-03-2016, 01:29 AM
Post: #13
|
|||
|
|||
RE: ROUND instruction not working as expected
Well..., let's try this again.
I am using the ROUND instruction in a program. This is my code: QmFlow1:=ROUND(QmFlow1,0); My calculator is set to fix 4 (Number Format: in the Home settings). I now take QmFlow1 and use the INPUT instruction to display QmFlow1's value. In the above example, if QmFlow1's value was 123.4567, in v8151 it displayed as 123. In v10077 it displays as 123.0000. Per the on calc help file, ROUND(QmFlow1), rounds QmFlow1 to system display settings (or I interpret it as 123.0000). If optional places is given, ROUND(QmFlow1,0), rounds value to 0 decimal places (which I interpret should display the value as 123 or 123.). The example given in the help file, appears to bear that assumption out. It doesn't appear that Number Format: has any bearing on how QmFlow1 is displayed, at least per the example. All I can say is something changed in the way QmFlow1 is displayed in v10077. Either ROUND changed or INPUT changed or maybe something else changed. It's ok either way, but the help file should reflect how the instruction actually operates. rcf |
|||
05-03-2016, 02:37 PM
Post: #14
|
|||
|
|||
RE: ROUND instruction not working as expected
(05-03-2016 01:29 AM)Bob Frazee Wrote: QmFlow1:=ROUND(QmFlow1,0); Understood - you have now rounded to "123" internally on the number. That number displays using your system settings. Quote:if QmFlow1's value was 123.4567, in v8151 it displayed as 123. In v10077 it displays as 123.0000. Correct, INPUT follows the system display completely now. It did before - but incorrectly not for first display in the box. It behaves the way everything else in the system does now. Your system settings dictate how the numbers will be shown. Quote: settings (or I interpret it as 123.0000). It would be 123.4567 - you are in FIX 4. Hence no rounding actually would happen. Quote: If optional places is given, ROUND(QmFlow1,0), rounds value to 0 decimal places (which I interpret should display the value as 123 or 123.). It changes the internal number itself - not display. Display is completely separate from the internal digits in the number. Quote: The example given in the help file, appears to bear that assumption out. It doesn't appear that Number Format: has any bearing on how QmFlow1 is displayed, at least per the example. I'll look if I can think of a way to improve the ROUND help. What we are really trying to show there is that your number value changed. However, if you are set in FIX 4 for example, all the results shown in the help files for every example will be "wrong" because they will show using your system settings. INPUT displays using your system format. I can possibly add a sentence about this in the help, but it seems to me like something that is simply expected since the rest of the system has ALWAYS behaved that way. INPUT was just brought into compliance for that first display. If you'd like a number to be displayed in a specific way in the INPUT form, you could either convert the number to a string variable before the INPUT or set your display settings before the INPUT form, and then restore them after. TW Although I work for HP, the views and opinions I post here are my own. |
|||
05-05-2016, 07:08 AM
Post: #15
|
|||
|
|||
RE: ROUND instruction not working as expected
Quote:INPUT displays using your system format. I can possibly add a sentence about this in the help, but it seems to me like something that is simply expected since the rest of the system has ALWAYS behaved that way. INPUT was just brought into compliance for that first display. Tim, A while ago I wrote a thread about the fixed value issue in the input command. It's solved! THANKS TIM! Ps Looking to the presented fixed values, I was thinking that it is (maybe) nicer if they were right orientated, of course not for text. What do you think Tim? If it is a big software change, don't do it! — Dirk Hartland |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)