Essantially a parametric surface is a maping from R^2->R^3 thus defining a 2D surface in 3 space. The algorithms for performing a surface integral in 3 space are well defined for this situation. A vector field (in my case) is a map from R^3->R^3 which defines a 3 vector for every point in space. There is a significant difference between the two types of functions and their physical interpretation. Getting back to the main point. I see how I missed the variable switch. I guess what I am trying to understand is why do I need to declare a set of variables to integrate over in the SurfaceInt function and in the SetCoordinates function that preceeds it? Incidentally, when I made the changes I still didn't get the expected behavior. restart; with(VectorCalculus): # Set the coordinates… SetCoordinates(spherical[r, phi, theta]); SurfaceInt( phi, [r, phi, theta] = Sphere(<0,0,0>,Rho), inert ); #gives an integral over sin^2( phi ) which is not intuitive given the description above. to wit… Int(Int( Rho^3 * sin(phi)^2 * sin(theta), phi = 0 .. Pi), theta = 0 .. 2*Pi) # I think it easy to see what is going on here. # phi is actually being treated as if it is the cannonical "y" and # being converted to spherical polar coordinates inside the function. The result of this integral, assuming it has been done over the correct variables should be: 2 Pi^2 Rho^2 After playing quite a bit, what I am coming to understand is that the lhs of the "surface" description is just a list of variables for the integral that represent cartesian coordinates regardless of the settings of SetCoordinates. The function over which the integral is performed is also assumed to be a scalar function expressed in cartesian coordinates. I do get the correct answer for the integral if I do the following: SurfaceInt( arctan(sqrt(y^2+x^2)), [x, y, z] = Sphere(<0,0,0>,R), inert ); #gives… Int(Int(arctan(sqrt(-R^2*(-1+cos(phi)^2)), R*cos(phi))*R^2*sin(phi), phi = 0 .. Pi), theta = 0 .. 2*Pi) # or 2*Pi^2*R^2 # which is the desired result. On a related note, in a number of Maple examples I see statements like r:='r'; and such while in other circumstances such declarations seem unimportant. When is it necessary to do this kind of literal assignment? Could this be my problem?

Essantially a parametric surface is a maping from R^2->R^3 thus defining a 2D surface in 3 space. The algorithms for performing a surface integral in 3 space are well defined for this situation. A vector field (in my case) is a map from R^3->R^3 which defines a 3 vector for every point in space. There is a significant difference between the two types of functions and their physical interpretation. Getting back to the main point. I see how I missed the variable switch. I guess what I am trying to understand is why do I need to declare a set of variables to integrate over in the SurfaceInt function and in the SetCoordinates function that preceeds it? Incidentally, when I made the changes I still didn't get the expected behavior. restart; with(VectorCalculus): # Set the coordinates… SetCoordinates(spherical[r, phi, theta]); SurfaceInt( phi, [r, phi, theta] = Sphere(<0,0,0>,Rho), inert ); #gives an integral over sin^2( phi ) which is not intuitive given the description above. to wit… Int(Int( Rho^3 * sin(phi)^2 * sin(theta), phi = 0 .. Pi), theta = 0 .. 2*Pi) # I think it easy to see what is going on here. # phi is actually being treated as if it is the cannonical "y" and # being converted to spherical polar coordinates inside the function. The result of this integral, assuming it has been done over the correct variables should be: 2 Pi^2 Rho^2 After playing quite a bit, what I am coming to understand is that the lhs of the "surface" description is just a list of variables for the integral that represent cartesian coordinates regardless of the settings of SetCoordinates. The function over which the integral is performed is also assumed to be a scalar function expressed in cartesian coordinates. I do get the correct answer for the integral if I do the following: SurfaceInt( arctan(sqrt(y^2+x^2)), [x, y, z] = Sphere(<0,0,0>,R), inert ); #gives… Int(Int(arctan(sqrt(-R^2*(-1+cos(phi)^2)), R*cos(phi))*R^2*sin(phi), phi = 0 .. Pi), theta = 0 .. 2*Pi) # or 2*Pi^2*R^2 # which is the desired result. On a related note, in a number of Maple examples I see statements like r:='r'; and such while in other circumstances such declarations seem unimportant. When is it necessary to do this kind of literal assignment? Could this be my problem?

I overreacted a bit. I am on using Maple on a Mac system which has some well documented interface issues (relatively minor, but annoying nonetheless.) These frustrations as well as my steep learning curve beyond the simple stuff just caused my head to explode for a moment. I actually think that on the whole Maple is very neat. I am getting better at dealing with it. I discovered what you pointed out, is the "organic" nature of Maple. I, too, believe that this is a strength, ultimately. I am a big fan of open source work built on sturdy platforms. The problem with open source is that often there are many different perspectives on how to solve a problem and the documentation on which path to take to solve a particular problem isn't always clear. More specifically I have been setting up some material for my students and become more familiar with the VectorCalculus package and have, if I may say so, grown quite fond of it. I have already built some visualization tools (I am sure they already exist but I needed to do this myself) to help support my intended use of the material and I am much happier person for it.

Sorry, I have been offline for a week (spring break) but this exchange has been very helpful. I think I see what is going on. There is a subtle inconsistancy in the way in which maple pulls expressions from previous lines (refering to the formula directly vs assigning a name vs embedding the expression). It is not a major problem but just knowing that there are differences helps me understand what is happeneing when things don't quite give me what I expect.

Sorry, I have been offline for a week (spring break) but this exchange has been very helpful. I think I see what is going on. There is a subtle inconsistancy in the way in which maple pulls expressions from previous lines (refering to the formula directly vs assigning a name vs embedding the expression). It is not a major problem but just knowing that there are differences helps me understand what is happeneing when things don't quite give me what I expect.

