Before I posed this question, I had read the "help" and found the command "printlevel" where it says that "printlevel=1000 is not uncommon". You  can guess what my traceback looked like. Your suggestion is much better. Thank you.

By the way, in case anyone reading this is interested, I tried this sum on Mathematica and it failed to come up with an answer.

Sorry not to be clear. To rephrase: the question is: "what internal algorithm did Maple use to come up with that answer", or alternatively, how can I find out what internal algorithm it used.

Thank you.

@acer Thank you - that did it.

try

solve(identity(Expr,x), {A,B});

It seems that "irem" is all I ever needed, but it's next to impossible to find using the "help" facility.

So that solves my immediate problem.

While we are at it - out of curiosity who invented the "m mod(n)" syntax and why?

It runs counter to just about any other command syntax in the Maple (and just about any other) computer language. And as "acer 9771" points out, the result is premature substitution.

Thank you.

OK - here is a workaround - you have to split the statement into two.

Maybe someone would be kind enough to tell me why the following works?

subs(m=21,m mod(4));
subs(m=21,'m mod(4)');
evalf(%);
                               21
                          `mod`(21, 4)
                               1.

@Preben Alsholm 

Yes it does! Cute. Thank you.

Now maybe you happen to know how to extract constants from an integrand and place them outside the integration operator - e.g

Int(a*f(x) becomes a*Int(f(x)

I was kind of hoping that there was some way of doing both. It seems that the method I originally proposed, doesn't work at all. The only solution I can see so far is to write a procedure for each sum. Otherwise it is easy to get the wrong answer without knowing it - see attached worksheet. Note the difference between "Sum" and "sum".

Michael

PS - Howcum Maple notification doesn't work?

Download conditions.mw

.

Me neither! (+....)

I have seen similar things which were never resolved.

You should know that even with a restart, unlike any other computer program you've ever seen, Maple doesn't always follow the same path each time it is run for reasons that escape me, but somehow make sense to the Maple developers. You often see this if you are using pattern matching and/or substitution - consecutive identical runs don't always succeed because the patterns are different but equivalent (two minus signs instead of a plus, for example). It makes programming difficult to say the least, unless you cover all possible variations that Maple may come up with.

So, even if you are restarting your program, it doesn't necessarily follow the same path each time, and once-in-a-while goes off on a path that you (or the developers) may not have considered. Try trivial things like changing the order of two statements where it shouldn't matter. I have noticed that "simplify" is especially prone to this problem. If you are using "simplify", try using one of the options to limit its operation to your case. I have long suspected that many of the built-in commands call "simplify" internally, in which case you have no control.

Also, be careful with your definition of freezing - sometimes the program path is just taking a long time. If the time clock on the bottom right changes, even at long intervals, and memory report jumps once-in-a-while, its not frozen, just taking its own sweet time (which can approximate eternity). In this case, the problem is that Maple has run out of memory.

Use taskmanager to keep an eye on this - the disk may be thrashing as memory is swapped in and out and whether or not you get a "freeze" will depend on the state of your machine.  Buy more memory if possible. Try judicious use of garbage collection (gc).

Good luck.

One of the reasons I upgraded to Maple 15 was the (unsupported) thought that maybe the "Latex export" facility in version 11 would have been improved by version 15.

My original post and your followup, shows that it wasn't. On April 26, 2011 I asked tech support to look into the issue. On July 27, 2011 I received the following:

"This is indeed a bug and we hope to have it fixed in a future release.
Thank you for providing us with this information."

So, for Latex export, I am now back to using Maple 11, which is bad, but not worse, and I am also squirrelling away  pennies for an eventual upgrade to Maple 19.

It escapes me how the purveyors of Maple can continue to distribute code with known bugs, and require that their customers purchase new versions to fix known flaws. No other manufacturer would get away with that.

Predictions

1. Someday, the consumer watchdogs will take a look at this issue and initiate class-action lawsuits.

2. In future, tech support will never acknowledge a bug.

Could you please interpret the statement "plot( [ <<L1>|<L2>>, <<L1>|<L3>> ] );" ?

I've been using Maple for many years and never seen the "bra-ket" "< >" notation ever used.

Nor does t he "help" give me any enlightenment. Is this some sort of Boolean operation?

It works, but why?

Thank you.

Could you please interpret the statement "plot( [ <<L1>|<L2>>, <<L1>|<L3>> ] );" ?

I've been using Maple for many years and never seen the "bra-ket" "< >" notation ever used.

Nor does t he "help" give me any enlightenment. Is this some sort of Boolean operation?

It works, but why?

Thank you.

I suppose it encourages the complainant to upgrade to the next version.

I have a collection of replies from technical support saying that bugs I have found "will be fixed in a future version".

How about a change of policy prior to Maple 17 - fix bugs as they are found.

(I have often wondered about the legality (as opposed to the wisdom) of continuing to distribute code with known bugs... Maybe someone would care to comment on that)