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

Why exactly do you need to display the expanded expression? You wrote, "in order to check its sign". Do you mean that you will be checking it visually, by inspection? Is that the only reason for having its expanded form be printed? Wouldn't it be easier to have have Maple report the sign to you directly, programmatically?

acer

As far as the error goes, see the attached revision of the worksheet.

code_2_corr.mw

It might not be a big portion of the time resources used by your code (esp. at few iterations) but repeatedly concatenating lists with code like,

function1 := [op(function1], ...];

executed in a loop is inefficient and scales worse in resources used as the list length gets high. Perhaps see a response to your other recent question, where results are stored in a table as they are individually computed and then converted to a list of lists altogether -- only when the looping is finished.

Is it really necessary to compute at Digits=20, because that likely incurs quite a performance penalty. If you leave Digits=10, ie, at its default value, then do you get enough accuracy? Are you only needing the results for a final plot -- because you don't need much, much better than about 1e-5 rel. accuracy for that, do you?

acer

Here is a modification of your worksheet, that gets a 3D pointplot.

I made a few modifications to the ranges of the variables, as passed to fsolve. Judging from the piecewise functions it seemed to make sense to bound n1 by -4 from below, so as to not waste time in fsolve's search. It wasn't clear to me whether you wanted to get the points that lay along some single spacecurve (as n1 changed), but since there might be other solutions I restricted beta by -2 from below. And I extended the lower bound of `a` to -20, as it seems to extend the curve nicely.

deflection_domain_tr.mw

By the way, since your computational code that invokes fsolve and checks the result is not inside a procedure then I tested it utilizing eval(sol,1) so that the type-check did not cause a wasted efforst in repeating the fsolve computation in the case that it had failed and returned unevaluated. (See here for explanation.)

acer

If you are asking about coursework then check recently posted Questions before submitting a duplicate.

See here for an earlier, answered version of this question.

acer

If you are asking about coursework then you should search the recently asked Questions, before submitting a duplicate.

See here for a recently answered version of this question.

acer

Terminate your do-loop with end do rather than just do.

acer