CAS-> Variable() warning msg?

[DrD]

In HOME when a variable is intended to be used as a function, for example: a:=x^2
then: a(4) => 16, etc., without further adieu.

In CAS a warning asserting that "Substitution" should be used for the expression in a. Depending on the expression, that could be a lot of extra baggage, and generates computational delay. Is there another context for a() than originally defined? (Why is the warning necessary in CAS)?

-Dale-

[parisse]

You are confusing an expression and a function (HOME does not have functions). Functional notation is reserved to function (f(x):=x^2 or f:=x->x^2 then f(2)), not to expressions where subst should be used (g:=x^2, subst(g,x=2) or g|x=2). I'm currently introducing in Xcas a new notation for substitution in expressions, like this: g(x=2).

[DrD]

The example, a:=x^2, was created in the CAS environment.

Upon switching to the HOME environment, for any a(n), //where a(x) is used as a pseudonym for standard function notation f(x), but functionally the same//, is operated on according to the function's definition, just like a function machine, per the wikipedia 'function' definition.

In HOME a(n) returns the function value immediately, with no warning message.
In CAS first a warning is issued, then the same a(n) function value is returned.

I was wondering if there were some OTHER kind of operation that COULD take place using the function variables contents, different (and unintended), from the original definition a:=x^2? This could justify the CAS warning, which, perhaps, would not occur in the HOME environment.

I stumbled on this kind of variable usage (on the prime) the other day, and I'm just exploring its possible virtues.

Thank you for your time, Parisse. You've been extremely helpful!

-Dale-

[parisse]

Most of the CAS commands expects expressions, not functions. As soon as you do computer algebra, you must make the distinction between both. That's why the CAS evaluates univariate_expression(something) like if univariate_expression was a function, but issues a warning.

[Han]

You should be careful with using functional notation on expressions as opposed to actual functions (and by functions, I mean as "defined" by the CAS).

a:=x^2;
x:={1,2,3,4};

a(1) through a(4) will behave as expected, but a(-1) will produce an error. The CAS is able to handle list processing, so that x^2 is {1,4,9,16}. The a(n) notation is now a reference to the n-th object in the list x^2. So a(-1) makes absolutely no sense in this context.

[DrD]

EMU CAS

Testing with a:=x^2

a(-1) => 1
a(-4) => 16
a({-1,-2,-4}) => {1,4,16}
n:=7, a(n) => 49
n:=-6, a(n) => 36

So far so good. Seemed to work with complex numbers, too. Where does it fail?

[Han]

It fails when you define x as a list in exactly the same manner shown my post.

[DrD]

Yeah ... I screwed that up by re-using x as the dummy variable, thus killing my x-based defining expression. So I edited the post to use n, instead. I'm sorry about that.

[Han]

Try this:

restart;
a:=x^2;
x:={1,2,3,4};
a(1);
a(2);
a(3);
a(4);
a(-1);
a(5);

The last two produce an error. On the other hand, using:

restart:
a(x):=x^2;
x:={1,2,3,4};
a(1);
a(2);
a(3);
a(4);
a(-1);
a(5);

will result in no failures.

[DrD]

(10-31-2014 11:04 PM)Han Wrote:  Try this:

restart;
a:=x^2;
x:={1,2,3,4};
a(1);
a(2);
a(3);
a(4);
a(-1);
a(5);

Restart, and restart() are cool! Learned something from that.

True, this example fails; but using variable 'x' is troublesome in the quoted example. If you use a different variable, say 'n', as the independent variable instead, the above works fine. Using 'x' in the defining expression, then using 'x' again as an independent variable, is asking for trouble. The independent 'x' became a pointer to the list 'x', in expression involving x^2. Using 'n' has no particular relationship to 'x^2'. I don't think that counts as a fail in this case.

I'm not really sure that there is a point to all of this, other than I just happened on to the prime's use of a variable to contain a function, returning the function value by containing an independent range within parentheses on it (not an index into it). Sort of a short hand way of using functions, more for the general good than anything.

Usually, when I discover something (new to me) like that, I find limitations I hadn't considered. So I hang back waiting for the recoil! This idea works pretty good, in spite of the cautions about it.

-Dale-

[Han]

(11-01-2014 12:48 PM)DrD Wrote:  True, this example fails; but using variable 'x' is troublesome in the quoted example. If you use a different variable, say 'n', as the independent variable instead, the above works fine. Using 'x' in the defining expression, then using 'x' again as an independent variable, is asking for trouble. The independent 'x' became a pointer to the list 'x', in expression involving x^2. Using 'n' has no particular relationship to 'x^2'. I don't think that counts as a fail in this case.

This is precisely the point of the example. That is, when you create a proper function, the 'x' in the function is just a dummy variable. So if one subsequently defines 'x' it does not affect the behavior of the function. On the other hand, creating an expression and expecting it to work like a function (even if it does work most of the time) is a bad idea of one intends to use the expression as an actual function because there will be instances when such expected behavior breaks.

[DrD]

Ok ... but that is not entirely unlike crossing over HOME and CAS with "variable" consequences. Case matters, reserved variables matter, and context matters. It's a matter of remembering which variables matter, ... not to splatter the matter any badder.

-Dale-