New Version: 2.1.14181 (2018 10 16)

[Eric Rechlin]

(04-13-2020 12:55 AM)Jacob Wall Wrote:  I looked at this again now, and the issue is the use of IFERR when combined with CAS commands. Take this example:

Code:

EXPORT slk3()
BEGIN
  LOCAL a:=0,b:=0,c:=0,d:=0,r:=0;
  LOCAL OP3:=0,F:=0,Z22:=0;
  PRINT();
  INPUT({{a,[0],{10,20,1}},{b,[0],{40,20,1}},{c,[0],{10,20,2}},{d,[0],{40,20,2}}},"Distance Between 2 Points",{"X₁:","Y₁:","X₂:","Y₂:"},{"Enter a Value for X₁ (Any Real Number).","Enter a Value for Y₁ (Any Real Number).","Enter a Value for X₂ (Any Real Number).","Enter a Value for Y₂ (Any Real Number)."});
  IF 0 THEN BREAK;
  END;
  // IFERR 3/0 THEN END;
  r:=√((c-a)^2+(d-b)^2);
  MSGBOX(r);
  r:=approx(r);
  MSGBOX(r);
  F:=fp(r);
  r:=exact(r);
  MSGBOX(r);
END;

Run it as is and should show the distance in each of the three MSGBOX instances, then un-comment the line with IFERR which has a divide by zero error on purpose. I think the first time running with that line un-commented will still work, but then something happens and the next run and you'll see just 'r' in the second and third MSGBOX, which follow the CAS commands.

If no errors get triggered by IFERR, then everything should be just fine. My workaround for this was to just write my own PPL commands to substitute for the CAS commands I was using, there was no other solution that I found because the IFERR in my case was to catch a ON key press.

Related topic https://www.hpmuseum.org/forum/thread-10995.html

Thanks for looking into it. I wonder if maybe there was a bug introduced into HP-PPL that is causing this? I'm testing with the 2020-01-16 release so the behavior remains the same now as it was when this issue was first noticed after the 2018-10-16 release. It doesn't make sense to me that the IFERR processing would "corrupt" the unrelated variable like that.