[35s] Bizarre program bugs when running under solver - Hewlett Packard

This is a discussion on [35s] Bizarre program bugs when running under solver - Hewlett Packard ; I'm getting bizarre and wrong behaviour from programs which execute as a subprocess to the solver. Here's the most trivial case I was able to come up with to reproduce the problem: B001 LBL B B002 INPUT T B003 INPUT ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: [35s] Bizarre program bugs when running under solver

  1. [35s] Bizarre program bugs when running under solver

    I'm getting bizarre and wrong behaviour from programs which execute as a
    subprocess to the solver. Here's the most trivial case I was able to
    come up with to reproduce the problem:

    B001 LBL B
    B002 INPUT T
    B003 INPUT X
    B004 CF 1
    B005 FS? 1
    B006 XEQ C001
    B007 0.2xX-T
    B008 RTN
    C001 LBL C
    C002 STOP
    C003 RTN

    When program B is executed normally, the XEQ C is never called, as ought
    to be the case. When I set FN=B and solve, it calls C, even though it
    should not, and hits the STOP. All kinds of conditionals seem to be
    broken when running under the solver, not just FS?. I looked through
    the manual for some statement about functionality which is not available
    in programs being "solved" instead of executed, but I could not find
    anything. WTF is going on? Do other people have this problem, or do I
    have a calculator with a subtle defect that needs to be returned?

    Any thoughts or insight would be appreciated.

  2. Re: [35s] Bizarre program bugs when running under solver

    Replying to myself:

    > I'm getting bizarre and wrong behaviour from programs which execute as a
    > subprocess to the solver. Here's the most trivial case I was able to
    > come up with to reproduce the problem:
    >
    > B001 LBL B
    > B002 INPUT T
    > B003 INPUT X
    > B004 CF 1
    > B005 FS? 1
    > B006 XEQ C001
    > B007 0.2xX-T
    > B008 RTN
    > C001 LBL C
    > C002 STOP
    > C003 RTN
    >
    > When program B is executed normally, the XEQ C is never called, as ought
    > to be the case. When I set FN=B and solve, it calls C, even though it
    > should not, and hits the STOP. All kinds of conditionals seem to be


    I beat my head against this problem for several more hours after
    posting, and I now have a hypothesis for what's going on. The solver
    needs to find all the INPUT statements when it first starts up so that
    it can prompt the user for the variables as necessary. In order to find
    ALL the relevant INPUT statements, it needs to examine all the code
    lines which are going to execute. To do this, it employs a simple
    heuristic to step through the program in an initial pass:

    * Do not store anything to variables
    * Do not put anything on the stack
    * Evaluate all conditionals as if they were true
    * Prompt for any variable in an INPUT statement
    * Obey any XEQ, GTO or RTN statement
    * Obey any STOP statement (I don't know why)
    * End upon reaching the RTN from the original program

    After making one initial pass in this manner, presumably to find the
    INPUT statements, it then starts executing normally to actually evaluate
    the function. However, this initial "INPUT finding" heuristic is
    braindamaged, because it causes most loops written the usual way to
    become infinite loops. Whoever came up with this can't have tested it
    on a nontrivial program, and to make matters worse, this behavior
    appears to be undocumented.

    On the bright side, once the issue is understood, it is possible to work
    around it by inserting an always-false conditional followed by a return
    right after your input statements. This RTN will execute in the initial
    modified-behavior pass, and then never again. Example:

    B001 LBL B
    B002 INPUT T
    B003 INPUT X
    B004 CF 1
    B005 FS? 1
    B006 RTN
    B007 FS? 1
    B008 XEQ C001
    B009 0.2xX-T
    B010 RTN
    C001 LBL C
    C002 STOP
    C003 RTN

    I still wonder if I'm missing something, since I searched the newsgroup
    and the hpmuseum articles and found nothing related to this. I'd be
    surprised if I were actually the first person to run into this issue,
    but perhaps running the solver on arbitrary programs is just not
    commonly-used functionality? Perhaps I just didn't find the right terms
    to search on.

+ Reply to Thread