help with hpppl

[leprechaun]

hi there!

I was inspired by some threads in the forums and being really excited about the patch nots (cas now loves hpppl) I decided to dig out my prime and start over.

Well, it seems that local variables do not interact with cas like I expected, so I do really need advice.

I tried to make this program. It would make me use the prime at work for the first time :-)

Code:


ZIN_F:=4000000;
ZIN_REAL:=400;
ZIN_IMA:=400;

EXPORT ZIN()
BEGIN
LOCAL REAL,IMA,N,W,R,C;
INPUT({{ZIN_F,[0]},{ZIN_REAL,[0]},{ZIN_IMA,[0]}},"IMPEDANCE",{"freq","real","imag"});

W:=2*π*ZIN_F;
N:=1+W^2*'R'^2*'C'^2;
REAL:='R'/'N';
IMA:=W*'C'*'R'^2/'N';
CAS.solve({REAL=ZIN_REAL,IMA=ZIN_IMA},{R,C});

RETURN {R,C};
END;

I always get {0,0} as a result. What am I doing wrong to pass local variables and data to the cas?
Help is very much appreciated.

A simpler version that solves R+C=var would be

Code:


EXPORT CASTEST(N)
BEGIN
LOCAL R,C;
CAS.solve('R'+'C'=N,'R')
END;

Maybe the simplest approach shows my error most easily.

Thanks guys!

[roadrunner]

Add a local variable x:

LOCAL REAL,IMA,N,W,R,C,x;

Store the result of the solve operation in x and add quotes around R and C

x:=CAS.solve({REAL=ZIN_REAL,IMA=ZIN_IMA},{'R','C'});

then RETURN x;

And you get {{0,_(1013904223)}} for an answer. I don't know if it's the right answer, but it's a start.

Here's the code with the suggested changes:

Code:


ZIN_F:=4000000;
 ZIN_REAL:=400;
 ZIN_IMA:=400;

EXPORT ZIN()
BEGIN
LOCAL REAL,IMA,N,W,R,C,x;
 INPUT({{ZIN_F,[0]},{ZIN_REAL,[0]},{ZIN_IMA,[0]}},"IMPEDANCE",{"freq","real","imag"});

 W:=2*π*ZIN_F;
 N:=1+W^2*'R'^2*'C'^2;
 REAL:='R'/'N';
 IMA:=W*'C'*'R'^2/'N';
 x:=CAS.solve({REAL=ZIN_REAL,IMA=ZIN_IMA},{'R','C'});

 RETURN x;
END;

-road

[roadrunner]

Changing N, W, R, and C to lower case (n, w, r, c) may help also.

-road

[salvomic]

(05-07-2016 05:00 PM)roadrunner Wrote:  Changing N, W, R, and C to lower case (n, w, r, c) may help also.

-road

yes, 'cause in Home the calc uses the uppercase as default variables, so NW means N*W...
non with nw that gives "Error: syntax error".

Salvo

[roadrunner]

leprechaun,

I had some more time to look at your code. This seems to do what you need:

Code:

ZIN_F:=4000000;
ZIN_REAL:=400;
ZIN_IMA:=400;

EXPORT zin1()
BEGIN
 LOCAL REAL,IMA,n,w,r,c;
 LOCAL x,y,z;
 INPUT({{ZIN_F,[0]},{ZIN_REAL,[0]},{ZIN_IMA,[0]}},"IMPEDANCE",{"freq","real","imag"});

 w:=2*π*ZIN_F;
 n:=1+w^2*'r'^2*'c'^2;
// REAL:='R'/'N';
// IMA:=W*'C'*'R'^2/'N';
 x:="[r/("+n+")="+ZIN_REAL+","+w+"*c*r^2/("+n+")="+ZIN_IMA+"]";
 y:="[r,c]";
 z:=CAS.solve(x,y);

//({REAL=ZIN_REAL,IMA=ZIN_IMA},{'R','C'});
 RETURN z;
END;

try it and see if it gives you good results.

-road

[leprechaun]

Thanks guys!
I will study your code and try to understand my faults later. atm I am on the way back home.

