Difference between lower and upper case chars in CAS and Home

[tiamattia]

Hello
I'm new to this calculator and I'm trying to understand some of its beaheviur.

When the calc. is in Home the chars are by default in uppercase, in CAS instead they are lower case by default. Why this beaheviur?

Is it correct to say that in CAS lower case chars are interpreted as symbolyc vars, upper case chars are interpreted as values?

What's the difference between lower case and upper case commands?

Thanks everyone for the help.

[DrD]

Parisse once wrote:

Quote:The CAS parser was adapted from the Xcas parser (some rules are not available), and the CAS lexer has less keywords than the Xcas parser: for example synonyms were removed unlike in Xcas, where you can sometimes use several keywords for the same command (one is familiar for TI users, one for maple users, etc.). The general rule in Xcas is that you can type a command all lowercase (no need to switch if you type from keyboard). The general rule in Prime Home is that you can type a command all uppercase. Some commands exist in Home uppercase and CAS lowercase that have almost the same functionnality, but not exactly the same: convert is one example, since convert in CAS can also do symbolic conversions. I think that if HP modifies the UI so that commands in the catalog appear in lowercase when called from CAS mode and both commands exist, a large part of the confusions would disappear.

Generally, Home commands are upper case commands, and CAS commands are lower case. You can use either type of command in either view, but many of the CAS command arguments must be handled within quotation marks, in order to work in Home view.

For example:
Suppose you want to solve a transfer function for a certain value in the s-plane. If the transfer function is given as Gp=1/(s+1), it could be entered
as:

[CAS ]
Gp:=1/(s+1);

or

[Home]
CAS("Gp:=1/(s+1)"); // note quotes

Then you might want, for example, to substitute s=1, in the transfer function equation:

[CAS]
subst(Gp,s,1); // ==> 1/2

or

[HOME]
subst("Gp,s,1"); // ==>1/2

The example used lower case (CAS) variables, which would not work in Home view. This is a confusing requirement, but as time marches on, perhaps HOME vs CAS operation will become more fluid.

The secret to success is to use the prime often! A great teacher is, (ahem), a mistake!

-Dale-

[tiamattia]

Thanks DrD for the answer. For a beginner this can be quite confusing, but as you said, practice will solve the dubts.

Instead, from what i understood about vars (tell me if i'm wrong):
In home view are accepted only names that exist, if the name does not exist, the parser checks if that name should be parsed as a product of existing names.

So if i store 1 in A and 2 in AA, the result of AAA is A*A*A: 8.
So the parser checks single chars vars first then vars with a name made of more chars. If it can't find a combination -> syntax error.

In CAS view instead all names are accepted but existing ones are directly evaluated.

[DrD]

The best answer I can give you is to check the help doc's on the calc:

[Help] [Tree] [Variables]

I'll be the first to admit the documentation isn't perfect, but reserved variables, (in particular), are described. You will need this information early on.

One other thing to avoid (in general) is implicit multiplication. You show AAA as shorthand for A*A*A. The prime doesn't like AAA, except in certain cases like 2PI, for example. For consistency, don't use 2PI, go for 2*PI, and avoid implicit terms.

When you begin programming, simplicity details (like avoiding implicit multiplication) will make life easier. Some folks recommend avoiding reserved variables, but I like to incorporate them, avoiding local vs global issues. This comes with the risk of not making sure a reserved variable doesn't already contain a previous value, but this risk actually helps me, by knowing that I have to initialize them first, instead of using a reserved variable, "by chance," and spend a long time trying to debug a function using it, only to find a previous value is preventing success. This is a common mistake.

-Dale-