Doug writes: "I agree that the context menus are the easiest way to customize a plot, but I wish there was a way to get Maple to return the command needed to (re)produce the plot from the command line. This seems like it should not be too difficult to achieve. What are the chances it could appear in the near future?"

For the very near future, I don't think the chances of getting this feature are good. In general, plots can be created through a combination of library commands, context-menu actions and drag-and-drop actions. For anything other than the most simple cases, I'd think it would be difficult to recover a library command to generate an arbitrary plot.

However, in the long term, there may be other features that will make it easier to keep track of changing options in plots. As some of you have noticed, there have been steady improvements in plots over the past few releases. I expect that making plots better and easier to use will continue to be a priority in the future.

Paulina

The real reason you're seeing the difference in the titles is because of standard and extended typesetting. The plot system currently uses standard typesetting, even when the user changes the default to extended. However, the call to Typesetting[Typeset] generates the extended typesetting output. We hope to resolve some of these standard/extended typesetting issues in the future. In the meantime, you can use Typesetting[Typeset] to achieve the desired result, but it's one of those "use at your own risk" routines. It's meant to be an internal undocumented routine, but there is some information about it on the Typesetting help page, as it can be useful to users in some cases.

If you are not restricted to generating all parts of the plot programmatically and can adjust it interactively, then the easiest way to get the desired title is to edit the title in place using the context menu.

Paulina Chin
Maplesoft

Even though 'filledregions' can indeed be shortened to 'filled', it's better to use 'filledregions' in Doug's example . In Maple 11, we added the 'filledregions' option to reduce confusion about the 'filled' option. Before that time, 'filled' was used to mean both "fill to the x-axis in the 2-d case or fill to the x-y plane in the 3-d case" and "fill the region defined by the curve".  In most situations, the choice was clear from the context, but there were a few ambiguous cases. So we now use 'filled' to mean "fill to the x-axis or x-y plane" and 'filledergions' for the other meaning. However, the impliciplot and contourplot routines still accept 'filled' for backward compatibility, and this is interpreted in the same way as 'filledregions'.

I don't understand completely the original poster's question about filling in 3-d spaces, but I will mention that Maple does not have the equivalent of 'filledregions' for 3-d plotting. The only exception is for commands like contourplot3d where you're still colouring a surface rather than filling in a volume.

Paulina Chin
Maplesoft

The reason Robert's example fails, as acer has noted, is that the Optimization[Maximize] command gets confused by the dummy variable. For this reason, we added the 'variables' option (in Maple 11, if I recall correctly) to deal with the problem. Maximize(g, x=0..2, variables=[x]) should work. The operator form that acer showed also works, as there is no ambiguity about the optimization variables in this case.

I'll also add my thoughts about plotting versus optimization. One very simple way to optimize is to choose some points in the region of interest, sample the objective function at those points and then select the maximum or minimum. That's essentially what you're doing when you use the plot command. The problem with this approach is that you can easily miss the optimum if you choose too few sample points, but you do wasteful computation if you choose too many points. As David pointed out earlier, you have to hope that your plot's sample points hits the actual optimal point.

Most routines in the Optimization package try to do better than the basic approach by using derivative information. These routines necessarily assume the functions are smooth and they find only one local optimum point. (An exception is method=branchandbound, which finds a global solution to unconstrained univariate problems). So it is not generally true that if one can plot numerically, one can also optimize numerically, at least not with these particular solvers.

On the other hand, if you don't have smooth objective and constraint functions, you can use the GlobalOptimization package, which has looser requirements. The routines do require continuity of the objective, but the package often "works well" when even that is not met, though there are no guarantees of success.

Now, having said all this, I'll also add that it's fine to plot a univariate function to locate its maximum, if the function is inexpensive to evaluate and you don't need great accuracy. The method you choose depends on your needs.

Paulina Chin
Maplesoft

The CurveFitting[Spline] routine needs its second argument to be of type name or numeric, but type(h(t), name) is false, as h(t) actually has type 'function' in Maple. A possible workaround is to call BasinArea with a name and then do a substitution, as in subs(v=h(t), BasinArea(v)).

Paulina Chin
Maplesoft

For the differential equation, you'll want to use the numeric routines again. Try looking at the dsolve/numeric help page. There are examples showing how you can use operator form. "Operator form" refers to input that's in the form of a procedure rather than an expression, and this is the form used in the evalf(Int(Q, 0..,1)) call.

Paulina

I believe your example will work if you use evalf(Int(Q, 0..1)).  You can look at the evalf/Int (Numerical Integration) help page for more examples.

Paulina Chin
Maplesoft

I'll try to explain the differences between Standard and Classic without getting overly technical. Users just interested in using the log plotting commands without knowing about the underlying structures can ignore this.

In Maple 11, we introduced the new 'axis' option to allow better control of the axes, but this is available only for the Standard interface. The 'axis' option has a 'mode' option that allows one to specify a log axis. The log axis is created by the GUI renderer based on the data sent to it from the math library routines.

We'd updated the log plotting commands to use the new way of creating a log axis. The problem with the sampling was simply an oversight that occurred when the code was being updated, and we corrected this in Maple 12.

Unfortunately, because Classic interface does not support the new 'axis' option, it still uses the older log plotting code. The results (apart from the sampling in Maple 11) are not ideal. The older log plotting code created the axis and its associated labels in the math library routines, which meant that the result had to be independent of the plotting device. This meant that a plot might have nice looking tickmarks and labels with one device but look awful with another. The heuristics used to create the labels were not particularly strong and improving them was difficult.. The current solution leads to much improved plots.

