26592 Reputation

29 Badges

17 years, 0 days

Social Networks and Content at

MaplePrimes Activity

These are replies submitted by acer

You could zip-compress-archive the file, then upload and attach the .zip file using the green up-arrow in the Mapleprimes editor.

@Carl Love A PlotComponent allows for properties (clickx  clicky) to be queried programatically. Those can be used with a single right-click, or click&drag.

The `Explore` command allows for this by having two (or one) parameters be specified via its `markers` option. Additionally, the corresponding Sliders may be shown, or suppressed. See ?Explore as well as ?examples,Explore .

The above have a notion that the scale of the parameters is the same as the scale of the 2D plot. Naturally, if the interactive plot is 3D then such marker-style interaction (on a 2D plot area) would need to be in a separate plot, by the side say.

I'm away from a computer until this coming Sunday  and then again from Mon-Fri. Apologies not being to show examples by code.

[edit. If I can paste properly...]

The parameter values taken from a 2D plotting area can be used as simply the x,y values of an input point. Or they can be used as a pair of parameters used in some quite different manner of your own devising.

IIRC, here's an Explore app that used markers to grab an x-y point input on-the-fly,

And here's an embedded components app that also used clickx,clicky (but not via Explore) to control parameters,


As far as a (forcing) programmatic transformation goes, do you care whether it is always valid?

ps. Is this entirely different from all your earlier queries on 2-argument arctan, and if not then why split up the topic?

@Christian Wolinski I believe that the OP is aware that he can write it out, with the body of the inner procedure hard-coded. Ie, more tersely,

f := a -> (b -> a/b);

      f := a -> b -> a/b



I believe that the OP's issue was in programmatically building f such that the body of the inner operator was constructed from the predefined expression e.

@vv If g changes then the efficient course would be to rebuild dgdx2. (The efficiency alluded to is the cost of repeatedly invoking D for each call to dgdx, not the cost of construction.)

In terms of simplicity but with a similar inefficiency, forming dgdx2 once, prior to defining g, makes it behave like dgdx1, ie. consistent results. (But it's still simpler and more straightforward.) Eg,

dgdx1:=(x,T) -> D[1](g)(x,T);
dgdx2:=  D[1](g);

g := (x, T) -> T*x + x^2:  #just an example
dgdx1(1, 2);
dgdx2(1, 2);

g := (x, T) -> T*x + 7*x^2:
dgdx1(1, 2);
dgdx2(1, 2);


You've accidentally pasted Tom's 1D plaintext code in as 2D Input, without altering it to avoid (incorrect) implicit multiplications.

You've changed the boundary conditions in two different ways (both invalid).

You've changed f(x) in one of the equations.

@vv If g has already been defined then I don't see why you'd want to incur the cost of having dgdx invoke D each time it gets called, instead of simply assigning,

   dgdx := D[1](g);

@FDS What I gave originally was 4x1 Matrix. I've edited it to return a column Vector.

@mehran rajabi You could upload and attach the worksheet in which the plot is not displayed for those commands...

@Carl Love For no reason except that I think this looks nifty.

(edit: one reason is that shading=xyz can convey some depth, which is less clear with a monochromatic curve.)

Done in Maple 2018.2 for Linux.


with(DocumentTools): with(DocumentTools:-Layout):
with(DocumentTools:-Components): with(plots,display):

end proc:





[diff(x(t), t) = 35*y(t)-35*x(t), diff(y(t), t) = -x(t)*z(t)-7*x(t)+28*y(t), diff(z(t), t) = x(t)*y(t)-3*z(t)]

sol:=dsolve({eqs[], (V(0)=~ V||~0)[]},numeric,maxfun=-1,parameters=V||~0):


[x0 = .107335941150510, y0 = .767616132399701, z0 = .244155091492448]





@dvilla It is possible to programmatically embed a plot with a specified zoom scaling (zoom) factor and adjusted vertical (or horizontal) offset within the inlined plotting window. In other words, to take the burden off of the end-user, and to allow you to enforce the initial aspect.

In the following worksheet the plots get "displayed" (even from scratch) just as shown. I appreciate such programatic vertical trimming of blank white space, if I do not intend to rotate the 3D plot head-over-heels.

Unfortunately this forum's backend baulks as rendering this worksheet.

Those wrapping commands which force the scaling/offset/etc could easily be made into a reusable procedure, which could also be optionally hidden -- say in the Startup region of the worksheet.

An alternative is to rescale the formula and then force new tickmarks, but it can get complicated to implement robustly as a general mechanism. 

I used Maple 2022.1, and got no disk artefact. But that's a separate issue to getting the zoom, offset, aspect ration, etc, just as you want.

@dvilla Do you know that if you right-click on a plot then you get a menu?

One of the items on the menu is "Manipulator". Selecting that gets to a submenu, with "Zoom in" as a checkbox. If you select that checkbox then you can rescale the plot, within its window. You can either click-and-drag the left mouse button, vertically, or you can scroll the mouse wheel.

Also, I don't get that separated disk, that you show in your image.

Why don't you mark your Question with your Maple version (in the editor of the Question, as the "Product" combobox), or at the very least tell us which version you're using? 

Why don't you upload and attach your actual worksheet, using the green up-arrow in the Mapleprimes editor?

I changed both of your recent Posts into Questions.

In future, please the form for submiting a new Question, for distinct new queries. It's right there on the Mapleprimes front page, as a big green rectangle/button.

Are you all using the very same Operating System?

Does the file's name have any special (eg. non-alphanumeric) characters, apart from a period (".")?

Has she tried importing the data using either the command Import, or the package command ExcelTools:-Import?

You might consider stating the specific OS, and then uploading and attaching a zipped file containing the data file. Then others might be able to reproduce the issue, and possibly debug the problem.

@lcz I don't understand exactly what you mean, about executable files.

You can compile (externally, or as a system call) files from Maple procedures that can be completely handled by CodeGeneration[C].

Alternatively, when you use Compiler:-Compile on a Maple procedure (with option inmem=false, with no callbacks to any non-C Maple function) then the generated, external, shared object library (.dll, .so) has an outer and an inner function. The outer function admits Maple structures as arguments. The inner function admits pure C structures, and may be used by other external programs. See also with its undocumented option keeptemps=false, files under /tmp say...

Or are you taking about using OpenMaple?

I can't tell which you mean, sorry.

5 6 7 8 9 10 11 Last Page 7 of 494