acer

32348 Reputation

29 Badges

19 years, 330 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@Rouben Rostamian  The two reasons why you cannot assign to the entries outside the stated bands of your Matrix B is that it is prevented by its indexing function (ie, the band[0,1] shape) and the absence of the corresponding off-band storage. The indexing function is the primary reason, as the attempted off-band assignment hits that restriction first.

The BandMatrix command can still be used to create a Matrix with the specified entries, and to which off-band entries can be assigned. Eg,
  LinearAlgebra:-BandMatrix([[0],[$1..N]],0,N+1,storage=rectangular,shape=[])
This is somewhat longer than calling the Matrix command with its scan option, naturally.

band_comment.mw

 

The four techniques that Carl laid out in his Answer can be accomplished (in essence) in versions back to Maple 6 (2000).

A few modifications would be necessary for some of them. For example the 3rd could be done by calling a module export, since the ModuleApply functionality appeared in Maple 9.5 (2004). And, while thisproc functionality appeared in Maple 14 (2010), the 4th can be implemented using option remember. And so on.

I will mention that one can programmatically manipulate the cache table of a procedure defined with option cache. So it is possible to add persistent entries to procedures even while the cache table manages other values up to some specified size as temporary. The Help page for topic CacheOption illustrates this with explicit examples, where op(4,...) is used to refer to the cache table of such a procedure. Indeed the text states, "Permanent entries can be inserted into a cache table by using the AddPermanent command.   This allows cache remember tables to still be used for base cases in recursive functions and for storing commonly used values."

Have you considered using the Calendar package (new in Maple 2018)?

This kind of thing was shown in this old response on this site, from the year 2006.

@Stretto Yes, your point was already clear.

@Carl Love I understood what you meant. But I often get a scenario in which the Maple GUI's buttons and icons (and its X, etc) don't respond while closing with the desktop's controls somehow still triggers the Maple GUI to prompt me for a worksheet-save.

So I guess that it might help someone, to be able to try both, in some situations.

