For a few releases now `.` is automatically in `libname`.

I think that is quite risky, especially for those in the habit of writing out .m files (also dubious, IMHO).

So perhaps you could strip that solitary `.` from `libname` in your initialisation file. Either of these might do, I suppose,

libname:=remove(type,[libname],identical("."))[];

libname:=remove(`=`,[libname],".")[];

acer

Let me know if I got the shift bookkeeping wrong.

For your 184x184 image pair there are 184^2/2 possible shifts of the 1D Array in each direction (well, there is also the zero-shift...). This below takes about 35sec for all 184^2+1 possible shifts & adds, running Compiled. But it should be possible in Maple 18 to run that Threaded as well, with a bit more bookkeeping effort.

Running Compiled serially is faster than running 4-way parallelized evalhf for this code, I believe. But running the Compiled version in parallel and getting a few more factors of 2 out of it might be nice.

Anyway... let me know if I got it all wrong. Do you have the solution image already, to compare with?

[update: I used C[SBest] when I should have used just SBest in the final call to CircularShift. And padding either image with zeroes seems wrong for this shifting & abs-differencing scheme, so I have changed that to simple rescaling. I've updated the inlined content and attached worksheet and the final result looks much more sensible now.]

Download circshift5.mw

acer

Which version of Maple did you create the worksheet in? Which version of the Player do you use? I don't think that the "18" version of the Player has been made available yet, has it?

I was able to use the exploration if I created it in Maple 17 and then ran it in "Maple Player 17" (seen from the About menubar item in the Player).

But in order to get it to run properly, even with the versions matching (ie. version 17 for both creation and player) I had to put the assignment fn:=x^2; into the Startup Region of the document. That makes sense to me, since the Player does not run or execute all the contents of an opened sheet. But it does run the Startup Region's code if present. Your plot exploration depends upon `fn` being defined as an expression in terms of `x`. (This is an important aspect of the Player, and is not just related to Explore per se. If the action code behind any embedded components require some previous assignments then those could be executed in the Startup Region.)

By the way, the edited exploration that I got to run in Maple 17 and the Maple 17 Player also worked for me if I opened it in Maple 18. That is evidence of some degree of backwards compatibility.

But forwards compatibility is another story. Often when trying to open in Maple's GUI some document created in a later version there will be a warning about some features possibly not working.

Another observation, which I hope won't confuse the items above: The examples in the ?examples,Explore sheet don't make much if any use of names which have been assigned symbolic expresssions. The first argument to Explore has special evaluation rules (which seems to me to have been an early design mistake). I believe that there are cases where such chained symbolic assignments will not get adequately evaluated and resolved to be interpreted in terms of the names one might expect. It seems ok in this example but in general I would suggest instead either making the expression fully explicit in the actual call or use a function call. Eg,

Explore( plot(a*x^2,x=-2..2,view=-10..10),parameters=[a=1..5.0]);

or,

fn:=x^2:
f:=a->plot(a*fn,x=-2..2,view=-10..10):
Explore(f(a),parameters=[a=1..5.0]);

or,

f:=a->plot(a*x^2,x=-2..2,view=-10..10):
Explore(f(a),parameters=[a=1..5.0]);

or, (and the expert may recognize this as a heavy-handed way around the special evaluation rules, because `Explore` isn't as, umm, "convenient" as `plots:-animate` or `frontend`),

restart:
fn:=x^2;
eval('Explore'( 'plot'(a*fn,x=-2..2,view=-10..10),parameters=[a=1..5.0]));

acer

How about this, which takes about 20sec to compute all 100 frames in my Maple 17. This forces numerical integration only, with an accuracy target appropriate for plotting, and a method for oscillatory functions.

restart:
with(plots):

z := 2*Int((sin(2*y)-sin(y))*cos(y*x)*exp(-y^2*t)/y, y=0 .. 200,
            epsilon=1e-3, method=_d01akc)/Pi:

animate(plot, [z, x=0 .. 10], t = 0.01..1, frames = 100);

acer

How about,

g:=readstat();

When it runs I can just type 45 and hit the Enter key, when the popup box appears.  It also seems to work if I have hit the menubar's triple-exclamation icon, ie. the whole sheet continues to execute.

acer

You may have forgotten to load the `plots` package before calling `display`. You can also call is as,

plots:-display( ... )

acer

Maple 18.00 is build id 922027.

That is the value shown on the main menubar via Help->About Maple. It is also given by issuing the commands,

  kernelopts(version);

  version();

acer

Using Maple 17.02 on 64bit Windows 7,

restart;
g:=0.88641:
e:=2.53128:
eq:=tan(g)= e*sin(f)/(1+e*cos(f)):

fsolve(eq,f);
                          1.197496352

fsolve(eq,f,avoid={f=%});
                          -2.566269006

acer

restart:

with(Physics,diff);
                             [diff]

diff(y(x)^2,y(x));
                             2 y(x)

restart:

use diff=Physics:-diff in
  diff(y(x)^2,y(x));
end use;
                             2 y(x)

restart:

Physics:-diff(y(x)^2,y(x));
                             2 y(x)

acer

Hopefully the Online Help will be updated soon, so that the new links similar to this (and in its side panel) will be available,

http://www.maplesoft.com/support/help/Maple/view.aspx?path=updates/Maple17/index

acer

restart:

F:=proc(x) local y;
     y:=sprintf("%a",op(1,x));
     [seq(parse(y[i]),i=1..length(y))];
end proc:

F(0.567);
                           [5, 6, 7]

x:=evalf[100000](5555/7):

CodeTools:-Usage( F(x) ):
memory used=210.69MiB, alloc change=0 bytes, cpu time=765.00ms, real time=762.00ms

For reasons I don't fully understand, above approximately 10^5 or 10^6 digits it seems that garbage collection dominates the computation and the timing grows worse than linearly w.r.t. digits. This seems to affect both Carl's original approach and mine. I'm not sure where the culprit is, but I suspect the very many calls to builtin `parse`. I got no better with sscanf.

acer

The procedure that produces the list from the set has to be told how high it should check, no?

restart:                                          

m:=LL->{seq(`if`(LL[i]=1,i,NULL),i=1..nops(LL))}: 

unm:=(SS,k)->[seq(`if`(member(i,SS),1,0),i=1..k)]:

L:=[1,0,1,1,0,0]:                                 

S:=m(L);                                          

                                S := {1, 3, 4}

unm(S,nops(L));                                   

                              [1, 0, 1, 1, 0, 0]

acer

I don't know if there is a way to truly clear the 'value' of an already inserted PlotComponent.

I usually just code something to make the component's 'value' be something effectively close to an empty plot, using the `plot` command and without having to build a PLOT structure manually.

Eg, if the identity of the PlotComponent is "Plot0",

  DocumentTools:-SetProperty("Plot0",':-value',plot([[undefined,undefined]],':-axes'=':-none'));

So try that as the Action code behind your "Clear" Button.

acer

It's not very difficult to find two real roots of the system using `fsolve` if eq[1] is first solved for `a` and then substituted into eq[2], or if some special range for variable x is supplied.

restart:
f := x*exp((1 - x)*a):
f[2] := subs(x=f,f):
eq[1] := f[2] - x:
eq[2] := diff(f[2],x) + 1:
eq[4] := a=solve(eq[1],a);
                               /  x - 2\
                             ln|- -----|
                               \    x  /
                       a = - -----------
                               -1 + x   
R3 := subs( eq[4], eq[2] ):

#plot(R3, x=0..2);

rsols := [ fsolve(R3, x=0..1), fsolve(R3, x=1..2) ];
                  [0.2777041405, 1.722295859]

eval( subs(eq[4],[eq[1],eq[2]]), x=rsols[1] );
                      [     -10        -9]
                      [-5 10   , 1.9 10  ]

[x=rsols[1], eval( eq[4], x=rsols[1])];
              [x = 0.2777041405, a = 2.526467726]

[x=rsols[2], eval( eq[4], x=rsols[2])];
               [x = 1.722295859, a = 2.526467725]

Digits:=100:

rsols := [ fsolve(R3, x=0..1), fsolve(R3, x=1..2) ]:

eval( subs(eq[4],[eq[1],eq[2]]), x=rsols[1] );
                      [    -100       -99]
                      [1 10    , -1 10   ]

It is interesting that `fsolve` has difficulty solving the system unless it gets help with at least one of the ranges.

fsolve( [eq[1],eq[2]], {a,x}, x=0..1 );
              {a = 2.526467726, x = 0.2777041405}

fsolve( [eq[1],eq[2]], {a,x}, x=1..2 );
               {a = 2.526467726, x = 1.722295859}

And what is this nonsense? (Happens in M17.02 with Digits=10 but not Digits>10 it seems.)

s:=fsolve( {eq[1],eq[2]}, {a,x}, x=-3..0 );
              {a = 6.564724757, x = -2.865536950}

eval( [eq[1],eq[2]], s );
   [               856928220820                856928220833]
   [-1.472743519 10            , 2.009082419 10            ]

acer

acer