Suggestion for EXECON.

[John P]

I was just playing with EXECON and found that if you have for ex. two lists l1:={1,2,3}, l2:={a,5,6} and if you do EXECON("&1-&2",l1,l2) I get the "Error:Syntax Error". I think because l2 has symbolic element in it and because l2 is accessed element by element using "&2". If there are no symbolic elements in l2 then there is no error and no problems. When I do for ex. sum(EXECON("abs(&1*l2)",l1,l2)) also there is no error even though l2 has symbolic element(s). My conclusion is that: the error occurs only when "&" finds in a list(s) symbolic element(s) ex. 'a', 'a*b' etc.. I do not know if it is at all possible to fix that and make EXECON to work when "&" also accesses list(s) with symbolic element(s) then, I think, the EXECON would be more versatile.

[Snorre]

Hello JohnP,

I think your assumption about EXECON not doing symbolic calculation, i.e. not firing up the CAS, is right. You could do it by yourself:
EXECON("CAS(\"&1-&2\")",l1,l2)
or -- easier to enter --
EXECON("CAS(""&1-&2"")",l1,l2)

It seems that EXECON is just repeatedly doing an EXPR(...) on the string after substituting each &n-pattern by the corresponding list's element. So you could put nearly arbitrary content (e.g. whole program chunks) into the pattern. For example, you could print out what's going on:
EXECON("LOCAL x; IFERR x:=EXPR(""&1-&2""); THEN x:=""Nah!""; END; PRINT(""&1-&2 → ""+x); x",l1,l2);

Greetings

[John P]

(12-14-2014 05:28 PM)Snorre Wrote:  Hello JohnP,

I think your assumption about EXECON not doing symbolic calculation, i.e. not firing up the CAS, is right. You could do it by yourself:
EXECON("CAS("&1-&2")",l1,l2)
or -- easier to enter --
EXECON("CAS(""&1-&2"")",l1,l2)

It seems that EXECON is just repeatedly doing an EXPR(...) on the string after substituting each &n-pattern by the corresponding list's element. So you could put nearly arbitrary content (e.g. whole program chunks) into the pattern. For example, you could print out what's going on:
EXECON("LOCAL x; IFERR x:=EXPR(""&1-&2""); THEN x:=""Nah!""; END; PRINT(""&1-&2 → ""+x); x",l1,l2);

Greetings

Hello Snorre,

Thank you. Your suggestion works, but the question is: is that work around a problem or how the EXECON should work. If it is work around some problem in EXECON, I think they should fix it.

Cheers

[Marcus von Cube]

(12-14-2014 09:12 PM)John P Wrote:  If it is work around some problem in EXECON, I think they should fix it.

I don't think so. The CAS is an independent subsystem which can be called form other places. EXECON is part of "the other places". It can call the CAS if told to do so but it is not automatic. The question is: Should the system call the CAS whenever it feels incapable to perform a specific task? This may lead to unexpected results when an error message would be the more appropriate answer to a problem. I concur that resorting to the CAS is a good idea whenever a function is called from the CAS command line, even if it is defined in "the other world".

[John P]

(12-14-2014 09:44 PM)Marcus von Cube Wrote:  

(12-14-2014 09:12 PM)John P Wrote:  If it is work around some problem in EXECON, I think they should fix it.

I don't think so. The CAS is an independent subsystem which can be called form other places. EXECON is part of "the other places". It can call the CAS if told to do so but it is not automatic. The question is: Should the system call the CAS whenever it feels incapable to perform a specific task? This may lead to unexpected results when an error message would be the more appropriate answer to a problem. I concur that resorting to the CAS is a good idea whenever a function is called from the CAS command line, even if it is defined in "the other world".

Hello Marcus von Cube,

"The question is: Should the system call the CAS whenever it feels incapable to perform a specific task?"
Not exactly and not in the sense: when the system is incapable to do something to call CAS. If I work in CAS or in HOME the system should be aware where it is and behave appropriately. In that sense the system is buggy.

[cyrille de brébisson]

Hello,

