I did not really need to use plots, in my approach using Optimization:-Maximize. If you read Carl's, Markiyan's, and my answers you can see similarities in the approaches. I'f I'm not mistaken, we all relied on using Im(objective)=0 as extra known information (eg. as constraint, or constraints plural). Carl used exact `maximize`, Markiyan used the add-on DirectSearch package, and I used the Optimization package.

The feasible set ends up being (the union of) three disjoint line segments, and the answer is the largest of the maximum for each. Not all the approaches listed had to examine those separately, or even explicitly.

Feasible sets which have measure zero (in the domain to be searched) can be hard for optimizers.

Carl got nice exact results. It might seem that his code relies of inspection of the objective, and manual extraction of the three extra conditions. But it should be simple to automate that, so I do not consider it a flaw. Note the helper proc that he wrote, though. Markiyan's answer (improving on what he might have reported as tried in his original Question) is very simple and straightforward. My approach worked harder and was most complicated, generating a set of "simple" extra constraints so as to get multiple calls to local `Maximize` over the finite collection of candidate regions. (There is obviously stuff for Optimization to learn from DirectSearch's way of handling such domains, and I accomodated an inequality->range conversion to get coverage of all the feasible domain.)

acer

I did not really need to use plots, in my approach using Optimization:-Maximize. If you read Carl's, Markiyan's, and my answers you can see similarities in the approaches. I'f I'm not mistaken, we all relied on using Im(objective)=0 as extra known information (eg. as constraint, or constraints plural). Carl used exact `maximize`, Markiyan used the add-on DirectSearch package, and I used the Optimization package.

The feasible set ends up being (the union of) three disjoint line segments, and the answer is the largest of the maximum for each. Not all the approaches listed had to examine those separately, or even explicitly.

Feasible sets which have measure zero (in the domain to be searched) can be hard for optimizers.

Carl got nice exact results. It might seem that his code relies of inspection of the objective, and manual extraction of the three extra conditions. But it should be simple to automate that, so I do not consider it a flaw. Note the helper proc that he wrote, though. Markiyan's answer (improving on what he might have reported as tried in his original Question) is very simple and straightforward. My approach worked harder and was most complicated, generating a set of "simple" extra constraints so as to get multiple calls to local `Maximize` over the finite collection of candidate regions. (There is obviously stuff for Optimization to learn from DirectSearch's way of handling such domains, and I accomodated an inequality->range conversion to get coverage of all the feasible domain.)

acer

@PatrickT 

Is this of any help?

> restart:

> eq := x = 11/500+6*u*(1/25)-u^2
>           +(-174200000000*x^5+13045131*E^4*u^4)^(3/5)/(65225655*E^4*u^4): 

> subsindets(eq,`^`,convert,surd):

> lprint(%);

x = 11/500+(6/25)*u-u^2+(1/65225655)*surd(-174200000000*x^5+13045131*E^4*u^4, 5)^3/(E^4*u^4)

@PatrickT 

Is this of any help?

> restart:

> eq := x = 11/500+6*u*(1/25)-u^2
>           +(-174200000000*x^5+13045131*E^4*u^4)^(3/5)/(65225655*E^4*u^4): 

> subsindets(eq,`^`,convert,surd):

> lprint(%);

x = 11/500+(6/25)*u-u^2+(1/65225655)*surd(-174200000000*x^5+13045131*E^4*u^4, 5)^3/(E^4*u^4)

One could address the question, "For which naturals is the number of divisors odd?"

A divisor is always matched by a corresponding quotient, and those are equal for the case of the square root of a perfect square. So there is only ever an "odd man out" for a perfect square.

If I understood the posed question, then the ith coin is flipped at the jth iteration, where j is any divisor of i (except 1, as you started by skipping 2). So you need to find out whether the number of divisors of i is odd or even, in order to figure out whether it stays as H or becomes a T.

acer

One could address the question, "For which naturals is the number of divisors odd?"

A divisor is always matched by a corresponding quotient, and those are equal for the case of the square root of a perfect square. So there is only ever an "odd man out" for a perfect square.

If I understood the posed question, then the ith coin is flipped at the jth iteration, where j is any divisor of i (except 1, as you started by skipping 2). So you need to find out whether the number of divisors of i is odd or even, in order to figure out whether it stays as H or becomes a T.

acer

@Christopher2222 I see, you were considering the plotting of structures emited as the result of calls to the `smartplot3d` command. You seem to be asking for live regeneration of the 3D plot, when that is panned. Thanks for explaining.

My point 3 was to do with the PlotComponent (embedded component) and the menubar's orientation toggles. In particular, it is already possible to programatically specify orientation when calling 3D plotting commands. It's also already possible to alter a PLOT3D data structure with a different ORIENTATION() call within it (by using `subs`, which creates a new structure). The new structure has to be passed from kernel to GUI as data. I want to be able to sidestep all that overhead, and to programatically control the GUI's own controls which manage the rotational view of the whole plot image. I want to be able to access those rotation controls of the GUI, without generating and passing new plot datastructures. And having such programatic control by means of properties of a containing PlotComponent seems like a natural way to do it. Something similar to all the PlotComponent properties for controlling an animation.

