Items tagged with bug


Hi all,


I think the developers should pay attention to this problem.


This simple expression with Threads:-Map executed perfectly on my machine with 8-threaded CPU and 16 GB RAM:

Threads:-Map(proc (i) options operator, arrow; ln(i)/2. end proc, [`$`(1 .. 10^7)]);


But the similar expression with Grid:-Map never be executed:

Grid:-Map(proc (i) options operator, arrow; ln(i)/2. end proc, [`$`(1 .. 10^7)]);

Maple or freezed, or crashed every time. Although the consuming of memory is not reached even 50%.


The similar problem exist for Grid:-Seq too. With `$`(1 .. 3*10^6) Grid:-Map and Grid:-Seq executed normally. With `$`(1 .. 5*10^6) - 50/50. But not with `$`(1 .. 10^7).


Is this a real bug of Grid:-Map and Grid:-Seq ?

Or is exist a way to fix this problem?





I got a new error behavior of Grid:-Map in this case instead crash or freeze:

Grid:-Launch(numnodes = 8);

st := time[real](); Grid:-Map(proc (i) options operator, arrow; ln(i)/2. end proc, [`$`(1 .. 10^7)]);


print(`output redirected...`); # input placeholder

`System error, `, "bad id"


I hope this helps developers to fix this bug.

Consider the following code, which just generates two "identical" matrices, differing only in their requested storage type, and then does some simple manipulations.

# Define matrix using sparse storage
   testM:= Matrix( 40,40,
# Define identical(?) matrix with rectangular storage
   nm:= Matrix( 40,40,
# Define procedure to return some matrix properties
   matData:= proc( myMat::Matrix)
                            return op(3, myMat)[2], # check storage type
                                      myMat[5, 1..-1], # get 5-th row
                                      add(myMat[5, 1..-1]); # add elements in 5-th row
                    end proc:
# Get properies of the two matrices - should be identical
# but check result of adding elements in the 5-th row

The matData procedure ought to produce the same results for the two matrices, with the exception of the storrage type. But the 'add()' command does not. The 'myMat[5, 1..-1]' command produces the same vector, the 5-th row - but stick an add() wrapper around it and all hell breaks loose.

Is this a bug or am I missing something?

Suggestions such as avoiding sparse data storage are not really acceptable: the above is a much simplified version of my original problem where I was using graph theory to play with a "cost function" and (with G a graph) the command,


returned a sparse-storage matrix - and I didn't notice. There appears to be no option on the WeightMatrix() command to control the storage tyoe of the returned matrix. Result was that all subsequent code based on slicing/dicing/and particularly 'add()ing' sub-blocks of this weight matrix fell apart

Don't get me wrong: I can sort of accept that the weight matrix of minimal spanning tree would (hopefully) be mainly zeros so sparse-storage might be a good default option but I don't see why the results of a command such as

add(myMat[5, 1..-1])

should vary depending on the internal storage used for the matrix, particularly when I have no control over the storage type being adopted


Starting with Maple 18, the Print to PDF feature caused the document page to be hard-aligned at the left margin of the page. Maple 2015 still seems to have this problem / bug.

Does anyone else have the same problem? Has a work-around been posted? Is a fix in the works after nearly 9 months?


Why does Maple 2015 solve this very simple system incorrectly?

solve({abs(a-b)=0, sqrt(2*b+c)=0, c^2-c+1/4=0});



With Maple 12 no problem:

solve({abs(a-b)=0, sqrt(2*b+c)=0, c^2-c+1/4=0});




In my  Standard GUI Maple 2015 (32 bit)  on Windows 8.1  plots[spacecurve]  command does not work:

plots[spacecurve]([cos(t), sin(t), t], t = 0 .. 2*Pi);



Can someone confirm this bug?

This message is for those who prefer use Maple in 1-D Math Input.

In 1-D Math Input, in previous versions of Maple, it was very comfortable to have the freedom to write ONE large statement in Continuing ON SEVERAL LINES for clarity and better reading from a *.wm file.

Here are simple examples, but in reality, I work on very complex cases.


Example #1:

A := u*( x + ln(x +1) + cos(x))

     + v*(1 + sqrt(x))

     + w*(sin(x) + tan(x) + x);


Example #2:


          , cos(s)*sin(t)

          , sin(s)]);


Example #3:


  plot(f(x), x = x1..x2)

, plot(g(x), x = x1..x2)

, plot(h(x), x = x1..x2)



In Maple 2015 with a *.wm file, when you try to execute these example in 1-D Math Input, an error is returned and unfortunately forces you to write everything on the same line, what makes reading tiring.


Is a bug or a voluntary deactivation?

Can you help me, please?



In the following, the diff operator calcuates the derivative correctly, but the D operator doesn't.  A bug?


f := x -> a[1][2]*x;    # the double index on a[][] is intended

proc (x) options operator, arrow; a[1][2]*x end proc


diff(f(x), x);






Here is a worksheet containing the commands above in case you want to try it yourself:

