acer

31086 Reputation

29 Badges

19 years, 71 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are answers submitted by acer

The GUI's mechanism for rendering of "usual" animations has the behaviour that only a single instance of each "global" plot feature gets used.

By "global" I mean the kinds of plot feature that is common when one merges plots. For example the axis tickmarks, or the orientation, or the total view, or (in your case) the background image, etc. Those aspects become common/uniquified in every frame, when handled by the GUI's usual animation rendering mechanism.

So, you can't do a usual animation where the view changes with each frame. And you can't do one in which the background image changes with each frame. And (wisely or not) the Statistics:-HeatMap command uses a background image to get nice sharp edges on its rectangles, while reducing the use of GUI resources by avoiding a structure with many rectangles as POLYGONs.

You can, however, show such separate plots by sequentially sending them individually to an embedded PlotComponent. One easy way to get such an effect is to use the Explore command.

Why_cant_I_animate_still_images_like_this_ac.mw

You can experiment with frame duplicates, of floor/ceil/trunc of variable `i`, etc, to alter the frame-rate. Or you could Explore a call to a custom short procedure that did a Threads:-Sleep call before returning a frame.

Naturally, for a construction as quick as your HeatMap you might even Explore direct calls to it (on the fly, not precomputed).

ps. It's not clear how/whether you wanted your go2 procedure to utilize its parameter.

Here is an example that uses Optimization:-Maximize, as well as a 3D plot.

FindingExtractingvaluesdsolvewithspecificconditions_ac.mw

There are a few corrupt blobs of XML in your attached .mw file, ie. unclosed Equation fields.

Here is some recovery (more than I was able to get from Maple itself):

C_Users_Tobia_OneDrive_Desktop_Multivariat_Exercises175_MAS_ac.mw

Let me know if there are additional problems with it.

I strongly suggest that your upgrade from Maple 2022 to Maple 2024, since the latter has far fewer reports on such kinds of worksheet corruption.

Is this the kind of effect that you're after?

You can manipulate the expression temp, etc, and then if you want replace that L[b1] with a number later on.

temp := Eval(diff(diff(w[2](x[1],t),t$2),x[1]),x[1]=L[b1]);

Eval(diff(diff(diff(w[2](x[1], t), t), t), x[1]), x[1] = L[b1])

eval(temp, L[b1]=5);

Eval(diff(diff(diff(w[2](x[1], t), t), t), x[1]), {x[1] = 5})

value(%);

eval(diff(diff(diff(w[2](x[1], t), t), t), x[1]), {x[1] = 5})

Download Eval_eval.mw

It appears that you are making multiple fsolve calls. But just three, or many? How large are the systems? Are they all systems of polynomials?

You may be able to tell whether RAM is the problem by looking at your OS (TaskManager, or `top`). I'd expect that it'd take many systems of equations, or very large systems, for that to be the bottleneck in (purely) such fsolve attempts.

But you might well be able to run such multiple fsolve calls concurrently and in parallel (even stopping all, once any root is found) by using either the Grid or Threads packages. In that situation getting the fastest CPU with multiple cores might be most fruitful.

nb. The only parallelism done by Maple with the graphics card is (optionally) some Vector-Matrix multiplication, and that's been mostly surpassed now by the fast regular BLAS (which don't need the mem transfer). It's likely irrelevent here.
nb. Maple GUI resources can be supressed by supressing/avoiding large 2D Math output or input/plots, and so the computational time for your numeric rootfinding is likely unrelated to the RAM/GUI interaction.

In your Maple 2022 you can try out the following.

See also odetest.

restart

kernelopts(version)

`Maple 2022.2, X86 64 LINUX, Oct 23 2022, Build ID 1657361`

DE := diff(3*(diff(u(x), x))^2, x) = x

6*(diff(u(x), x))*(diff(diff(u(x), x), x)) = x

sols := dsolve(DE)

u(x) = -(1/12)*x*(6*x^2+6*_C1)^(1/2)-(1/12)*_C1*ln(x*6^(1/2)+(6*x^2+6*_C1)^(1/2))*6^(1/2)+_C2, u(x) = (1/12)*x*(6*x^2+6*_C1)^(1/2)+(1/12)*_C1*ln(x*6^(1/2)+(6*x^2+6*_C1)^(1/2))*6^(1/2)+_C2

evala(diff(3*(diff(-(1/12)*x*sqrt(6*x^2+6*_C1)-(1/12)*_C1*ln(x*sqrt(6)+sqrt(6*x^2+6*_C1))*sqrt(6)+_C2, x))^2, x))

