Page **1** of **1**

### SOLVE reentrancy

Posted: **Thu Nov 25, 2021 1:17 pm**

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 ?

### Re: SOLVE reentrancy

Posted: **Thu Nov 25, 2021 4:29 pm**

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

### Re: SOLVE reentrancy

Posted: **Thu Nov 25, 2021 4:36 pm**

by **jneven**

Thanks Werner!

### Re: SOLVE reentrancy

Posted: **Fri Nov 26, 2021 1:28 am**

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.

### Re: SOLVE reentrancy

Posted: **Wed Dec 01, 2021 3:51 pm**

by **jneven**

Thank you, Thomas!

I only tested this because I first looked for the lazy and luxurious solution before making an iterative approach myself.

I think, in the spirit of HP-42S, a single level "Solve" is normally sufficient.