SOLVE reentrancy

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
Post Reply
jneven
Posts: 11
Joined: Sat Jan 23, 2021 6:32 pm
Location: Belgium

SOLVE reentrancy

Post by jneven »

I tried to use PGMSLV/SOLVE into a function used in the SOLVE application.
I got a message "solve(solve)" when executing SOLVE.
I suppose it's because SOLVE is not reentrant.

Or am I wrong ?
whuyse
Posts: 167
Joined: Thu Dec 21, 2017 1:23 pm

Re: SOLVE reentrancy

Post by whuyse »

You're not wrong. You can't use SOLVE recursively. You can SOLVE an INTEG, or INTEG a SOLVE, once, but not SOLVE a SOLVE or INTEG an INTEG ;-)
Werner
42S #3249S01123
DM42 #00345
DM41X #01215
jneven
Posts: 11
Joined: Sat Jan 23, 2021 6:32 pm
Location: Belgium

Re: SOLVE reentrancy

Post by jneven »

Thanks Werner!
Thomas Okken
Posts: 968
Joined: Tue May 02, 2017 5:48 pm
Location: The Netherlands
Contact:

Re: SOLVE reentrancy

Post by Thomas Okken »

Yes, the solver and integrator both have a bunch of internal state that is stored in global variables, making them non-reentrant. This is fixable by putting everything in dynamically allocated data objects, and maybe I'll end up doing it in Plus42 (*). The reason I haven't done it ages ago is that it can't be done in a way that is 100% backward compatible (**), but it could be done by introducing new, reentrant versions of SOLVE and INTEG.

(*) I assume the reason HP didn't make SOLVE and INTEG reentrant in the HP-42S is that the machines were too slow to make nested SOLVE or INTEG practical in most cases, but with today's hardware, that is no longer a concern.

(**) The problem is that with the present instructions, the system wouldn't be able to know with perfect confidence when a SOLVE, happening while SOLVE is already active, is supposed to be a nested SOLVE, and when the intent is to abandon the current SOLVE and replace it with a new one. And same for INTEG, of course.
Post Reply