Hello,
I’m new to PPL and have a question about fsolve. I’m trying to run this function:
export tdew2()
begin
HAngle:=0;
local x, y;
y:=fsolve(cos(x)=.5,x);
return y;
END;
When I do, I get this error message:
"fsolve(((cos(0))==0.5),0) Error: Bad Argument Value"
I can run: fsolve(cos(x)=.5,x) directly from the input line and get the correct answer. I get the same results on the emulator and the calculator, and in CAS and HOME mode. Can anyone tell me what I am doing wrong?
[
attachment=2160]
[
attachment=2161]
Any help would be greatly appreciated.
Paul
Hello again,
I just solved my own problem. This works:
export tdew2()
begin
HAngle:=0;
local w, x, y, z;
z:="fsolve(cos(x)=0.5,x)";
y:=CAS(z);
return y;
END;
Next time I'll investigate further before asking.
Another way:
Code:
export tdew2()
BEGIN
local x, y;
HAngle:=0;
y:=CAS("fsolve(cos(x)=.5,x");
return y;
END;
Why do you guys put the solve command inside a program? Is there a benefit? Since there is no variable input nor further processing I would do the fsolve() command in cas directly?
I'm curious to learn why you add numerous programs for pure cas calculations?
Thanks!
The original poster said that he was new to PPL and wanted to learn about it. So this could be a snippet as part of a larger context; or perhaps for similar reasoning that one climbs mountains.
-Dale-
Quote:Why do you guys put CAS commands inside a program? Is there a benefit?
Let's say you were pondering the ways of the world, and while admiring the beauty of the Prime's keyboard, you just happen to code in a CSP2D optimization program. Knowing that you will need some test data, (in HOME view), you simply key in the command line:
M1:=CAS("randMat(N,3,ip(1..10))");
It gets late, and another day, you pick up where you left off. In the meantime, you have cleared the calc's history, having used it for various other things. Once again, you need test data, so you key in the above, again. Perhaps again and again ... soon you decide there must be a better way to get fresh test data and Voila!: you say to yourself, "Self, I'll make a grand program to do that for me!" And you happen to make this:
Code:
EXPORT td(n)
BEGIN
N:=n; // pass CAS
M1:=CAS("randMat(N,3,ip(1..10))"); // Generate matrix of test data, M1[#pieces,length,width] of N patterns
END;
Realizing how much easier, and quicker, and less error prone, it is to type td(positive integer) whenever you need fresh test data, you're glad you did that, rather than that long CAS embedded HOME view command line. You soon you finish the CSP2D program, which works wonderfully, and you consider sharing it. Please do.
-Dale-
I have no problems to follow the usefullness of td(n) program. My idea was that you end up in a heavily filled toolbox/user menu. Because you cannot make a directory UserPrograms/calculations or UserPrograms/DataGeneration or UserPrograms/calculations/UnderTest you fill up the menu quickly. You could (should) write the little programs in a single source file, but then re-working the sources is annoying and still you are limited to one subdirectory i.e. the original name of the source file, again.
I am still curious what other users do, HOW they do it and why they do it. No offense, no accusement. It is you who learn to use the prime at school. I don't have that comfort.
A program that does something that is parametrized or called by others is what made people to invent programming. Just like your td(n) example.
The connectivity kit's backup feature is helpful, but I keep a "Master Catalog.zip" file, (which can support folders), but mainly just contains many programs, that I've found useful. Those programs can then be "drag / dropped," "to / from", the zip file to the emulator (or the hardware device), via the connectivity kit.
For program management, this works well for me. Perhaps a bit more difficult if you are in a kayak in the middle of the Columbia river, when that little program needed is on the desktop, in that zip file back home!
A separate master.zip file could be used for other things: apps, matrices, lists, notes, etc.
-Dale-