As Robert suggests, you can indeed use `plots/loglogplot` to get the older-style log plot in Standard with Maple 11. However, `plots/loglogplot` is an internal routine. We don't prevent users from calling internal routines but we do try to discourage it. We try very hard to maintain backward compatibility for all documented routines, but we can't guarantee that we'll never change the behaviour or calling sequence of an undocumented internal routine.

Paulina Chin
Maplesoft

As Robert had observed, there was indeed a change to the log plotting commands in Maple 12 that resulted in better sampling.  I would still encourage you to upgrade to Maple 12 as there are a number of other plotting improvements (e.g. polar axes, dual-axis plots) that you may find useful. However, there is a workaround in Maple 11. You can use the 'sample' option with the plot command to specify a list of points at which you want the function sampled. If you want only those points sampled and no additional ones, then also add the adaptive=false option. These options are described on the plot/options help page.

Paulina Chin
Maplesoft

To remove the legend, use the 'functionoption' option with the ApproximateInt command, eg., functionoptions=[legend=""].

Doug pointed to the root of the problem in his response. The 'legend' option cannot be passed to plots[display], which is used by ApproximateInt to build the plot. This is by design.  Perhaps the option name 'legend' is a little misleading. One should think of it as providing a legend entry rather than the legend itself. The option is associated with a single curve, polygon or set of points, and not with the entire plot. In the Student routines, one usually needs to add the 'legend' option to the 'functionoptions' list, because the legend is associated with the given function.

To address Doug's complaint, the plots[display] command does not accept the 'legend' option because, in the general case, it does not know how many plot objects there are and how to associate the legend entries to them. For example, a single "function" built by one of the Student routines might contain several pieces, including curves and points. Also, order is not always preserved when several plots are combined. So currently, plots[display] cannot handle legend entries, and such entries must be provided in the commands that are used to build the individual plot components combined by plots[display]. As David mentioned earlier, there is an interactive way to update the legend entries after the final plot is built. Improving the plots[display] command so that it can process the 'legend' option, at least for the more straightforward cases, is certainly something we would consider for future work.

Paulina Chin
Maplesoft

You can put two plots side-by-side or one on top of the other by using an Array. For example:
> plots[display](Array([plot(...), plot(...)]));
The plots[display] help page gives more information about this feature and includes a few examples.

Paulina Chin
Maplesoft

The solver in the Global Optimization Toolbox is most certainly dependent on the search ranges, and this applies to all the methods available. The local optimization solvers in the Optimization package generally start from an initial point and use derivative information to search for a local minimum from that point. However, the global solvers partition the search space specified by the ranges, and so providing different ranges can give different results.

Keep in mind the limitations of a global optimization solver based on numerical methods. It's easy to think that the solver should return the true optimal solution, but in reality, the solver returns the best solution achieved before the stopping criteria are met. The stopping criteria include such things as an optimality tolerance and a computational time limit. Changing the ranges will change how the search proceeds and possibly which stopping criteria are met.

Also note that the methods used by the GlobalOptimization solver do make some continuity assumptions. Most of the time, the solver returns a reasonable answer even if these assumptions are not met, but there's no guarantee the true optimum will be found.

The GlobalOptimization/Computation help page should give more details about these matters. You could try setting infolevel[GlobalOptimization] to a value greater than 1 to view more information about the stopping criteria used during the computation.

Paulina Chin
Maplesoft

Use of the 'optimize' option, with or without the additional 'tryhard' option, is not essential. It's up to you to decide whether it's worth the effort to do the optimization and that depends on what sort of code is produced and how you plan to use it. As mentioned on the codegen/optimize page, the 'tryhard' option does use a different algorithm and consumes more time and memory. Most people who need to optimize their code experiment with the different options, but it is definitely not essential and, as Axel points out, the compilers will optimize as well.

To answer the "codegen vs. CodeGeneration" question, please note that the codegen package is not deprecated. Only two routines, codegen[C] and codegen[fortran], are deprecated and replaced by the newer versions in the CodeGeneration package. The other routines are still in use; however, not all have support for newer language features in Maple (e.g. modules).

Paulina Chin
Maplesoft

This looks like a bug in plots[polygonplot] which I'll record in our database. Until this is fixed, you can use the plottools[polygon] command as a workaround. This command takes similar arguments, but it creates a single POLYGONS structure rather than a plot. You'll have to call plots[display] to create the plot itself, but you can display several polygons at once. Here's an example:

> with(plottools);
> p1 := polygon([[1, 0], [2, 2], [1, 1]], color = "Blue", legend = "a triangle");
> p2 := polygon([[3, 3], [3, 2], [2, 3]], color = "Green", legend = "another triangle");
> plots[display](p1, p2);

Paulina Chin
Maplesoft

Joe writes, "A good question elicits good responses, and is just as valuable." I find that almost all questions are valuable, including frequently asked questions and ones from novice users. They often help developers figure out what's confusing, complex, easily misunderstood, or poorly documented in Maple. If a question arises often enough, especially from users who'd already made a serious attempt to understand the issue, it makes us think about whether the user interface or documentation can be improved. So, Brian, rest assured that your post is worthy of a MaplePrimes point.

Paulina Chin
Maplesoft