dharr

Dr. David Harrington

6115 Reputation

21 Badges

19 years, 328 days
University of Victoria
Professor or university staff
Victoria, British Columbia, Canada

Social Networks and Content at Maplesoft.com

I am a professor of chemistry at the University of Victoria, BC, Canada, where my research areas are electrochemistry and surface science. I have been a user of Maple since about 1990.

MaplePrimes Activity


These are replies submitted by dharr

@acer My understanding is that the minimal polynomial is the lowest degree polynomial (with rational coefficients since you didn't specify an extension field) that u1 with index=1 for both RootOfs is a root of. Since that u1 value is not the one corresponding to the desired trig expression, is it only coincidence that in this case the desired root is another root of the minimal polynomial? There is something special in this case that of the 6 roots only three are distinct, so does this work more generally? I suppose it can always be tried and checked...

@dharr I took a closer look at why @acer's solution doesn't lead to the solutions in the form with the square root, which Maple cannot simplify further.

restart;

expected:=(1+cos(arctan(3/4)/3))/3;evalf(%);

1/3+(1/3)*cos((1/3)*arctan(3/4))

.6590276223

alpha[1]:=evalc(convert(RootOf(60*_Z^3 - 60*_Z^2 + 15*_Z - 1,index=1),radical));evalf(%);
alpha[2]:=evalc(convert(RootOf(60*_Z^3 - 60*_Z^2 + 15*_Z - 1,index=2),radical));evalf(%);
alpha[3]:=evalc(convert(RootOf(60*_Z^3 - 60*_Z^2 + 15*_Z - 1,index=3),radical));evalf(%);

-(1/6)*cos((1/3)*arctan(3/4))+1/3-(1/6)*3^(1/2)*sin((1/3)*arctan(3/4))

.1090390090

-(1/6)*cos((1/3)*arctan(3/4))+1/3+(1/6)*3^(1/2)*sin((1/3)*arctan(3/4))

.2319333686

1/3+(1/3)*cos((1/3)*arctan(3/4))

.6590276223

The simplify here is the key to finding the simpler (factored) form of the quadratic). (a here stands in for the RootOf above).

quad[1]:=RootOf(simplify(eval(4*_Z^2 + (4*a - 4)*_Z + 4*a^2 - 4*a + 1,a=alpha[1])));
quad[2]:=RootOf(simplify(eval(4*_Z^2 + (4*a - 4)*_Z + 4*a^2 - 4*a + 1,a=alpha[2])));
quad[3]:=RootOf(simplify(eval(4*_Z^2 + (4*a - 4)*_Z + 4*a^2 - 4*a + 1,a=alpha[3])));

RootOf((cos((1/3)*arctan(3/4))-3*_Z+1)*(3^(1/2)*sin((1/3)*arctan(3/4))-cos((1/3)*arctan(3/4))-6*_Z+2))

RootOf(-(cos((1/3)*arctan(3/4))-3*_Z+1)*(3^(1/2)*sin((1/3)*arctan(3/4))+cos((1/3)*arctan(3/4))+6*_Z-2))

RootOf(36*_Z^2+(12*cos((1/3)*arctan(3/4))-24)*_Z+4*cos((1/3)*arctan(3/4))^2-4*cos((1/3)*arctan(3/4))+1)

The quadratic doesn't obviously factor in the "native" form, so using allvalues before substituting in the alpha's leads to pesky square roots.

factor(4*_Z^2 + (4*a - 4)*_Z + 4*a^2 - 4*a + 1);

4*_Z^2+4*_Z*a+4*a^2-4*_Z-4*a+1

Find all 6 roots

rts[1]:=[allvalues(quad[1])];evalf(%);
rts[2]:=[allvalues(quad[2])];evalf(%);
rts[3]:=[allvalues(quad[3])];evalf(%);

[-(1/6)*cos((1/3)*arctan(3/4))+1/3+(1/6)*3^(1/2)*sin((1/3)*arctan(3/4)), 1/3+(1/3)*cos((1/3)*arctan(3/4))]

[.2319333686, .6590276223]

[-(1/6)*cos((1/3)*arctan(3/4))+1/3-(1/6)*3^(1/2)*sin((1/3)*arctan(3/4)), 1/3+(1/3)*cos((1/3)*arctan(3/4))]

[.1090390090, .6590276223]

[-(1/6)*cos((1/3)*arctan(3/4))+1/3-(1/6)*(-3*cos((1/3)*arctan(3/4))^2+3)^(1/2), -(1/6)*cos((1/3)*arctan(3/4))+1/3+(1/6)*(-3*cos((1/3)*arctan(3/4))^2+3)^(1/2)]

[.1090390091, .2319333685]

rts[1][2];
rts[2][2];

1/3+(1/3)*cos((1/3)*arctan(3/4))

1/3+(1/3)*cos((1/3)*arctan(3/4))

 

