tomleslie

6985 Reputation

17 Badges

10 years, 256 days

MaplePrimes Activity


These are questions asked by tomleslie

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

 

 

When the loop variable can be written as a unit step sequence, I never really distinguish between using

seq( f(i), i=m..n ), and

f(i) $ i=m..n

However I recent came across a case where the 'seq' construct ran about 2.5x faster. Is using 'seq' always faster? Does it depend on the function being evaluated? Why is there such a large difference in execution time

The original example which exhibited the problem is shown below, although after some experimentation, I have found other cases where 'seq' is faster (and plenty where it doesn't seem to make any difference!)

Example code for implementation using '$' is

restart:
ulim:=1000000:
t1:=time():
ans:= max
          ( { iquo(3*d, 7)/d $ d = 1..ulim }
             minus
            {3/7}
         ):
t2:= time()-t1;


Example code for for implementation using 'seq' is

restart:
ulim:=1000000:
t1:= time():
ans:= max
        ( { seq
            ( iquo(3*d, 7)/d, d=1..ulim )
          }
          minus
          {3/7}
        ):
t2:= time()-t1;

On my machine, the version using the 'seq' construct runs 2.5x faster

 

1 2 3 4 Page 4 of 4