> l1:={1,2,3}; l2:={a,5,6}; EXECON("&1-&2",l1,l2) -> "Error:Syntax Error".

how did you get 'a' in l1?
as a mater of fact, what is l1?
Are you working with user defined Home variables or program local or global variables?
These are important point of data to find what is happening...

What is sure is that execon will generate a series of strings with the proper data in it. Once it gets to "1-a", it seems that it can not parse it properly and errs on it...
it might not be due to symbolic, it might be due to the fact that execon is not aware of the existence of a in this case... This is what I Am trying to assert...

Cyrille

[John P]

(12-15-2014 10:09 AM)cyrille de brébisson Wrote:  Hello,

> l1:={1,2,3}; l2:={a,5,6}; EXECON("&1-&2",l1,l2) -> "Error:Syntax Error".

how did you get 'a' in l1?
as a mater of fact, what is l1?
Are you working with user defined Home variables or program local or global variables?
These are important point of data to find what is happening...

What is sure is that execon will generate a series of strings with the proper data in it. Once it gets to "1-a", it seems that it can not parse it properly and errs on it...
it might not be due to symbolic, it might be due to the fact that execon is not aware of the existence of a in this case... This is what I Am trying to assert...

Cyrille

Hello,

1. I was working in CAS on command line. I did not yet try EXECON in program mode.
2. l1 is just a list with curly brackets. Just now I tried the same with square brackets and it also does not work.
3. I just put small 'a' in l2 as an element, but it does not matter where 'a' or any symbolic is it does not work, though it works with numbers only.
4. I defined l1 and l2 as user variables in CAS.
5. I tried another example sum(EXECON("abs(&1*l2)",l1,l2)) and it works as long as "&" does not refer to list with symbolic element(s).

Cheers

[Snorre]

Hi John P,

so, as Marcus pointed out, there are two worlds on the Prime: CAS and the rest.
EXECON is a command from the HOME-world and so get's executed in a non-CAS-environment even if called from the CAS (similiar to other PPL programs).

BTW: in CAS you normally wouldn't grub yourself with strings which contain expressions to be evaluated (like EXPR(), EXECON() etc., which is IMO a very BASIC approach -- simple, powerful, but a bit unaesthetic) since you've the full power of a functional system with "apply", "map", "seq", "zip" and all the implicit composite-type-handling of the other operators.

Greetings

[DrD]

It's treating the symbolic "a" as a variable, expecting it to contain a numeric value.
l1:={1,2,3}
l2:={a,5,6}
EXECON("&1-&2",l1,l2) ==> "Error: Syntax Error"

If:
a:=4
EXECON("&1-&2",l1,l2) ==> [-3,-3,-3]

[Didier Lachieze]

(12-15-2014 12:36 PM)DrD Wrote:  It's treating the symbolic "a" as a variable, expecting it to contain a numeric value.

At least "a" should be defined. Here is what I tried in CAS:

• Define l1
• Define l2
• Define a as a list
• Execute EXECON => it works
  

Now going to HOME:

• Print l1
• Print l2
• Execute EXECON => it works as in CAS
  

[John P]

(12-15-2014 12:31 PM)Snorre Wrote:  Hi John P,

so, as Marcus pointed out, there are two worlds on the Prime: CAS and the rest.
EXECON is a command from the HOME-world and so get's executed in a non-CAS-environment even if called from the CAS (similiar to other PPL programs).

BTW: in CAS you normally wouldn't grub yourself with strings which contain expressions to be evaluated (like EXPR(), EXECON() etc., which is IMO a very BASIC approach -- simple, powerful, but a bit unaesthetic) since you've the full power of a functional system with "apply", "map", "seq", "zip" and all the implicit composite-type-handling of the other operators.

Greetings

Hello,

I have no problems what you and others say and I do not want be to picky at all ,but if EXECON works like it does, at least for me, it is a crippled funktion and if it could be fixed, why not.

Cheers

[John P]

(12-15-2014 12:50 PM)Didier Lachieze Wrote:  

