@Clarins The example you're citing relates to 3D data and interpolation, and the input points (at which one wants to compute interpolated values) are expected to be supplied in an Array with the corresponding dimension(s).

That input Array just looks a little funny when there is just one single new point at which to interpolate. But the structure could alternatively hold multiple such points.

If you intend 1/(x*(1-x))*(1+2*x) then type it in that way, rather than as 1/(x(1-x))(1+2*x) . What you had involved function calls, not multiplication.

acer

@Markiyan Hirnyk 

bandbpatch.mw

@lg674 Kitonum's code works for me in Maple 18.02. I attach it in a Worksheet.

curve.mw

I also added the option numpoints=500 to the calls to spacecurve, to get a smoother curve (for the full range of t) in that Maple version.

@Axel Vogt Hi Axel, I've made a few posts about cusomiztion of context-menus in the past, ie, here, here, here, and a few others. But none of those generated much commentary or response, even by those more expert at Maple programming.

Maybe I should write the code to augment the stock context-menus with calls to the DirectSearch package's commands (possibly in the submenu used for Optimization?)

@Chris It must be tough to use a Maple Document or Worksheet, including stock context-menus for instructing primary school students. How do you help them not become confused by the mathematical jargon that is years beyond their current knowledge?

There are some interactive popup applications (Maplet based "applets") available from the main menubar, via Tools->Options->Tutors (or Assistants). The one's from the Precalculus package might provide a gentle experience for the very young or mathematically inexperienced.

I should probably mention that the third argument of the Entries:-Add command in the code snippet I gave above is the type which the right-clicked expression must match in order for the context-menu item to appear. Now, (x-1)/(x-2) will trigger it, since that is of type ratpoly which is the type I used in that code example. But y=(x-1)/(x-2) is not of that type, and so won't trigger it. You could either relax that type to be something like, literally, anything instead of ratpoly so that it is matched by more variants of expression. Or you could construct a more involved type that more expressions would satisfy.

You can also augment the context-menu with even more items, such as more of the available tutors. Or if you find (or author) even more popup applets then you could augment the context-menu with those too.

In my code snippet above the first line makes a full copy of the "stock" Library-side context-menus. And you can add your own customized items into existing submenus (like I did above), or make your own submenus for them. You could even start from scratch with an essentially empty set rather than use the Copy command as I did above, and add only your own items. Or you could experiment with the ContextMenu[CurrentContext][Entries][Disable] command if your students are overwhelmed by the jargon in the slew of stock items. The system is pretty flexible, but setting up a customization does require programming.

This is an area for which I haven't seen a lot of interest in customization by users, over the years. It's possible that this is because there are only programmatic means available for customization. I wonder whether a Maplet or Embedded-Components based graphical interface to customization would make a big difference.

Why do some of the equations use lambda and sigma as multiplicative terms ( eg, note the `*` in 3*P[0](s)*lambda ) while the latter equations also make function calls to lambda and sigma, eg, lambda(P[3](s)...) ?

Or did you intend the latter equations to be more like the following. Note the `*` following the lambda.

P[3](s) = 2*lambda*(P[1](s)+P[2](s))/(s+2*mu[1]+lambda)