You are correct. The simple example you gave does work as advertised. When I do something more elaborate I don't have quite so much success. Let me offer again the trivial ODE proposed above: restart; m*diff(y(t),t,t)=m*g-sigma*A*diff(y(t),t); (1) y(0)=h,D(y)(0)=0; (2) dsolve({(1),(2)}); (3) eval(rhs((3)),{A=2,m=50,sigma=1.2}); I get what I expect: a proper substitution for the named constants. If, on the other hand I redo this calculation with a constraint that is more complex... restart; posConst := AndProp( realcons, RealRange(Open(0),infinity) ): assume( m::posConst ); assume( g::posConst ); assume( A::realcons ); assume( sigma::realcons ); m*diff(y(t),t,t)=m*g-sigma*A*diff(y(t),t); (5) y(0)=h,D(y)(0)=0; (6) dsolve({(5),(6)}); (7) eval(rhs((7)),{A=2,m=50,sigma=1.2}); I don't get any substitution. BUT, if I issue the command: eval(rhs((7)),{`A~`=2,`m~`=50,`sigma~`=1.2}); then the substitutions occurs. I do indeed have the 'show assumed' condition turned off. Your example juxtaposed against mine illustrates the problem I have been having in many more cases than this one. Maple works great with one example but a slight variation gives a different representation based on what appears to be the same set of rules. It 'appears' inconsistent (even though it may not be). Maybe I haven't learned enough of the rules to understand what is going wrong here.

You are correct. The simple example you gave does work as advertised. When I do something more elaborate I don't have quite so much success. Let me offer again the trivial ODE proposed above: restart; m*diff(y(t),t,t)=m*g-sigma*A*diff(y(t),t); (1) y(0)=h,D(y)(0)=0; (2) dsolve({(1),(2)}); (3) eval(rhs((3)),{A=2,m=50,sigma=1.2}); I get what I expect: a proper substitution for the named constants. If, on the other hand I redo this calculation with a constraint that is more complex... restart; posConst := AndProp( realcons, RealRange(Open(0),infinity) ): assume( m::posConst ); assume( g::posConst ); assume( A::realcons ); assume( sigma::realcons ); m*diff(y(t),t,t)=m*g-sigma*A*diff(y(t),t); (5) y(0)=h,D(y)(0)=0; (6) dsolve({(5),(6)}); (7) eval(rhs((7)),{A=2,m=50,sigma=1.2}); I don't get any substitution. BUT, if I issue the command: eval(rhs((7)),{`A~`=2,`m~`=50,`sigma~`=1.2}); then the substitutions occurs. I do indeed have the 'show assumed' condition turned off. Your example juxtaposed against mine illustrates the problem I have been having in many more cases than this one. Maple works great with one example but a slight variation gives a different representation based on what appears to be the same set of rules. It 'appears' inconsistent (even though it may not be). Maybe I haven't learned enough of the rules to understand what is going wrong here.

Thanks, that seemed to do the trick. It does what I want, anyway.

Thanks, that seemed to do the trick. It does what I want, anyway.

I am coming from the other side of the equation. I have used Mathematica on and off since 1990. I am relatively new to Maple. My impression is that Maple is very formal and quite exhaustive in its mathematical designs. However, this is not necessarily an asset. (I used MathCAD as well but the last version for the Mac was version 6 and didn't provide the flexability of Mathematica.) For day to day engineering where what you want is to manipulate data and process information rather than formal rules I'd say Mathematica does a better job. Note that the reason it seems to work better is because it is less strict in interpreting its inputs. For example: if you read information into an array, Mathematica treats all arrays like vectors like 1D matrices like Lists. No special conversions are needed. There is no special type to distinguish a List from an array. Maple, on the other hand, seems to make this distinction and while this is important for formal mathematical modelling it is a PITA when all you are trying to do is to manipulate some datasets. It seems I am forever having to 'convert' arrays to lists to vectors and back again to get various functions and operators to do their thing. I could be missing something basic in the Maple interface but that only points further to the dense documentation. I also found the learning curve for Mathematica to be considerably faster than for Maple. Mind you, I believe Maple is the more 'powerful' tool.

I am coming from the other side of the equation. I have used Mathematica on and off since 1990. I am relatively new to Maple. My impression is that Maple is very formal and quite exhaustive in its mathematical designs. However, this is not necessarily an asset. (I used MathCAD as well but the last version for the Mac was version 6 and didn't provide the flexability of Mathematica.) For day to day engineering where what you want is to manipulate data and process information rather than formal rules I'd say Mathematica does a better job. Note that the reason it seems to work better is because it is less strict in interpreting its inputs. For example: if you read information into an array, Mathematica treats all arrays like vectors like 1D matrices like Lists. No special conversions are needed. There is no special type to distinguish a List from an array. Maple, on the other hand, seems to make this distinction and while this is important for formal mathematical modelling it is a PITA when all you are trying to do is to manipulate some datasets. It seems I am forever having to 'convert' arrays to lists to vectors and back again to get various functions and operators to do their thing. I could be missing something basic in the Maple interface but that only points further to the dense documentation. I also found the learning curve for Mathematica to be considerably faster than for Maple. Mind you, I believe Maple is the more 'powerful' tool.

Since Maple is being pushed into the introductory educational market, this would be an extremely valuable feature. I may take a stab at trying to write a package that will offer some of this functionality. MathCAD has its limitations but this is/was a nice feature (I have a really old version)

Since Maple is being pushed into the introductory educational market, this would be an extremely valuable feature. I may take a stab at trying to write a package that will offer some of this functionality. MathCAD has its limitations but this is/was a nice feature (I have a really old version)