12497 Reputation

19 Badges

12 years, 231 days

MaplePrimes Activity

These are answers submitted by tomleslie

Since your polynomials are univariate, I suggest you examine the PolynomialTools[CoefficientList] command. Use of this command ensures that polynomial coefficients appear in defined order (with an option to reverse).

My solution for your problem is shown in the attached


No real problem with the above but

for k to 9999 do
     if add
        ( irem(q, 10, 'q')^3,
           k = 1..length(q)
        >= k
     then n:=k

runs about 15x faster

# generate some data
  N2:=NormalRandomVariable[Normal](0.5, 0.5):
# Produce two histograms
  P1:=Histogram(A, style=polygon, color="Red"):
  P2:=Histogram(B, style=polygon, color="blue"):
# display them

VectorCalculus[CrossProduct](a,b), requires that a, b be 3-D vectors, yours are 2-D. Easiest thing to do is just add a third entry and set it equal to zero as in

r:=(u,v)->Vector[column]([u*cos(v), u*sin(v),0]);

Fairly easy to filter the array with


data:=[seq(`if`(Z[n]<>val,[n,Z[n]],NULL), n=1..5)];
t1:=plot(data, style=point, symbol = solidcircle, color= red):

Whatever is assigned to val (NULL, a numeric, it doesn't matter) will be omitted from the data plotted

In the code loop

for i from 1 to 2*r+1 do

H[i] is a scalar but Tr(X) and Tr(X0) are vectors so the matrix multiplication operation '.' is invalid. Use '*' instead.


Tr(X)*H[i] is a 1*3 vector
Tr(X0)*H[i] is a 1*3 vector, but
-3*(Tr(X).Dtau1.CC[i].Tr(Dtau2).U)) is a scalar -and so cannot be combined with the preceding vectors. If you mean this term to be add to each element of the preceding vectors then use


Couldn't check the subsequent code becuase the next execution group contains


Both N and M are undefined, so the seq won't execute - based on the generation of CCC in the preceding loop, 2*r+1 looks like a good bet for the last argument to seq, but I decided that this was piling up too much guesswork about what you wished to achieve


I find that if I use

dataplot(L0[()..(), 1], L0[()..(), 2], axes = box, size = [600, 320] ,symbol=point);

in Maple2015, then this gives the same result (at least "visually") as

plot(L0[()..(), 1], L0[()..(), 2], axes = box, size = [600, 320]);

in Maple 18 (apart from the fact that they use different colors by default - trivial to fix).

The dataplot command is new in Maple2015 but AFAIK, it is meant to be a "simpler" interface to the same underlying commands. All of which means that the behaviour of the underlying plot command (ie the ones you used) has been changed - I don't know why, so I think you have a legitimate gripe and if you don't get a better answer here than this one, then I suggest you send it to the Maple techies as a bug.

A few (probably irrelevant) comments

  1. Your data file contain roughly 10 identical x-values with different y-values: I say roughly 10 because it seems to vary from about 6 to about 11. when first examining your data I thought this might be an issue and upsetting the plot, but it doesn't *seem* to be. I tried plotting the second column of you matrix against row number: Maple 18 and Maple2015 still gave substantially different results, so I don't think this is an issue
  2. interesting way to select columns of a matrix the L0[()..(),1]. Normally I'd just use L0[..,1]

Couldn't really follow what you code was trying to do. An implemenatation of the logical process you went through in the statement of your question would be

# Initialise 4 bags with nothing in any of them
# and an index for the "current bag
   bags:=table([b1=0, b2=0, b3=0, b4=0]):
# loop round all sums which have to be achieved
   for j from 1 to 15 do
     # check whether j cannot be obtained as a sum
     # of existing bags
     if member( j,
                      ( add,
                        combinat[choose] ( [entries( bags, 'nolist' ) ] )
         # j must go in the next available bag
            bi:= bi+1:
            bags[ b||bi ]:= j:
# display result

Output from taylor is of datatype series. Generally you need to convert to polnomial form to do further manipulations. Try


int(X^2 + 3*y + 3*z + X^7,X=0..1);

Depends on whether you are allowed to select the same sideLength more than once - or do you specifically wish to exclude all isosceles and equilateral triangles??? Not obvious from your question, although if you are just constructing valid triangles - then why exclude equilaterals and isosceles???

Code provided by Kitonum deliberately excludes isosceles and equilaterals - but do you want to do this????

A minor revision to Kitonum's first code example will allow isosceles and equilaterals to be included

L:=[seq( seq( j,k=1..3), j=1..8)];
P:=combinat[choose](L, 3):
for p in P do
    a:=p[1]; b:=p[2]; c:=p[3];
    if a+b>c and a+c>b and b+c>a
    then k:=k+1:

In which case you will get 70 valid triangles (rather than 22) - makes a big difference

The difference actually gets smaller as the number of side lengths goes up. A simple revision to Kitonum's second code example to allow isosceles and equilateral triangles, with a judicious choice of limits for the innermost loop to apeed things up a bit would be

#ne:=8: #a check value
ne:= 500:
for a from 1 to ne do
    for b from a to ne do
        for c from b to min(a+b-1, ne) do
            if   a+c>b and b+c>a
            then k:=k+1;

results in 10510625 triangles, rather than 10323125, and run in about 6secs on my machine

I accept that the OP was not interested in a built-in command because (s)he wanted to produce a solution as an exercise. However I think it is reasonable to compare the OP's code with the Maple's built-in version, just for verification purposes

Looking at the codes supplied by OP and Kitonum (the two are equivalent), I was struck by thought that they might do interesting things depending on whether the number of points requested was 0 mod 3, 1 mod 3, or 2 mod 3.

The accuracy of the original version of what is now known as "Simpson's 3/8" rule, is completely independent of the number of points (although the name "3/8 rule" probably only makes real sense, when the number of points is a multiple of 3). The Maple help page ?Student[Calculus1][Simpson's 3/8 Rule] is actually quite informative in this respect

Consider the attached worksheet which will allow you to compare/contrast the result of OP's code, Kitonum's code, and the Maple's built-in version of "Simpson's 3/8" rule in two scenarios - where the number of points is small, and where the number of points is large

Notice how accurate the Maple built-in function is for small numbers of points, irrespective of whether the number of points is 0 mod 3, 1 mod 3, or 2 mod 3. OPcode (and Kitonum - because they produce identical results) are pretty close when the numbers of points is a multiple of 3 and pretty awful otherwise

Even with a large number of points, it is still noticeable that OPcode/Kitonum agrees much better with the Maple built-in command when the number of points is a multiple of 3.

Actually I expected complete agreement when the number of points is a multiple of 3, but I haven't got the time/energy to figure out why there is a discrepancy in this specific case - let's just say I'm backing the Maple version!

Why do I care??
Well I live quite close to where Thomas Simpson was born and is buried (and have visited the latter). A small plaque in a very old church isn't much reward for torturing generations of students, but hell, it's more than most of us will get, and he deserves some respect (even although many, much earlier, mathematicians had probably produced the same rules)

Don't understand why you care, but

seq(x, j=1..10); #10 for example can be a variable

For the 2*3 matrix which you have specified, the options fortran_order and C-order just determine the "internal" storage format: fortran_order would be

M[1,1], M[2,1], M[1,2], M[2,2], M[1,3], M[2,3], so if I view this strictly as a list with no reference to actual matrix indices the non-zero entries would be 4,5,6 which would map to e, b, f

On the other hand C_order would be

M[1,1], M[1,2], M[1,3], M[2,1], M[2,2], M[2,3], so again viewed as a list, with no reference to actual matrix indices, the non-zero entries would be 3,5,6, whihch ought to map to b, e, f. My interpretation of what is happening is that

  1. the first non-zero entry in this list is the third, ie 'b' which *ought* to be reported as M[1,3], but it seems as if it is being reported as the third entry in an fortran-order list, so is reported as M[1,2]
  2. the second non-zero-entry in this list is the fifth, ie 'e' which *ought* to be reported as M[2,2], but it seems as if it is being reported as the fifth entry in a fortran_order list, so is reported as M[1,3]
  3. the third nonzero entry in this list is the sixth which is M[2,3] in either storage format so comes out correctly

However it seems as if SearchArray() "assumes" fortran_order for the underlying list, even when C_order has been specified, which I would consider a bug

If I understand you problem correctly, then something like

M:=Array(1..9,1..4, (i,j)->[i, j, i+j, i-j]);
V:=Array(1..9, (i)->[i, 2*i, 2*i-1, 2*i+1]);
R:=Array(1..9,1..4, (i,j)->M[i,j]*~V[i]);

ought to work.

Note that I generated 4-element lists in the entries of the starting "matrix" and "vector" more or less as random values, because the way you presented it, there was no sensible way to access your values

First 185 186 187 188 189 190 191 Page 187 of 191