Ok, first of all (and this is just minor convention), it's common to use .mpl as the file extension for plaintext maple source files (and .mw only for non-plaintext worksheets and documents).
Next, it's not really necessary to go to all the trouble about argc and argv, for the purpose you described.
So, here's a maple source file. Let's call it foo.mpl .
--------- start foo.mpl -----------
fd:=fopen(usethisfile,READ,TEXT);
fscanf(fd,"%ld");
---------- eof file foo.mpl -------
Now, in a bash shell I can do things like this,
bash% echo "23 27 29" > file1
bash% maple -c "usethisfile:=file1" -q foo.mpl
fd := 0
[23]
So, you could probably do it similarly using perl's system() call.
acer

Ok, first of all (and this is just minor convention), it's common to use .mpl as the file extension for plaintext maple source files (and .mw only for non-plaintext worksheets and documents).
Next, it's not really necessary to go to all the trouble about argc and argv, for the purpose you described.
So, here's a maple source file. Let's call it foo.mpl .
--------- start foo.mpl -----------
fd:=fopen(usethisfile,READ,TEXT);
fscanf(fd,"%ld");
---------- eof file foo.mpl -------
Now, in a bash shell I can do things like this,
bash% echo "23 27 29" > file1
bash% maple -c "usethisfile:=file1" -q foo.mpl
fd := 0
[23]
So, you could probably do it similarly using perl's system() call.
acer

Yes, I believe so. I agree, that the union of Pi*(2*n+1) and Pi*(2*n), for all integers n, isn't as simplified as it could be. I already mentioned the answer might not be optimally simplified. But it does still represent the right solution, I think.
As for @n1*Pi, it is also obscure to the new user, just as the Maple syntax is. The @ symbol is mysterious. It's unclear why it's n1 instead of just n. The letter n connotes an natural integer to me, while Z is more suggestive of all integers. It's not indicated whether n1 can be assigned to, or has assumptions or properties attached to it. These are all relative weaknesses of the TI solution.
It's pretty obvious that any advanced mathematical system is going to have its own notations, and that those will appear unobvious to the new user. And, once familiar, these same notations will appear so obvious that it'll be hard to remember when they weren't.
acer

Yes, I believe so. I agree, that the union of Pi*(2*n+1) and Pi*(2*n), for all integers n, isn't as simplified as it could be. I already mentioned the answer might not be optimally simplified. But it does still represent the right solution, I think.
As for @n1*Pi, it is also obscure to the new user, just as the Maple syntax is. The @ symbol is mysterious. It's unclear why it's n1 instead of just n. The letter n connotes an natural integer to me, while Z is more suggestive of all integers. It's not indicated whether n1 can be assigned to, or has assumptions or properties attached to it. These are all relative weaknesses of the TI solution.
It's pretty obvious that any advanced mathematical system is going to have its own notations, and that those will appear unobvious to the new user. And, once familiar, these same notations will appear so obvious that it'll be hard to remember when they weren't.
acer

The return value of -3.14159.. means that this is an approximate root of the expression sin(x)^2/x . And so it is.
The call fsolve(sin(x)^2/x, x = 0) is the syntax to request that fsolve find a root of sin(x)^2/x with 0 as the initial point. What fsolve does with the initial point is less relevant than the fact that it returns a perfectly valid root. Nowhere does the documentation say that the expression *must* be defined at the initial point, which leaves fsolve quite free to select another point, etc. Neither does it say that the returned root *must* be closest to the initial point. Nor does it say that limiting values are acceptable as roots.
acer

The return value of -3.14159.. means that this is an approximate root of the expression sin(x)^2/x . And so it is.
The call fsolve(sin(x)^2/x, x = 0) is the syntax to request that fsolve find a root of sin(x)^2/x with 0 as the initial point. What fsolve does with the initial point is less relevant than the fact that it returns a perfectly valid root. Nowhere does the documentation say that the expression *must* be defined at the initial point, which leaves fsolve quite free to select another point, etc. Neither does it say that the returned root *must* be closest to the initial point. Nor does it say that limiting values are acceptable as roots.
acer

