## 4741 Reputation

9 years, 154 days

## Suggestion...

In the code loop

for i from 1 to 2*r+1 do
CCC[i]:=simplify(Tr(X).H[i]-Tr(X0).H[i]-3*(Tr(X).Dtau1.CC[i].Tr(Dtau2).U));
od;

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

Furthermore

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

CCC[i]:=simplify(Tr(X)*H[i]-Tr(X0)*H[i]-~3*(Tr(X).Dtau1.CC[i].Tr(Dtau2).U));

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

J:=3*(Tr(X).X+Tr(U).U);
MM:=Minimize(J,{seq(CCC[i]=0,i=1..N*M)});
MINIMUM_IS:=op(1,MM);

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.

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

restart;
#
# 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]):
bi:=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,
map
combinat[choose] ( [entries( bags, 'nolist' ) ] )
)
)=false
then
#
# j must go in the next available bag
#
bi:= bi+1:
bags[ b||bi ]:= j:
fi;
od;
#
# display result
#
op(bags);

## Suggestion...

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

restart;
uimj:=taylor(u(x-h,y),h,4);
uipj:=taylor(u(x+h,y),h,4);
convert(uimj,polynom)+convert(uipj,polynom);

## easy...

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):
k:=0:
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:
fi;
od:
k;

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

restart;
ts:=time():
k:=0:
#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;
fi;
od:
od:
od:
k;
time()-ts;

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

## Boring pedantry...

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

simpson38.mw

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)

## One way to do it...

Don't understand why you care, but

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

## Legitimate gripe (I think)...

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

## Something like...

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

## A couple of points...

1. You should modify the last boundary condition to D[1,1](f)(5)=0

2. The above will work, but the since you have not indexed the solutions for k, then each solution will overwrite the previous solution, so I suggest you use

R:=Array(1..numelems(L)):
for k  from 1 to numelems(L) do
R[k]:=dsolve(eval({Eq1,Eq2,Eq3,bcs1},K=L[k]),[f(eta),theta(eta),phi(eta)],numeric,output=listprocedure);
end do:

Assuming that yuo have the data in an excel spreadsheet (which your question implies) then you can try something like the following

excelImp.mw

which I tested with

testData.xlsx

Obviously you will have to do a bit of "dirPath" and "file" renaming, but something close to the above .mw file should achieve what you want (at least it will, starting from Excel)

## With great difficulty!!!...

Despite what Mathtype claims, it is rather better at exporting equations than importing them.

The best I have come up with so far is to use the MathML[Export] facility in Maple, followed by absolutely standard CTRL-C/CTRL-V to drop the result into a Mathtype window. This works on the limited number of examples I have tried but does produce some error markers in Mathrype which have to be removed manually.

The only reason I can think of for this behaviour is that MathML[Export] in Maple produces "tags" which Mathtype doesn't understand - I can't see any easily see any way round this.

Unusual to want to get to MathType as a "final" destination. If you actually want to get to Word" or a webpage, then the MathML[Export] routine might work better by going directly to the end application, rather than using MathType as an intermediary

If I make a few edits to your worksheet, hopefully without changing your intent, then I can persuade everything to execute properly. However I was not too surprised to find that all the numeric solutions failed at 13/3, because of the "singularity" at this point.

You may be able work around this problem by using the 'events' option. I can't try this today - other commitments

diffsing.mw

## A little help - maybe...

When it comes to translating programs between (for example) Maple, Mathematica, Matlab, my defualt position is that yoiu might get about 95% of the code correct, which means none of these translations will work without some human input

Your first problem seems to be that Maple cannot even find the Mathematica file. Two ways to fix this: either use

currentdir(pathToTheDirectoryWhich containsThe.nbFile):
with(MmaTranslator);
FromMmaNotebook( "plot.nb" );

or

with(MmaTranslator);
FromMmaNotebook( "FullPathName/plot.nb" );

When I do this Maple produces no errors or warnings and creates a plot.mw file in the same directory as the plot.nb file. However, if I load this file into Maple it doesn't execute :-( So still more work to do

However just being able to read it in Maple syntax, I can guess what was intended in the original Mathematica file. First issue I see is that this is a system of partial differential equations, but is using dsolve rather than pdsolve for a solution. Changing dsolve to pdsolve still results in an error, which (strangely??) is removed if I delete the numeric option, in which case Maple gives me the analytic solution

At which point with a little massaging, I can get the plot commands to work as well

Frankly for such a simple problem I wouldn't bother trying to convert a Mathematica worksheet and hope that it would work out OK - I'd just enter the original problem in Maple!!!

 First 102 103 104 105 106 107 108 Page 104 of 108
﻿