This post was the one that finally put you over in the big leagues - 400 Maple Primes points! Of course, Tom4 and Will 'cheated' by getting so many freebie points by being the ones who started a lot of the various books and forums, and were posting on this site to test it long before the rest of us. You got your points the really-hard-way!

This post was the one that finally put you over in the big leagues - 400 Maple Primes points! Of course, Tom4 and Will 'cheated' by getting so many freebie points by being the ones who started a lot of the various books and forums, and were posting on this site to test it long before the rest of us. You got your points the really-hard-way!

> lside := (-64*a*cos(8*t)-64*b*sin(8*t))*exp(6*t)+65*(a*cos(8*t)+b*sin(8*t))*exp(6*t)+81*c*exp(2*t);

  lside := (-64 a cos(8 t) - 64 b sin(8 t)) exp(6 t) + 65 (a cos(8 t) + b sin(8 t)) exp(6 t) + 81 c exp(2 t)

> collect(lside, [sin(8*t), cos(8*t)]);

      b exp(6 t) sin(8 t) + a cos(8 t) exp(6 t) + 81 c exp(2 t)

Raw expand will indeed ruin your expression. But it has a little-used optional argument that does what you want:

> expand(lside, sin(8*t), cos(8*t));

              6                    6                         2
        exp(t)  a cos(8 t) + exp(t)  b sin(8 t) + 81 c exp(t)

> expand(lside, sin, cos, exp);

      b exp(6 t) sin(8 t) + a cos(8 t) exp(6 t) + 81 c exp(2 t)

> lside := (-64*a*cos(8*t)-64*b*sin(8*t))*exp(6*t)+65*(a*cos(8*t)+b*sin(8*t))*exp(6*t)+81*c*exp(2*t);

  lside := (-64 a cos(8 t) - 64 b sin(8 t)) exp(6 t) + 65 (a cos(8 t) + b sin(8 t)) exp(6 t) + 81 c exp(2 t)

> collect(lside, [sin(8*t), cos(8*t)]);

      b exp(6 t) sin(8 t) + a cos(8 t) exp(6 t) + 81 c exp(2 t)

Raw expand will indeed ruin your expression. But it has a little-used optional argument that does what you want:

> expand(lside, sin(8*t), cos(8*t));

              6                    6                         2
        exp(t)  a cos(8 t) + exp(t)  b sin(8 t) + 81 c exp(t)

> expand(lside, sin, cos, exp);

      b exp(6 t) sin(8 t) + a cos(8 t) exp(6 t) + 81 c exp(2 t)

In this particular case, I was referring to the kernel and the library taken together. More specifically, take those parts of the kernel and library that have been there since Maple 6. That part of Maple is certainly 'mature'. The GUI is, with Maple 11, just coming out of the 'experimental' stage into something mostly stable. Frankly, I am not quite sure what I would want either, other than a few obvious things like: more uniformity (in command names, in argument passing, in data-structure representation); more composability (there are unfortunately too many commands whose output ought to work as input to another, but doesn't); fewer special cases (Maple's evaluation rules are arcane, and that's being polite about it). Before someone misinterprets this thread: the whole point of wondering about this is not that Maple is bad, quite the contrary! Maple is very good, but it could be better. This is not a slight on anyone, it is the natural process of Software Aging. Maple's architecture and fundamental design is after all a product of the 70s (implemented in the early hours of the 80s), so it should be no surprise that mixed in with the brilliant insights are a few bad (or simply obsolete) ideas too. Of course, there are two paths one can take towards Oak: 1) find (and keep) the fundamental ideas of "Mapleness", whatever they are 2) go new Note that #1 does not mean backwards compatible, it just means the same overall feel. If backwards compatibility is a restriction, then Maplesoft is probably doing as good a job of evolving the product as any commercial entity could! There are too many things right with Maple to bother with #2; and even if one were tempted to go that route, there are other forums which would be more appropriate for such a discussion. In part what made me think of all of this is Microsoft and Sun! More precisely one of their projects: for Microsoft, F^#, especially the built-in data visualization environment; for Sun, Fortress, a new programming language aimed at high-performance computing, especially where its code looks like math, and many other features (full specification). Of particular interest is the fully integrated dimension types (very reminiscent of Maple's Units, just way more integrated). The people who should be most worried about Fortress are the MathWorks. The speed at which both those projects are progressing is quite impressive, and soon the main Maple competitors may not be Mathematica and MuPAD (and sometimes Matlab), but F# and Fortress!

In General, Maple stores only one instance of any given object. The one exception is when you make an explicit copy of a mutable object - like is done in this code. In your case, the answer is rather complex, as it is both yes and no! I think I can only explain that with an example where I compare the actual representations of 2 different entries:

> dismantle[hex](Sq[2,3]);
MODULE(8A6068C,4) #[record]
   EXPSEQ(8A60678,4)
      NAME(8A5B46C,5): Number
      NAME(8A5F4C4,6): Possible
      NAME(8A5F4A8,6): NumPossible
   MODDEF(8A15DDC,10) #[record]
      EXPSEQ(8A564CC,2)
         NAME(8977B04,6): thismodule
      EXPSEQ(89780EC,1)
      EXPSEQ(8A191D8,2)
         NAME(8A18450,5): record
      EXPSEQ(8A52C70,4)
         NAME(8A08824,5): Number
         NAME(897A448,6): Possible
         NAME(89E0164,6): NumPossible
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
   EXPSEQ(8A61878,1)

and

> dismantle[hex](Sq[1,1]);

