@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...)

@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...)

I forgot to mention, above, that you could compare the relative performance between either of,

n := 10^5: # or higher

L := RandomTools:-Generate(list(integer(range=-100..100),n)):

f:=RandomTools:-Generate(integer(range=-100..100),makeproc=true):
L := [seq(f(),i=1..n)]:

and,

n := 10^5: # or higher

V := LinearAlgebra:-RandomVector(n,generator=-100..100):
L := convert(V,list):

Using `if` as condition inside the `seq` constructor (especially with NULL as the fallback value) is a must-know technique, I agree.

And it's easy enough to compare performance of a few appoaches. Sometimes the charge can be levied at Maple (quite fairly) that it is more difficult to use because there are lots of ways to do a given task and the most efficient way is often not the most obvious. But I believe that in this case some of the performance differences can be ascribed to particular qualities of the approaches.

The 6 ways below are all repeated over again, at the end, so as to show that the timings aren't due to the order in which they are tried in the very same session.

Method C) is one of the three fast ways (almost identically quick -- the difference between them seems to vary less that does the difference they show individually when tried repeatedly in several new sessions). And method C) is the only one of the 6 shown which does not involving creating a new list as a temporary (collectible garbage) object.

The worst performer is F), which uses `is`, and that's no surprise. The `is` command is like an umbrella covering many approaches. Using it to accomplish what could be done with just some `evalb` arithmetic comparison is overkill. It's a bit like using `simplify` when you know that `nomal` covers the given expression type.

The difference between B) and D) is conceptually quite like the difference between A) and E), The D) and E) approaches both use some custom "user-defined" operator, wrapped around a builtin arithmetic comparison, which gets called for each entry test. That costs quite a bit more than does testing with just the builtin entry-wise comparison. The moral here is that it you're going to use `select` then always spend a moment wondering whether there is a (possibly creative) way to get the predicate (1st argumnet) to be a fast builtin. The user-defined operators like x->.... are still relatively slower interpreted code, no matter how short and simple they are.

And the difference between A) and B) is something similar to the difference between D) and E). If Maple didn't have the `select` command then we might code as in A) to get the functionality. Note that it becomes a bigger issue when compounded by the problem of wrapping with a user-defined operator.

Download listselectorcomp1.mw

Maybe I can mention one more. It's similar in spirit to the `is` approach, using `type`. It's much quicker here than is its cousin `is`. 

CodeTools:-Usage(   nops(select( type, L, negative))   );
memory used=114.25MiB, alloc change=0 bytes, cpu time=624.00ms, real time=618.00ms
                            4974312

acer