es2a+@andrew.cmu.edu (Eric Stuyvesant) (12/05/90)
I hate to call this by the b** word, but it at least seems like
incorrect documentation:
In order to evaluate an expression with certain definite numbers
substituted for names that occur in the expression, HP has provided |.
Given an expression in level 2 and a list of name-value pairs in level
1, | is supposed to substitute the values for the names in the
expression.
In order to provide run-time error trapping, HP has provided the
IFERR trap-clause THEN error-clause {ELSE normal-clause} END structure.
From the HP 48 Programmer's Reference Manual, p. 174 (IFERR):
" If an error occurs during execution of the trap clause:
1. The error is ignored.
[Non-relevant points]
5. If Last Arguments is enabled [Flag -55 is clear], the arguments
to the command that caused the error are returned to the stack.
6. Program execution jumps to the error clause.
" [End Quote]
Now try:
-55 SF Enter @ Last Arguments disabled
'INV(X)' Enter
{ X 0 } Enter
\<< IFERR | THEN END \>> Enter @ | is Alpha-Blue-J
EVAL
This returns nothing (as advertised).
Next, try:
-55 CF Enter @ Last Arguments enabled
'INV(X)' Enter
{ X 0 } Enter
\<< IFERR | THEN END \>> Enter @ | is Alpha-Blue-J
EVAL
This returns 0.
This behavior is evident on both a REV-A machine and a REV-D machine.
I presume this is happening because the LASTARG command is returning
the last argument it has seen, in this case, an argument to some
not-user-visible function called by |. Can anyone shed any light on the
situation?
Thanks in Advance.
P.S. Am I the only one who thinks HP should include an ML version of
EXCO in their next calculator?
P.P.S. Why can't you single-step through IFERR structures?
-Eric Stuyvesant
es2a+@andrew.cmu.edu
Go MEMS!edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (12/05/90)
In article <YbKxdFy00WBLM1o15J@andrew.cmu.edu>, es2a+@andrew.cmu.edu (Eric Stuyvesant) writes: > I presume this is happening because the LASTARG command is returning >the last argument it has seen, in this case, an argument to some >not-user-visible function called by |. Can anyone shed any light on the I expect what is happening is that the | function takes apart the expression it is given. Piece by piece, it compares each variable to the list of substitions and makes appropriate replacements. And to put the expression back to together, it evaluates things as it goes. So for 'INV(X)' at X=0, it substitutes 0 for X and then tries to apply INV to it. This causes an error. 0 is returned to the stack, and you proceed to the error clause. -- edp
jurjen@cwi.nl (Jurjen NE Bos) (12/05/90)
This has nothing to do with IFERR, but it has to do with LASTARG. I don't have the manual handy, but it is true that any action that results in the evaluation of an algebraic or user program results in influencing the LASTARG register according to the behaviour of that program. So the EVAL function, and all operations that do evaluation, change the LASTARG during the computation of programs and algebraics, influencing the LASTARG register in cometimes unexpected ways. Operations doing evaluation are not only EVAL and |, but also differentiation, integration, ISOL, QUAD, STR-> (OBJ-> for strings), and many more. The LASTARG register contains what is left on the stack after an error, so you have to take care if you use IFERR. Hope to have cleared this up.