Threaded Mode | Linear Mode

brianddk · (This post was last modified: 04-24-2016 02:41 PM by brianddk.)

I've noticed on other models (and simulators) there are flag configurations that would effectively amount to 'Continue On Error'. For the hp42s, this would refer to flag 25 (User's Guide pg 275).

Although there are 'Halt on Overflow' flags in the 35s (flags 5,6 page 14-9), they only seem to control overflow and don't seem to have a 'Continue on Error' setting. This makes it very difficult to trap for errors in your programs. My only workaround is a Kludge.

Say for example you have to take a square-root, and you know it will only work on reals, not vectors or complex numbers. Since there doesn't appear to be a CPLX? or VECT? instruction, you have to produce some way to trap these errors. Best I can come up with is to make programs Restartable with user flags. Here's an example:

Code:

T001 LBL T          ;Main Routine

T002 FS? 0          ;Check to see if we have been restared

T003 GTO T007       ;.. if so, go to Flag_0 restart point

T004 SF 0           ;Enter danger zone

T005 SQRT(X)        ; dangerous operation

T006 CF 0           ;Leave danger zone

T007 FS? 0          ;Flag_0 Restart point

T008 XEQ T011       ;If flag was set, we must have restarted

T009 42             ;All code gets here, even errors

T010 RTN            ;Return the answer to everything.

; 

; Error Trap Code

;

T011 SF 10          ;Prepare to display msg

T013 FOUND BUG      ;Display message

T014 PSE            ;.. temporarily

T015 CF 10          ;Unset our flags

T016 CF 0           ;.. all of them

T017 RTN            ;Done with trap, continue prog

When you run this with a real in STKX, then everything goes fine. But if you run it with a VECT or IMAG in STKX, then you will see an INVALID DATA message, as well as a FLAG_0 annunciator. If you then rerun PRGM_T then it will restart realizing FLAG_0 was never cleared, so an error must have occurred at T005

Since the flag annunciators are visible this at least lets the user know that something happened, and they should do something (like rerun the PRGM).

This is the best I can come up with to trap for errors in my programs.

Anyone have a better way for the 35s?

brianddk · 04-24-2016, 02:44 PM

Updated comments in the code... Realized there are about 15 restart points you can create per program based on this type of trapping. Many more if you start consuming system flags, though that's a bit tricky since they are 'invisible'.

Dieter · 04-24-2016, 03:09 PM

First of all, hello and welcome.

(04-24-2016 08:40 AM)brianddk Wrote: I've noticed on other models (and simulators) there are flag configurations that would effectively amount to 'Continue On Error'. For the hp42s, this would refer to flag 25 (User's Guide pg 275).

The 41C was the first HP to include flags for error trapping (flag 25 for all errors, flag 24 for overflow). Earlier calculators – and most midrange programmable models that followed – did not offer such a feature.

(04-24-2016 08:40 AM)brianddk Wrote: Since there doesn't appear to be a CPLX? or VECT? instruction

No, there are no such tests. But nevertheless your program can check whether X is a simple real, a vector or complex. I seem to remember this has been discussed here some time ago.

(04-24-2016 08:40 AM)brianddk Wrote: This is the best I can come up with to trap for errors in my programs.
Anyone have a better way for the 35s?

IMHO the best method is a careful choice of the algorithm and a close look at the mathematics behind them. The points where errors may occur usually can be identified beforehand, e.g. in your example the sqrt where X may be negative. Here a x<0? test can branch to an alternate routine that may handle this case, e.g. evaluating the sqrt by 0,5 i 0 y^x in order to get a complex solution.

Dieter

brianddk · 04-29-2016, 10:45 PM

(04-24-2016 03:09 PM)Dieter Wrote: The 41C was the first HP to include flags for error trapping (flag 25 for all errors, flag 24 for overflow). Earlier calculators – and most midrange programmable models that followed – did not offer such a feature.

Ohh... Thanks for the correction. My exposure to the calcs were (in order) {48gx, Free42s, 50g, 35s}. My first three just happened to implement it and didn't realize they were the outliers.

(04-24-2016 03:09 PM)Dieter Wrote: No, there are no such tests. But nevertheless your program can check whether X is a simple real, a vector or complex. I seem to remember this has been discussed here some time ago.

Yeah, I got the complex check figured out, but I can't seam to figure out how to test for a 2D/3D vector. Been combing the forum archives without luck... I'm sure I'll hit it sooner or later.

(04-24-2016 03:09 PM)Dieter Wrote: IMHO the best method is a careful choice of the algorithm and a close look at the mathematics behind them. The points where errors may occur usually can be identified beforehand, e.g. in your example the sqrt where X may be negative. Here a x<0? test can branch to an alternate routine that may handle this case, e.g. evaluating the sqrt by 0,5 i 0 y^x in order to get a complex solution.

Yes, honestly, I haven't hit a snag yet where a test for complex or vector is required, I just noticed a few things that surprised me. Getting a bit more accustomed to things now though.