(I've edited my answer, as I realize now that I mistakenly made it seem like we were talking about the same control widgets, sorry.)

I'll add that I always open every worksheet in a standalone Maple GUI session, so that a crash of kernel or GUI can only ever affect a single opened file. And since I only have a single sheet opened per GUI instance, the GUI doesn't show me the X of which you were speaking. That is, I open a wholly separate GUI instance for each concurrently open worksheet.

So, this somewhat usual crash scenario for me is where the kernel crashes and the GUI's File Close/Open from the menubar are grayed out and inoperative. It is at that juncture that closing with the desktop widget still prods the Maple GUI to prompt for a Save -- which is better than my killing the process outright.

@ddaigle321 Two lists are not identical just because they might be "mathematically" equal.

Two lists are identical under evalb if they have the same memory address (see the addressof command). That is generally not the same thing as being mathematically equal -- the definition of which varies with the mathematical domain.

Perhaps see also the verify command, and in particular verify,list help topic. To compare two lists L1 and L2 as being "mathematically" equal under a general "mathematical" verification ver one could use the command,
   verify(L1, L2, list(ver))

Somewhat similar remarks may be had about sets.

Of course it is quite possible that the elements of your lists will also be identical, in which case evalb testing would suffice. We can't tell, because you won't disclose the details of what you're actually trying to accomplish.

@Carl Love Yes, I was addressing only the original Question's literal text, not your Answer.

You mentioned writing your own function with the short name RPF, with which you could wrap each plot. But that's exactly what setPlotSize does, and you can easily rename that at will (and give it default values).

I'm not talking about making things fully automatic, especially for 3D plots. But the part of your Question about writing any additional wrapping function simply doesn't add up.

On the other hand, I think that your need and expectation of a convenient way to set both default 2D and 3D plot size is very sensible.

I can think of a few ways to accomplish that, but I'm not sure which would be best, both long term and/or as quick fix. (Eg. alter behavior of plots:-setoptions, ask for new interface settings, alter PLOT/PLOT3D printing, alter individual plotting commands, etc). For a one-off quick fix it might be simplest to alter the printing... I might have time for that.

Your question does not make sense.

Please explain clearly what you are trying to do.

@Carl Love  I forget where I first saw the idea to factor the degree 8 polynomial using this field extension. It factors into a pair of quartics (which can each be solved explicitly, naturally). I have a recollection that it might have been something by Robert Israel.

restart;

kernelopts(version);

`Maple 2019.2, X86 64 LINUX, Oct 30 2019, Build ID 1430966`

P:=op(1,convert(cos(Pi/17),RootOf));

256*_Z^8-128*_Z^7-448*_Z^6+192*_Z^5+240*_Z^4-80*_Z^3-40*_Z^2+8*_Z+1

Rs:=simplify(radnormal~([solve(factor(P,sqrt(17)),explicit)]),size):

R:=select(r->is(r-cos(Pi/17)=0),Rs)[1];

(1/64)*((17^(1/2)-3)*(17+4*17^(1/2))^(1/2)+17^(1/2)+5)*(34+6*17^(1/2)-8*(17+4*17^(1/2))^(1/2))^(1/2)+(1/64)*(-4*17^(1/2)+20)*(17+4*17^(1/2))^(1/2)-(1/16)*17^(1/2)+1/16

simplify(R-cos(Pi/17));

0

 

Download forfun.mw

@Carl Love That's nicely done.

 

@Kitonum I'm curious as to your methodology. Mine didn't produce a nice form for the sin term. Did I miss something easy?

restart;

H:=solve(op(1,convert(cos(Pi/7),RootOf)))[1]
   +I*solve(op(1,convert(sin(Pi/7),RootOf)))[3];

(1/12)*(-28+(84*I)*3^(1/2))^(1/3)+(7/3)/(-28+(84*I)*3^(1/2))^(1/3)+1/6+((1/12)*I)*3^(1/2)*((-28+(84*I)*3^(1/2))^(1/3)*(I*(-28+(84*I)*3^(1/2))^(2/3)*3^(1/2)-(-28+(84*I)*3^(1/2))^(2/3)-(28*I)*3^(1/2)+28*(-28+(84*I)*3^(1/2))^(1/3)-28))^(1/2)/(-28+(84*I)*3^(1/2))^(1/3)

evalf(H);

.9009688680+.4338837391*I

Q:=cos((1/7)*Pi)+I*sin((1/7)*Pi);

cos((1/7)*Pi)+I*sin((1/7)*Pi)

evalf(Q);

.9009688678+.4338837393*I

simplify(Q-H);

0

# oof
S:=solve(op(1,convert(sin(Pi/7),RootOf)))[3]:
frontend(u->u,[expand(S^2)],[{`+`,`*`},{}]):
subs((-28+84*I*sqrt(3))^(1/3)=PP,1/(-28+84*I*sqrt(3))^(1/3)=1/PP,%):
new:=(simplify(subs(PP=(-28+84*I*sqrt(3))^(1/3),collect(%,PP)),size))^(1/2):

HH:=solve(op(1,convert(cos(Pi/7),RootOf)))[1]+I*new;

(1/12)*(-28+(84*I)*3^(1/2))^(1/3)+(7/3)/(-28+(84*I)*3^(1/2))^(1/3)+1/6+I*(7/12+(1/48)*(I*3^(1/2)-1)*(-28+(84*I)*3^(1/2))^(1/3)-(7/12)*(I*3^(1/2)+1)/(-28+(84*I)*3^(1/2))^(1/3))^(1/2)

evalf(HH);

.9009688680+.4338837393*I

simplify(Q-HH);

0

 

Download conv_radical.mw

@CyberRob There is no doubt a more efficient way to do this using coeff/coeffs. But I'm trying to figure out whether this is what you're after.

I still don't understand why in your second example you wanted a factor like,
   nurdel*(dnub*nur + dnur*nub)
while in your first example you wanted a factor like,
   dnub*nur*nurdel + dnur*nub*nurdel

restart;

vars := [nur, nub, dnur, dnub, nurdel, nubdel, dnurdel, dnubdel]:

expr1 := c4*dnub*kpbr*ksr*nur*nurdel + c4*dnur*kpbr*ksr*nub*nurdel:

targ1 := c4*kpbr*ksr*(dnub*nur*nurdel+dnur*nub*nurdel):

expr2 := c4*dnub*kpbr*ksr*nur*nurdel + c4*dnur*kpbr*ksr*nub*nurdel + nub:

targ2 := c4*kpbr*ksr*nurdel*(dnub*nur + dnur*nub)+nub:

expr3 := c4*dnub*kpbr*ksr*nur*nurdel + c4*dnur*kpbr*ksr*nub*nurdel
         + (c4*nus0 + c5)*dnub+dnub:

targ3 := c4*kpbr*ksr*nurdel*(dnub*nur + dnur*nub) + (c4*nus0 + c5+1)*dnub:

step1 := proc(ee) local K;
           eval(simplify(collect(ee,vars,K)),K=(x->x));
         end proc:

step2 := proc(ee) local temp;
           temp:=[seq(map(`*`@op,[selectremove(has,[op(u)],vars)]),
                  u=`if`(ee::`+`,ee,[ee]))];
           map[2](op,1,temp),map[2](op,2,temp);
         end proc:

step1(expr3);
step2(%);
targ3;

c4*kpbr*ksr*nurdel*(dnub*nur+dnur*nub)+(c4*nus0+c5+1)*dnub

[nurdel*(dnub*nur+dnur*nub), dnub], [c4*kpbr*ksr, c4*nus0+c5+1]

c4*kpbr*ksr*nurdel*(dnub*nur+dnur*nub)+(c4*nus0+c5+1)*dnub

step1(expr2);
step2(%);
targ2;

c4*kpbr*ksr*nurdel*(dnub*nur+dnur*nub)+nub

[nurdel*(dnub*nur+dnur*nub), nub], [c4*kpbr*ksr, 1]

c4*kpbr*ksr*nurdel*(dnub*nur+dnur*nub)+nub

step1(expr1);
step2(%);
targ1;

c4*kpbr*ksr*nurdel*(dnub*nur+dnur*nub)

[nurdel*(dnub*nur+dnur*nub)], [c4*kpbr*ksr]

c4*kpbr*ksr*(dnub*nur*nurdel+dnur*nub*nurdel)

 

Download collect_ac2.mw

An alternative for step1 (possibly better) might be,

step1 := proc(ee) local K;
           eval(collect(collect(ee,vars,K),K,simplify),K=(x->x));
         end proc:

@Kitonum For the very first example the OP's expected result is not the "simplest" form (lowest leaf count, shortest, fully factored, etc). So, while your comment is correct, I don't see how it figures in here.

First 193 194 195 196 197 198 199 Last Page 195 of 592