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].

The weirdest thing is that for such problems, the assume facility uses... simplex! So it appears that there is a real, non-trivial bug in that area of assume. Since linear programming is so well and thoroughly understood, FAIL is not even an acceptable answer, things should be true/false here. I will make an explicit bug report.

The weirdest thing is that for such problems, the assume facility uses... simplex! So it appears that there is a real, non-trivial bug in that area of assume. Since linear programming is so well and thoroughly understood, FAIL is not even an acceptable answer, things should be true/false here. I will make an explicit bug report.

whattype lies sometimes. It gives back a type t for some expressions expr which "type(expr,t)" will return 'false' ! It is a useful command for interactive uses, but should never be relied upon in programs.

whattype lies sometimes. It gives back a type t for some expressions expr which "type(expr,t)" will return 'false' ! It is a useful command for interactive uses, but should never be relied upon in programs.

Try using plotsetup(ps,plotoutput=`myfile.ps`); This (used to) use a completely different plot driver, which was free of those bugs.

It seems that if you really want your bug reports to 'count', the best way still is to email them to support@maplesoft.com, else they don't always get logged.

If you miss some recent stuff, use the left-hand Navigation section and use 'recent posts'. I have been using that constantly today to catch up on a week's worth of posting content (in reverse chronological order). And, like you, I would like it if all of our suggestions were at least explicitly acknowledged - even those which will not be implemented, for one (good) reason or another.

The poll was great when it changed monthly, but it's been stuck for quite some time now. Seems Tom 4 is slacking off...

Yes, well, there really is a singularity there. I don't know why PDEtools[dchange] is flumoxed by that - it would be nice if the error message was more precise as to why this is a problem.

Yes, well, there really is a singularity there. I don't know why PDEtools[dchange] is flumoxed by that - it would be nice if the error message was more precise as to why this is a problem.

In other words, even if the current very partial handling of module exports is by-design, it is quite fragile. By all accounts, it seems that the Maple 10 behaviour was definitely preferable. Hopefully this regression will be fixed in 12.

My description was indeed 'operational' rather than a justification. It is indeed strange that this started ``working'' in Maple 11, it seems like a regression rather than an improvement! I cannot really think of a rationale for doing this (other than ``it can be done''). Hopefully we'll get an official answer on this one. But, just to be sure, you should probably file this as a bug with support@maplesoft.com.

Look at the following:

> ToInert(p:-sin);

  _Inert_ASSIGNEDLOCALNAME("sin", "PROC", 143973196, _Inert_ATTRIBUTE(

        _Inert_NAME("protected",

        _Inert_ATTRIBUTE(_Inert_NAME("protected")))))

which mostly says that p:-sin looks like a (local) name 'sin'. And evalhf does its dispatch based solely on the name of the function. Whether this is right or wrong is another matter, but it is in many ways ``expected''.

A long time ago, there was a half-hearted attempt to ``rationalize'' the Maple naming scheme. One of the pre-conditions to being able to implement any naming-scheme was a way to be able to distinguish between various kinds of names (system, constants, inert, etc). It was agreed that % would serve as the prefix for inertizing, so that %int would replace Int, etc, leading to much less confusion as well as much more regularity; it would also help clean up the issue that some routines return inert versions, others return unevaluated, while others return new data-structures, all when denoting essentially the same idea. Some of the features needed for a better naming scheme were (partly) implemented (like %, and TypeTools). But at some point, this kind of radical infrastructure work became unfashionable, and was dropped. Of course, this only ever lasts so long, and Maple 11 has seen serious infrastructure work (for examples for Threads and making many more packages into modules) done behind the scenes. It is even possible that the %-prefix got documented somewhere, but I really can't recall where that would be.