(12-15-2014 12:36 PM)DrD Wrote:  It's treating the symbolic "a" as a variable, expecting it to contain a numeric value.

At least "a" should be defined. Here is what I tried in CAS:

• Define l1
• Define l2
• Define a as a list
• Execute EXECON => it works
  

Now going to HOME:

• Print l1
• Print l2
• Execute EXECON => it works as in CAS
  

Hello,

Fine, but I want 'a' to be 'a' with no value for now and I want it in the final result as an 'a' and then to use it if I need to. In your example you showed elements of 'a' were subtracted from the first element of l1 and then 5 from 2 and 6 from 3. What your example shows is that EXECON when using "&" with symbolic element in a list does not use CAS and this is exactly what Snorre explained in his first post.

Cheers

[Marcus von Cube]

(12-15-2014 01:15 PM)John P Wrote:  Fine, but I want 'a' to be 'a' with no value for now and I want it in the final result as an 'a' and then to use it if I need to.

What you are asking for is an execon (lower case is intentional) function in the CAS. What you are using by now is EXECON, a Home function. Even if you use it from the CAS command line it is still executed in the non symbolic environment and thus is incapable of handling symbolic input.

It shouldn't be rocket science to create your own implementation as a CAS program.

[cyrille de brébisson]

Hello,

Sorry OP, but EXECON, as stated by other is a numerical command.
What is means is that EXECON, when executed from the CAS, or with CAS arguements will 'transport' all the CAS stuff into the HOME/Numerical world and will execute there...

Now, in some cases, such as purely numerical data in your list, it will all happen with no issues...

BUT if you are using items which as CAS only, then it will, unfortunately not...

They are 2 similar (but not fully equivalent) functions in the CAS: apply and map. you should have a look at them.

Cyrille

[John P]

(12-16-2014 06:58 AM)cyrille de brébisson Wrote:  Hello,

Sorry OP, but EXECON, as stated by other is a numerical command.
What is means is that EXECON, when executed from the CAS, or with CAS arguements will 'transport' all the CAS stuff into the HOME/Numerical world and will execute there...

Now, in some cases, such as purely numerical data in your list, it will all happen with no issues...

BUT if you are using items which as CAS only, then it will, unfortunately not...

They are 2 similar (but not fully equivalent) functions in the CAS: apply and map. you should have a look at them.

Cyrille

Hello, and thank you all for your explanations. I certainly learned something from the discussion.

Cheers

[parisse]

For the example above, you can use the zip command, e.g.
zip('+',[a,b,c,d], [1,2,3,4])

[John P]

(12-16-2014 08:01 AM)parisse Wrote:  For the example above, you can use the zip command, e.g.
zip('+',[a,b,c,d], [1,2,3,4])

Hello,

I do not want to extend this discussion indefinitely. What I like very much about EXECO is that by using "&" I can use in "expression" element(s) of the same list(s) many times over for example "(&2-&1)/&1" or somethin like that. OK, EXECON works as numerical function that is clear, but in the light what Snorre wrote in his first post I thought that porting it to CAS would not be very big problem and EXECON would be much more versatile. There is no problem at all because I can always write my own function using Snorre suggestion with slightly different name and get what I want and if I need. Thanks.

Cheers

[parisse]

You can also do that with zip, like this
zip((a,b)->(b-a)/b,l1,l2)

[John P]

(12-16-2014 09:48 AM)parisse Wrote:  You can also do that with zip, like this
zip((a,b)->(b-a)/b,l1,l2)

Hello,

If I have: zip((a,b,c)->(a+b)/(b+c),l1,l2,l3) I get "Error: Bad Argument Value", but if I do:
EXECON("CAS(\"(&1+&2)/(&2+&3)\")",l1,l2,l3) I get what I want. It looks as "zip" takes only two arguments and this is what I mean "EXECON" is, could be, more versatile.
Thank you.

Cheers

[parisse]

Yes, EXECON is more versatile. zip and apply work for 2 or 1 arg function. Otherwise just write a loop yourself if you need it in the CAS.