In this case, Maple could have in fact done things your way.  t-x and x-t are definitely different expressions.  And while, to Maple -t+x and x-t are the same, (-1)*f(t)*(t-x) and f(t)*(x-t) are in fact different.

Basically, this is due to Maple doing

1. internal ordering of sums by address
2. automatic distribution of integer factors inside sums.

Note that automatic distribution of integer factors does not happen inside products.  So while you have no control over 2*(x-1) [it always show up as 2*x-2], you have control over 2*a*(x-1) [which shows as is].  So, in your case, it is possible to choose to put that -1 factor inside the polynomial factor instead of out.

In fact, it seems that Maple 11 (unlike Maple 9.5) chooses a form closer to your liking.

Of course, we humans prefer our binomial terms with one positive and one negative coefficient to show as A-B rather than -B+A.  That is one of those deep design decisions from the early days (see a previous post on that topic) that is unlikely to change.

In this case, Maple could have in fact done things your way.  t-x and x-t are definitely different expressions.  And while, to Maple -t+x and x-t are the same, (-1)*f(t)*(t-x) and f(t)*(x-t) are in fact different.

Basically, this is due to Maple doing

1. internal ordering of sums by address
2. automatic distribution of integer factors inside sums.

Note that automatic distribution of integer factors does not happen inside products.  So while you have no control over 2*(x-1) [it always show up as 2*x-2], you have control over 2*a*(x-1) [which shows as is].  So, in your case, it is possible to choose to put that -1 factor inside the polynomial factor instead of out.

In fact, it seems that Maple 11 (unlike Maple 9.5) chooses a form closer to your liking.

Of course, we humans prefer our binomial terms with one positive and one negative coefficient to show as A-B rather than -B+A.  That is one of those deep design decisions from the early days (see a previous post on that topic) that is unlikely to change.

I should have made it clear that the fact that the core design decisions behind Maple can no longer be changed does not mean that Maple cannot evolve or isn't evolving.  From looking at what is done in each release, it should be quite clear that it is definitely evolving.  We can certainly discuss (and often have) whether this evolution is 1) fast enough, and 2) in places of interest to [current] Maple users. 

What it does imply is that some avenues of evolution are closed.  But in some ways, it is not clear how much that really matters.  For example, the current design decisions don't really restrict how good a symbolic integrator or a symbolic differential equation solver you can write in Maple.  Granted, some of the internals may be sub-optimal, but that has no real effect on whether an answer canor cannot be computed.  At worst, it affects performance.

My guess is that fsolve simply does not have special-case code for piecewise (yet).  So it resorts to purely numerical techniques, which are much easier to fool.  My hope is that your post will cause someone at Maplesoft to go 'oops', and add the few lines of code necessary to fix it.

My guess is that fsolve simply does not have special-case code for piecewise (yet).  So it resorts to purely numerical techniques, which are much easier to fool.  My hope is that your post will cause someone at Maplesoft to go 'oops', and add the few lines of code necessary to fix it.

Last week was really busy for me, so now is the first time where I have a moment where I can answer this properly.

1) Yes, I am absolutely convinced that the next few years would have been very different; Maple and Maplesoft would be very different.  Would 'different' mean better?  It is possible.  But I did work at Maplesoft for a time when Gaston was trying to 'direct' the company and its development remotely from Switzerland.  That was not a happy time for the employees, who were extremely resentful of having someone who only knew bits and pieces of the issues make sweeping decisions "from on high".  The decisions may have been right in some cases but we certainly felt like some of them were absolutely wrong. 

For example, Gaston for a very long time prevented lexical scoping from being implemented in the language.  He said he just didn't see the point, and it would slow down Maple unecessarily.  That was one of the first thing that was implemented once it was finally possible to do so.  AFAIK, Darwin has lexical scoping now, as Gaston saw the benefits [and that it could be implemented at no real efficiency cost].

2) Long before Gaston Gonnet, David Parnas wrote about Software Aging (online version).  That paper is an excellent read. 

