Note this output from Maple:

> assume( mU <1-u, mU > 0, u >0, u<1, mU <1, mU >3/4*(1-u), mU < u,mU <1/2*u, mU < 1/4*u) ;
> coulditbe(mU > 1-u);
                                      FAIL

> is(mU > 1-u);
                                     false

So is is correct, and returns this very fast. And now I see the issue -- coulditbe is essentially a 'clone' of is [with very minor changes in logic], but is has been repaired while coulditbe has not. However, with much black magic, one can convince coulditbe to be smarter:

> _EnvTry := 'hard';
> coulditbe(mU > 1-u);
                                     true

No, I don't think _EnvTry is documented anywhere. That's what showstat is for...

Note this output from Maple:

> assume( mU <1-u, mU > 0, u >0, u<1, mU <1, mU >3/4*(1-u), mU < u,mU <1/2*u, mU < 1/4*u) ;
> coulditbe(mU > 1-u);
                                      FAIL

> is(mU > 1-u);
                                     false

So is is correct, and returns this very fast. And now I see the issue -- coulditbe is essentially a 'clone' of is [with very minor changes in logic], but is has been repaired while coulditbe has not. However, with much black magic, one can convince coulditbe to be smarter:

> _EnvTry := 'hard';
> coulditbe(mU > 1-u);
                                     true

No, I don't think _EnvTry is documented anywhere. That's what showstat is for...

Logged in as myself, my score shows up as 895 [I guess it will be 896 when I post this], so it would be odd if you saw it as 900! [Though I am sure I will get there soon enough...] Currently, there is no color past red. Someone on another post suggested that there be a new colour established for 1000, which is a nice 'round' number to aim for. Or we could be ubber-geeks and request that it be for 1024. In any case, no Maplesoft-ite has yet replied one way or another with hints of a 'next' colour. And good luck on the Grad School thing. Have fun with it!

Not the ones who are in charge of running this site (as the French would say, that would be 'louche'), but those who volunteer their time and post. If current trends are any indication, I would certainly wish to nominate certain contributors who fall into this category.

that Axel means a[j,k] instead of a[j][k].

that Axel means a[j,k] instead of a[j][k].

It is bad that there is a bug, but in the long term this strategy is certainly better. Of course, there are also duplicate LaTeX generators, different HTML generators, different pretty-printers, etc [all with their pros and cons too]. Good luck in ensuring that the one that 'remains' is the least buggy... [writing drivers that produce aesthetically pleasant results is a highly under-estimated task, and usually requires years of effort, and this effort does not seem to be "compressible", at least it has not been the case so far for any of the drivers (plots or pretty-printers)!].

I tried to reproduce this, and I could not come up with an example! The most 'misleading' (although not strictly wrong) I could come up with are

> whattype(Pi), whattype(gamma), whattype(true);
                        symbol, symbol, symbol

Of course, this provides an example (because the type call fails), but is again borderline:

> whattype(NULL), whattype(1,2,3);
                           exprseq, exprseq

But raw expressions sequences always cause problems in Maple, so that's not surprising (and is actually documented).

I tried to reproduce this, and I could not come up with an example! The most 'misleading' (although not strictly wrong) I could come up with are

> whattype(Pi), whattype(gamma), whattype(true);
                        symbol, symbol, symbol

Of course, this provides an example (because the type call fails), but is again borderline:

> whattype(NULL), whattype(1,2,3);
                           exprseq, exprseq

But raw expressions sequences always cause problems in Maple, so that's not surprising (and is actually documented).

Perhaps anames(user) would be a more precise way of filtering?

It is the "design" of whattype which is flawed. So this can't really be fixed, as it might introduce backwards compatibilities. Which is why it is best avoided altogether. I know that it has been (all but) erradicated from Maple's own library. Whatever 'commands' are in Maple but actually not used in Maple's own library, it is best to follow the lead of the Maple developers...

It is the "design" of whattype which is flawed. So this can't really be fixed, as it might introduce backwards compatibilities. Which is why it is best avoided altogether. I know that it has been (all but) erradicated from Maple's own library. Whatever 'commands' are in Maple but actually not used in Maple's own library, it is best to follow the lead of the Maple developers...

A link to this post probably belongs in the 'tools of the masters' book.

Maple's symbolic capabilities are fundamentally based on expressions (i.e. like piecewise). While some routines will sometimes work with procedures too, the results are frequently more complicated [if you get results at all], and often buggier. Why do you insist on using computer-science style of writing functions defined piecewise instead of the more mathematical way of doing it? Combining that with Maple, it seems like you are trying to make things more difficult for yourself. [I am aware that the 'input' of piecewise functions in Maple 8 is more awkward than the corresponding sequence of ifs, but not by a lot].

Could you please post the exact sequence of commands that caused the error in PDEtools[dchange]? The author needs that to look into the problem further [he asked me to post].