I wonder whether difficulty in sending you messages is related to the fact that your handle has a space in it.
acer

I wonder whether difficulty in sending you messages is related to the fact that your handle has a space in it.
acer

A simple (perhaps shortened) example would help, to understand just what the procedure is doing.
acer

A simple (perhaps shortened) example would help, to understand just what the procedure is doing.
acer

The behaviour you've described is not in Maple, but in the engine that drives this site. (Is it Drupal?)
This issue, with less-than, etc, is common here. It should be answered in a FAQ. It's a by-product of allowing either plaintext or marked-up HTML in the posts. It's pretty easy to change for each post, but I wish it could be set as a personal default.
Answers that one obtains from scientific software should be verified. If the software is good (as Maple mostly is) then it should not be too difficult to verify the results by using the same program (different pieces of it, naturally).
One measure of satisfaction with software can come from how quickly one receives support, and from how quickly issues are resolved or "fixed". The presence alone of a bug in a piece of software is not, in and of itself, surprising.
acer

The behaviour you've described is not in Maple, but in the engine that drives this site. (Is it Drupal?)
This issue, with less-than, etc, is common here. It should be answered in a FAQ. It's a by-product of allowing either plaintext or marked-up HTML in the posts. It's pretty easy to change for each post, but I wish it could be set as a personal default.
Answers that one obtains from scientific software should be verified. If the software is good (as Maple mostly is) then it should not be too difficult to verify the results by using the same program (different pieces of it, naturally).
One measure of satisfaction with software can come from how quickly one receives support, and from how quickly issues are resolved or "fixed". The presence alone of a bug in a piece of software is not, in and of itself, surprising.
acer

The less-than and greater-than symbols are special to HTML. You could change the "Input format" (just below the input box here for a comment or posting) to Plain Text, as one way to get what you're after.
Or you can use HTML input but insert less-than as
& l t ;
without the spaces. That should produce < .
I believe that your attempt to use of < in HTML input, for the purpose of showing plaintext, will cause the remaining portion of the comment to not appear (presumably because it gets recognized as unfinished mark-up content.
acer

The less-than and greater-than symbols are special to HTML. You could change the "Input format" (just below the input box here for a comment or posting) to Plain Text, as one way to get what you're after.
Or you can use HTML input but insert less-than as
& l t ;
without the spaces. That should produce < .
I believe that your attempt to use of < in HTML input, for the purpose of showing plaintext, will cause the remaining portion of the comment to not appear (presumably because it gets recognized as unfinished mark-up content.
acer

I will try to give some hints that might help you. I'm not going to give a lot of very formal notes; if you wish you can read some advanced texts.
One can try to find some definitions.
In Maple11, one can issue the help-query, ?closedform , and get a somewhat helpful definition.
Also of interest might be

this link, and

this link.
The second of those two links mentions a pertinent notion. Suppose that one arrives at a function of one variable, which has no closed form solution (say, under a finite number of arithmetic operations). Suppose further that it can be approximated numerically, plotted, and even shown to truly be a single-valued function. So, why not give it a name, and learn to treat it like an old friend. How much different from this is our use of ln(), or sin(), or perhaps even sqrt()? Axel mentioned erf(). Lots of "special functions" could be placed in such a category. People feel comfortable with some of them, even without rigourous formal definitions for them -- I suspect mostly because of familiarity.
Other links that might interest you are definitions for

elementary functions, and

special functions.
I like sin(), as an interesting example. Sure, you may be able to find a power series to represent it as an infinite sum of terms. But as a polynomial with finitely many terms? No. Yet people are comfortable with. It has its own button on calculators. And, interestingly, we can do all sorts of useful conversions and computations and simplifications using all the known trigonometric identities. Isn't that fascinating, that we can do exact computations and manipulations of expressions containing sin(), even though we have no arithmetic formula (with finitely many operations) for it exactly?
Now look at the Maple help-page ?evala . That refers to a whole suite or routines which can be used to investigate and compute with algebraic numbers and functions represented with the RootOf notation. The power of these evala routines alone show the usefulness of the RootOf as placeholder.
acer