I think that the original poster was wanting the exact symbolic integral in particular. What's the difference between evalf(int(...)) and evalf(Int(...)), you might wonder, if they both returned a floating-point result here? Well, the first of those, tries to do an exact integration, just as int() does, and then evaluates the result under evalf. And the second, evalf(Int(...)) uses numeric methods and may not attempt to compute the exact symbolic integral at all. (It can howevere do some fancy symbolic analysis, to find singularities, etc.) But when int() returns unevaluated, because it does not compute or find a integration result, then subsequently hitting that unevaluated result with evalf() will result in doing the numeric computation all the same. If int(foo) returns unevaluated, then evalf(int(foo)) should give you the same thing as evalf(Int(foo)). Except it may take longer, possibly considerably longer, while it tries and fails to do the exact symbolic integral. There are cases, too, where evalf of a formulaic symbolic exact integral result (at default Digits precision) will have measurable round-off error. And it could also be that, for the same integrand, evalf(Int(...)) will produce a more accurate result. And that's certainly not always the case. I'm not trying to muddy the waters by mentioning that, but it's a good idea to find a way to check results. acer

Which interface are you using with Maple 11? Classic or Standard? If it's Standard, then which "mode", Document or Worksheet? 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

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