Are you saying that you don't like the choice of colors in the default palette of Maple 16?

If so, then you can change the color palette using the plots:-setcolors command, eg.

plots:-setcolors("Classic"):

See also the setcolors help-page.

restart:
plot([x,x^2,x^3,x^4,x^5,x^6,x^7,x^8,x^9],x=0..Pi);
plots:-setcolors("Classic"):
plot([x,x^2,x^3,x^4,x^5,x^6,x^7,x^8,x^9],x=0..Pi);
plots:-setcolors("oldplots"):
plot([x,x^2,x^3,x^4,x^5,x^6,x^7,x^8,x^9],x=0..Pi);
plots:-setcolors("default"):
plot([x,x^2,x^3,x^4,x^5,x^6,x^7,x^8,x^9],x=0..Pi);

acer

How about a different approach, since you're just summing terms.

G := sqrt(3)/4 + Sum( sqrt(3)/12*(2/3)^(2*n-2), n=1..N );

                      /  N                         \
                      |-----                       |
                      | \                 (2 n - 2)|
           1  (1/2)   |  )   1   (1/2) /2\         |
           - 3      + | /    -- 3      |-|         |
           4          |----- 12        \3/         |
                      \n = 1                       /

value(G);

                                        (N + 1)
                2  (1/2)   27  (1/2) /4\       
                - 3      - -- 3      |-|       
                5          80        \9/       

limit(%,N=infinity);

                            2  (1/2)
                            - 3     
                            5       

value(subs(N=infinity,G));

                            2  (1/2)
                            - 3     
                            5       

limit(G,N=infinity);

                            2  (1/2)
                            - 3     
                            5       

sqrt(3)/4 + sum( sqrt(3)/12*(2/3)^(2*n-2), n=1..infinity );

                            2  (1/2)
                            - 3     
                            5       

acer

Your worksheet specifically does great many calls to int(...,numeric=false). If these are replaced with calls to evalf(Int(...)), and if all the `assume` stuff is removed, then I see a reduction from about 2min to about 25sec. The numeric X results and the plots seem the same.

If you thought that those integrals might succeed generically (symbolically), then they'd then be better placed outside the loop. The assumptions might serve a purpose, in this case. The same goes for attempting a generic symbolic `solve` instead of using fsolve in the loop. I didn't try any of this.

Another modication is for the fsolve calls, inside the loop. The idea is to use the previous iteration's fsolve solution as a starting point for the current iterations's fsolve call, on the supposition that the roots may not have moved much (your plots are mostly smooth, and perhaps expectedly so). If this call to fsolve (with initial point supplied) fails to converge then a second call to fsolve is made, without any initial point supplied. This produces the same final results, but in about 13sec.

Apart from removing the `assume` stuff, I also removed the assignments to {hb, hbt, etc) and their unassignments. It's enough to use 2-argument `eval`, to get the results into X.

The integrands may still contain variables whose values must be obtained by scoping. I mean the refences in the integrands to assignments made even outside of your procedure. If that is the case then it would mean that fast evalhf mode cannot be used for the numeric integration solvers. It's possible that you could get more savings if the integrands were all evalhf'able. I haven't the time to confirm this now, sorry.

qn_mp_v1_modif2.mw

acer

> a := binomial(37, x-105)*.85^(142-x)*0.15^(x-105):

> Optimization:-Maximize(a, x=105..142);

       [0.18320882465623625, [x = 110.194002601565]]

acer

Notice the differences between surd, ^, and root.

(You could also try the RealDomain package. And you might enjoy this list by Robert Israel.)

Download surdystuff.mw

acer

The first argument to StringTools:-Remove should be a predicate in Maple 12. That's not the same as true or false as a result.

a := "Just try to remove a letter using Maple 12's StringTools[Remove]":

StringTools:-Remove(t->evalb(t="e"), a);

         "Just try to rmov a lttr using Mapl 12's StringTools[Rmov]"

StringTools:-SubstituteAll(a,"e","");

         "Just try to rmov a lttr using Mapl 12's StringTools[Rmov]"

StringTools:-Remove("e", a); # Maple 16

         "Just try to rmov a lttr using Mapl 12's StringTools[Rmov]"

acer

An eigenvalue L of this generalized eigenvalue problem has to satisfy this equation,

> LinearAlgebra:-Determinant(L*LinearAlgebra:-IdentityMatrix(3).G-P) =  0;

                        2
                       L  - L beta - L + beta - kappa L = 0

