@acer 

As I see it, your paragraph to oldstudent:

Your basic problem seems to be either that you feel the x-axis has to be drawn along y=0 and you are not paying attention to the tickmarks drawn by Maple, or that you feel that y=0 ought to be occur at the bottom of the graph. Or some other muddle related to an inflexible notion of how this curve should be "graphed properly".

was extremely aggresive, and there is no other way to understand it as an indoctrination on what is right or wrong. Moreover, as a "welcome message" sent to a first-time user. 

On the contrary, my stand is that when users meet a problem with a design feature, it is the design which should be in question first. And here we have a user with a perfectly valid fresh expectation about the plot view default. And it was plain clear that the OP had recognized that the bottom of the original plot corresponded to y=2 rather than to y=0...

So, what I would have expected instead from you is a more open attitude, recognizing that there is a default issue here and inviting to discuss it.

@acer 

Is oldstudent inflexible about his notion of how this curve should be "graphed properly", or you are by claiming that Maple default view is the "right way"? Defaults are matter of design by some individual, and as such they are debatable issues, always subject to improvement. In particular, for this plot, Wolfram Alpha/Mathematica takes a different default, showing a splitted vertical axis.

@itsme 

I agree. As a specific example, we may take the area of plot labels. Sage's TeX based implementation is far better than Maple's TypeMK one.

@itsme 

During the 90's, because of my activities as ambassador, I have been in contact with diverse communities, some of them are Mathematica fans, some other ones are Maple fans, etc. As I have observed it, the common key feature driving this usage pattern were their academic contacts. For instance, physicists in my department and closely related institutions in this area are Mathematica fans, as you have described. Mathematica arrived here in the early 90's from contacts in some US institutions. And once settled, the barrier for switch is practically unsurmountable. It turns out a cultural issue. But phycisists in some other area of this country, with different academic contacts settled early for Maple instead. Similarly, Maple is top in the neighbouring Mathematics department of the same faculty, while Mathematica is prefered in the Mathematics department of another faculty in the same university. And many Brazilian physicists seems to prefer Maple (Edgardo may tell better) and so on.

@itsme 

Maple's debugger stops into procedures, not into top-level for loops, if this is what mehdi says. So, the loop should be run inside a procedure.

This problem looks more general, and it seems to arise in this conditional statement at the begining of Matrix:

> showstat(Matrix,1..3);
Matrix := proc()
local dim, row_dim, row_dim_set, col_dim, col_dim_set, readonly_opt, initializer, rtable_opt, shape_opt, scan_opt, storage_opt, fill_opt, arg, build_init, row_dim_actual, col_dim_actual, i0, j0, symmetry, array_dims, dims_reqd, _arg, square_reqd, shape_opt_set, i, j, reverse, _BODY, scalardata, NoInitializer, L, ro, dt, symbol_opt, ord, _init, _d, mostly_sparse_initializer, result, extfun, initializer_info, processed_initializer, row, col, row_dim_list, col_dim_list, row_index, col_index;
   1   if nargs = 1 and type(args[1],('identical')('%id') = ('integer')) then
   2     return _rtable[rhs(args[1])]
       elif typematch([args],('list')({L::{('list')(('And')('algebraic',('Not')('indexable'))), ('listlist')(('And')('algebraic',('Not')('indexable')))}, ro::{('identical')('readonly'), ('identical')('readonly') = ('anything')}, dt::(('identical')('datatype') = ('anything')), ord::(('identical')('order') = ('identical')('Fortran_order','C_order')), 'nonnegint'})) then
   3     dim := select(type,[args],'nonnegint');
         ...
       end if;
       ...
end proc

Look at the elif line structured type check for L, basically whether it is a list of objects of type algebraic and not type indexable (see ?type,algebraic and ?type,indexable ). Objects of type integer pass this check but strings do not:

> type("a",algebraic);
                                     false
> type("a",indexable);
                                      true

Hence, for a list of integers, the arguments 5,5 are strightforwardly taken as the dimensions of the Matrix, and things go smoothly. But for the case of strings the computation gets stranded, finally producing the aforementioned error message. Also, some other objects like those of type set fail at this check the same as strings. And we can do the same play with them:

> z := map(convert,x,set);
z := [{1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}, {10}, {11}, {12}, {13}, {14},
    {15}, {16}, {17}, {18}, {19}, {20}, {21}, {22}, {23}, {24}, {25}]
