Items tagged with bug bug Tagged Items Feed

Maple does not cope with the following simple example:

with(geom3d):

point(A,0,0,0), point(B,1,0,0), point(C,2,0,0), point(E,2,1,0):

AreCoplanar(A,B,C,E);

           Error, (in geom3d:-plane) the points may not be AreCollinear

 

Should we interpret this behavior as a bug? I think I met with this yet 10-12 years ago, but unfortunately since then nothing has changed.

Hi, 

     I was just curious about the difference between defining tensors as arrays/matricies/TensorArrays vs defining them as algebraic symbols. I found that defining them as an expression lead to the wrong answer, and I was forced to define a tensor (LKh) as an array. I've attached a worksheet demonstrating my problem.

I apologize for the amount of tensors needed to find this problem, but it is the only one I have reproduced the issue. I basically define the metric
Metric = g_
auxillary tensor = h
Killing vector = K
LieDerivative of h, wrt K = LKh (not a tensor array)
LieDerivative of h, wrt K = LKh2 (tensor array)
Then I compare two expressions, rho1 and rho2 computed from LKh and LKh2 and they disagree. 


MapleQuestion.mw

Thanks!

Hi, 

     I'm computing a simple covariant derivative of a tensor field W[a,b] in 3 spacetime dimensions. Unfortuntly, my result in Maple 2015 is disagreeing with those obtained in GRTensorII. I think this could be a bug in D_.

Looking at the first result, W[r t ; t] = mu/r in GRTensor II  but D_[t] W[r t] = -mu/r*(cos(theta)^2 - 2). Some ones are correct (diagonals), and some are off by a factor of 2. Some are completely off though.

ErrorsInD.mw


Thanks,

Hi,

     I was wondering if there is an easy way to define another set of indices in the Physics package. For example, usually greek indices are for all 4 spacetime dimensions. Using Setup(spaceindices = lowercaselatin), we can define 3 of those as space indices. I was hoping there is a more general command, so that I could use only 2 indices as "space indices". For example, X[i] would run over x,y while X[mu] would run over t, z. Is there such a command in the Physics package, or a simple way to implement this personally?

Second thing. I was playing with SumOverRepeatedIndices on an expression that contained both space indices and spacetime indices. Usually this seems to work, but in my attached example it does not. I tried the same thing with just spacetime indices in Maple 18 (newest Physics update) and it gave the same error.


Any help appreciated,

PhysicsBug.mw

When solving a simple assignment problem in Maple 2015.1 the bug occurs:

 

In Maple 2012 there are no problems:

A := Matrix([[1, 7, 1, 3], [1, 6, 4, 6], [17, 1, 5, 1], [1, 6, 10, 4]]):

n:=4:

z:=add(add(A[i,j]*x[i,j], j=1..n), i=1..n):

restr:={seq(add(x[i,j], i=1..n)=1, j=1..n),seq(add(x[i,j], j=1..n)=1, i=1..n)};

sol:=Optimization[LPSolve](z, restr, assume=binary); 

 

 

In Maple 2015, on windows 8.1 64-bit the command
series(2*x*(x-y)/y, y = 0, 3);
gives

which is incorrect. The answer is


You can notice the minus sign in front the the -2x is incorrectly typeset, which makes me wonder if it's a bug in the typsetting program and not series itself.

Please fix asap

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?

 

Thanks.

 

Updated:

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)]);

time[real]()-st;

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

`System error, `, "bad id"
2267.482

 

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.

restart;
#
# Define matrix using sparse storage
#
   testM:= Matrix( 40,40,
                           (i,j)->`if`(j>=i,1,0),fill=0,
                           storage=sparse
                        ):
#
# Define identical(?) matrix with rectangular storage
#
   nm:= Matrix( 40,40,
                        testM,
                        storage=rectangular
                     ):
#
# 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
#
    matData(testM);
    matData(nm);

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,

WeightMatrix(MinimalSpanningTree(G))

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?

--
JJW

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:

Vector([cos(s)*cos(t)

          , cos(s)*sin(t)

          , sin(s)]);

 

Example #3:

display(

  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?

 

Guy.

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

restart;

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);

a[1][2]

 

D(f)(x);

(D(f))(x)

 


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

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

# E.g.

CodeGeneration[Python](Pi*(a+2));

# leads to

cg5 = math.pi * a + 2

which is obviously wrong.

1 2 3 4 5 6 7 Last Page 1 of 9