x

simplify(eval((lhs-rhs)(DE), sols[1]))

0

simplify(eval((lhs-rhs)(DE), sols[2]))

0

odetest(sols[1], DE)

0

odetest(sols[2], DE)

0

Download is_this_correct_ac.mw

The command selectremove returns a sequence of two results.

In your code selectremove acts on a list as input, which is whatever list is currently assigned to L. And it returns two lists: the first being the list of entries in L that satisfy the predicate ( i->(i mod divisor = 0) ), and the second being the list of entries in L which do not.

The assignment,
   divisible, L := ...
assigns the first result to name divisible, and assigns the second result to name L.

That action, with a sequence of names on the LHS of the assignment statement, is called multiple assignment. See its description in the fourth bullet point in Desciption section of the Help page for assignment.

The respective values of those two names (divisible, and L) get updated in this way, each time this multiple assignment gets done in the loop.

If you change the statement terminator following the end do (od) from a full colon to a semicolon then you can see this looped multiple (re)assignment.

sr_loop.mw

ps. You also wrote, "Why isn't divisible defined with an operator like -> ?". The name divisible is used here merely as a name to which repeatedly assign some lists. It's not used as an operator/procedure. It's not applied to any arguments. It's just used to store intermediary list results, as also is the name L.

First you need to fix your faulty syntax and provide missing details.

The assignment to C1 fails in your attachment, yet you ask for a plot of it's expression. You should fix that, or at least explain properly what your intention is for assigning to C1.

Next, your expression assigned to C2 contains a function calls that seem like a mistake. Why does it have the function call R0er(y) appear in the expression assigned to C2? Did you forget a multiplication sign or a space to denote multiplication implicitly in 2D Input?

For which parameters do you want to have Sliders? Is it just g2, or also any of the others in DATA?

If I guess the fixes to the above problems, then here is the kind of thing you can do with a simple call to the Explore command:
question_plot_slider_ac.mw

You should be able to adjust your expressions (A11, etc), if needed.

Here is one way, using rsolve,

rsolve({A[n + 1]*(5*A[n] + 2) = A[n], A[1] = 1}, A[n])

1/(3*2^n-5)

Download rs_ex.mw

Your attempt was getting tripped up by the ratpoly, not the indexed syntax.

Fwiw, given your original form,

eq := A[n + 1] = A[n]/(5*A[n] + 2):
neweq := numer((lhs-rhs)(eq)):
rsolve({neweq,A[1]=1},A[n]);

       1/(3*2^n-5)

You can use the eval command to substitute for u throughout, or for any/all of the derivatives separately.

For example,

restart;

PDEtools:-undeclare(prime, quiet):

de := diff(u(x,t),t) = -a*diff(u(x,t),x,x) + b*diff(u(x,t),x);

diff(u(x, t), t) = -a*(diff(diff(u(x, t), x), x))+b*(diff(u(x, t), x))

eval( de, u = F );

diff(F(x, t), t) = -a*(diff(diff(F(x, t), x), x))+b*(diff(F(x, t), x))

eval( de, u = ( (x,t)->G(x)*H(t) ) );

G(x)*(diff(H(t), t)) = -a*(diff(diff(G(x), x), x))*H(t)+b*(diff(G(x), x))*H(t)

eval( de, u = ( (x,t)->sin(x)*H(t) ) );

sin(x)*(diff(H(t), t)) = a*sin(x)*H(t)+b*cos(x)*H(t)

eval( de, u = ( (x,t)->G(x)*cos(t) ) );

-G(x)*sin(t) = -a*(diff(diff(G(x), x), x))*cos(t)+b*(diff(G(x), x))*cos(t)

eval( de, u = ( (x,t)->sin(x)*cos(t) ) );

-sin(x)*sin(t) = a*sin(x)*cos(t)+b*cos(x)*cos(t)

eval( de, [ diff(u(x,t),t)=P(x,t),
            diff(u(x,t),x)=Q(x,t) ] );

P(x, t) = -a*(diff(Q(x, t), x))+b*Q(x, t)

Download eval_substitutions_ex.mw

Note that the Optimization package will compute local optima for multivariate problems, so you might want global optimization instead. See DirectSearch v2. In my attachment I've used both.

I've rewritten the objective so that it doesn't error out if the de solving throws an error (eg. ostensibly runs into a singularity, etc). Also, it stores the best value found so far, which means that you can interrupt it and still see how well it did. (This can be convenient if your options choices make it take a long time.)

