[35s] Program Err Trapping

04242016, 08:40 AM
(This post was last modified: 04242016 02:41 PM by brianddk.)
Post: #1




[35s] Program Err Trapping
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 149), 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 squareroot, 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 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? MyCalcs: Physical: {hp48gx, hp50g, hp35s} Emu: {hp42s(Free42), hp41c(v41)} Blog: https://brianddk.github.io/ 

04242016, 02:44 PM
Post: #2




RE: [35s] Program Err Trapping
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'.
MyCalcs: Physical: {hp48gx, hp50g, hp35s} Emu: {hp42s(Free42), hp41c(v41)} Blog: https://brianddk.github.io/ 

04242016, 03:09 PM
Post: #3




RE: [35s] Program Err Trapping
First of all, hello and welcome.
(04242016 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. (04242016 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. (04242016 08:40 AM)brianddk Wrote: This is the best I can come up with to trap for errors in my programs. 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 

04292016, 10:45 PM
Post: #4




RE: [35s] Program Err Trapping
(04242016 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. (04242016 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. (04242016 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. MyCalcs: Physical: {hp48gx, hp50g, hp35s} Emu: {hp42s(Free42), hp41c(v41)} Blog: https://brianddk.github.io/ 

« Next Oldest  Next Newest »

User(s) browsing this thread: