Advanced Search
All Posts : Product Tips & Techniques

Couple of months out

PhyTch.Paul 38 Maple
July 27 2006
1
I have been playing with Maple on and off for 3 months. This summer, now that school is out, I have set about trying to master this environment. My frustration with Maple has subsided a bit only to be replaced with an understanding of its limitations. I set about building my own package of doing surface and flux integrals as a way of discovering how to manipulate expressions. I think I know why Maple is so tough. I read somewhere on these forums a diatribe on what seemed an esoteric nuance in the difference between the way Mathematica approaches functions vs the way Maple does. Mathematica is essentially a functional programming language wrapped around list structures (ala LISP). In mathematica everything, at the ground level, is a list. Various types get defined for different quantities but they are essentially lists. Maple defines its types internally. I don't know how they are put together (rtables?) Maple has evolved over time so that these types have grown to a huge number that are hard to keep track of. The inability of maple functions to screen their inputs for different data types means that the Maple programmers have to write lots of different functions for the different data types. This is a very old style of programming. How does this esoterica affect the Maple interface? Profoundly. Lets get back to my original mission: surface integral. I set up a parametric surface. This should be an ordered list of functions describing the effect of each variable as a function some others. R -> R for a 3D surface. I need to take the derivatives of this "vector" wrt to the parametrized values to build the differential suface element dS. Maple balks at taking derivatives of vectors since they are not arrays. I have to convert them to arrays, take their derivatives and now it is time to take the cross product. The cross product operator doesn't recognize arrays as an input so I need to explicitly convert the arrays back to vectors. (Did I mention that there are vectors and Vectors?) I take the cross product and get its 'length'. I then throw it in the integral but it needs to be conveted back to an algeraic. I spent most of my time converting from Vector to array and back again. Mathematica doesn't distinguish between these types since arrays are vectors are lists. Even if they were a different type the sophisticated pattern matching means that if I define a new operator that may share the same name as some new operator it can be easily defined to match only the new data type and not override existing functions. What this means is that I don't need 3 different named functions for the "cross product", conversions from lists to vectors, arrays happen naturally and automatically*. Loading a library doesn't change the state of the interface and create unpredictable namespace problems (vector vs Vector). Many purists will point out that these type distinctions are a good thing. Yes, as a former programmer I appeciate the need for strict type checking. There are times, however, when this kind of checking can get in the way of getting things done. Maple is very close to that line. I think I need to get some better reference material on worked problems in Maple to make any headway into this system. * While I am picking on this one part there are numerous examples of functions that need to be redefined to allow some new type defined in some included library. To Maple's credit these libraries are VAST. The downside is that the documentation is incomplete in weird ways. The descriptions are detailed without being clear as to what the function does and how it does it.
derivative integral document interface

Please Wait...