After the last patch time I'll fall in love with the prime. I promise and I will do my very best! :-)

I HAD that program running on the prime some time ago in cas as following:

(rea,ima)->BEGIN
LOCAL realteil,imagteil,w,n;
w:=2*π*4000000.;
n:=1+w^2*c^2*r^2;
realteil:=r/n;
imagteil:=w*c*r^2/n;
solve({realteil = rea,imagteil = ima},{r,c});
END;

But I would like to benefit from the comfort of hpppl and I must say I WANT to understand what HP designed and what they had in mind when doing so. I do not want to fail with the prime. I am more into low level code and that might be the reason for my constant problems with the machine.

[leprechaun]

But a quick look at roadrunner's code looks like you still have to deal with strings when mixingmcas and hpppl? I did hope that that part had evolved after reading the patch notes.

A quick test Gives [undef]. Any suggestions?

[roadrunner]

You're right!

I ran down to my kid's computer that is running 10077 and I get [undef]

I go up to my comuter that is running 8151 and get an answer.

I'll have to determine what's going on with that later. Right now the kids want there computer back.

-road

[cyrille de brébisson]

Hello,

Home/Cas interraction has changed with the 10077 version.
It has changed to make it better, but it might have side effect that affect you..

Attached is a file that describes the current 'system' in detail.

Cyrille

[leprechaun]

Thank you for your efforts. For me adding some cas code to simple programs seems to be unavoidable and it happens sooner or later.

Quote: roadrunner Wrote:
Changing N, W, R, and C to lower case (n, w, r, c) may help also.

-road


yes, 'cause in Home the calc uses the uppercase as default variables, so NW means N*W...
non with nw that gives "Error: syntax error".

That was something that made me think about in the car this morning. What the program does is using a locally declared variable R for the cas call. Ok i might switch to lower case variables if that helps, but what I do not understand is: it does use a local variable which is something different that the HOME/R built-in variable... I think.

Patch notes say "mproved interaction between CAS functions and HPPPL program. CAS functions can now access directly HPPPL local variables as expected". Isn't that exactly what my problem is about?


lokking forward to getting new information about what I am doing wrong.

[leprechaun]

I have tried the simplest code I could think of. No variables passed to the program. Nothing sophisticated. Results are commented in the code. The [undef] result is contained as one could expect.

This is no special coding and similar tasks will arise sooner or later to everyone. What changes in the firmware might cause the result? How should I code a problem like the original one and what did I get wrong with the patch note about finally integrating the cas into home??

Code:


EXPORT tst()
BEGIN
local argument,result;

//version1 result is [undef]
//argument:="b^2=10,b";
//CAS.solve(argument);

//version2 result is "solve(b^2=10,b" i.e. the call
//argument:="solve(b^2=10,b)";
//CAS(argument);

//version 3 result is [b^2=10 b]
//CAS("b^2=10,b");


END;

P.S:
F1:="B^2=10";
RETURN solve(F1,B);

Does the trick, BUT(!) that is really unintuitive and no improvement and I am sure that there must be an other way. And second it is totally different from what the other posters suggested i.e. useing lower case letters.... because F1:="b^2=10"; solve(F1,b) in all variants fail with syntax errors.

So I am curious about what is going on.

[roadrunner]

(05-09-2016 05:09 AM)cyrille de brébisson Wrote:  Attached is a file that describes the current 'system' in detail.

Cyrille

Thanks Cyrille. That document explains everything!

Leprechaun,

Here is a modified program that works with version 10077:

Code:

ZIN_F:=4000000;
ZIN_REAL:=400;
ZIN_IMA:=400;

EXPORT zin1()
BEGIN
 LOCAL REAL,IMA,n,w;
 LOCAL x,y,z;
 INPUT({{ZIN_F,[0]},{ZIN_REAL,[0]},{ZIN_IMA,[0]}},"IMPEDANCE",{"freq","real","imag"});

 w:=2*π*ZIN_F;
 n:="1+"+w^2+"*r^2*c^2";
 x:="[r/("+n+")="+ZIN_REAL+","+w+"*c*r^2/("+n+")="+ZIN_IMA+"]";
 y:="[r,c]";
 z:=CAS.solve(EVAL(x),EVAL(y));

 RETURN z;