acer

The manual is referring to whether Maple's own tools (savelib, LibraryTools, etc) would be able to alter the library archives that are installed with the product.

There is a command in the LibraryTools package for querying or setting this aspect of a library archive file. For example,

LibraryTools:-WriteMode("c:/Program Files/Maple 14/lib/maple.mla");

          [["c:/Program Files/Maple 14/lib/maple.mla", "READONLY"]]

There are several other library archive files in that location.

If you forget to create your own personal .mla, somewhere else, and you mess up some call to the savelib or LibraryTools:-Save commands, then you might inadvertently store something in one of the installed system libraries. If the system .mla archives are all read-only then that wouldn't happen, and the mistake would just result in getting an errant .m file. An errant .m file is a great deal easier to notice or find. Imagine the scenario where you saved the value of 2 to the name `P`, and that value was picked up in any new session when you first tried to use P.

I made this mistake once, and it took a while for me to track the problem down. If I recall correctly it was because of the following, in my Maple 15. (I forget whether it was a bug, or whether I toggled it by mistake in some code of mine. I should fix it right this minute...)

LibraryTools:-WriteMode("c:/Program Files (x86)/Maple 14/toolbox/NAG/lib/Maple-NAGConnector.mla");

  ["c:/Program Files (x86)/Maple 14/toolbox/NAG/lib/Maple-NAGConnector.mla", "READONLY"]]

LibraryTools:-WriteMode("c:/Program Files (x86)/Maple 15/toolbox/NAG/lib/Maple-NAGConnector.mla");

  ["c:/Program Files (x86)/Maple 15/toolbox/NAG/lib/Maple-NAGConnector.mla", "WRITABLE"]]

The system .mla archives should all be read-only, when installed.

acer

It seems that the hang occurs in a call to `ssystem`. Is the `ssystem` command busted altogether, in this interface/installation/OS combination?

Now it's not a replacement for more general uses but it seems as if the particular use of `ssystem` inside Compiler:-Compile can also be accomplished by using `system`. (It's the step of running the external compilation command, to compile the .c file to .obj using the watcom executable.)

So, on my 64bit Windows 7 Pro (with 64bit Maple 16.01 also installed, fwiw), running the 32bit Maple 16.01 Classic GUI,

restart:

mycompile:=proc()
    local res;
    unprotect(:-ssystem);
    :-ssystem:=proc() option builtin="system"; end proc;
    try
        res:=Compiler:-Compile(args);
    finally
        :-ssystem:=proc() option builtin="ssystem"; end proc;
        protect(:-ssystem);
    end try;
    eval(res);
end proc:

p:=proc(x) sin(1.0*x); end proc:

cp:=mycompile(p):

cp(2);

                         0.909297426825681710

interface(version);

  Classic Worksheet Interface, Maple 16.01, Windows, Apr 30 2012, \
        Build ID 743496

I don't know why I bothered with the `finally` clause, since it might just be reinstating something which doesn't work.

acer

Initial commands (and results) supplied to the commandline interface (CLI) using the -c option are not echoed, I believe.

Does these produce the expected, printed 4?

maple -c "print(2+2);"

maple -c "x:=2+2;" -c "print(x);"

If that works, and is what you wanted, then great. But it's not quite clear whether you are just trying to use the CLI normally, or as a simple calculator, or...? Did you want the session to continue, after the initial commands? Or did you want to also pass -s and -c quit

acer

A:=LinearAlgebra:-RandomMatrix(10,1);

                                      [ 82]
                                      [   ]
                                      [ 72]
                                      [   ]
                                      [ 42]
                                      [   ]
                                      [ 18]
                                      [   ]
                                      [-59]
                                 A := [   ]
                                      [ 12]
                                      [   ]
                                      [-62]
                                      [   ]
                                      [-33]
                                      [   ]
                                      [-68]
                                      [   ]
                                      [-67]

rtable_scanblock( A, [rtable_dims(A)],
   (val,ind,res)->`if`(abs(val)>abs(res[2]),[ind,val],res),[[1,1],A[1,1]],
   (val,ind,res)->`if`(abs(res[2])>abs(val),[ind,val],res),[[1,1],A[1,1]]
);

                         [[1, 1], 82], [[6, 1], 12]

V:=ArrayTools:-Alias(A,[10],column):

