(08-22-2022 09:32 AM)Gil Wrote: [ -> ]...I press then EVAL
and get the message
EVAL Error
Non algebraic in expression
What's wrong?
Short answer:
That error can come up when working with limit expressions if system flag -124 is
set. Try clearing that flag and repeating your attempt.
Longer answer:
When working with limit expressions, make sure the following modes are observed:
- RAD angle mode
- Exact Mode ON (-105 CF)
- Symbolic results (-3 CF)
- CAS Object Evaluation allows CASCOMPEVAL (-124 CF)
- Silent Mode OFF (-120 CF) (if signed results are important)
Limit expressions are a bit problematic on the 50g. Generally speaking, you need to use the Equation Writer app to place the expression on the stack
or use backquote notation (
`<algebraic expression>`) to construct a fully-formed limit expression if you want it evaluated immediately. There's a bug in the compiler used by the command line interpreter (along with
STR→ and
OBJ→) that throws a syntax error when given perfectly legitimate limit expressions (
documented here).
Among other headaches, this means that limit expressions converted to strings with
→STR may generate a syntax error if re-compiled with
STR→ or
OBJ→.
To see this bug in action,
set the modes as described above and create a limit expression with the Equation Writer as follows:
Pressing ENTER will place the fully-formed limit expression on the stack:
Make a copy:
First, we EVALuate the expression by pressing
EVAL. Almost immediately you'll be presented with this alert:
Choose YES to proceed (this example was intentionally designed to show why that choice can be important):
The "+0" designation in the limit condition means "determine the limit as X approaches from the right". Choosing YES to the above alert designates that we want the signed result. You can probably guess what happens if the limit condition had "-0" appended instead.
Now let's see where the bug enters the mix. Presuming you kept a copy on the stack, drop the "-∞" result then execute
→STR:
(note that the full string is
"'lim(TAN(X),X=\pi/2+0)'")
That looks exactly as we might expect. Now attempt to convert that string back into the compiled limit expression using
STR→ or
OBJ→ (the result is the same either way):
The bug causes a syntax error, even though the string is perfectly legitimate. The conversion to a string was unfortunately a one-way street.