Also, it's not clear what you meant by "rearrange". And you comments about functions and assignment are also unclear. Why don't you 1) upload a worksheet, and 2) use -> notation for creating operators (if that's what you really want)? Why would making operators help anyway, when you could instead create equations? Are you just trying to solve for, or eliminate, some names ( or function calls P[i](s) )?

acer

@Carl Love This is on 64bit Linux of Maple 2015.2.

First, this is for many inner lists, each with few entries. I'm not really sure, but the cost of the function calls seems to less than the cost of production and reclamation(?).

restart: kernelopts(printbytes=false):
LL:=[seq([seq(i*j,i=1..100)],j=1..100000)]:
CodeTools:-Usage(map(parse@cat@op, LL)):
memory used=1.17GiB, alloc change=448.00MiB, cpu time=7.58s, real time=6.47s, gc time=1.69s

restart: kernelopts(printbytes=false):     
LL:=[seq([seq(i*j,i=1..100)],j=1..100000)]:
CodeTools:-Usage(map(`@`(parse,cat,op), LL)):
memory used=1.17GiB, alloc change=448.00MiB, cpu time=7.59s, real time=6.48s, gc time=1.68s

restart: kernelopts(printbytes=false):       
LL:=[seq([seq(i*j,i=1..100)],j=1..100000)]:  
CodeTools:-Usage(map(L-> parse(cat(L[])), LL)):
memory used=297.72MiB, alloc change=448.00MiB, cpu time=3.68s, real time=3.29s, gc time=592.00ms

Now, with more entries per inner list, and with fewer inner lists,

restart: kernelopts(printbytes=false):         
LL:=[seq([seq(i*j,i=1..1000000)],j=1..10)]:    
CodeTools:-Usage(map(parse@cat@op, LL)):
memory used=0.96GiB, alloc change=75.43MiB, cpu time=5.96s, real time=5.95s, gc time=24.00ms

restart: kernelopts(printbytes=false):     
LL:=[seq([seq(i*j,i=1..1000000)],j=1..10)]:
CodeTools:-Usage(map(`@`(parse,cat,op), LL)):
memory used=0.96GiB, alloc change=75.43MiB, cpu time=6.04s, real time=6.04s, gc time=24.00ms

restart: kernelopts(printbytes=false):       
LL:=[seq([seq(i*j,i=1..1000000)],j=1..10)]:  
CodeTools:-Usage(map(L-> parse(cat(L[])), LL)):
memory used=0.96GiB, alloc change=75.43MiB, cpu time=6.02s, real time=6.01s, gc time=20.00ms

Are these results affected by the choice of example? Perhaps random entries would give significantly different results?

Are you asking a question similar to this?

acer

@Markiyan Hirnyk It is a curious bug in the branchandbound method, which only seems triggered for some ranges. The `nodelimit` option doesn't help.

I will submit a bug report.

restart;
p := -x^2+1:

Optimization:-NLPSolve(p,x=0..2,method=branchandbound);

           [-2.24, [x = 1.8]]

eval(p,x=2.0);

                             -3.00

Optimization:-NLPSolve(p,x=0..2.1,method=branchandbound);

               [-3.41, [x = 2.1]]

eval(p,x=2.1);

                             -3.41

@Bendesarts I haven't forgotten this. It is a challenge to do this kind of thing exhaustively while being efficient and reducing repeated computations (ie. the memoization can be tricky to do "well").

But I've run into this kind of problem before, and that makes me supect that it it could be worthwhile and useful.

I have you example running at 10-15 minutes on a fast machine, if I do it exhaustively and somewhat naively. I'm working on making it more efficient.

I can add a few bells and whistles (such as extraction of best found result after early termination, optional early termination on time-limit, optional early termination upon achieving a target "size", etc). But making it more efficient is till something that I'm working on.

We've gotten a little side-tracked, on the topic of 3D plot sizing and aspect rations, rather than the original question about meshing and grid appearance on surfaces. My comments below continue on the side-topic.

3D plot rendering in the Standard GUI changed in several ways after Maple 12. In modern Maple there is also access to three rotation angles (orientation, and in manual rotation with the mouse too).

And while stretching of the rendered 3D plot (following manual restretching of the 2-dimensional "plot window") provided another bit of functionality in Maple 12, it had its limitations. For example it was still hampered by the inability to manually rotate in the 3d orientation angle. And it was only available for the scaling=unconstrained case, and it still forced the x-y axes' to be in a 1-1 aspect ratio. And the aspect ratios of the x-z or y-z axes could only be done roughly with mouse action, and not be done precisely and programmatically.

By coincidence I have been working on assembling a document which I hope will illustrate a more complete set of desirable cases. Basically I was something like this:

1) The `size` option for 3D plots, to allow forced and precise control of the 2-dimensional viewing window, so that the user can avoid wasted white-space (above and below), ensure that long labels or long tickmark values are visible, etc.

2) Aspect ratios for the 3D plot axes, to get full and precise, programmatic control of the relative lengths of the visible portions of the axes (ie, pairwise relative). This detail should probably be done as a new bit of data in the PLOT3D data structures axis substructure, and available to commands with the `axis[n]` options, say.

After giving it considerable thought I am pretty sure that 1) and 2) need to be separate. Ie, a three-valued `size` option would not suffice, and would be a misimplemenation that does not adequately cover enough situations.

What I'm trying to assemble is a set of 3D plots, in a worksheet, that exhibit the varied scenarios, so that a full and proper solution might be realized. I happen do be constructing these using Library-size techniques of re-scaling, manually made tickmarks, and a little programmatic content generation and embedding. (And I suspect that this might be useful as an interim stop-gap for people who want to force a particular appearance in a document, now.) But that's just to build the cases -- I still want a PLOT3D datatstructure and GUI rendering implementation as the ideal.

How does that code you showed have anything to do with setting a time limit?

Explain how Maple's timelimit command doesn't provide what you want. Are you attempting numeric dsolve computations? Are you hoping to get partial numeric results, upon timing out?

acer

Supply the source code. Be clear in explaining your objections.

Use the same for both plots. You have one plot with x from -2 to 2 and another from -2 to 0.

@Kitonum Thanks for that.

While compoly is certainly a useful addition to one's toolbag there are still some easy examples where both it and simplify miss the mark.

The following example is not even in the harder class in which terms which need to be added/subtracted also contain the relevant variables (eg. my 7th power expansion above). And the degrees are low.

We can observe that compoly requires just the right variable names in order to make progress (which may still be incomplete). The CompleteSquare command does better, with less guidance.

Download compoly.mw

I don't pretend that for higher degrees this is not a hard task in general, or course.