rtable_scanblock( V, [rtable_dims(V)],
   (val,ind,res)->`if`(abs(val)>abs(res[2]),[ind,val],res),[[1],V[1]],
   (val,ind,res)->`if`(abs(res[2])>abs(val),[ind,val],res),[[1],V[1]]
);

                            [[1], 82], [[6], 12]

acer

Isn't this just the new smartview::truefalse option, introduced in Maple 16?

plot(a,t=0..23,smartview=false);

(See this Post for a discussion on this site.)

acer

This might give you some ideas. The key is to be able to integrate from left-endpoint `A` to any arbitrary point `b` inside the range `A` to `B`. You want to do rootfinding on that integral minus half the total area.

Note that in general the result may be quite sensitive to the degree of the spline approximation as well as the way of handling end-points (natural, or as not knots, or as periodic).

restart:

N := 11:
A,B := 4.3, 7.2: # end points

x:=Vector(N+1,i->A+(i-1)*(B-A)/N,datatype=float[8]):

y:=Vector(N+1,i->evalhf((i-1)*sin(2*Pi*(i-1)/N)),datatype=float[8]):
yerr:=LinearAlgebra:-RandomVector(N+1,generator=-0.01..0.01,datatype=float[8]):
y:=y+yerr:

Ppts:=plots:-pointplot(<x|y>,view=-10..10):

# method 1
interpol1:=t->CurveFitting:-ArrayInterpolation(x,y,t,method=spline):
#plots:-display( Ppts, plot(interpol1,A..B) );
areab1:=b->evalf(Int(interpol1,A..b)): # computes area from A to some point b
totalarea1:=areab1(B);

                       -5.056144579015009

totalarea1/2;

                       -2.5280722895075045

#plot(t->areab1(t)-totalarea1/2, A..B, adaptive=false, numpoints=30);
RootFinding:-NextZero(t->areab1(t)-totalarea1/2, A);

                          6.682287858
# method 2
interpol2 := unapply(CurveFitting:-Spline(<x|y>, t, degree=3), t):
#plots:-display( Ppts, plot(interpol2,A..B) );
areab2:=b->evalf(Int(interpol2,A..b)):  # computes area from A to some point b
totalarea2:=areab2(B);

                          -5.056144580

totalarea2/2;

                          -2.528072290

#plot(t->areab2(t)-totalarea2/2, A..B, adaptive=false, numpoints=30);
RootFinding:-NextZero(t->areab2(t)-totalarea2/2, A);

                          6.682287858

# method 3
Z:=int(CurveFitting:-Spline(<x|y>, t, degree=3),t):
areab3:=b->eval(Z,t=b)-eval(Z,t=A):
totalarea3:=areab3(B);

                          -5.05614437

totalarea3/2;

                          -2.528072185

RootFinding:-NextZero(t->areab3(t)-totalarea3/2, A);

                          6.682287847

acer

In the nicest way, I'd like to offer the advice that unless impractical you could strive not to write procedures which do side-effects on (name) arguments, or write to globals, etc. In the long run these will just add unnecessary confusion.

In this particular case, the most usual way to get the answer from `f` to be assigned to `result` is straightforward and simple, and can be performed multiple times without need for any special quoting, etc.

restart:

f := proc(x)
     local res;
     if x <= -7 then 
         res :=  1:
     elif x > -7 and x <= 7 then 
         res := 2:
     elif x > 7 then 
         res := 3:
     end if:
     return res;
end proc:

result:=f(2);
                               2

result;
                               2

result:=f(12);
                               3

result;
                               3

acer

I'm not sure that I understand why fsolve has to be used. Can't the specified events alone reveal success versus failure?

If I understand you then success only occurs when y(t)=3.05 (the height of the basket) and D(y)(t)<0 (meaning the ball is moving downward). If the ball reaches its maximal height before y(t) ever equals 3.05 then that is an easy case of failure.

You can access the values of y(t), x(t), and D(y)(t) following an event trigger by using the special keyword 'last'.

Strict equality testing might not work best, if dsolve is allowing itself any numeric error. And I suppose that you would ideally want to restrict success according to whether the ball (of nonzero width) is going to physically clear the hoop? That math (events) for that could get tricky. In other words, now it gets fun(?!). For example, D(y)(t) would have to be qute a bit less than zero, for the ball to score.

Is this below close to what you want? (About 17 sec to get the plot, on am Intel i5.) If I got it all wrong then hopefully you can adjust and correct.

event0.mw

acer