There seems to be a bug in the CodeGeneration package for Python which leads to a deletion of braces in some cases.

# E.g.


# leads to

cg5 = math.pi * a + 2

which is obviously wrong.

I am a research student and I am writing up my thesis. I was reading one of the paper written earlier by authors in 2003.

The authors calculated a symbolic rank of a matrix A, and got 9, using Maple 6.


Then new methods developed in 2012 and proved that the "true" rank should be 8. The later paper that "Most  recent versions of Maple have this simplification built in and are able to return a rank of 8.".


I just noticed that in Maple 18.01, this matrix was still evaluted for a symbolic rank 9, if no simplifcaiton was done before using Rank(), see attached.


I didnt explore a lot, but just as a notice. I am a bit concerned as most of my research was trying to deal with exponentials.


Is that something to be fixed in future versions?



In Maple 16  (obviously, the result must be positive):

VectorCalculus:-int(x+y, [x, y] = Sector(Ellipse((1/4)*x^2+(1/9)*y^2-1), 0, (1/2)*Pi));


Probably, this error occurs only in the latest versions, as in Maple 12 the output is correct. It would be interesting to know the reason for this behavior.


According to kernelopts(version), I am using Maple 16.02, X86 64 LINUX, Nov 18 2012, Build ID 7888210 , having just updated

Maple 16.

I have a Maple worksheet with some graphs of 10^5 data points. When I export the worksheet to a pdf for inclusion in a LaTeX document (with pdfpages package, this recognizes page breaks), the file is around 100 Mb, much larger than I would like.

It seems that the file is large as a figure in the pdf is not just an image, the pdf seems to contain all of the information necessary to plot each data point individually.

Is there some way to encourage Maple 16 to treat figures as bitmaps (or something similarly much smaller than the original figures) upon exporting a worksheet to a pdf? I'll be happy for any suggestions.


1. This question was originally for Maple 16.00. Updating to 16.02a has not solved the problem.

2. I am suspicious that there is some bug in how Maple 16 exports figures made with "plot" to a pdf file.

When I try various methods of compressing the pdf that I've seen on the web, such as with pdftk 1.44, or ghostscript 8.70 or 9.07,  or pdf2ps followed by ps2pdf ,

error messages are returned. For example using pdftk:

pdftk input.pdf output.pdf


"Done. Input errors, so no output created"


To me the following behavior of solve is surprising:

solve(f(0.5)=7,f(0.5)); #Output NULL
solve(f(1/2)=7,f(1/2)); #Output as expected 7

Debugging solve suggested to me that the following might work
and indeed it did (outout the float 7.).
This behavior seems to have started in Maple 10. I checked Maple V,R3 and several other old versions including Maple 9.5. All behaved as I would have expected. MapleV,R3 gave the float 7. in the first case, the other the integer 7.
I take this to be a bug and shall file an SCR.
Any comments?

To motivate some ideas in my research, I've been looking at the expected number of real roots of random polynomials (and their derivatives).  In doing so I have noticed an issue/bug with fsolve and RootFinding[Isolate].  One of the polynomials I came upon was

f(x) = -32829/50000-(9277/50000)*x-(37251/20000)*x^2-(6101/6250)*x^3-(47777/20000)*x^4+(291213/50000)*x^5.

We know that f(x) has at least 1 real root and, in fact, graphing shows that f(x) has exactly 1 real root (~1.018).  However, fsolve(f) and Isolate(f) both return no real roots.  On the other hand, Isolate(f,method=RC) correctly returns the root near 1.018.  I know that fsolve's details page says "It may not return all roots for exceptionally ill-conditioned polynomials", though this system does not seem especially ill-conditioned.  Moreover, Isolate's help page says confidently "All significant digits returned by the program are correct, and unlike purely numerical methods no roots are ever lost, although repeated roots are discarded" which is clearly not the case here.  It also seems interesting that the RealSolving package used by Isolate(f,method=RS) (default method) misses the root while the RegularChains package used by Isolate(f,method=RC) correctly finds the root.

 All-in-all, I am not sure what to make of this.  Is this an issue which has been fixed in more recent incarnations of fsolve or Isolate?  Is this a persistent problem?  Is there a theoretical reason why the root is being missed, particularly for Isolate?

Any help or insight would be greatly appreciated.

with pointplot3d and 14,000 points when I enter symbol=point I get an empty plot.

Only when I set symbolsize=1 (a point) do I get points appearing in the graph.  Bug?

Hi there

There seems to be a bug when evaluating elliptic integrals using assuming. Here's an example:



is our integral for some a. Now evaluate the integral using assuming on X in different ways:


INT2:=simplify(value(INT)) assuming X>0, a>0, a<1;

INT3:=simplify(value(INT)) assuming X<0, a>0, a<1;


These give analytic solutions which are different. Now plot them both and compare to the numeric solution




I'm finding that the red curve which should work for X>0 is wrong, while the green one which is for X<0 is ok for X either sign. [blue is the correct answer - numerically!]


Any ideas?

2 3 4 5 6 7 8 Page 4 of 11