I know that the algorithm for choosing tickmarks in Classic was worked on very extensively.  It would be most clever of the Standard writers to reverse engineer the algorithm (ie read the code and understand it) and re-implement it in Java.  That would take at least an order of magnitude fewer hours than trying to reinvent something as good.

While they're at it, they could do something similar with the pretty-printer...

The one I referred to was Digital Tigers, just in case you had not found it yet.

And the latest research shows that the start of your post was right.  Computers do seem to harm people's skills and creativity!  [As a professor of Computer Science, this is not good news for me either].

That's clearly just a bug in the printer for procedures, which hasn't been updated to be 'modern'.  I'm guessing it would take less than 5 minutes to fix (and a couple of days to fix the test failures that would ensue!).

More specifically, the bug is in the naive way that `coulditbe/internal` treats "indeterminates".  Basically in the first case, assume is able to abstract out x,y and t and retain only Q.  In the second case, it can't, and then runs out of steam and FAILs.

There are 2 hacks which I can think of to fix this.  The simplest one: 

eval(eval(eq), signum = proc(a,b) if nargs=2 and a=1 and b=Q(x,y,t) then 0 else 'signum'(args) end if end proc);

A more complicated approach would involve first replacing all the derivatives by names (like you do later in your code), including 0th order (is Q(x,y,t) becomes QQ say).  Put assumptions on QQ, BB, HH, etc, NOT on Q(x,y,t) [this should be done before the substitution btw].  If you do the replacement via eval (and not subs), then the signums should go away on their own.

You should report the bug in assume (see 'Submit Maple SCR' on the left hand navigation bar).

More specifically, the bug is in the naive way that `coulditbe/internal` treats "indeterminates".  Basically in the first case, assume is able to abstract out x,y and t and retain only Q.  In the second case, it can't, and then runs out of steam and FAILs.

There are 2 hacks which I can think of to fix this.  The simplest one: 

eval(eval(eq), signum = proc(a,b) if nargs=2 and a=1 and b=Q(x,y,t) then 0 else 'signum'(args) end if end proc);

A more complicated approach would involve first replacing all the derivatives by names (like you do later in your code), including 0th order (is Q(x,y,t) becomes QQ say).  Put assumptions on QQ, BB, HH, etc, NOT on Q(x,y,t) [this should be done before the substitution btw].  If you do the replacement via eval (and not subs), then the signums should go away on their own.

You should report the bug in assume (see 'Submit Maple SCR' on the left hand navigation bar).

A system that allows you to vote for/against (like on reddit) but is completely optional would be best.  Good answers would rise up, bad answers get buried.  It also seems to work fine on digg.

I believe that the ideas which I listed in my previous post are the key ideas needed for that path.  They are really quite profound design idea which are quite fruitful once you 'get it'. 

You are quite right.  What I was suggesting was one small step in getting Maple to travel down the same road.  Remember, Maple is closed-source and Maplesoft is for-profit, so this is a rather different problem.  But note that you only need a large published test suite for observing the results, not the full test suite [although this doesn't help with coverage].  BTW, Wolfram Research is even more secretive.

There aught to be a way to make sure that the account 'PatrickT' keeps its stars properly, even if you change your email address.

I got confirmation this morning that this output is incorrect and is ultimately due to a bug in Maple's SolveTools:-Linear routine.

I got confirmation this morning that this output is incorrect and is ultimately due to a bug in Maple's SolveTools:-Linear routine.

As promised above, there will be a special of JAR dedicated to this topic - see the CFP.

Depending on the guide, I might find such a tour most amusing and entertaining.

And you are quite right that a visit to Waterloo might be more exciting for others...

I will take this opportunity to point out my principal advice for Maplesoft: 

Make sure that Maple is useful to its users.

By 'useful', I mean that it is a convenient tool to get 'real work' done.  In other words, it helps you solve problems.  The system should otherwise be completely invisible to users, in the same way a good hammer becomes a trusted but an invisible tool when the problem is a nail.

And while it is fine to expand Maple's user-base, it is extremely important that the product be useful to whatever the set of users who actually purchase the product - past, present and future.

The easiest way to make sure a product is useful is through the development of "use cases".  In Maple's case, this means making sure that problems which ought to be seamlessly solveable with Maple actually are.  One can test this in various ways.  The most instructive is to give completely new users a specific problem to solve (using Maple) and observe them [in a usability lab, i.e. behind one-way glass].  I could expand on this testing methodology and its variants, but this is rather well documented in the literature.  This is a particularly effective way to test whether a new feature is useful.