> de := diff(y(t),t,t) + 3*diff(y(t),t) + 2*y(t) = 0;
                        / 2      \
                        |d       |     /d      \
                  de := |--- y(t)| + 3 |-- y(t)| + 2 y(t) = 0
                        |  2     |     \dt     /
                        \dt      /
 
> f := eval(de, y(t)=c*exp(r*t));
                    2
            f := c r  exp(r t) + 3 c r exp(r t) + 2 c exp(r t) = 0
 
> vals:=solve(f);
 vals := {c = 0, r = r, t = t}, {c = c, r = -2, t = t}, {c = c, r = -1, t = t}
 
> seq(eval(c*exp(r*t), sol), sol in vals);
                           0, c exp(-2 t), c exp(-t)

I'm not quite understanding exactly what problems you described having.

You can use Explore for this too.

expr1:=1-exp(-rho*x):

expr2:=-(1-p)^n+(p/(1-p)+1)^n*(1-p)^n+(1-p)^(n-1)*((exp(rho)*(-1+p)-p)*((exp(rho)*(-1+p)-p)/(exp(rho)*(-1+p)))^(n-1)-exp(rho)*(-1+p))/exp(rho):

isect:=rhs(isolate(expr1=expr2,x)):

G:=subs([Expr1=expr1,Isect=isect,Expr2=expr2],
        'plot'([Expr1,Expr2,[Isect,t,t=0..1]],x=1..100,view=[1..100,0..1])):

Explore(G);

I chose n=1 to 100, p=0.1 to 0.9, rho=0.01 to 0.2, and skipped `t`, in the initial Explore pop-up.

You can also get a similar effect with the plots package's interactive Maplet, eg.

plots:-interactiveparams(plot,
                         [[expr1,expr2,[isect,t,t=0..1]],x=1..100,view=[1..100,0..1]],
                         n=1..100,p=0.1..0.9,rho=0.01..0.2);

You can also set it up entirely yourself with Components, if you want the whole thing embedded in your current worksheet. (I added code showing a simple plot-slider component example to your previous post, btw). For this example you could have one Plot component, and three Slider components each with the "Action When Value Changes" property be merely the call update_component(). Your worksheet could use the above code to assign expr1, expr2, and isect as well as this procedure below.

update_component:=proc()
  uses DocumentTools;
  SetProperty(Plot0,'value',
    plot(
       subs([n=GetProperty(Slider0,'value'),
             p=GetProperty(Slider1,'value'),
             rho=GetProperty(Slider2,'value')],
            [expr1,expr2,[isect,t,t=0..1]]),
       x=1..100,view=[1..100,0..1]));
  NULL;
end proc:

Of course, you'd want to change the end-points for the sliders, and their tick marks, etc.

As far as not evaluating those tickmarks goes, how about something like this

plot(log[10](x/(10^6)),x=1..6,xtickmarks=[seq(i=10^convert(-i,name),i=1..6)]);

The mapping log[10](x/(10^6)) is, of course, quite unimportant (said just to preempt any pedants in the crowd...) But perhaps the 'name' trick is of use.

Simply supply either of the two end-points in the parameter's range as a float, in order to allow that parameter to take float values ("continuously") thoughout that range. For example, for parameter p set the ranges to, say, 0.0 and 1.0 in the initial Explore pop-up window.

Try this, using suitable ranges for n (eg 10 to 100) and p (eg 0.1 to 0.9)

Explore(Statistics:-DensityPlot(Binomial(n,p),view=[0..100,0..0.4]));

(toggle it to "skip" `view` as a variable, in the initial pop-up window)

You could, alternatively, insert a Plot component yourself along with and a pair of sliders or dials that you hook up to the appropriate action. The Explore facility can be nice for... exploring what's possible.

Here's an outline of doing it yourself, with Components.

First execute this code (optionally hiding it in a Code Region of your Document).

update_component:=proc(P::evaln,S1::evaln,S2::evaln)
  DocumentTools:-SetProperty(P,'value',
     Statistics:-DensityPlot('Binomial'(
     DocumentTools:-GetProperty(S1,'value'),
     DocumentTools:-GetProperty(S2,'value')),view=[0..100,0..0.4]));
  NULL;
end proc:

Now create one Plot Component and two Slider Components. Let's suppose that the Plot Component's properties (right-click to see 'em) show its name as Plot0, and that the Sliders are Slider0 and Slider1. In the "Action When Value Changes" property of both sliders, put the following call.

update_component(Plot0,Slider0,Slider1);

You could optionally have simply inserted the code body of `update_component` right into the Sliders actions. I personally like having the actions be a procedure call, so that I can update the working code outside of the Components, especially when the code is re-used in more than one place.

Then adjust a few other properties of the sliders, to make then look nice. Eg, toggle the boxes for "Show Axs Labels", "Update Continuously While Dragging". And give them suitable ranges, especially Slider1 which should have floats as its range end points, like 0.1 and 0.9 say. You could also adjust the spacing of their major and minor tick marks.

That should be it. Slide away.

How about,

V,C := Data[1..-1,1], Data[1..-1,2];

to get a pair of 1D Arrays. Then you have a choice, if you really want column Vectors. You can create new objects like this

convert(V,Vector[column]);

Vector[column](V);

Or you can alter V or C themselves (in-place)

rtable_options(C,subtype=Vector[column]);
C;

> with(Units:-Standard):

> 1000*Unit(N)*Unit(m);
                                   1000 [J]
 
> Units:-AddSystem(MySI,Units:-GetSystem(SI),N*m,kN*m):
> Units:-UseSystem(MySI):

> 1000*Unit(N)*Unit(m);
                                    [kN m]

Is there a transcription mistake? Was the second part of the suggested solution actually given as

Vector(4,{1=2/3,2=1/6,3=1,4=0})

You should be able to test the second suggestion Vector, to see whether or not it solves the homogeneous system. Just multiply it by your Matrix A, and see if you get the zero-Vector as a result.

You can solve the problem in the following way.

with(LinearAlgebra):

eq1:=-x[1]-2*x[2]+x[3]+2*x[4] = 8;

eq2:=2*x[1]-2*x[2]-x[3]+x[4] = 13;

A,B:=GenerateMatrix([eq1,eq2],[x[1],x[2],x[3],x[4]]);

answer:=NullSpace(A);

You could also have solved LinearSolve(A,Vector(2,[0,0])) which returns your final, parametrized solution as a sum. ie. the linear combination of the solution's basis Vectors (including arbitrary, named parameters). You only obtained one Vector from that parametrized solution. But there are two parameters, so you should be looking for two linearly independent Vectors. So, you could try another pair of values for the parameters. In this example it is "easy" to see that _t0[2]=0, _t0[4]=1 and _t0[2]=1, _t0[4]=0 give a linearly independent pair. But you can use Rank to check.

You can test it by checking that this gives Vectors which 1) solve the homogeneous system, and 2) are linearly independent. (There are several ways to do 2))

for V in answer do
  A.V;
end do;

Rank(Matrix([op(answer)]))=nops(answer);

I think that the lmgrd binary is expecting to find /lib/ld-lsb.so.3 but that ubuntu version has just /lib/ld-linux.so.2 by default.

So you could try the "right thing" and install optional lsb packages as Lark suggests. Or you could try to wing it by a symlink alone.

Do you mean that you want it automatically applied to all new output? I think that you might be able to create a customized "style" for that. (You might also be able to make it a new default for yourself, too.)

See ?worksheet,documenting,styles

Please state explicitly the range of integration in both variables, and the desired accuracy of the result, and then we can see whether you really do need to find an approximating formula, or whether you can simply call evalf(Int(...)).

So far, I haven't seen anything in this or your ealier post to suggest that direct 2D numerical integration won't suffice. Ie, no need for an approximating function, no need to do one of the integrals symbolically, etc. You appear to have overlooked my suggestion that you might not be invoking the numerical integration in the best way, resulting in much longer computation time than necessary. For example

> restart:

> f:=sqrt(1+cos(x)*cos(y)*cos(x+y)):

> st:=time():
> evalf(Int(Int(f,y=0..1),x=0..1));
                                  1.177995497
 
> (time()-st)*Unit(seconds);
                                   0.048 [s]

Compare that with calling it as evalf(int(int(f,y=0..1),x=0..1)) which  takes so long I had to interrupt it.

But perhaps you intend some wider range than just 0..1 (which is the widest that got mentioned earlier, I think)? For a wider range, you might need to specify the numeric method and/or some other options.

I'm not saying that I know for sure which way you attempted the numerical integration. But the error message you reported in your earlier post on this topic suggested to me that when you thought you were attempting pure numeric intergration you might actually have been calling lowercase `int`.

When you tried that numerical attempt, how did you go about it? I mean, did you call evalf(Int(...)), or evalf(int(...)), or use the palettes to get an integral symbol which you then either wrapped in evalf or called "evaluate numercally" from the right-click context-menus?

I ask because that error message sounds suspiciously like something that would come out of a call to lowercase int (via solve). Of all those schemes above, only an explicit evalf(Int(...)) might attempt numerical quadrature only. It boils down to whether you want to wait an extra 5 mins if the invocation of lowercase int() is also going to fail even when the integrand's parameters and range endpoints have been given numeric values.

Suppose that you intend on computing the result at many numeric choices of the parameters. You probably don't want Maple to attempt an unsuccessful exact integration prior to doing the numeric quadrature, each time. Just a thought.

Sometimes (rarely) Maple can do integrals when the unknowns have numeric values, but fails on the general symbolic problem.

Does the method matter, or just the final answer? By that I mean: are you supposed to use some particular things that you've been taught from Linear Algebra?

