Possible bug with polar_coordinates
07-03-2018, 04:10 AM
Post: #1
 Jacob Wall Member Posts: 157 Joined: Dec 2013
Possible bug with polar_coordinates
Today I spent some time chasing down a very unexpected result with polar_coordinates command that I by chance encountered. I don't think this whatever is causing it is necessarily limited to this command. I have a little program to demonstrate this:

Code:
EXPORT IFERR_polar() BEGIN   LOCAL m;   RECT_P();   TEXTOUT_P("Press Any Key",G0,0,0,3);   REPEAT     IFERR m:=WAIT(-1); THEN       m:=4;     ELSE     END;   UNTIL TYPE(m)==0 OR IFTE(SIZE(m)>1,m(1)==3,0);   MSGBOX(polar_coordinates({30,20}));   MSGBOX("Still running"); END;

Try running the program and:
1. When prompted, press any key other than the On key
2. When prompted, press the On Key

What is happening here?
1. When the user presses any key other then the On key, then the IFERR trap doesn't have an error to trap, the polar_coordinates calculation returns the expected result, and the "Still running" message box confirms the program is still running.
2. When the user presses the On key, then the IFERR trap does have an error to trap, the polar_coordinates calculation returns a bizarre error even though the program is still running as proven by the following "Still running" message box.

If I replace the polar_coordinates command with a user-defined function, then there is no problem so I can get around this by just using my own code for the calculation, however I'm more curious if someone has an explanation for this?
07-03-2018, 04:53 AM
Post: #2
 cyrille de brébisson Senior Member Posts: 1,047 Joined: Dec 2013
RE: Possible bug with polar_coordinates
Hello,

In PPL, the ON key is tested at the begining of each function's execution to see if the user is pressing the ON key and wants to stop execution.
This test is done by checking a 64 bit integer where each bit correspond to one of the calculator keys. If the bit corresponding to the ON key is set, then it means that the ON key is pressed. This integer is maintained by the keyboard interrupt function.

The CAS is inherently a unix program. And it's cancel mechanism works around checking if the ctrl+C signal has been sent. To do this, it uses a boolean variable set to false in the main loop (the one waiting for you to press a key and to react to it). and set to true when the user presses ctrl+c...

The issue here is that CAS does not have a IFERR or similar and does not have a way to "cancel" the ctrl+c signal.

All this being said, what is happening is that your program is running. the user presses ON. The calcualtor ON handling code sets the ON key bit in the keymap to 1 and sets the ctrl+c boolean to true.
the PPL evaluator, which is running detects the ON key. Generates an error. The error is caught by the IFERR and PPL continues evaluation.
when polar_coordinate is called, the CAS detects that ctrl+c is set and generates an error. this error is returned to PPL which continues execution.
When the progam terminates, the ctrl+c boolean is cleared.

Obviously, something needs to be done about this. maybe clearing the ctrl+c boolean when IFERR is called? I need to think about it some more.

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.
07-04-2018, 01:56 AM
Post: #3
 Jacob Wall Member Posts: 157 Joined: Dec 2013
RE: Possible bug with polar_coordinates
Thanks Cyrille for the explanation. It makes sense with what I was seeing.
 « Next Oldest | Next Newest »

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