The font size in the output pane of the standard interface, interactive debugger is really, really small and I can't figure out how to increase it. (Other than drop my screen resolution from its native 2560x1440, which makes it bigger but "fuzzier" - not a huge improvement for tired eyes!!)

Consider the equation

eqn1:=5^(2*abs(y-1)+2) = (1/15625)*625^abs(y-1);

and note that

eval( eqn1, y=-3);
eval( eqn1, y=5);

both return valid solutions. So why does

testeq(eqn1);

throw a numeric exception.

Given the manual description of testeq(), I would expect it to return either true or FAIL - but not a numeric exceprion!!!!

Any ideas?

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

Tried posting responses to a question this evening. Click the question title, hit the "reply" button and enter a phrase like "Clarification" in the Title filed of the reply form, the reply form just disappears. Tried this in Firefox and Chrome - same behaviour. Means I can no longer contribute - has somebody broken something??? Or I have a problem with *all* my browsers

PS not even sure that this post will appear correctly

The Maple help definition for spherical coordinates uses the triple (r, φ, θ) (Note the ordering!!) with φ in the range 0..Π and θ in the range 0..2Π. This means that the second entry in the triple is the zenith angle (latitude) and the third entry in th triple is the azimuth angle (longitude). This is confirmed by the relation to cartesian coordinates stated on the definition page as
x= r sin(φ) cos(θ)

y= r sin(φ) sin(θ)

z= r cos(φ)

However the help page for coords has spherical polars defined by the triple (u, v, w), with the relation to cartesian coordinates given as

x= u cos(v) sin(w)

y= u sin(v) sin(w)

z= u cos(w)

which suggests that this time it is the third entry in the triple (ie w) which is the zenith angle (latitude), with the second entry being the azimuth (longitude).

My simple-minded attempt to check which of these interpretations is correct is shown in the attached worksheet. This seems to confirm that the MapleHelp definitions page is correct and the help/coords page is incorrect - or am I missing something??

Download posVecChk.mw