MODULE(8A52D10,4) #[record]
   EXPSEQ(8A52CFC,4)
      NAME(8A52480,5): Number
      NAME(8A4AD9C,6): Possible
      NAME(8A4AD80,6): NumPossible
   MODDEF(8A15804,10) #[record]
      EXPSEQ(8A564CC,2)
         NAME(8977B04,6): thismodule
      EXPSEQ(89780EC,1)
      EXPSEQ(8A191D8,2)
         NAME(8A18450,5): record
      EXPSEQ(8A52C70,4)
         NAME(8A08824,5): Number
         NAME(897A448,6): Possible
         NAME(89E0164,6): NumPossible
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
   EXPSEQ(8A57214,1)

The thing to notice is how the names in the MODULE are different, but the ones in the MODDEF structure are the same.

In General, Maple stores only one instance of any given object. The one exception is when you make an explicit copy of a mutable object - like is done in this code. In your case, the answer is rather complex, as it is both yes and no! I think I can only explain that with an example where I compare the actual representations of 2 different entries:

> dismantle[hex](Sq[2,3]);
MODULE(8A6068C,4) #[record]
   EXPSEQ(8A60678,4)
      NAME(8A5B46C,5): Number
      NAME(8A5F4C4,6): Possible
      NAME(8A5F4A8,6): NumPossible
   MODDEF(8A15DDC,10) #[record]
      EXPSEQ(8A564CC,2)
         NAME(8977B04,6): thismodule
      EXPSEQ(89780EC,1)
      EXPSEQ(8A191D8,2)
         NAME(8A18450,5): record
      EXPSEQ(8A52C70,4)
         NAME(8A08824,5): Number
         NAME(897A448,6): Possible
         NAME(89E0164,6): NumPossible
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
   EXPSEQ(8A61878,1)

and

> dismantle[hex](Sq[1,1]);

MODULE(8A52D10,4) #[record]
   EXPSEQ(8A52CFC,4)
      NAME(8A52480,5): Number
      NAME(8A4AD9C,6): Possible
      NAME(8A4AD80,6): NumPossible
   MODDEF(8A15804,10) #[record]
      EXPSEQ(8A564CC,2)
         NAME(8977B04,6): thismodule
      EXPSEQ(89780EC,1)
      EXPSEQ(8A191D8,2)
         NAME(8A18450,5): record
      EXPSEQ(8A52C70,4)
         NAME(8A08824,5): Number
         NAME(897A448,6): Possible
         NAME(89E0164,6): NumPossible
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
      EXPSEQ(89780EC,1)
   EXPSEQ(8A57214,1)

The thing to notice is how the names in the MODULE are different, but the ones in the MODDEF structure are the same.

if (A<=x and x<=B) and y < C then ... end if Note that if this is inside a procedure, then it is usually a good idea to typecheck that x::numeric and y::numeric.

It seems to be more and more common in the answers provided on mapleprimes that the functionality required is indeed present in Maple, but buried so deep that only experts can find it. I believe that the developers are doing themselves a serious dis-service by not spending more time to ensure that their hard work is visible enough that users will easily find it, and appreciate the hard work. You show an obvious example above: copy was indeed updated, but this fact can only really be discovered empirically (or by luck), rather than by simply reading the appropriate documentation. A more user-centric approach to feature development would always have someone ask the question: suppose a user really needed the new work on feature X in the product, would they be able to find it easily? If the answer is 'no', then the feature is not 'finished' yet.

It seems to be more and more common in the answers provided on mapleprimes that the functionality required is indeed present in Maple, but buried so deep that only experts can find it. I believe that the developers are doing themselves a serious dis-service by not spending more time to ensure that their hard work is visible enough that users will easily find it, and appreciate the hard work. You show an obvious example above: copy was indeed updated, but this fact can only really be discovered empirically (or by luck), rather than by simply reading the appropriate documentation. A more user-centric approach to feature development would always have someone ask the question: suppose a user really needed the new work on feature X in the product, would they be able to find it easily? If the answer is 'no', then the feature is not 'finished' yet.

If you count the language features and the 'accessible' library (ie documented entry points), that is over 3000 separate things to document. The end result would look like... the Mathematica book! [It is HUGE]. And even then, it is easily dwarfed by the multiple-volumes Mathematica Guidebooks. Documentation-wise, Maple falls far, far, far below what Wolfram Research puts out for Mathematica. Luckily, this is not the case for the actual mathematics behind the respective systems!

If you count the language features and the 'accessible' library (ie documented entry points), that is over 3000 separate things to document. The end result would look like... the Mathematica book! [It is HUGE]. And even then, it is easily dwarfed by the multiple-volumes Mathematica Guidebooks. Documentation-wise, Maple falls far, far, far below what Wolfram Research puts out for Mathematica. Luckily, this is not the case for the actual mathematics behind the respective systems!

I have been going between Maple, Haskell, MetaOCaml, and Python, it gets messy. And of course, lots of LaTeX in between.

I have been going between Maple, Haskell, MetaOCaml, and Python, it gets messy. And of course, lots of LaTeX in between.

Some time (but not today!), I would like to post some measurements on efficiency that show something that few people really understand about Maple, and that is the effect of memory allocation on run times. Clearly, wild allocations take time (to do and to collect), and that shows up in the posts above. In fact, I am quite sure that the actual assignment to a list is exactly as fast as that to a vector, and that the apparent slowness of the list version is all due to memory (ab)use. But much more subtle is the fact that if you run a normal (symbolic) maple command that takes >1 second 1) in a clean environment 2) in an environment where all sorts of unrelated computations have been done [say where memory alloc is now 100 Megs], then that same command will be measurably slower in case 2. In fact, by increasing the amount of unrelevant other computations (to augment memory alloc, as well as memory fragmentation), this gets more and more pronounced. One word of warning: the effect will be different if one causes memory to be allocated in large chunks versus small chunks. Potential conclusion: don't use Maple for extended periods of time without doing save+quit+restart, else your "working environment" will ever so gradually get slower and slower.