Maple is now 28 years old - and some of the fundamental decisions of the early years are still there.  Some of those decisions were brilliant, others were not.  However many of those decisions were made within the context of what was well-known in 1980 [ie state-of-the-art circa 1973] by the people doing the actual work.  Remember, you can't expect experts in data structures and computer algebra to also be experts in programming languages and software engineering, right? So Maple has indeed aged quite a lot.  Every single force documented in Parnas' paper has acted on Maple. [The same is true for Maple's competition too!]

To answer your fundamental question: no, the internal workings of CAS systems do not change significantly once these systems reach the age of 2 or 3 years old.  Very significant new features (Threads very recently, modules longer ago, etc) can be added, but a set of a dozen or so fundamental decisions (basic data-structures and their implementation, garbage collection strategy, basic semantics of the language, general syntax of the language, structure of the language interpreter, the interaction paradigm, abstraction and information hiding tools, the meaning of some concepts (types, symbols, variables, ...), etc) become fixed.  Many of the decisions taken on those issues between 1980-1985 were excellent in the context of those years.  Unfortunately, a number of these have 'aged' significantly, so that a new system would most definitely choose otherwise.

The main reason that the Computer Algebra landscape only has Maple and Mathematica as the only viable competitors is that building a decent system seems to require around 100 person-years, and take at least 8 elapsed years to get something stable.  One can build a nice system for a smaller niche in less time and effort, but not something as broad as these two.  So that this a huge barrier to entry.  And because the competition does not stand still, attempts at breaking in (MuPAD) did not succeed [though there are a host of other reasons why MuPAD did not succeed].  That is also the same reason that Matlab is pretty much alone in its field (Scilab notwithstanding), even though it is even older [and it shows].

Note that Maplesoft itself is "semi private".  From the perspective of the law it is not a public company.  However, the company structure has a (largish) number of shareholders how own the company, and vote on who the board of directors is.  Once in a while, the company issues dividends to those shareholders when it is profitable.  The board of directors, along with the CEO, decide whether the corporation should go for the "long term" or the "short term".  Which it is can best be seen by the evolution of the main product, Maple, and the introduction of the plethora of side-products over the past few years.  Whether this is good or bad really depends on whether you are a (major) shareholder of Maplesoft or a heavy user of Maple.

Take a look at recent Maplesoft press releases - it is not hard to read the tea leaves.  Clearly they are working hard on "physical modeling" (or variations thereof, the tea leaves are not precise on that point).  And that kind of modeling very naturally produces DAEs.  So, if they want to be credible in that space, that will naturally lead to improvements to the DAE solvers.

Jeff Shallit documents this particular story as an urban legend.  More details over at JSTOR.

That is extremely kind of you, but Euler was an astonishing genius.  I just have many years of experience in math, CS and Maple, and am indeed quite happy to answer questions.

As to the matter at hand - the question forum is for just that, questions.  'blog' here is used a little bit funny, but it is for (often longer) expository material that many might find interesting.  It can range rather widely in topic, but the main feature is that it is expository rather than asking a definite question.

If you ask Will (since this is your post), he might be able to move it.

Why was this posted in the student forum instead of on your blog?  Your blog would have seemed a really appropriate place for an interesting story like this -- and it most definitely isn't a "student question"!

William Kahan, winner of the 1989 Turing award for his deep and long-lasting work in numerical analysis, has been telling all software makers the same thing for decades: by default, essentially all non-trivial Matrix computations should output the condition number of the Matrix as part of its output.  This would at least alert users to the issue that the result might be complete nonsense, as the result should be trusted only when the number of Digits in the computation outweigh the condition number's effect.

Maple, like Matlab, has not yet listened to this sound advice.  Most numerical analysis instructors do not give this advice either.  So we continue to perpetrate a fraud on these students, leading to believe that numerical analysis can do more than is real.

William Kahan, winner of the 1989 Turing award for his deep and long-lasting work in numerical analysis, has been telling all software makers the same thing for decades: by default, essentially all non-trivial Matrix computations should output the condition number of the Matrix as part of its output.  This would at least alert users to the issue that the result might be complete nonsense, as the result should be trusted only when the number of Digits in the computation outweigh the condition number's effect.

Maple, like Matlab, has not yet listened to this sound advice.  Most numerical analysis instructors do not give this advice either.  So we continue to perpetrate a fraud on these students, leading to believe that numerical analysis can do more than is real.

It is important to note that the quote was from Gaston - I just happen to like it because it reflects my personal opinion for my own use of Maple.  But I have a definite usage style: I am a ``power user'', who does not use Maple as a glorified calculator, but rather as an advanced productivity-enhancing tool.  Pointy-clicky features definitely allow more people to draw more power out of Maple.  But that merely moves the bar from glorified calculator to super-duper calculator.   That usage mode of Maple can, at best, draw out about 20% of Maple's true power.  To get at the rest, you need to dig in deeper.

Note that I am not against pointy-clicky features.  Some of them even enhanced the productivity of power users.  The best example is Microsoft's last 2 versions of Visual Studio.  Using F^# in Visual Studio is definitely better than using it old-style (with a text editor and a command line).  The features provided by Visual Studio are definite productivity enhancers for serious programmers.

I believe that he means in terms of market share, as well as "mind share".  Many many more people have heard of Mathematica than of Maple.  Of course, that may be an entirely irrelevant statistic: when interestect with potential users of these products, it is quite possible that the statistic is not so skewed anymore.

He basically bemoans the issue that very little attention was paid to interface issues early on.  He is also mystified by the "fact" that the market seemed to prefer a product that looked good over a product that was correct.  This was one of the hard lessons -- that marketing trumps technical matters.

This has to be taken with a big grain of salt.  Advanced users of Mathematica express very similar frustrations as Maple users over interface issues.  Features that are easy to sell and easy to demo are not necessarily useful features!