@lisa1301 I just editted the piecewise command, so look again. See also my comment above about the bug in the MaplePrimes editor.

If you really want tapered natural-looking ends, any function f(t) can be used for the radius multplier (candy, in my example) that satisfies f(0) = 0, f(1) = 0, 0 < f(t) <= 1 for 0 < t < 1. A good example is 4*x*(1-x).

@lisa1301 I just editted the piecewise command, so look again. See also my comment above about the bug in the MaplePrimes editor.

If you really want tapered natural-looking ends, any function f(t) can be used for the radius multplier (candy, in my example) that satisfies f(0) = 0, f(1) = 0, 0 < f(t) <= 1 for 0 < t < 1. A good example is 4*x*(1-x).

There's the darnedest bug in the MaplePrimes editor in my web browser. This has happened to me before. If I edit a post that has a less-than sign, it removes the rest of that line, including the sign, as if it were expecting some HTML-type code enclosed in angle brackets. I have to manually put back in the rest of the line. Have you heard of this? I'll edit it now.

There's the darnedest bug in the MaplePrimes editor in my web browser. This has happened to me before. If I edit a post that has a less-than sign, it removes the rest of that line, including the sign, as if it were expecting some HTML-type code enclosed in angle brackets. I have to manually put back in the rest of the line. Have you heard of this? I'll edit it now.

Bravo, Joe. It is a pleasure to read code written so clearly. One question: What is reset? Obviously it is a command to reset the iterator to the beginner, but I can't find documentation on it.

This comment is not meant to answer your question, but perhaps some trouble is coming from this. I notice that n is a free variable in your genfun1. Was that what you intended? Also, genfun1 contains no mu, so how could it equal genfun2?

@PatrickT Thank you for the kind words.

@PatrickT Thank you for the kind words.

@GrecoRoman Yes, you can make it nops(data) instead of 25. Try it.

@GrecoRoman Yes, you can make it nops(data) instead of 25. Try it.

Preben's example of frontend uses the default value of the third parameter, [{`+`,`*`}, {}], so one could just use the user-friendlier-looking frontend(collect, [ex,s]).

I often forget about this powerful command simply because the name is so vague. IgnoreIndets would be a better name, as it seems closely related to subsindets and evalindets.

Preben's example of frontend uses the default value of the third parameter, [{`+`,`*`}, {}], so one could just use the user-friendlier-looking frontend(collect, [ex,s]).

I often forget about this powerful command simply because the name is so vague. IgnoreIndets would be a better name, as it seems closely related to subsindets and evalindets.

Can you make a smaller example? Your sums go from 0 to 42. Could you substantially reduce the 42 and still have the same questions? Get the bugs worked out with fewer terms, then move on to 42.

The example above showed that two Records which seem identical but are stored at different addresses will be stored as separate entries in the table---which may slow down the recursion, but won't cause a real error. The following example---of the converse situation: different Records, same address---is more insidious.

restart;
A:= Record(a=1):
T[eval(A)]:= 1:
A:-a:= 2:
eval(T);

     table([Record(a = 2) = 1])

So even though the record has changed, the value associated with it in the table has not. This situation would cause a procedure that used a remember table on Record arguments to give wrong results.

There is a way that cache tables might help, though it wouldn't usually be worth it: If the situation in the example immediately above was relatively rare, then you could clear the cache every time you changed the contents of a record.

The example above showed that two Records which seem identical but are stored at different addresses will be stored as separate entries in the table---which may slow down the recursion, but won't cause a real error. The following example---of the converse situation: different Records, same address---is more insidious.

restart;
A:= Record(a=1):
T[eval(A)]:= 1:
A:-a:= 2:
eval(T);

     table([Record(a = 2) = 1])

So even though the record has changed, the value associated with it in the table has not. This situation would cause a procedure that used a remember table on Record arguments to give wrong results.

There is a way that cache tables might help, though it wouldn't usually be worth it: If the situation in the example immediately above was relatively rare, then you could clear the cache every time you changed the contents of a record.