@Kitonum 

Yes, though this is an independent bug. Really, weaknesses and bugs of is would be the subject for another thread. For a simpler example:

is(х>0) assuming x>0;
                                     false

For additional information see this thread.

Actually, method FTOC (or FTOCMS), which handles something like 70% of the definite integrals, is nothing but computing the primitive/antiderivative plus taking the lateral limits and checking for discontinuities in this function. All these steps could be done individually by hand, but it is clearly convenient that they were performed automatically. However, little in the core routines dealing for these steps has been improved significantly in recent versions. And the discontinuity checker is probably the weaker link in this chain. So, improvements as you suggest are certainly needed.

Actually, method FTOC (or FTOCMS), which handles something like 70% of the definite integrals, is nothing but computing the primitive/antiderivative plus taking the lateral limits and checking for discontinuities in this function. All these steps could be done individually by hand, but it is clearly convenient that they were performed automatically. However, little in the core routines dealing for these steps has been improved significantly in recent versions. And the discontinuity checker is probably the weaker link in this chain. So, improvements as you suggest are certainly needed.

Yes, this is a bug in the Maple 12 2-D parser. It was solved in later versions. So, in Maple 12 Standard GUI use 1-D input.

Yes, this is a bug in the Maple 12 2-D parser. It was solved in later versions. So, in Maple 12 Standard GUI use 1-D input.

@Markiyan Hirnyk 

If you mean the beginning of the academic year in the northern hemisphere, after the summer there, my guess is that this option was analyzed and discarded: the time of the peak of work for the new release would coincide with summer vacations at Maplesoft... 

@johan162 

Not only Maplesoft is a quite small company, in relation to the complexity and size of Maple, but also a significant part of its development is carried out in a decentralized mode, typically at research groups by temporary agreements. So, besides marketing priorities, because of the developers own agenda, it is quite likely that dot releases bring more new features "for free" than bug fixes. The case of Maple 15.01 is a good example. Moreover, as a significant part of the development goes undocumented (for the user), it is usual that new features were introduced but you may not realize of them until much later. 

On the other hand, bugs and weaknesses may be well known to stay there, not only at the time of the 00 release but for many years, and nevertheless remain unfixed. So, their queue is very, very long. And maintainance, in general, is a problematic issue. So much that five years later of this linked thread, in Maple 16, you will still find packages not yet made into modules... 

I hope that Will will never become the editor of a dictionary! It would result in something like this.

These assumptions of names with property Matrix are unecessary in that they are not being checked in the transformation rule. Such check would be actually useful as one would not want transformation rules specific for matrices being applied to other type of objects included in type algebraic. So, a type specific to symbolic matrices is needed in the context of abstract linear algebra.

Now, it happens that Matrix is a property because Matrix is a type. But type Matrix checks for rtable based matrices ( ?type,Matrix ). So that:

> type(A,Matrix);
                                     false
> is(A,Matrix);
                                      true

and, on the other hand, this property/type for matrices should hold for the result of operations of matrix algebra, so that they become a faithful represention, and in particular could be used in further computations. But nothing like that holds for Matrix:

> applyrule(r, expr);
                            (A~ + (B~ &* K~)) &* z~
> is(%,Matrix);
                                      FAIL
> type(%%,Matrix);
                                     false

This means, in my opinion, that a type specific for symbolic matrices is needed. Perhaps a pair: one for base matrices, declared as such (using an attribute, say), and another one, built upon in recursive way, for the result of matrix operations on them.

These assumptions of names with property Matrix are unecessary in that they are not being checked in the transformation rule. Such check would be actually useful as one would not want transformation rules specific for matrices being applied to other type of objects included in type algebraic. So, a type specific to symbolic matrices is needed in the context of abstract linear algebra.

Now, it happens that Matrix is a property because Matrix is a type. But type Matrix checks for rtable based matrices ( ?type,Matrix ). So that:

> type(A,Matrix);
                                     false
> is(A,Matrix);
                                      true

and, on the other hand, this property/type for matrices should hold for the result of operations of matrix algebra, so that they become a faithful represention, and in particular could be used in further computations. But nothing like that holds for Matrix:

> applyrule(r, expr);
                            (A~ + (B~ &* K~)) &* z~
> is(%,Matrix);
                                      FAIL
> type(%%,Matrix);
                                     false

This means, in my opinion, that a type specific for symbolic matrices is needed. Perhaps a pair: one for base matrices, declared as such (using an attribute, say), and another one, built upon in recursive way, for the result of matrix operations on them.

I guess that you mean staff and not stuff.

I guess that you mean staff and not stuff.

I do not know which is such "subtle bug" for you. For me, this is a bug arising in the usage of has in line 3:

>  selectfun(Int(x,x=0..1),Int,x);
                                      1
                                     /
                                    |
                                  { |   x dx}
                                    |
                                   /
                                     0

as the definite integral is no function of the dummy variable x.

This code also shows me the interesting undocumented feature of using a list or set of function names as second argument of the structured type specfunc. ?type,structured just states a single function name: "specfunc(type,foo)  the function foo with type arguments". So, this is a documentation bug, in my opinion.

I do not know which is such "subtle bug" for you. For me, this is a bug arising in the usage of has in line 3:

>  selectfun(Int(x,x=0..1),Int,x);
                                      1
                                     /
                                    |
                                  { |   x dx}
                                    |
                                   /
                                     0

as the definite integral is no function of the dummy variable x.

This code also shows me the interesting undocumented feature of using a list or set of function names as second argument of the structured type specfunc. ?type,structured just states a single function name: "specfunc(type,foo)  the function foo with type arguments". So, this is a documentation bug, in my opinion.

The list of alternative names for the diverse arrow types is hardcoded in the line 116 of `DEtools/DEplot`:

> showstat(`DEtools/DEplot`,116);
`DEtools/DEplot` := proc(inDES, invars, trange)
local DES, nDES, vars, dvar, ivar, highorder, totalorder, dvrange, linepts, initial, ninits, iter, lims, toplot, f, IC, w, eivar, fldcolor, arrowpts, test1, test2, stopp, dirfld, label_ftr, line_color, arrlen, userarrs, hasindep, lv, color_l, multi, t_s, data, alldata, maxv, arrs, defnpoints, npoints, nsteps, h, arrw, grid, m, n, o, numarrow, nullcl, nullclcolor, nullclgrid, nullclfill, nullclthick, anicurve, anifield, aniboth, nframes, allarrs, plot3dftr, plot2dftr, numftr, plot_ftr, dsol_ftr, meth_ftr, thick, plot3, bd, per, t1, t2, t3, t4, np, i, j, k, l, r, opt;
global _plotDigits;
       ...
 116           allarrs := [['curve', ['CURVE', 'tads', 'TADS'], 'CURVE'], 
['comet', ['fish', 'Fish', 'FISH', 'Comet'], 'FISH'], 
['line', ['LINE'], 'LINE'], ['small', ['SMALL', 'thin', 'THIN'], 'SMALL'], 
['medium', ['MEDIUM', 'slim', 'SLIM'], 'MEDIUM'], 
['large', ['LARGE', 'thick', 'THICK'], 'LARGE'], 
['none', ['NONE'], 'NONE'], ['mediumfill', [], 'mediumfill'], 
['smalltwo', [], 'smalltwo'], NULL]
       ...
end proc

As you see, this is a list of lists, one for each arrow type, whose first element is the "main" name (e.g. curve), and then alternative names including capitalization variations (CURVE, tads, TADS).