@Carl Love Oh I did. As well as excallgraph(). The latter actually seems to give a bit more info; however, I haven't yet fully figured out the relationship of the reported times between the two as they differ.

That is when I found many of my routines missing. So I checked the file; and they are not in there as well so clearly these do not get recorded in the first place. I don't know yet whether they go into a common bucket ( like "unknown" or some-such) or whether they get completely ignored. exprofile() suggests the latter; but excallgraph() reports a total time that is closer to the truth (if I interpret the table right) and therefore these times should be accounted for somewhere.

Anyway, the ex... routines together with setting the kernelopts may be a bit more straightforward than the CodeTools:-Profile routines. Thanks much for that hint.

Mac Dude.

@Carl Love 

Ok, this actially works...sort of. The generated routines are, however, nowhere to be found. In fact; scanning through the file generated by kernelopts(profile=true); the generated routines do not show up there.

So I guess Maple lacks a mechanism to profile code that includes such routines... :-(.

Thanks anyway for the suggestion.

M.D.

@tomleslie Instead of looping and rejecting I would use the following:

s:=Sample(X,20,method=[envelope,range=rnge[1]..rnge[2]]);

s becomes a row Vector of random numbers generated within the range. Sample is very efficient in generating Vectors of random numbers all at once; much less so when it is called repeatedly. The Help file on Statistics:-Sample and its associated routines is well worth reading to understand what is possible and effficient.

There are pitfalls, however. one is if the distribution function is not differentiable, in which case this approach fails. Another one has to do with inflection points and is relatively subtle.

M.D.

You mention several possible commands/packages in Maple that may be helpful. Why don't you read up on these in the Maple documentation and the Help facility. There are examples in there that should guide you along.

Then, post a specific question or problem with your (unsuccessful) attempt at solving it, and I am quite sure you will get helpful hints and answers.

But as you posed it: what do you expect people to do? fsolve? (maybe). RootFinding? (maybe). solve? (maybe). what? (hmm, not so sure).

M.D.

@Thomas Richard Just to be clear: Maple does not have the X11 drivers in the OS X version (unless maple 2015 is different). Reviewing my earlier reply, i do not see where I threw OS X into the mix... my (X)terminal phrase simply referred to running in a terminal emulator under X11. My apology if that was unclear.

Having said that: it always struck me as strange that X11 was not in OS X Maple... would lend it much appreciated additional power like being able to run it on my office Mac from home... (no, I cannot run VNC or its derivatives due to security concerns).

M.D.

@Prashanth Ok, I am afraid what you are trying to do is different from my use of Maple. I would probably try something like writing out the data from your Java program in a suitable form and then fire off a Maple routine using the Maple GUI. That routine would read and plot what you want and give you the interactive features. While I haven't actually tried such a thing I am fairly convinced it can be done.

If it is just getting plots, I'd use something like gnuplot.

M.D.

@Markiyan Hirnyk

Dear Markiyan, it seems like you may not have read Venkat's comment in full. He is exactly making the point that "There is a place for non-gradient approaches" but that he often sees them used in cases simple enough to not need them. I can find no fault in that statement, whether or not you like and/or use DirectSearch or any other package like that.

Whether any of these constitute true global optimizers I am not qualified to judge (and I do not say that DirectSearch claims to be that). However, as most of us know, global optimization in general is very hard, so any claim of a true global optimization technique should probably be met with some skepticism.

Myself, I have found that Maple's procedures actually go fairly far when used with some diligence and guidance and proper conditioning of the problem.

M.D.

@amrramadaneg Unless and until you upload an actual worksheet no one can tell for sure; but it seems like you are trying to assign matrix elements in a direct way, maybe using the palettes? I'd suggest you use the Matrix constructor (find Matrix in help for info how to do this). The ? in red boxes are most likely non-printable characters or similar that Maple does not understand. Also note that the error message appears to be truncated: usually there would be an explanation, however cryptic, as to what Maple does not like. At least on Mac OS X the GUI has a bug so that the message sometimes is obscured; select it and the rest will come into view.

HTH,

M.D.

@Carl Love Thanks very much for still looking into this. I have been on travel for the last several days so have not been able to do anything more on this.

At the root of my problem are the bugs in the plotting routines that manifest themselves in ignoring the "axis=[mode=...]" option when using plots:-display after plots:-setoptions() has been used. With help from MaplePrimes I am finally able to list routines like plots:-display and others, but of course they are not particularly well commented---and the problem almost certainly lies much deeper than in this particular routine---so it'll be a major job to finding out what is wrong. Maplesoft support confirmed the problem (which is there in Maple 15, absent in  Maple 16 and returned in Maple 17). Incidentally, I am on OS X, so no Classic Interface for me.

I have not fully explored what happens when I completely avoid plots:-setoptions(). It is in my .mapleinit file so avoiding it is a bit of a nuisance as in most cases I need it. Unfortunately I need to use plots:-display to plot the amplitude and phase in an array; else the horiz. axes are not lining up which really, then, is not a Bode diagram anymore.

Again, thanks much for any help you can give me. But I also understand that we all have day jobs...

M.D.

I have a hard time understanding what it is you want to achieve. First, you define the function with an argumernt x, that you then do not use. I assume that is a typo and you mean to say f:=(z) -> ...  If you want to generate points equidistant in f(z); I would suggest you invert the function (solve will do that, RTFM) and then generate values of z for a list of values for f(z). If you want to generate f(z) for a sequence of non-equally spaced values for z, you can assign your desired values for z to the elements of a list and the write

for z in zlist do ... end do;

with zlist being

zlist:=[z1,z2,..,zn];

and the z1,z2, etc. being any value you choose.

Hope this helps,

Mac Dude

@Carl Love Just to add a caveat (likely not directly applicable to the OP's issue): When you set UseHardwareFloats to true (as opposed to deduced or false) then the digits specifier in evalf does not seem to apply, at least not universally. I once banged my head against the wall for quite some time on this as I set this in my .mapleinit file and then found that evalf[40] would not do what I expected, i.e. it only gave me 15 digits worth of numbers.

M.D.

Someone constructs an ill-conditioned situation and then uses it to prove that a certain package has limitations. To me this sounds a bit like the Maple-Mma comparisons that are occasionally pilfered on the web in order to demonstrate the superiority of one over the other.

In this case, I do not believe the example says much about the quality of DirectSearch, or the other tools in Maple. If faced with an exponent of 100 in a real situation I would not even dream of using any package in a direct straightforward application. Axel gets my vote here: first bring your problem into a form amenable to a solution. If that is not possible, you are likely up to no good in the sense that the underlying problem may just be too ill-conditioned to be amenable to a solution. And granted, I see this from a physicists perspective, meaning that in my world there would usually be some underlying physics or engineering problem. If the problem is ill-conditioned, likely any solution would not be very stable in practice.

Personally, I prefer to use Maple's build-in facilities (solve and fsolve for solution, the various fiting modules for linear and nonlinear fits). Do they have limitations: you bet they do. Can one work around those: in a surprising number of cases: yes. What do I do if Maple's modules do not succeed: I go back to my problem reviewing what I am actually trying to do here. I have dabbled with DirectSearch but not seriously used it, but in the cases where I tried it its results were not out of line with the ones I found using Maple's modules. In that sense I don't think DirectSearch is any worse; and I can believe that it will solve problems that Maple's modules have a hard time with.

But finding roots involving powers of 100 using numerical methods... well, I have a hard time with that no matter what they are called and who programmed them. And it certainly does not disqualify a software routine if it can't do that without a lot of hand-holding.

Just my $0.02

M.D.

@Carl Love I tried your logarithmic plotting application. Getting it to load (in Maple 15 in this case) seemed easy enough; but I run into trouble when running logplots.mws: The first example produces no error but also no output (the linear plot works but Logplot( ) produces nothing); the 2nd example produces an error:

Error:Error creating plot:nullPlot Internal Error:unrecognised option Dag in Plot.

That unrecognized option Dag shows up repeatedly for the other examples.

If you can check this and a fix is possible with reasonable effort I would appreciate your looking into it. At the same time I understand that fixing this may require too much effort...

Many thanks,

M.D.

@tomleslie Right. Doing that... and running into the old bug in plots:-display that affects Maple 15 and Maple 17, the two I am using most of the time: Once you use plots:-setoptions() (which I have in my .mapleinit to set things like gridlines and axis label fonts), axis[n]=[mode=log] no longer works right. So I cannot get the plots to be log-log for the amplitude and log-lin for the phase.

I tried to list plots:-display with interface(verboseproc=2); but I only get this:

and I cannot list plots/display. Listing "plots" in this way just gives me the list of exports but not the actual members of "plots". My idea was to see if by any chance I could make a custom version of plots:-display that works itself around the issue with log scales. The bug was confirmed by Maplesoft support (probably 2 years ago) and it may be fixed in Maple 2015 (and even Maple 18) but at present none of my machines can run higher than Maple 17 (and no, I will not or cannot upgrade to OSX beyond 10.6.8). I am a bit hesitant to try overwriting the plots:-display package (e.g. using the one from Maple 16 that does not show the bug) until I have at least some understanding what is going on under the hood, since I do not want to kill my Maple installation(s).

Anyone knows how I can inspect plots:-display?

M.D.

@Carl Love @tomleslie

Yes, the DynamicSystems package would require me to recode the whole simulation (which is what produces my data). That may be of advantage eventually, but the whole model I have is suffuciciently complicated that such a recoding would be by no means a trivial task.

But I did investigate the arrayplot in some more detail and it turns out it is useful in that it allows me at least to get the X axes to line up. It is not really what I want it to be, but it gets closer than what I have been using so far, so there is some progress. I played around with plots:-dualaxisplot and so far did not like the results, but there is probably more I can try with it. I also looked at the plot structures documentation but I do not quite see how I can program these to produce a plot closer to my liking. Maybe this is a little beyond what Maple can deliver right now, as far as plotting is concerned...

Thanks much for looking into this,

M.D.