The one thing I still have not figured out how to do - linking to images. Clearly you have, please tell us how!

For solving problems of this kind, Risch's algorithm is totally useless. In fact, this answer may well be coming out of Risch. The Risch algorithm (in full or in parts) is well-known to not care at all about continuity, and to produce wildly discontinuous answers for clearly continuous inputs. Mathematica is clearly not using (classical) Risch to get this integral correct. The problem is that the Risch algorithm is purely algebraic, while integration, definite or indefinite, is a problem of analysis. Even though this issue has been identified a long time ago, very few people have made much progress in this area. This is a large gaping hole in the theory, and it does not look like it will be filled any time soon. My (admittedly radical) opinion: the Fundamental Theorem of Calculus is one of the worst ways of solving problems of definite integration. I used to think FTOC was brilliant as both a theorem and as a computational means; now I have revised that to just 'as a theorem'. This is from years of hard-won experience fixing bugs in definite integration routines. Computationally, computing the limits required to apply FTOC seem to be (in general) a more difficult problem than the original integration problem!

While Scott has done a great job administering the site, this kind of fix needs programming - that was what Will did. But he is now on other projects. This is plainly visible by the fact that, for the past year, our mapleprimes suggestions have not been implemented, while for the year before that, most user suggestions for mapleprimes got implemented within a week, often times even faster than that.

You have just clearly illustrated the benefits of readable source. Imagine what we could do if we had even more access?

I think you have just identified a new, real bug -- adding that extra type-check should not have that dramatic an effect! The time and memory allocation traces there point to a real issue that needs to be looked at by someone in the kernel group.

Now it is the turn of user eTwqgQegPG to muck up the rankings by having a whole lot of phantom blog posts.

is actually the original author of the Statistics package. Unfortunately, he has moved on to work in the Financial industry. I do not think he looks at mapleprimes anymore.

What our code would do would be to reduce a procedure that says

proc(n::posint) local X;
    X := Statistics:-RandomVariable(Normal(0,1));
    Statistics:-Sample(X,n);

down to something like

proc(n::posint) local X, p;
    X := [explicit procedure];
    [the code for Statistics:-ExternalSupport:-Initialize ];
    p := [explict routine given by Statistics:-ExternalSupport:-DefineExternal("MapleNormalRandomSample");]
p(n,0,1);
end proc;

Actually, we might even be able to optimize that further, where X and p above would be done as static module exports. Think of it as massive and aggressive inlining if you wish, along with some "smarts" to get it right. [I was tempted to not answer right away, as my Maple Ranking of 1111 was rather amusing, but oh well]

What our code would do would be to reduce a procedure that says

proc(n::posint) local X;
    X := Statistics:-RandomVariable(Normal(0,1));
    Statistics:-Sample(X,n);

down to something like

proc(n::posint) local X, p;
    X := [explicit procedure];
    [the code for Statistics:-ExternalSupport:-Initialize ];
    p := [explict routine given by Statistics:-ExternalSupport:-DefineExternal("MapleNormalRandomSample");]
p(n,0,1);
end proc;

Actually, we might even be able to optimize that further, where X and p above would be done as static module exports. Think of it as massive and aggressive inlining if you wish, along with some "smarts" to get it right. [I was tempted to not answer right away, as my Maple Ranking of 1111 was rather amusing, but oh well]

Hi Dave, I am not hinting that you can do much better with dispatching (although your point about ProcessOptions is quite valid). In a dynamically typed language such as Maple, what Statistics currently does is the ``right thing''. What I am saying is that, if users are willing to go to a compilation-like step, then the information available in their particular call to Statistics (amongst other heavy dispatchers) can be used to get rid of most of the dispatching code at ``compile time'', leaving a clean, fast residual routine. This is a kind of Maple-to-Maple optimizer. Mike (Kucera) and I have just recently started experimenting with calls to Statistics via MapleMIX, because of the posts here on mapleprimes. Right now, we are encountering a small bug that prevents proper residualization, but expect to be able to fix it shortly. We will then post all of that online.

Hi Dave, I am not hinting that you can do much better with dispatching (although your point about ProcessOptions is quite valid). In a dynamically typed language such as Maple, what Statistics currently does is the ``right thing''. What I am saying is that, if users are willing to go to a compilation-like step, then the information available in their particular call to Statistics (amongst other heavy dispatchers) can be used to get rid of most of the dispatching code at ``compile time'', leaving a clean, fast residual routine. This is a kind of Maple-to-Maple optimizer. Mike (Kucera) and I have just recently started experimenting with calls to Statistics via MapleMIX, because of the posts here on mapleprimes. Right now, we are encountering a small bug that prevents proper residualization, but expect to be able to fix it shortly. We will then post all of that online.

See the CodeTools[Profiling] package - it has many useful routines for figuring out where both time and memory goes. See also the commands 'exprofile' and 'nprofile'. These routines are really under publicized.

As the (original) author of LREtools, I feel bad that I implemented all sorts of advanced features, and left out something as simple but as useful as that. Only later did I realize that often the simple commands are as valuable to users as the complicated ones.

As the (original) author of LREtools, I feel bad that I implemented all sorts of advanced features, and left out something as simple but as useful as that. Only later did I realize that often the simple commands are as valuable to users as the complicated ones.

There are tons and tons of proof assistants - see for example The seventeen provers of the world (also available online). A word of warning: provers are very hard to use. People are not used to being that formal, and ``usability'' has so far escaped these systems entirely.