ahdinw01@ULKYVX.BITNET (05/31/90)
[ I posted part of this several weeks ago but our mailer was acting up, sorry
for possible multiple posts]
SOS:
Does OBGET and EXGET still exist in the HP48SX? I went on a scavenger hunt
through the manuals and can't find anything. Maybe under a different name?
I admit these command are not often used BUT ARE occasionally nice to have.
If they no longer exist( tell me I'm wrong :-( ), are there work arounds???
Does anyone have a listing of features available on the 28S not avail on the
48SX (hopefully such a list doesn't exist)?
Also, does anyone know of a way to execute commands such as ->def or TRG* under
the equation writers rules application from within a program?
Thanks in advance,
Aaron Dinwiddie
==> Agima <==edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (05/31/90)
I don't think OBGET and EXGET are in the HP-48. They are replaced by
OBJ-> which, for an algebraic input, returns to the stack the
"outermost" function (e.g., "+" in '3+4*5'), the number of arguments of
that function, and the arguments. Then you can further decompose the
arguments by using OBJ-> again, so you can completely take apart and
reconstruct an algebraic. This operation is one of the things I (and
probably others) asked HP for; it is a natural way to work with
algebraic expressions.
The OBGET and EXGET operations had a shortcoming in that you could not
use them to take apart and reconstruct algebraics without additional
information. Viz., I think there exist expressions for which EXGET and
other HP-28 operations cannot be used to determine which subexpressions
are arguments of which functions unless your program has knowledge of
which functions are infix or prefix and how many arguments they take --
so you would need something like built-in tables of functions in order
to write a general algebraic manipulation program.
You can get TRG* in a program with { 'EXP(&A)' 'COS(&A/i)+SIN(&A/i)*i' }
^MATCH. This will look for EXP applied to any expression and will
convert it to the trigonometric definition. I think it may perform
multiple expansions if the expressions appear disjointly in the
original; you can defeat that by taking apart the expression first and
presenting only pieces to ^MATCH. On the other hand, if you want to
replace all occurrences, you need to call ^MATCH repeatedly until it
indicates there are no more matches.
You can use the RULES menu to find the appropriate match pattern. Just
create an expression with &A in it, such as 'SIN(&A)', or &B . . . if
there are more than one different subexpression. Then invoke RULES and
transform it as you please. ->DEF changes the above to
'(EXP(&A*i)-EXP(-(&A*i)))/(2*i)'. Incorporate the result in a list with
the original expression, and use ^MATCH.
-- edpedp@jareth@enet.dec.com (Always mount a scratch monkey.) (05/31/90)
Here's an example of why OBGET and EXGET are insufficient. Suppose you are examining an expression and want to know (in a program) what the arguments to a MOD function are. You might have an expression of the form 'MOD(B*C,D)' or 'MOD(B,MOD(C,D))'. Are the arguments to the first MOD function B*C and D or are they B and MOD(C,D)? Well, your program might do OBGETs and EXGETs and try to figure out the difference. But the results are nearly identical for the two expressions: If you use OBGET to get any object from the two expressions, you'll get the same type of object in each case -- both expressions have operator, variable, operator, variable, variable, in that order. If you use EXGET and look at the size of the result, you'll get the same numbers for both expressions -- 5, 1, 3, 1, and 1. Now your program could figure out the difference between B*C and MOD(C,D) by performing further analysis. But that's going to be messy. You'd have to do a tree traversal to analyze an algebraic expression anyway, but this is more involved than a straightfoward traversal. Some analysis routine calls itself to figure out what 'B*C' or 'MOD(C,D)' looks like, and then it reports that to its caller, which uses that to figure out whether the other argument was D or B, except that could also involve analysis, et cetera. This isn't a clean algorithm. OBGET and EXGET don't analyze algebraic expressions the way the expressions themselves are structured. OBJ-> does. Also, having APPLY makes it easier to put expressions back together. On the 28, it is necessary to convert to strings and fiddle with them in order to reconstruct an algebraic without evaluating it (which could cause unwanted substitution of variables or premature calculation of functions of constants). -- edp