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

The combination of `print/...` and inert operators has been used in other related questions on this site, and while more work than ``() to set up and use it is more satisfying.

The fact that expand does too much can sometimes be controlled by frontend (true, say for the example cited), but in general that's even more finicky work to get right for different examples.

If the Asker just wants a quick and workable result for the given simple example then great, he now has several alternatives.

acer

The combination of `print/...` and inert operators has been used in other related questions on this site, and while more work than ``() to set up and use it is more satisfying.

The fact that expand does too much can sometimes be controlled by frontend (true, say for the example cited), but in general that's even more finicky work to get right for different examples.

If the Asker just wants a quick and workable result for the given simple example then great, he now has several alternatives.

acer

The URL to the worksheet is not working for me. Maybe try uploading again (different filename would be necessary), in a Comment to your Question?

acer

@slizovskiy This looks challenging. I've got a lot going on at work, and likely won't be able to dig into this soon. Feel free to send me a contact message if a week goes by and nobody's figured out an improvement.

@slizovskiy This looks challenging. I've got a lot going on at work, and likely won't be able to dig into this soon. Feel free to send me a contact message if a week goes by and nobody's figured out an improvement.

@Markiyan Hirnyk Yes, I had seen that. The points I was trying to make were that 1) Optimization:-Minimize can obtain a result (you had a little usage difficulty, that I wanted to quickly clear up), but that 2) use of a global method is preferred for the given task.

@Markiyan Hirnyk Yes, I had seen that. The points I was trying to make were that 1) Optimization:-Minimize can obtain a result (you had a little usage difficulty, that I wanted to quickly clear up), but that 2) use of a global method is preferred for the given task.

restart:

A := Matrix(3, 3, [5*a-4, 5*sqrt(a)*sqrt(b)-5, 7*sqrt(a)*sqrt(c)-6,
                   8*sqrt(a)*sqrt(b)-5, 8*b-2, 8*sqrt(b)*sqrt(c)-9,
                   4*sqrt(a)*sqrt(c)-1, 6*sqrt(b)*sqrt(c)-4, 9*c-5]):

eqs := Equate(A, Matrix(3)):

Optimization:-Minimize( add((rhs-lhs)(e)^2,e in eqs) );

    [31.1856590880747149, [a = 0.8107833782774988, 
                           b = 0.5717485896565585,
                           c = 0.7115891789684132] ]

or, more simply,

Optimization:-Minimize( add(e^2, e in A) );

    [31.1856590880747149, [a = 0.8107833782774988,
                           b = 0.5717485896565585,
                           c = 0.7115891789684132] ]

The main problem with using Optimization:-Minimize is that it's a local minimizer. If it returns something very close to zero as the optimal objective then great, one has shown that the Matrix A can be zero (up to floating-point approximation).

But if it returns a locally optimal objective value greater than zero then nothing can be concluded from that alone about whether A could become all zero, (in general, unless we can show certain things about the convexity of the problem). I mention this for other readers, of course, as I am sure that Markiyan is aware of the one-sided benefit of using a local minimizer in such a context.

restart:

A := Matrix(3, 3, [5*a-4, 5*sqrt(a)*sqrt(b)-5, 7*sqrt(a)*sqrt(c)-6,
                   8*sqrt(a)*sqrt(b)-5, 8*b-2, 8*sqrt(b)*sqrt(c)-9,
                   4*sqrt(a)*sqrt(c)-1, 6*sqrt(b)*sqrt(c)-4, 9*c-5]):

eqs := Equate(A, Matrix(3)):

Optimization:-Minimize( add((rhs-lhs)(e)^2,e in eqs) );

    [31.1856590880747149, [a = 0.8107833782774988, 
                           b = 0.5717485896565585,
                           c = 0.7115891789684132] ]

or, more simply,

Optimization:-Minimize( add(e^2, e in A) );

    [31.1856590880747149, [a = 0.8107833782774988,
                           b = 0.5717485896565585,
                           c = 0.7115891789684132] ]

The main problem with using Optimization:-Minimize is that it's a local minimizer. If it returns something very close to zero as the optimal objective then great, one has shown that the Matrix A can be zero (up to floating-point approximation).

But if it returns a locally optimal objective value greater than zero then nothing can be concluded from that alone about whether A could become all zero, (in general, unless we can show certain things about the convexity of the problem). I mention this for other readers, of course, as I am sure that Markiyan is aware of the one-sided benefit of using a local minimizer in such a context.

@Markiyan Hirnyk Thanks. I saw only that solutions arise exactly from x^2+x=x+n*2*Pi and missed that they also arise exactly from x^2+x=-x+n*2*Pi. (I guess that I really did need a computer algebra system, to make the key step...)