acer

32303 Reputation

29 Badges

19 years, 307 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

You can use rtable_elems() to get the indices of an Array. How about, seq([lhs(x)],x in rtable_elems(A)); It shouldn't be necessary to convert an Array to an array, in general. If it really couldn't be avoided for some task, then that'd be an indication that functionality were missing. acer
Isn't that what implicitplot3d() is for? See ?plots,implicitplot3d acer
Isn't that what implicitplot3d() is for? See ?plots,implicitplot3d acer
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
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
First 577 578 579 580 581 582 583 Last Page 579 of 591