The original objective SSE had some others flaws, on top of being fragile. The most important perhaps is that for an IVP and using the parameters option of dsolve one does not have to re-invoke dsolve every time one wants to use different parameter values. In fact the efficiency gain of not having to invoke dsolve each time is one of the major aspects of the parameters option. Also, picking off the values using rhs of the 3rd entry is poor, being fragile wrt the lexicographic ordering of the dependent function names.

You can play with the optimizer's options. Again, if it looks like it's not improving much, and taking long, you can interrupt and still see the current best and make the plot for that. You can also make the optimizers work harder/longer with additional options (iterationlimit, evaluationlimit, timelimit, etc -- though it varies by solver/method which if those you can use).

I found a data file by the same name on that github link you gave. The top portion at least seems to match what your sheet displayed.

Parameter_estimation_acc.mw

Here's one kind of result:

beta = 8.803946195*10^(-7), Gamma = 0.0129, S0 = 98274.5155341030, i0 = 93.2346673823882

 

If you assign a value to mu (by itself) then you will affect any instances of indexed names like mu[3], mu[4], etc.

So if you also want to have the subscripted names then you can instead use m__3 and mu__4 (double underscore). Those are completely separate and unrelated names.

But the double-underscore names will pretty-print as subscripted names in 2D Output.

The clause, "no computation was needed if basic math knowledge was utilized" connotes (to me) what is called abstract linear algebra.

If there were placeholders (objects, etc) that represented a Matrix, and enough accompanying functional syntax, then a strong abstract linear algebra package might be able to recognize the equivalence of those two forms without doing a computation with explicit Matrix entries.

At the other end of the spectrum is the fact that your pairs of concrete constructions are not producing the same final form. For example, there may be some difference in presence or absence of factorization of numerators or denominators of the resulting multivariate rational polynomials. On that note, getting the final Matrix of zeros for the difference can be attained just by normal (ie. simplify is not needed, and its symbolic option is not relevant here). Also, a true result for the comparison can be had by just,
   Equal(normal(expand(1/`⨂`(A, A))), normal(expand(`⨂`(1/A, 1/A))))
Using_basic_linear_algebra_ac.mw

In the middle ground there might be scope for hybrid abstract/concrete computation, where either of the two calls were somehow analyzed up front. That would require by-passing the usual evaluation of MatrixInverse (or rtable powering) or KroneckerProduct, so that their arguments could be analyzed abstractly. (Maple's usual evaluation of function calls has the inner calls evaluated before the outer calls get to "see" them.) In this example it might even be the case that the faster of those formulations could be used, once the form is recognized. Implementing this is possible, though possibly involved.

Closer to the concrete end is the idea that both results might be simplified/normalized by the commands themselves (though not at present) to a common form. This is not the way that several parts of Maple work; it can be too expensive and heavy-handed to do that in general, and it's often left to the user to do such as a subsequent step.

This could be improved (say, removing entries when no longer active).

restart;

util := 'map(nm->assign(`tools/gensym`(lhs(nm)),rhs(nm)),
    getassumptions([indices(`property/OrigName`)]))':


Execute this line by line.

assume(x>0);


Watch the Variables palette

util:

assume(y<4 and y>-1);

assume(z::posint);


Watch the Variables palette

util:


The last step did not assign to (or clobber) the actual
assumed names. You can do it repeatedly.

x,y,z;

x, y, z

Download assum_var_palette.mw

There are several ways to do that.

For example,

restart;
fn := "/home/PNL/test_file.txt":
fprintf(fn,"%a\n", "Hello, it is me"):
fprintf(fn,"%a\n", 3.1415):
fclose(fn);

restart;
fn := "/home/PNL/test_file.txt":
FileTools:-Text:-WriteLine(fn, "Hello, it is me"):
FileTools:-Text:-WriteLine(fn, "3.1415"):
FileTools:-Text:-Close(fn);

restart;
fn := "/home/PNL/test_file.txt":
FileTools:-Text:-WriteFile(fn, "Hello, it is me\n3.1415\n"):

Note that the directory must exist. Note also that the the first two of those require that the file handle be closed (by explicit command, or by a restart). The "\n" is for a new line.

I couldn't tell whether you wanted the Hello string to be written out including its quotes. If so then you could escape the quotes within a string, eg.
   "\"Hello, it is me\""

There are even more ways to do this kind of thing. But let us know if you get it working. It looks as if your OS is not MS-Windows, btw.

1 2 3 4 5 6 7 Last Page 1 of 324