END;

The variables r and c being declared as local is what was messing thing up.

-road

[Han]

(05-09-2016 06:48 AM)leprechaun Wrote:  I have tried the simplest code I could think of. No variables passed to the program. Nothing sophisticated. Results are commented in the code. The [undef] result is contained as one could expect.

This is no special coding and similar tasks will arise sooner or later to everyone. What changes in the firmware might cause the result? How should I code a problem like the original one and what did I get wrong with the patch note about finally integrating the cas into home??

Code:


EXPORT tst()
BEGIN
local argument,result;

//version1 result is [undef]
//argument:="b^2=10,b";
//CAS.solve(argument);

//version2 result is "solve(b^2=10,b" i.e. the call
//argument:="solve(b^2=10,b)";
//CAS(argument);

//version 3 result is [b^2=10 b]
//CAS("b^2=10,b");


END;

P.S:
F1:="B^2=10";
RETURN solve(F1,B);

Does the trick, BUT(!) that is really unintuitive and no improvement and I am sure that there must be an other way. And second it is totally different from what the other posters suggested i.e. useing lower case letters.... because F1:="b^2=10"; solve(F1,b) in all variants fail with syntax errors.

So I am curious about what is going on.

My suspicion is that you do not have a clear understanding of variable types and their priorities. B is a system-wide variable whereas b is generally not (it must be created). Moreover, when you use F1:="b^2=10" this will likely generate and internal syntax error if b does not already exist as a variable.

http://www.hpmuseum.org/forum/thread-215.html

[leprechaun]

Thank you for your comments.

The whole system is not easy to manage. At least to me far from being intuitive. Personally I solved my problem with a cas-function that was called by the input function, but I disliked that. I will try to understand cyrille's paper and the proposed code.
Frustrating thing ;-)

[Tim Wessman]

(05-09-2016 05:35 PM)leprechaun Wrote:  Thank you for your comments.

The whole system is not easy to manage. At least to me far from being intuitive. Personally I solved my problem with a cas-function that was called by the input function, but I disliked that. I will try to understand cyrille's paper and the proposed code.
Frustrating thing ;-)

Well, there is one more piece to be taken at some point (hopefully in the not too distant future) - the ability to declare a variable as a symbolic identifier. That should be the last step to allowing clean access to the CAS. Something like this is kind of the direction I'm thinking.

LOCAL x:=id(x); //or possibly LOCAL x=id('x');
x=CAS.int(x^2-2,x);
print(x);
return x;

or similar would then work like you'd think.

Should look familiar to anyone who's used SymPy I'd think.


What really happened in this last release is that using local variables for function calls behaves in a consistent manner rather then automatically replacing the variables with content on evaluation. The limitation of "the variable still contains some content - even if it is 0" is still there.

Hence the thinking for the future improvement I mused about above.

[CH3791]

(05-09-2016 12:55 PM)roadrunner Wrote:  

(05-09-2016 05:09 AM)cyrille de brébisson Wrote:  Attached is a file that describes the current 'system' in detail.

Cyrille

Thanks Cyrille. That document explains everything!

Leprechaun,

Here is a modified program that works with version 10077:

Code:

ZIN_F:=4000000;
ZIN_REAL:=400;
ZIN_IMA:=400;

EXPORT zin1()
BEGIN
 LOCAL REAL,IMA,n,w;
 LOCAL x,y,z;
 INPUT({{ZIN_F,[0]},{ZIN_REAL,[0]},{ZIN_IMA,[0]}},"IMPEDANCE",{"freq","real","imag"});

 w:=2*π*ZIN_F;
 n:="1+"+w^2+"*r^2*c^2";
 x:="[r/("+n+")="+ZIN_REAL+","+w+"*c*r^2/("+n+")="+ZIN_IMA+"]";
 y:="[r,c]";
 z:=CAS.solve(EVAL(x),EVAL(y));

 RETURN z;
END;

The variables r and c being declared as local is what was messing thing up.

-road

Thanks Roadrunner, your code really helped.