Either using the palettes or the keyboard, free-form entry is problematic because so many inputs are "syntactically valid Maple", while a much much smaller number of inputs is "semantically understandable by Maple". Unfortunately, there is still no button (or context-menu option, or ...) which will check if an expression you enter is "meaningful (in the context of calculus)", which is what a lot of beginning users really need. Actually, while I am sure some experts love the flexibility in being able annotate their documents with arbitrary mathematics, most users are only interested in mathematics which is "meaningful", and most of the time, that can even be interpreted to mean "meaningful to Maple". So it would be very useful if the default mode of entry would force users to enter only maple-meaningful Math; advanced users (as they currently do by switching to 1D mode) could turn on the option of being able to enter arbitrary mathematics via the equation editor. [Free-form entry is a clear issue of ``featuritis'' winning over ``usability'']

Long ago "it can be done" was the bar that software had to meet for users to be satisfied. Luckily, we are no longer in that era, and now the proper bar to meet is "it is simple and convenient", at least for ``common'' operations. Whether an overbar is indeed common is a different question. Personally, I am rather happy to live in a world of iPod (and now iPhone) being commodity devices. Even your average web browser is quite usable (for the purposes it was built for). That sets a standard at a level that benefits the customer. That being said, clearly Maplesoft and Wolfram Research are madly trying to meet that challenge -- our discussion here is not about their failure, but rather those areas where there is still a fair bit of room for improvement. Hopefully we will see further great improvements in this area in Maple 12, that will reflect the huge amount of feedback that has been offered on MaplePrimes. Hopefully no one thinks that the equation entry (and display!) in Standard is anywhere near ``finished''! There are still dozens of things where the quality of the equation display in Classic is far superior to that in Standard; I really hope that Maple 12 will have the Standard GUI at least recover the same quality of output that we had in Classic.

Long ago "it can be done" was the bar that software had to meet for users to be satisfied. Luckily, we are no longer in that era, and now the proper bar to meet is "it is simple and convenient", at least for ``common'' operations. Whether an overbar is indeed common is a different question. Personally, I am rather happy to live in a world of iPod (and now iPhone) being commodity devices. Even your average web browser is quite usable (for the purposes it was built for). That sets a standard at a level that benefits the customer. That being said, clearly Maplesoft and Wolfram Research are madly trying to meet that challenge -- our discussion here is not about their failure, but rather those areas where there is still a fair bit of room for improvement. Hopefully we will see further great improvements in this area in Maple 12, that will reflect the huge amount of feedback that has been offered on MaplePrimes. Hopefully no one thinks that the equation entry (and display!) in Standard is anywhere near ``finished''! There are still dozens of things where the quality of the equation display in Classic is far superior to that in Standard; I really hope that Maple 12 will have the Standard GUI at least recover the same quality of output that we had in Classic.

Maple 11 finds the following very nice solution, where simplify(pdsolve(PDE)); returns (and quite quickly too) {alpha[1](u,v) = -exp(1/2*I*(u-v))*(-_C4*cos(1/2*2^(1/2)*v)+I*cos(1/2*2^(1/2)*v)*_C3*2^(1/2)-_C3*sin(1/2*2^(1/2)*v)-I*_C4*sin(1/2*2^(1/2)*v)*2^(1/2)+_C1*sin(1/2*2^(1/2)*u)-I*_C2*sin(1/2*2^(1/2)*u)*2^(1/2)+_C2*cos(1/2*2^(1/2)*u)+I*cos(1/2*2^(1/2)*u)*_C1*2^(1/2)), alpha[2](u,v) = exp(-1/2*I*(u-v))*(_C1*sin(1/2*2^(1/2)*u)+_C2*cos(1/2*2^(1/2)*u)+_C3*sin(1/2*2^(1/2)*v)+_C4*cos(1/2*2^(1/2)*v)), beta[2](u,v) = 1/2*I*exp(1/2*I*(v+u))*(I*_C1*sin(1/2*2^(1/2)*u)+I*_C2*cos(1/2*2^(1/2)*u)+I*_C3*sin(1/2*2^(1/2)*v)+I*_C4*cos(1/2*2^(1/2)*v)-_C1*cos(1/2*2^(1/2)*u)*2^(1/2)+_C2*sin(1/2*2^(1/2)*u)*2^(1/2)), beta[1](u,v) = 1/2*I*exp(-1/2*I*(v+u))*(I*_C1*sin(1/2*2^(1/2)*u)+I*_C2*cos(1/2*2^(1/2)*u)+I*_C3*sin(1/2*2^(1/2)*v)+I*_C4*cos(1/2*2^(1/2)*v)+_C3*cos(1/2*2^(1/2)*v)*2^(1/2)-_C4*sin(1/2*2^(1/2)*v)*2^(1/2))} On my (large, high resolution) screen, the above equation pretty-prints very nicely, while the driver used on this site produces something rather narrow and really really badly line-broken. [See how it breaks beta[2](u,v) right before the v! This is astonishingly ugly, and I am surprised it has not been seen and fixed yet].

