I really should have been more precise and talked about zero equivalence, as discussed before.

Certain classes of functions means functions which are both analytic (or at least meromorphic) and whose definition involves closed-forms only [like the class of holonomic functions.

You are right that nesting produces complexity in weird ways.  Originally, it was thought that nesting was reasonably well-behaved, and this lead to the uniformity conjecture, for which some counter-examples were later found.  However, for special functions, the situation is well-understood and deciding whether an expression is zero is decidable (see the work of van der Hoeven from the first link).

I really should have been more precise and talked about zero equivalence, as discussed before.

Certain classes of functions means functions which are both analytic (or at least meromorphic) and whose definition involves closed-forms only [like the class of holonomic functions.

You are right that nesting produces complexity in weird ways.  Originally, it was thought that nesting was reasonably well-behaved, and this lead to the uniformity conjecture, for which some counter-examples were later found.  However, for special functions, the situation is well-understood and deciding whether an expression is zero is decidable (see the work of van der Hoeven from the first link).

If Maple insists on using FTOC and discontinuous anti-derivatives for definite integration, then it has to be able to figure out all the points of discontinuity in the domain, as well as properly figuring out all the limits involved (which is very very hard in this particular case).  My guess is that sufficient digging into this particular issue would reveal an actual bug in either discont or limit.  I have fixed many bugs in int in my time that were just like this one, and pretty much all of them reduced to a discont or limit bug.  As I have stated before, it is now my belief that although FTOC is a wonderful theorem of "theoretical calculus", its actually computational usefulness is much more limited [a statement with which you seem to agree in this particular instance].

with a particular LF, we can figure out what is really going on.  It might be that, while fixing some bug in Maple 10, this was broken for 11, unbeknownst to the developers.  If you can find such an instance, then it is worth reporting that bug (known as a 'regression' bug, which are taken quite seriously).

If by "finding the domain" you actually mean "finding where the function is properly defined", then for certain classes of functions that is algorithmic (up to deciding zero of the underlying domain).  This is a result one of my students obtained about 4 years ago, but unfortunately we never published it.  Of course, it is trivial to come up with weird cases where the problem is extremely hard - think of sin(1/sin(1/x)) for example.  But for 'shallow' functions (ie no nasty nesting), this is easy.  It is most likely undecidable in the nested case, probably as soon as you have 3 levels of nesting I would guess.

If by "finding the domain" you actually mean "finding where the function is properly defined", then for certain classes of functions that is algorithmic (up to deciding zero of the underlying domain).  This is a result one of my students obtained about 4 years ago, but unfortunately we never published it.  Of course, it is trivial to come up with weird cases where the problem is extremely hard - think of sin(1/sin(1/x)) for example.  But for 'shallow' functions (ie no nasty nesting), this is easy.  It is most likely undecidable in the nested case, probably as soon as you have 3 levels of nesting I would guess.

In just a few contexts, indexed variables don't quite work as normal variables do in the rest of Maple.  Because it is a bit unpredictable which functions will/will not work properly with indexed variables, long-term users have made a habit of avoiding them, just to be safe.

In just a few contexts, indexed variables don't quite work as normal variables do in the rest of Maple.  Because it is a bit unpredictable which functions will/will not work properly with indexed variables, long-term users have made a habit of avoiding them, just to be safe.

We tried many different names just based on maple - maple.com, maple.on.ca, etc, all of which were already taken.  At the time, we were still "Waterloo Maple Software".  'maplesoft' had Maple in it, was a short-form for the current company name, and was a really memorable pun on 'microsoft' too.  At the time, Microsoft was a quickly growing company, not "the evil empire" yet!  People who were around at the time liked it, so that was it.

Basically what convert/FormalPowerSeries does (but with considerably more code) is

1. get a DE with gfun[holexprtodiffeq]
2. translate to a recurrence with gfun[diffeqtorec]
3. get a hypergeometric solution with LREtools[hypergeomsols]
4. fool around a bit to match up initial conditions (this is not always easy!)

This is remarkably powerful, as so many functions are indeed holonomic, but is limited to that class.

Basically what convert/FormalPowerSeries does (but with considerably more code) is

1. get a DE with gfun[holexprtodiffeq]
2. translate to a recurrence with gfun[diffeqtorec]
3. get a hypergeometric solution with LREtools[hypergeomsols]
4. fool around a bit to match up initial conditions (this is not always easy!)

This is remarkably powerful, as so many functions are indeed holonomic, but is limited to that class.

No, such lawsuits are not 'usual'.  However, in some cases they appear to be justified.

Over 20 years ago, the so-called 'lemon laws' in the US were instituted because of the harm to consumers caused by bad cars.  They were instituted as a response to many successful lawsuits against car companies.

Current consumer protection legislation in most countries have exceptions built-in for software.  In other words, you are not allowed to sell bad toasters or bad cars, but it is perfectly OK to sell bad software.  It is my personal opinion that in less than 10 years, this will change.  Software will have to be "fit for purpose", otherwise the consumer will be either allowed their money back (for simple shrink wrap software) or liability payments (if the software advertised itself as suitable for an engineering or health-related task).  The software industry (in general) today is very much like the North American car industry of the mid-70s.  There are exceptions: I have talked to software developers who make true "engineering software", and they are much more ready for the era of liability lawsuits than makers of consumer software.

In its earliest incarnation, Maplesoft was known as 'Waterloo Maple Software Incorporated', or WMSI for short.  That can easily be pronounced 'whimsy'.  From there, it is not far to the english word whimsical.  Folding that back in, one gets wmsical. 

I did not remember all those details.  The email came through the University of Waterloo (we had a direct phone line), but Waterloo got most of its 'net connection through Toronto, yes.

But what I meant was that 'wmsical' is in part an acronym - of what?

I should have tried my own idea before posting it!  [I was in a hurry when I posted it].  It seems that assuming traps all errors itself and simply returns the value of its argument if the assumptions "go wrong".  It is unclear to me if that is actually the right design.  I would rather think that that is a bug.