Without seeing what is in (3), it is also impossible to tell. However, my guess is that someone at Maplesoft goofed and used a list as an updatable data-structure in the code somewhere, thereby ensuring that this routine does not scale to larger examples. List assignments should be forbidden in the Maple library! I am honestly surprised that this has not been made a rule; it is very easy to have the test-suite-kernel issue a hard error on these.

Without seeing what is in (3), it is also impossible to tell. However, my guess is that someone at Maplesoft goofed and used a list as an updatable data-structure in the code somewhere, thereby ensuring that this routine does not scale to larger examples. List assignments should be forbidden in the Maple library! I am honestly surprised that this has not been made a rule; it is very easy to have the test-suite-kernel issue a hard error on these.

2D in Standard works very well for "expressions" that are meant to be manipulated in Maple (only). For anything else, use 1D. This means that if you are writing code, manipulating code, generating code, whichever, use 1D. 2D will give you all sorts of headaches, as it seems that these use cases were not imagined when 2D was implemented. If you hunt around MaplePrimes, the reasons for epsilon coming out funny have been documented (has to do with Typesetting and how 2D works). The short answer for Maple 11 is to use 2D when you are manipulating expressions meant to be in Maple (only), and use 1D for other uses. [Manipulating expressions meant to be in Maple is what a huge percentage of beginners use Maple for, incidentally, so that 2D only works for that use case is not unreasonable].

2D in Standard works very well for "expressions" that are meant to be manipulated in Maple (only). For anything else, use 1D. This means that if you are writing code, manipulating code, generating code, whichever, use 1D. 2D will give you all sorts of headaches, as it seems that these use cases were not imagined when 2D was implemented. If you hunt around MaplePrimes, the reasons for epsilon coming out funny have been documented (has to do with Typesetting and how 2D works). The short answer for Maple 11 is to use 2D when you are manipulating expressions meant to be in Maple (only), and use 1D for other uses. [Manipulating expressions meant to be in Maple is what a huge percentage of beginners use Maple for, incidentally, so that 2D only works for that use case is not unreasonable].

I can't see any imaginary parts in what I posted. Be that as it may, you have to explicitly split an expression into real and imaginary parts, as C cannot handle complex numbers natively.

I can't see any imaginary parts in what I posted. Be that as it may, you have to explicitly split an expression into real and imaginary parts, as C cannot handle complex numbers natively.

Actually, if you reread what edgar and I posted, you'll see that what is really going on is that both of us are using is as a "mathematical assistant", to perform parts of the computations for us, but where definite human intelligence is needed to string together the proper steps. Maple is especially good at this. Once you change your view of it as something which does your work for you, to a tool that you use to get your job more efficiently, you'll probably start appreciating Maple a lot more. [And you might understand some of my rants when I find that new features of Maple make it less effective as a tool, though of course the intent of those new features is usually to ``help'' absolute beginners]. In your case, yes, things can be simplified a lot! Your expression is the very definition of the pochhammer symbol (see ?pochhammer). So what you are looking for is the real and imaginary parts of that -- which is a considerably easier problem!

Actually, if you reread what edgar and I posted, you'll see that what is really going on is that both of us are using is as a "mathematical assistant", to perform parts of the computations for us, but where definite human intelligence is needed to string together the proper steps. Maple is especially good at this. Once you change your view of it as something which does your work for you, to a tool that you use to get your job more efficiently, you'll probably start appreciating Maple a lot more. [And you might understand some of my rants when I find that new features of Maple make it less effective as a tool, though of course the intent of those new features is usually to ``help'' absolute beginners]. In your case, yes, things can be simplified a lot! Your expression is the very definition of the pochhammer symbol (see ?pochhammer). So what you are looking for is the real and imaginary parts of that -- which is a considerably easier problem!

Congrats to roman_pearce on his 400, and dcasimir on his 200. So nice to see the number of gold leafs stay constant! There has been interesting activity at the bottom of the first ranking page too. First, DJKeenan kicked Fred Chapmann off the first page, but then soon thereafter, pchin kicked DJKeenan back down to the second page! Just to keep things interesting, Schivnor in the meantime also sped past Fred Chapmann. To get onto the first page, now one needs a rank of 64. Question is, how long before Marvin Ray Burns and william budd are themselves booted off the first page? At this rate, it does not seem like it will take very long. At that point, making the first page will meant having a high 60s score. I am guessing that before the year is over, there will be no more bronze leafs on the first Ranking page.

Your variant is interesting as it puts a 'true' wherever something new is encountered. That leads me to the following variant: zap2 := proc(v) procname(v) := 1; 0 end proc: forget(zap2): zap := proc(v) zap2(v) := zap2(v) + 1; end proc:

You are right that the current set of checks is at the top-level only, and is ad hoc. In all fairness, it is generally quite effective, although it does have the drawback of seriously slowing down the top level in the presence of (large!) expressions. I think that there has been so much emphasis for many years now on the low-level Maple user that the high-end Maple user has been the loser in the shuffle of effort.

A fairly simple static analysis could tell that the global q needs to have a value for your procedure p to "make sense". So, for example, mint could easily be coded to issue a warning. Unfortunately, mint still has not been integrated into the Maple tool suite -- only the people who are still comfortable with a command line, a dwindling set, even know about it.

simplify, like combine, are very heavy-duty tools. Even for very simple expressions, they are costly, because they both set up a lot of infrastructure before ``real work'' happens [and are all the more powerful for it]. But it means that even on quite simple expressions, they make their presence felt.

For one thing, you can replace the complete if with if s::`*` then andmap(A, s) end if andmap is builtin (in Maple 11) and uses short-cut semantics, so that should be fastest. If you gave us more details about the predicate A, we might be able to speed that up too.

What you show will work for anything that naturally appears in Maple output (so includes int, diff, sum, etc, which can appear unevaluated). However, for any routine in Maple which has a meaning (and a symbolic representation) in mathematics but does NOT return unevaluated in Maple, then your trick will not work! [In fact, many Maple commands do not work on raw input]. The problem is that many commands are written to understand those things that are ``values'' in Maple, but pretty much none are written to understand ``commands''. Now, in everyday use, since just about everything is a value, this is not a big deal. But you'll notice that some things that are ``the same'' typeset differently. For example, sum typesets, add does not. So sum(i^2,i=1..10) will typeset, add(i^2,i=1..10) will not. This is an endless source of weird bugs. If you try to apply context-sensitive menus to general maple terms (i.e. those that never appear in output), you'll rapidly see what I mean.