> with(LinearAlgebra):

> A:= <<-3,0,0>|<0,-3,0>|<6,-6,3>>;
                                  [-3     0     6]
                                  [              ]
                             A := [ 0    -3    -6]
                                  [              ]
                                  [ 0     0     3]
 
> (e,P):=Eigenvectors(A):

> P . DiagonalMatrix(e) . P^(-1), A;
                      [-3     0     6]  [-3     0     6]
                      [              ]  [              ]
                      [ 0    -3    -6], [ 0    -3    -6]
                      [              ]  [              ]
                      [ 0     0     3]  [ 0     0     3]

> A:=Matrix(2,2,[a,b,c,d]);
                                      [a    b]
                                 A := [      ]
                                      [c    d]
 
> data:=[a=0,b=17,c=Pi,d=x]:
> A;
                                   [a    b]
                                   [      ]
                                   [c    d]
 
> eval(A,data);
                                  [0     17]
                                  [        ]
                                  [Pi    x ]
 
> A;
                                   [a    b]
                                   [      ]
                                   [c    d]

> newA:=eval(A,data);
                                      [0     17]
                              newA := [        ]
                                      [Pi    x ]
 
> newA;
                                  [0     17]
                                  [        ]
                                  [Pi    x ]
 
> A;
                                   [a    b]
                                   [      ]
                                   [c    d]


> a,b,c,d;
                                  a, b, c, d

The idea is that it's often more useful to be able to evaluate A at some values of its parameters, while allowing those individual parameter names to themselves stay unassigned. Whether you want this behaviour, or its complete opposite, depends on how the rest of your code and methodology works, of course. If you really want to assign to a,b,c, and d then you can use Eriks `assign` suggestion. (Personally, I find it easier to write code in which that sort of assignment is not necessary.)

Do you know about Gaussian elimination, or row-echelon form? Maple can do that for you.

> with(LinearAlgebra):


> M:=Matrix([[1,2,0],[2,k,1],[m,k,1]]);
                                   [1    2    0]
                                   [           ]
                              M := [2    k    1]
                                   [           ]
                                   [m    k    1]

> G:=LUDecomposition(M,output='U');
                             [1      2          0     ]
                             [                        ]
                             [0    k - 4        1     ]
                        G := [                        ]
                             [              2 (-2 + m)]
                             [0      0      ----------]
                             [                k - 4   ]

> G[1,1] * G[2,2] * G[3,3];
                                   -4 + 2 m

> Determinant(M);
                                   -4 + 2 m

Notice that the determinant of M is the product of the diagonal entries in that Gaussian elimination step (modulo a minus sign, according to how many row interchanges occurred). So you might be tempted to conclude that M has infinitely many solutions only when Determinant(M) = -4+2*m = 0.

Another answer comes from noticing that M will not be full rank (of 3) if any of the diagonal entries of G are zero. So -2+m=0 is one of those cases, when G[3,3]=0. But the other valid case is when G[2,2]=0 which occurs when k-4=0. So M can have infinitely many solutions when m=2 or k=4. But also ask yourself what m must be, when k=4.

If you also want to investigate whether or not the system might be inconsistent, then you can write M as an augmented 3x4 Matrix whith entries b1,b2,b3 in the 4th column. Then do LUDecomposition with output='U' and ask questions of yourself about what inconsistency might entail for that result. For example,

> M:=Matrix([[1,0,0,b1],[2,k,0,b2],[m,k,1,b3]]);
                                [1    0    0    b1]
                                [                 ]
                           M := [2    k    0    b2]
                                [                 ]
                                [m    k    1    b3]

> G:=LUDecomposition(M,output='U');
                       [1    0    0             b1          ]
                       [                                    ]
                  G := [0    k    0          b2 - 2 b1      ]
                       [                                    ]
                       [0    0    1    b3 - m b1 - b2 + 2 b1]

In this example, there can be infinitely many solutions only when G[2,2]=0 which is the case when k=0. But notice that G[3,4] cannot be zero or else the system is inconsistent. Also, when k=0 the G[2,4] formula cannot be zero, else there too it is inconsistent.

You can compare what happens when you ask Maple to solve M.X=B without any special consideration of the parameters, versus what happens when the special case(s) are handled separately. Note that LinearSolve(eval(M,[k=0])) does not succeed because LinearSolve is not designed to split off the special case on its own. Instead it just complains that the system is inconsistent, without showing the relationship b2=2*b1 that would still allow a solution.

M:=Matrix([[1,0,0,b1],[2,k,0,b2],[m,k,1,b3]]);

LinearSolve(M); # no special case consideration

LinearSolve(eval(M,[k=0])); # inconsistent system error

G:=LUDecomposition(M,output='U');

eval(G,[k=0]);

GenerateEquations(%,[x1,x2,x3]); # shows the special case solution

Hope that helps some.