I would rather agree with pagan. Just to get a magnitude of the number of the routines involved in the computation of the example provided by Preben, execute it with the line infolevel[all]:=5 before it. You will see in the output a very large number of lines of the form procedure name: message (this output in Maple 16.01 CLI is 1MB long). Typically, the procedures issuing these messages are kind of representative for a set of procedures. So, for each procedure name appearing in this output, there may be a large number of procedures behind. And this is just a simple example. And different sections of code may be involved in different executions of a given procedure. And diverse externally called routines may be involved (actually some of them appear in that output). 

Perhaps, such a patching could make sense in an open source CAS. Yet, fully documented source and an set of unit tests would be very important, even in that case.

Could you give a simple example of this issue?

@Christopher2222 

What do you mean? Same worksheet with different kernels? If both sessions differ and the worksheet for one is saved, would the second one overwrite when saved? I do not find clear your intended usage.

Generically, I agree with Erik's described behavior: any user provided information (range or view input) should be used unmodified in the computation of the plot view data, while the heuristic algorithm should try to make the best possible guesses it can for the rest of the data. I think that such behavior would satisfy the generality of users and usage situations.

And certainly, an undocumented routine producing unpredictable overriding of user provided information is probably confusing for any user alike. In the following examples of unpredictable behavior a second function added to the plot of exp(x) makes the horizontal view becomming back the provided variable range, who knows why. I do not see any common pattern that could explain such behavior:

plot([exp(x),x],x=-3..3);

plot([exp(x),exp(x^2)],x=-3..3);

Certainly, the last plot view is quite poor. This heuristic algorithm needs an improvement. I would expect a result as produced by this explicit view input:

plot([exp(x),exp(x^2)],x=-3..3,0..10);

Also, I find great that Maplesoft developers take part in these discussions on issues of implemented features. Yet, I would find it even greater, and more efficient, that such discussions would take place earlier, at a planning stage, so that introduced features reflect more closely what the users want. 

Dave, you are comparing apples to pears. In normal plotting usage the variable domain is the user input to the plot routine. This means what the user knows and wants it to be used as view. No heuristic routine should interfere in the user wish, nor the user should be forced to add options so that the desired view is produced. On the other hand, the plot range is the output for the user, i.e. the unknown. This is, normally, the reason to make the plot. So, the argument that justifies computing a vertical view that produces a reasonable and informative plot does not apply to the horizontal view.

The problem is that this breakage of the link between the plot variable domain and the horizontal view makes the default initially presented view less informative and useful. As simple as that.

It took several years for Maplesoft to realize that it was a very bad idea to export 3D plots to PostScript files containing embeded bitmap images. How many years will it take this time for you to realize that this change is bad?

Patrick, it is useless. These severe problems of Primes 2, and many other ones, have been pointed out a lot of times along these last two years with no result. About the administrators of this site, the only thing that I can say is "no hay peor sordo que el que no quiere oir". And if history of the transition from Primes 1 to Primes 2 is a guide, the next version of this forum will be even worst.

Can you open your eps file with Ghostscript?

At this point, I would suggest rereading the interview to Gaston Gonnet for the comments on the Maple vs Mathematica issue that occur along several pages (mixed with other issues) starting from p.49. First, I quote a comparison about the influence of the differences in design into the efficiency of maintainance and develpment:

I don't know what exactly the situation is right now in the internals of Mathematica, but for a long time most of the Mathematica libraries were written in C. Consequently they had a code base that was extremely difficult to maintain. People were telling me that because of lack of modularity, everybody who wanted to do something in Mathematica had to basically start from scratch. If you wanted to do integration, if you had to do something with polynomials, well you had to do it yourself because you could never trust the rest of the system because it was changing, because it was not reliable. You didn’t want to inherit someone else’s bugs. Fortunately, that was not the case in Maple. If that was happening, it was happening to a much lesser extent. We had a better code base. We had a better language. We had a more efficient system.

And then, the awakening on the Maple side:

We were just too complacent with our position. We were thinking users will appreciate our efficiency and our correctness. They are not going to go to Mathematica, and we were wrong. It was a shock to discover that we were wrong on that one, that users would prefer better input and output, even at the sacrifice of correctness. That was a rude awakening for us.

This interview occured in March 2005, and curiously an episode is described that occured three or four years before that. Roughly the same time when Mathematica growth stagnated:

Talking about open source, about three or four years ago, I mentioned this to Maple management. We had a sort of high-level discussion, and I was asked, “What would you do with Maple?” We were losing the battle with Mathematica. What should we do? I said, “Open source is your answer. Open source the programs, (the kernel, and the library) and sell the manuals, sell the consulting, sell the know-how for people that want to sell anything that is built on top on Maple. But get the open source energy…”

So, you find likely that Wolfram, such a succesful businessman, realized of making a comparison of Mathematica's size with its main competitor only at some day after year 2000? 

That awakening conjecture does not explain why the growth til then was slowing down, instead of keeping relatively linear as Maple.

On the contrary, using a large kernel is an important limitation for speedy development, as debugging compiled code is harder than debugging interpreted code. If you have followed Mathematica technical sales pitch along the years, you should have noted that a constant theme is the huge size and complexity of that system and the large number of lines of C code in the kernel, currently in the millons. No doubt, they keep praizing this issue because making it work is really a feat.

You may see also at this plot where they present time vs size of the system. Pay attention to the stagnation period at version 4. Do you believe that the reason for this "break" was increasing user satisfaction even further?

I am afraid that this discussion has gone completely off topic and acer may get angry :) So, it might be better branching it.

@Axel Vogt 

I would suggest reading ?ProgrammingGuide,Chapter06#ParameterDeclarations and ?parameter_classes .

@Axel Vogt 

I would suggest reading ?ProgrammingGuide,Chapter06#ParameterDeclarations and ?parameter_classes .

Why does Mathematica follow a 2+ year cycle for mayor releases? Is it user satisfaction, or a technical limitation? Note that Mathematica architecture is based on a large compiled kernel, and most likely Mathematica code is first prototyped in Mathematica programming language before being translated into C. This whole process may take much longer than an equivalent update in Maple, whose kernel is small, and a large part of the new code goes directly to the library in Maple programming language.

Also, Stephen Wolfram is clearly a successful business man, and from the money perspective, his company did better than Maplesoft. So, if version change = revenue, do you think that he would not release yearly if he could?

With value(%) it yields k.

The curious thing is that e.g IntegrationTools:-Combine is built upon (calls) `combine/range`:

> trace(`combine/range`):
> IntegrationTools:-Combine(Int(f(x), x = a..b)+Int(f(y), y = b..c));
{--> enter combine/range, args = Int(f(X),X = a .. b), [{Int, int}, {}]
[...]
<-- exit combine/range (now in combine/int) = Int(f(X),X = a .. c)}
                                     c
                                    /
                                   |
                                   |   f(x) dx
                                   |
                                  /
                                    a

But there is no equivalent interface for sums.