Download RootOfX.mw

@nm Nice use of remove_RootOf; I didn't know about that. When I evalf([%]) your result I get 

[[0.6114019859 = 0., 0.2874388753 = 0., 0.1011591386 = 0.]],

but none of these correspond to the expected result, so I'm confused about that.

@fnavarro If I just evaluate the expression at Digits=40 I don't see a problem, there are no strange values in pts:

restart;
Digits:=40;
pts:=[seq([x,x*exp(-x)],x=0..20,0.2)]:
plots:-pointplot(pts,connect);

I agree if you look at the points in the plot structure for the regular plot without adaptive = true, they look strange, but as  @Preben Alsholm points out this is a function of the adaptive routine. Perhaps you have an specific example not involving plot.

@Art Kalb There are lots of non-commutative operators - "." and the ones starting with "&". I was thinking that since "." knew about inverses, b.b^(-1) =1, that it might be useful, but expand doesn't work (&* is special in this respect, since expand has some special code for &*). In the end I think you have to specify a group to make progress. If you are OK with specifying group elements as permutations, then that is the simplest way, since you can use most groups in the GroupTheory package, as in the following. (It would be nice if Elements(G) always had the identity first so I fiddled with it to force it.) If you want nicer symbols for the group elements you have to work a bit harder, as DrawCayleyTable does.

group-ring_2.mw

@Nicole Sharp If the Maple code is going to run on your local machine, then it needs to be downloaded, regardless of which file format is used. Import imports the whole contents of the file, and MapleCloud also uploads and downloads files. (Your Mapleprimes account should work on MapleCloud,  easiest to sign on from within Maple.) The files could be single functions, if you want to dowload just one of many functions. But I don't see how you can avoid re-downloading after an update.

The alternative would be to run the Maple code on a server, say one you have an account on. Then you are accessing always the current version of that file. Maplesoft also has a separate product Maplenet that allows users to run Maple code on a server through a web browser.

@Nicole Sharp The end user need not know about the local file, in the sense that the file can be downloaded and immediately read every time. (The intermediate file stage could be avoided if the read statement had a source=direct option like import does, which means treat the string as file contents.)

You can take the string, use StringTools:-Split to split it at each endline "\n" character and them parse each line. Parse only does one expression or statement, and then you have to handle the statements differently from the expressions. In the end writing an intermediate file seemed to me the easier option.

(The Import statement is handling the .mpl file in just the same way as if it is reading a local file. It defaults to output=string.)

@WA573 Use

interface(showassumed=0):

to remove the ~

@C_R Yes, equatorial poles are harder with spherical coordinates. If you use phi>Pi/2 and have four regions of theta then you can have each octant colored separately; the equatorial and north/south poles are then at the points where the colors intersect. You could add something like

pointplot3d([[0,0,1],[0,0,-1],[0,1,0],[0,-1,0],[1,0,0],[-1,0,0]],
  symbol=solidsphere,symbolsize=10,color=black):

though there are little bumps then.

An equatorial band is possible with a small phi range and north-south bands with a small theta range, though the north-south ones narrow at the poles.

@Anthrazit  Thanks for the complete information. To make a nested table, you need

WhateverYouNeed["calculations"] := eval(calculations);

Edit: my earlier explanation is too simplistic. In one step:

WhateverYouNeed:=table(["calculations"=
                   table(["structure"=
                     table(["connection"=
                       table(["Cutright1" = "false", "graindirection1" = 90*Unit(arcdeg)
                       ])
                     ])
                   ])
                 ]);

TableDefinition.mw

@WA573 You needed nested seq, and I changed subs to eval, but the calculated values are complex and so you get an empty plot.

plot_dis.mw

@Zeineb I don't see any Maple errors, just a warning that i was not declared in A, which I fixed. You haven't written the integral as an integral with respect to psi, not t - just cancel "dt: in (dpsi/ dt)*dt = dpsi as I did above. I'm not sure what you are trying to do but you still have A's as a function of y's and y's as a function of A, which is confusing.

last.mw

@nm I agree. Indeed, odeadvisor has the option of testing other types, which you would not need if if was intending to return all types.

DEtools:-odeadvisor(ode,y(x),[homogeneous]);

gives

@WA573 In (6)-(8) I only see bars over expressions that contain eta, and are therefore potentially non-real; I don't see any bars directly over n or m alone.

@Zeineb Changing int to Int in Frac_D shows why the integrals are being evaluated as zero. Notice that A[0](x) works as expected but A[0](t) does not. This can be fixed by local t (in red), though this may be a side issue. But the code is confusing because the y[i] are used in the definition of A[n] but are defined later, and I lost track of locals and globals. I suggest you create the A[n] and y[i] one by one  in the right order, and only when it works put it into one loop.

compute_integral.mw

First 10 11 12 13 14 15 16 Last Page 12 of 63