CAS vs non-CAS

[Han]

I posted this in another forum, but I thought it might be useful here. After having gotten used to the fact that Home and CAS were separate from each other, I just assumed the idea that follows below. I may be completely wrong in my understanding, though. Perhaps this should be mentioned in the update of the manual?

The idea:

COMMAND() vs command() -- results depend on CAS vs non-CAS mode. Generally speaking, COMMAND() is used in non-CAS environment and command() is used in CAS environments. They behave similarly, but are not exactly the same. In many cases, the upper-case vs lower-case does not matter (for example, "IF" and "if" are treated the same).

TYPE(3*x) in CAS mode is treated as if you use TYPE(3*x) in the Home screen. That is, 3*x is evaluated first. And then the resulting object is passed to TYPE(). Tthe odd thing is they have slightly different error messages because of the mode. It is, in a sense, the opposite to doing CAS("function()") in a non-CAS program.

type(3*x) in CAS mode is treats 3*x as if it were an an algebraic expression. In non-CAS mode, 3*x would have produced an error if there was no global variable x.

This system, however, is not perfect (such as in the case of TYPE(1..2) where you get a reset when used in the CAS mode.

In summary, it appears as though one is a shell for the other. For example, it may very well be that COMMAND() preprocesses its arguments and then passes it to command() -- or perhaps vice versa. The distinction between COMMAND() and command() needs to be clarified, though. I have simply been assuming that COMMAND() preprocesses and then passes to command(). Is this how it works?

At any rate, missing (?) somewhere in this process is error-trapping code which then leads to warmstarts when used in the unexpected environment.

Edit: removed gibberish and added some sense into the original post.

Edited: 3 Oct 2013, 8:11 p.m. after one or more responses were posted

[Walter B]

Quote:

---

I somewhat what follows below for granted after ...

---

My English isn't sufficient for decoding that. Please help.

[deleted]

This Message was deleted. This empty message preserves the threading when a post with followup(s) is deleted. If all followups have been removed, the original poster may delete this post again to make this placeholder disappear.

[Han]

Quote:

---

My English isn't sufficient for decoding that. Please help.

---

Make that two of us!

"After having gotten used to the fact that Home and CAS were separate from each other, I just assumed the idea that follows below. I may be completely wrong in my understanding, though."

[cyrille de Brébisson]

Hello,

Here is how things work internally:

In Numeric mode, MOST functions are case insensitive, but use an uppercase display.

the parser distinguished between fully qualified names (My_Program.MyVariables) and non fully qualified ones (FOO)

The order of priority in name resolution for a non fully qualified name is:
1) Localy known program names (functions or vars)
2) Build in functions and variables (some beeing case insensitive)
3) Current app functions and vars
4) global program exported functions and vars
5) all standard app non forced fully qualified functions/vars (F1 for example. as you no doubd have discovered, you can call F1 even if function is not the current app. this is why)
6) user variables (the ones that get created when you do abc:=1)
7) CAS (functions and variables)

Having CAS here as number 7 is usefull, in the same way than allowing use of F1 even if function is not the current app is useful... However, it is dangerous (mostly for power users) as it can lead to strange results when used in non trivial cases, or can lead to confusion, or can be overriten...

If you want to use a CAS command, the best is to fully qualify it by doing: CAS.functionName(params)...

note, that most Numerical functions will evaluate all their parameters before they are called.

when calling a CAS function from the numerical world, the parameters will be transformed into a cas object (unevaluated) so that the CAS gets to decide what to do with them. However, it means that these objects need to be valid numerical mode objects...
If you want to call a cas function from numerical and the parameters are not valid in numerical mode (such as a undefined variables or a symbolic matrice), you need to use CAS.function("input") the string input will be parsed by the CAS and not the numerical mode and the CAS rules will apply to it.

As a general rule, the CAS has access to all the numerical mode functions/variables, with the exceptions of local variables... As a result, and as an exception to the rule above, local variables in CAS functions arguements get replaced by their values before the CAS is called...

so, here you are, the long story about how these work with each others!

cyrille

[Han]

Quote:

---

Hello,

Here is how things work internally:

In Numeric mode, MOST functions are case insensitive, but use an uppercase display.

the parser distinguished between fully qualified names (My_Program.MyVariables) and non fully qualified ones (FOO)

The order of priority in name resolution for a non fully qualified name is:

1) Localy known program names (functions or vars)

2) Build in functions and variables (some beeing case insensitive)

3) Current app functions and vars

4) global program exported functions and vars

5) all standard app non forced fully qualified functions/vars (F1 for example. as you no doubd have discovered, you can call F1 even if function is not the current app. this is why)

6) user variables (the ones that get created when you do abc:=1)

7) CAS (functions and variables)

Having CAS here as number 7 is usefull, in the same way than allowing use of F1 even if function is not the current app is useful... However, it is dangerous (mostly for power users) as it can lead to strange results when used in non trivial cases, or can lead to confusion, or can be overriten...

If you want to use a CAS command, the best is to fully qualify it by doing: CAS.functionName(params)...

note, that most Numerical functions will evaluate all their parameters before they are called.

when calling a CAS function from the numerical world, the parameters will be transformed into a cas object (unevaluated) so that the CAS gets to decide what to do with them. However, it means that these objects need to be valid numerical mode objects...
If you want to call a cas function from numerical and the parameters are not valid in numerical mode (such as a undefined variables or a symbolic matrice), you need to use CAS.function("input") the string input will be parsed by the CAS and not the numerical mode and the CAS rules will apply to it.

As a general rule, the CAS has access to all the numerical mode functions/variables, with the exceptions of local variables... As a result, and as an exception to the rule above, local variables in CAS functions arguements get replaced by their values before the CAS is called...

so, here you are, the long story about how these work with each others!

cyrille

---

Hi Cyrille,

This is _extremely_ useful information and I think will likely eliminate a good number of questions from programmers. Thank you for giving us insight on how the internals work.