Maple 11 finds the following very nice solution, where simplify(pdsolve(PDE)); returns (and quite quickly too) {alpha[1](u,v) = -exp(1/2*I*(u-v))*(-_C4*cos(1/2*2^(1/2)*v)+I*cos(1/2*2^(1/2)*v)*_C3*2^(1/2)-_C3*sin(1/2*2^(1/2)*v)-I*_C4*sin(1/2*2^(1/2)*v)*2^(1/2)+_C1*sin(1/2*2^(1/2)*u)-I*_C2*sin(1/2*2^(1/2)*u)*2^(1/2)+_C2*cos(1/2*2^(1/2)*u)+I*cos(1/2*2^(1/2)*u)*_C1*2^(1/2)), alpha[2](u,v) = exp(-1/2*I*(u-v))*(_C1*sin(1/2*2^(1/2)*u)+_C2*cos(1/2*2^(1/2)*u)+_C3*sin(1/2*2^(1/2)*v)+_C4*cos(1/2*2^(1/2)*v)), beta[2](u,v) = 1/2*I*exp(1/2*I*(v+u))*(I*_C1*sin(1/2*2^(1/2)*u)+I*_C2*cos(1/2*2^(1/2)*u)+I*_C3*sin(1/2*2^(1/2)*v)+I*_C4*cos(1/2*2^(1/2)*v)-_C1*cos(1/2*2^(1/2)*u)*2^(1/2)+_C2*sin(1/2*2^(1/2)*u)*2^(1/2)), beta[1](u,v) = 1/2*I*exp(-1/2*I*(v+u))*(I*_C1*sin(1/2*2^(1/2)*u)+I*_C2*cos(1/2*2^(1/2)*u)+I*_C3*sin(1/2*2^(1/2)*v)+I*_C4*cos(1/2*2^(1/2)*v)+_C3*cos(1/2*2^(1/2)*v)*2^(1/2)-_C4*sin(1/2*2^(1/2)*v)*2^(1/2))} On my (large, high resolution) screen, the above equation pretty-prints very nicely, while the driver used on this site produces something rather narrow and really really badly line-broken. [See how it breaks beta[2](u,v) right before the v! This is astonishingly ugly, and I am surprised it has not been seen and fixed yet].

I am also all for new technologies (else what am I doing on this site?), but I am for new technologies that help me. I am just as happy using old tools if they are more efficient than the new ones. One the giant failures of the internet boom was the sheer number of technology-for-technology's sake ideas that were floated around, and even captured people's attention. This has not died down, but has mostly moved to the user-interface front rather than being about complete business plans. What I tried to say about pen-and-paper is that there are some kinds of ``computations'' (mostly derivations, ie proofs) that I can do with pen-and-paper in seconds, while coercing Maple to do the same thing for me would take several minutes, at best. Frequently the problem has nothing to do with Maple -- most mathematics uses a 2D notation that is much much faster to write on paper than it is to type or click through or whatever. This is why people try again-and-again to come up with good pen-based computers! Hopefully, one day, they will. Also, there are areas of mathematics in which Maple is still in a ``learning'' stage, so it can be easier to just "get the work done" the old fashioned way rather than fight with Maple [which for some of us means using Classic rather than Standard sometimes, not just pen vs technology].

Edgardo is right here -- the integrability conditions make it clear there are no solutions. Of course, this means 'no solutions over the complexes', as the theory of DEs over other domains is completely different. So you really need to make sure that you phrase your problem in terms of real and/or complex functions. The other possibility is that one sign is off somewhere, and that would be sufficient to throw everything off!