> Matrix(5,5,z);
Error, (in Matrix) initializer defines more columns (25) than column dimension
parameter specifies (5)

Consequently, this bug may likely affect every initializer with objects that do not pass this type check.

@Kitonum 

Re is not so an unfortunate designation as long as a local Re is used. This way is possible since Maple 17:

> local Re:
> subs(W[0]=Re*V[0], V[0]/W[0] * diff(u(t),t));
                                    d
                                    -- u(t)
                                    dt
                                    -------
                                      Re
> Re(2+I);
                                   Re(2 + I)

Certainly, a bug remains as the typeset output is like the global Re.

@Markiyan Hirnyk 

Perhaps a lead is starting from a,b small. Then:

> mtaylor(f,[a=0,b=0],3);
                                   ln(x) a b
                                   ---------
                                     x - 1

Which is convex in a and b (being linear), as well as in x when a*b>0.

I wonder about that math forum and what exactly are those double moral standards.

@acer 

Here, on Linux 32-bit, the last example stops instead with a numeric exception, also at the initial 2nd derivative test, like:

> isconvex(eval(f,[a=1/2,b=3/4]), x, 0, 1);
...
memory used=5700.2MB, alloc=2680.0MB, time=48.44
Error, (in assuming) when calling 'combine/ln'. Received: 'numeric exception:
overflow'

Depending on the run, it may be overflow or underflow.

Now, you wrote earlier that testeq is rather limited. Indeed it is, e.g.:

> testeq(x^(1/2)=x);
                                      FAIL

But it hapens that in your code is is already calling testeq, try:

> trace(testeq):
> isconvex(eval(f,[a=1/2,b=3/4]), x, 0, 1);

And probably it is responsible (at least in part) of the failure of this derivative test (subexpressions with fractional exponents occur because of the choice of a and b).

Finally, "oder...?" in your code comment sounds German!

@ecterrab 

Actually, I was thinking about defining something similar, perhaps in the ini file, to save typing, as I make such plots also frequently. But, what about adding it directly to plots?

@itsme 

Yes, it seems like there are here several bugs to investigate and report...

@mehdi jafari 

What I have written has basically the purpose of showing several somewhat low-level/low-visibility routines, plus highlighting design quirks. Consequently it involves some technical complications, but it is very simple conceptually: for each term (summand) of the equation, compute the order of each derivative and sum them to get the total order.

For this purpose, I have used the command PDEtools:-Library:-DifforderJet from the PDEtools internal library, sketchly documented in ?PDEtools,Library . This command takes as argument the differential equation(s) in jet form. For this purpose, the equation has been rewritten using PDEtools:-ToJet (see its help page for information on the jet form and the jet space).

Quirks involve the precise form of the arguments that each command takes and the form of the output they produce. So, some manipulations are required to match things like changing from set to list, extracting function names and the like.

@mapleq2013 

Actually, the lesson from that discussion is that the core of that kind of memory problems is in the Java sector (by using the Standard GUI), so you may avoid them largely by using e.g. the command line interface (CLI).

@ecterrab 

No, it is not the case that I am asking personally for the explicit form of the function calls. I know these commands and I have read their help pages long time ago (surely you are aware of that). But I deemed that this one would have been a good opportunity for showing how these different solving engines produce results for the specific OP' system and then discussing them. You do not seem to think the same, well...

More precisely, my opinion is that a "universal" command like PDEtools:-Solve is actually misplaced, meaning that it its most sensible location is top level. But then, does it make sense two different top level commands solve and Solve? (it is not just a question of name or capitalization, but what overall system design would be better for the user). My answer is no, and they should better be merged.

Certainly it is a problem, in my opinion, that you see such closely related topics as different. In practice, if those powerful facilities like DEtools[rifsimp] and DifferentialAlgebra are too complicated for the average Maple user, whether they exist in Maple and not in Mathematica probably makes no difference for most users. So, I think that there is a challenge both on the sides of documentation and of interface, for making these facilities even more accesible (by the way, I do not make posts, being in protest mode since the disaster brought to this site in June 2010).

@Glowing 

Some familiarity seems unavoidable when dealing with Maple for over 20 years.... Reading your post reminded me the time when I got to know about this change, though I was not sure about the exact version when it did occured. So, I had to check several update help pages.