Here's where functionality related to point 3 (if not 3 itself) gets tricky: some people have suggested (here on Mapleprimes, I think..., but perhaps elsewhere) that adjusting (via right-click menus) a plot as stored in the GUI should be followed by a means to access the an equivalent modified plot data structure. Eg. first change the line or surface style, etc, and then somehow have the GUI pass back a modifed plot data structure (possibly only accessible as some potentially new property of a containing PlotComponent) to the kernel and thence to the user. I hope that it never gets implemented only like that. I would rather hope for an entirely new kind of data structrure for plots (ie. a Record, or object?) which is properly mutable, as a replacement to the current function-call structure. That's a huge task. I'm hoping for smaller, more realistic improvements.

@Christopher2222 Could you please explain how your idea of "Live 3d plot panning" differs from using "pan" as the mouse-cursor manipulator of a 3D plot?

Could you also please explain in detail what you meant by more "user programmable properties"? Is this "Live" panning one of those programmable things? If not, then what did you have in mind?

I apologize if I did not spell it out before, when I posted this: could you please refrain from general discussion on "wish lists" in the comments to this post?

If you would like to add concrete and particular detailed suggestions then please do so. But please put general comments in some other thread. It's very much not what I was hoping for here (even as a mixture, alongside particular concrete suggestions).

Thank you for your consideration,

acer

restart:
f:=-8.7754e-19*(1/(3590-t)^(1/4)):
plot([f,-f],t=2600..3600,filled=true,color=red,view=-6e-19..6e-19);

acer

restart:
f:=-8.7754e-19*(1/(3590-t)^(1/4)):
plot([f,-f],t=2600..3600,filled=true,color=red,view=-6e-19..6e-19);

acer

@pkassar Ok, so it looks as if `sM` is a local member of the module `MarriagePack`. Hence you might examine its contents with either,

  showstat(MarriagePack::sM);

or,

  interface(verboseproc=3):
  kernelopts(opaquemodules=false):

  eval(MarriagePack:-sM);

@pkassar Ok, so it looks as if `sM` is a local member of the module `MarriagePack`. Hence you might examine its contents with either,

  showstat(MarriagePack::sM);

or,

  interface(verboseproc=3):
  kernelopts(opaquemodules=false):

  eval(MarriagePack:-sM);

@Joe Riel Thanks for the suggestion, Joe, and I certainly do have other applications where I'd want to make use of that.

But for this fractal thing I have mixed purposes. The implementation allows one to generate a high resolution image (higher than is actually distinguishable in what is displayed on the label in the worksheet), and that is offered so that someone can easily copy the image file aside and retain it. If I put in a smart temp directory then I guess I'd have to also put in extra mechanisms to allow one to get at and copy the image file.

ps. I suspect that there might possible be some savings to be had in applying the formulae which control the colors. Since the Sliders affect only one color at a time then it might be possible to just treat the layer being changed. This might also relate to whether a particular color layer could be walked quickly in a fashion that minimizes cache misses (according to whether entries are continguous, etc). I haven't looked into this yet.

I made some modifications to this, and if anyone want to give some feedback it'd be welcome.

Download fastJuliabreakpoint.mw

One fun way to play with it is to set it as color Julia set with a custom scene and then drag the mouse cursor around the small plot entitled "Zc selector". If the resolution is set to 200 or 400 then the image should try and get updated continuously as the Zc point gets dragged around. (How smoothly it accomplished this depends on your computer's speed, of course.)

I've been staring at it too long, and it's hard now for me to see what bits are of more or less value.

From my point of view, what's left "to do" in to complete the functionality of the zoom window (it doesn't work yet), and to place a simple plot of the Mandelbrot set on the "Zc selector" Plot Component. The idea of the latter is that interesting things happen in the family of Julia sets as the "Zc" point travels in/out/around the Mandelbrot set.

The things I now question are:

• Since the realtime file i/o can be a major portion of the processing time then who really cares to see/configure whether it's using evalhf or the Compiler? I could just make a seperate post on using the Threads Task model on such embarassingly parallelizable jobs, and suppress all that clutter in the applet, no? Why not have the applet autoconfigure itself to the fastest thing it detects as possible?
• Should the "cut-off" and "maxiter" be sliders instead of a value changed in a TextBox?
• If the Zoom thing were fixed, then who really needs TextBox's to alter the end-points of the field of view? TextBox's are horrible for use as entry-boxes anyway, since hitting the Enter/Return key adds a new line rather than fires off the "Context Changed Action" code.
• Would it be nicer to save a ton of real estate and combine all the Sliders into just one Slider which changed its nature entirely according to a dropdown menu (ComboBox).

acer