Edgardo is right here -- the integrability conditions make it clear there are no solutions. Of course, this means 'no solutions over the complexes', as the theory of DEs over other domains is completely different. So you really need to make sure that you phrase your problem in terms of real and/or complex functions. The other possibility is that one sign is off somewhere, and that would be sufficient to throw everything off!

I guess it must be the fact that I still frequently turn to math books written over 100 years ago when I am interested in ``computational mathematics''. While I have integrated the use of the Internet (and computers) into my daily life in all sorts of scary ways, I am still not infatuated with everything that's new -- sometimes the old ideas really are better. Slide rules are one of those old ideas that need to be re-examined by young minds. Not that we should use physical slide rules, but as you say, that the fundamental input/output paradigm embodied in slide rules could certainly be adapted to the computer age and provide for a very efficient means of interaction. This is also why a lot of people still do their mathematics with pen and paper -- because it is generally way more efficient than using a computer to do the same thing. Maybe one day computers will have methods of interaction (and accompanying software) that make them just-as-efficient as pen and paper; lots of people have tried, but no one has yet succeeded. Here I mean to "write down" mathematics, by a trained mathematician/scientist/engineer/etc. If you are instead interested in "exploring" a mathematical idea, then Maple is frequently a better tool than pen and paper.

I tried that from a session where I had done a bunch of work already, so that probably doesn't count, it should be redone. And I scanned the assume help page, as well as searching for '_Env' and did not find it. Very strange. Of course, I can already make is() take an extremely long time as it is, so the _EnvTry restriction is rather out-dated.

I tried that from a session where I had done a bunch of work already, so that probably doesn't count, it should be redone. And I scanned the assume help page, as well as searching for '_Env' and did not find it. Very strange. Of course, I can already make is() take an extremely long time as it is, so the _EnvTry restriction is rather out-dated.

Diff(Int(f(t),t=0..x), x) displays with a partial symbol [in both Classic and Standard], so whatever code makes that decision is "naive". In your problem, things are WAY harder -- Maple will think that 'a' is a variable, won't it? While I certainly can expect Maple to see that Int(f(t),t=0..x) contains just one variable, how is it supposed to guess that 'a' is a constant in Int(f(t),t=a..x) ? You need to be able to 'declare' this, otherwise Maple has no choice but to make the conservative guess that 'a' is a variable. As I have mentioned before, mathematics as performed by humans is highly context-sensitive, and when we don't bother telling the whole truth to our tools, well, we get what we deserve [GIGO].

Diff(Int(f(t),t=0..x), x) displays with a partial symbol [in both Classic and Standard], so whatever code makes that decision is "naive". In your problem, things are WAY harder -- Maple will think that 'a' is a variable, won't it? While I certainly can expect Maple to see that Int(f(t),t=0..x) contains just one variable, how is it supposed to guess that 'a' is a constant in Int(f(t),t=a..x) ? You need to be able to 'declare' this, otherwise Maple has no choice but to make the conservative guess that 'a' is a variable. As I have mentioned before, mathematics as performed by humans is highly context-sensitive, and when we don't bother telling the whole truth to our tools, well, we get what we deserve [GIGO].

there really is just one variable in Int(t,t=0..x), at least semantically. Maple knows this as depends(Int(t,t=0..x),t) correctly returns false. The problem is that fsolve is likely doing a naive syntactic operation to grab the ``variables''. Maple is full of such issues where it relies on syntax [which users don't care about] instead of semantics [which is where one wants to pretend to work]. Using just a raw 'indets' to pick out ``variables'' from a Maple expression is one of those Maple anti-patterns, like adding one element-at-a-time to a list or set (or a symbolic `+` DAG). Hmm, maybe we should start an 'anti-patterns' page in the Tools of the Maple Masters book.

there really is just one variable in Int(t,t=0..x), at least semantically. Maple knows this as depends(Int(t,t=0..x),t) correctly returns false. The problem is that fsolve is likely doing a naive syntactic operation to grab the ``variables''. Maple is full of such issues where it relies on syntax [which users don't care about] instead of semantics [which is where one wants to pretend to work]. Using just a raw 'indets' to pick out ``variables'' from a Maple expression is one of those Maple anti-patterns, like adding one element-at-a-time to a list or set (or a symbolic `+` DAG). Hmm, maybe we should start an 'anti-patterns' page in the Tools of the Maple Masters book.