The functionality should be there to be helpful to users, not to 'train' users to think in a new, incompatible way! I consider this to be a bug. Some might claim it's a design decision - then it's a design bug. The requirements are clear: help the user. This does not do that - so it's a bug.

discont=true was, at one point, very seriously considered as the default. This was rejected for two reasons: 1) speed, and 2) bugs. Basically, when this considered, this slowed down plot too much; also there were enough problems with the underlying routines that discont uses that resulted in too many missed and/or spurious discontinuities that it was deemed 'premature' to make that change. But that was quite a long time ago now. Enough things have changed that this default should be seriously re-examined, as it might now be feasible to make discont=true the default.

Simon is quite the character. When you ask them (and I have talked to both Borweins about this), they readily admit that the first formula (and first ISC) was indeed created by Simon. However, their contribution was to provide both satisfactory mathematical explanations (formula and calculator) as well as important generalizations (again both). And they provided much publicity to this result. Inventors frequently underestimate the effort it takes to properly frame and publicize big discoveries so that the mainstream (first of mathematicians, then the 'larger' mainstream) understands and appreciates the result. Maplesoft is the conduit through which Maple, a product originally created/invented by just a few people, has been transformed from pure invention to useful product.

Jon Borwein has a competing version of the ISC. This latter one is much more algorithm-driven (like PSLQ) than database-driven. My well-known bias is to go for algorithms over databases.

FTC is a non-constructive theorem - it only tells you that there exists a continuous anti-derivative, not how to find it. Current algorithms for finding an anti-derivative, the famous Risch algorithm and its many extensions, is well-known to ignore issues of continuity altogether, since it is a purely algebraic algorithm. No one has yet designed an algorithm for integration in finite terms that respects analysis, except for some very small families of expressions.

Such an option, while potentially quite useful [though sometimes misleading as well], has one big problem: it would essentially admit that Maple has bugs. Otherwise, what would be the point of that option? Of course, if one is serious about applying Maple to problems in engineering, then that option is not a nicety, but manditory. Interesting conundrum, really.

There has to be some infrastructure way to stop this! I am sure there must be a Drupal module that is explicitly made to prevent this. This time, it's pEtAPgNzYENQB and ZPoTEhIyYwXyx.

The underlying OS certainly has a Sleep function. The point of using another thread is that, at worst, one can use it to call out to a C program, and then get woken up when that has finished sleeping. Event-based programming for these things is better than an explicit sleep call.

The underlying OS certainly has a Sleep function. The point of using another thread is that, at worst, one can use it to call out to a C program, and then get woken up when that has finished sleeping. Event-based programming for these things is better than an explicit sleep call.

That is active waiting. Sleeping involves the CPU doing nothing - the above routine will drive the CPU usage to 100%. system(sprintf("sleep %d",delay)) is friendlier; one can also do similar things with Threads[Wait].

That is active waiting. Sleeping involves the CPU doing nothing - the above routine will drive the CPU usage to 100%. system(sprintf("sleep %d",delay)) is friendlier; one can also do similar things with Threads[Wait].

On the theory side, very little progress has been made since that paper [which I quite like, but from the footnotes, you can probably figure out why!]. It is possible that some practical work inside Maplesoft has been done to make things better - I guess we will find out when Maple 12 comes out. For definite integration, other than table-lookup and methods based on MeijerG functions [both implemented and used heavily], there are also methods based on contour integrals [implemented in Maple but the code is seldom used], integral transforms [not implemented], and differential operators [not implemented].

MapleMIX is written to respect Maple semantics. Since Digits and UseHardwareFloats are environment variables, they have to be treated as dynamic. This means that any reference to Digits will be residualized, and branches depending on Digits as well. In other words, what would be residualized by MapleMIX here would contain an if. The advantage of MapleMIX is that this is all automatic [and configurable]. What had to be done for Statistics:-ExternalSupport:-DefineExternal was that someone had to think of what the good residual code should be and hand-create good templates. This is difficult and error-prone -- although a fair bit easier in Maple than in C++ say.

MapleMIX is written to respect Maple semantics. Since Digits and UseHardwareFloats are environment variables, they have to be treated as dynamic. This means that any reference to Digits will be residualized, and branches depending on Digits as well. In other words, what would be residualized by MapleMIX here would contain an if. The advantage of MapleMIX is that this is all automatic [and configurable]. What had to be done for Statistics:-ExternalSupport:-DefineExternal was that someone had to think of what the good residual code should be and hand-create good templates. This is difficult and error-prone -- although a fair bit easier in Maple than in C++ say.

What you are noticing there is how expensive it is to call a function in Maple. For raw speed, you need to inline functions as much as possible. Then you need to eliminate as many maple-level loops as possible. Unfortunately, for creating Matrices, these two goals pull in opposite directions!