@Petra Heijnen Yes, in Maple 18 you can insert a PlotComponent from the palette, and then in your looping code update that component by using SetProperty to give it a new value.

For example, insert a PlotComponent from the palette. Right-click on it and discover that its name/identity is, say, PlotComponent0. Then, in your looping code, whenever you wish to update the component to show a new plot you can use the SetProperty command. Your code might look something like this,

for i from something to whatever do

  if some_condition_of_yours then
    P := plot(...);
    DocumentTools:-SetProperty("PlotComponent0", ':-value', P, ':-refresh'=true);
  end if;

end do:

Now, it's up to you where you insert the component. You might want it close to the place from which you execute your code, but that's up to you.

Apply the evalf command to obtain floating-point approximations.

Eg,

evalf( ln(3) )

evalf( exp(5) )

acer

I'm supposing that this is homework of some sort, and that the goal is for you to figure out how and why (and whether) it can be done.

Create column Vectors of the coefficients in g1 and g2, both with respect to all of the terms present, ie., [x,x^2,y,y^2]. Concatenate those as columns of a Matrix M. Create a similar Vector V, for f. Then call LinearSolve(M,V) and the result if it exists will be a 2-element Vector whose entries are the coefficients of the linear combination.

If you have any constant terms then make the Vectors one row taller, and use them in the extra row. 

acer

Here is a hack for 2D display. I expect that someone could also do similarly for 3D.

Of course, it's not ideal to try and turn boxes into disks. The ideal would be support for customized appearance in the GraphTheory package itself.

Improvements welcome, but please remember that it was just written as a quick hack. I used a disk, as it was simplest to code. It could look better with an ellipse, depending on the length/height ratio of a vertex label.

restart:

quad2disk := proc(P::specfunc(anything,:-PLOT))
  subsindets(P,
             And(specfunc(':-POLYGONS'),
                 satisfies(p->nops(p)>0
                           and op(1,p)::[[numeric,numeric],[numeric,numeric],
                                         [numeric,numeric],[numeric,numeric]])),
             proc(p) local t,r;
               (t,r):=selectremove(type,[op(p)],list(list(numeric)));
               ':-POLYGONS'(seq(op(plottools:-disk([(op([1,1],pp)+op([3,1],pp))/2,
                                    (op([1,2],pp)+op([2,2],pp))/2],
                                   (op([1,1],pp)-op([3,1],pp))/2)),
                                pp in t), op(r)); end proc);
end proc:

with(GraphTheory):
W := Graph(undirected, {{0, 1}, {0, 2}, {0, 3}}):
HighlightEdges(W, W, black):
HighlightVertex(W, [1, 2, 3, 0], gray):
DrawGraph(W);

quad2disk(DrawGraph(W));

with(SpecialGraphs):
G := SoccerBallGraph():
HighlightVertex(G, Vertices(G), cyan):
HighlightEdges(G, G, gray):

DrawGraph(G);

quad2disk(DrawGraph(G));

with(RandomGraphs):
T := RandomTree(10):
HighlightVertex(T, Vertices(T), gold):
HighlightEdges(T, T, COLOR(RGB,0.2,0.2,0.7)):
DrawGraph(T);

quad2disk(DrawGraph(T));

with(GraphTheory):
G := Graph({{1,2},{2,3},{3,1},{3,4},{4,5},{5,6},{6,4}}):
A := ArticulationPoints(G):
HighlightVertex(G,A,magenta):
DrawGraph(G);

quad2disk(DrawGraph(G));

acer

Sorry this took a while. Hopefully it is still of some use to you.

I was able to compute smaller/shorter/simplified results for your problematic expressions, for which simplify(...) and simplify(...,size) was failing you. And using the same technique I was also able to compute smaller/shorter results for your earlier expressions which had previously been simplified. See the attached worksheet. I get similar results in Maple 18.02 and Maple 2015.1, but notice that timings are higher in 64bit Windows than 64bit Linux on comparable hardware.

The problems seem to boil down to a few things. Don't evaluate some of the unknowns to floating-point values before simplifying, if you can avoid it. It can lead to a variety of severe problems. Also, simplification of huge expressions containing trig function calls is tricky. In this case it seems that restraining the combining of trig terms to just a few of the relevant unknowns may be key.

I also tried to avoid final results with this kind of ugly and suspicious form, which you might normally hope would produce saner coefficients but which in fact gets returned by some simplification call:

(1.2349876*10^(-9)) * ( ...+ (5.6781234*10^11)*subexpr ... + anotherexpr/(3.4568762*10^(-8)) ... )

This particular run was in 64bit Maple 18.02 on Windows 7.

Download Example_modif2_1802.mw

If you want to see the module definition "shell" then you can still get that printed by querying for the 2nd operand of the module.

op(2,eval(sqrt));

      module() local ModuleApply, Nested, Product, Primes; end module

The above was done in Maple 2015.1, and is also what Maple 18.02's Standard GUI prints when eval(sqrt) is called.

acer

You seem to have used "basis" in two ways. At the end you mention a basis {C}, apparently in the mathematic sense. At the beginning you mentioned the A,B,C,D for a "basis" for your computations, apparently using the term in a non-technical sense. The inconsistency may confuse some people.

I'll use DD rather than D which is a protect Maple name with special meaning as the differential operator.

If you want to express the Matrix A+B in terms of the "basis" of Matrices {C,DD} then you can turn everything into column Vectors, concatenate the new column-Vector elements of your "basis" into a Matrix, and use LinearSolve.

Note that {C} or {C,DD} aren't enough to form a basis for the 4-dimensional space that spans the space. So for some candidate Matrix other that the Matrix A+B your set {C,DD} might not suffice.

Taking your trivial example,

restart:                                                       

DD:=Matrix(2,symbol=d):                                        
C:=Matrix([[i,i],[-i,i]]):                                     

A:=Matrix([[1,0],[0,1]]):                                      
B:=Matrix([[0,1],[-1,0]]):                                     

with(LinearAlgebra):                                           

f:=m->convert(m,Vector[column]):                               

sol:=LinearSolve(<f(C)|f(DD)>,f(A+B)):                         

A+B=add(`if`(sol[j]=0, 0, sol[j].[C,DD][j]), j=1..Dimension(sol));

                         [ 1    1]           [i     i]
                         [       ] = (1/i) . [       ]
                         [-1    1]           [-i    i]

In other words the problem solved above is to express A+B as a linear combination of the entries of {C,DD}. (...and the solution of that might be done using 4x1 column vectors rather than 2x2 Matrices.) Is that close to what you want? For other examples you might need to use values rather than just symbols for the entries of Matrix DD. In your trivial example is turns out not to have mattered...

You can change the above example to have C = Matrix([[0,i],[-i,0]]) instead, and then use f(A.B) instead of f(A+B) in the call to LinearSolve. The result of coefficients, sol, would happen to be the same.

acer

Fun := Diff(f(x), x):           

int(Fun, x = 2 .. 7, continuous);

                                 -f(2) + f(7)

acer

If you assign that expression to a name, say ee, then try,

simplify(ee, size)

acer

A call to fsolve with multivariate input returns unevaluated if it cannot find a solution. But as a numeric approach it may not be attempting to prove analytically that there is no solution, so the unevaluated return means only that it could not find one. In the general (including the nonpolynomial case) it may be that there is a solution which was not found, and thus it would be wrong for a routine that merely searches to return a result (such as NULL) and convey the impression that there definitely is no solution.

Checking whether the result is of type 'specfunc(anything,fsolve)' is an ok way to ascertain whether a solution was found. But note that if done at the top-level (outside of a procedure) then the assigned result should be wrapped in eval(...,1) as the first argument to type, if you wish to avoid a recomputation. See here for a post about that, and note Joe Riel's comment.

For such a system of polynomials with real, numeric coefficients you might consider using RootFinding:-Isolate if you wish to find all real roots and also to get an empty list in the case that it ascertains that none exist.

acer

If m1 is a Matrix then,

F,C := LinearAlgebra:-Dimensions(m1)

or,

F,C := op(1,m1)

acer

If I've understood you properly,

restart:
with(plots):
animate(plot3d,[sqrt(h),theta=-t..0,h=0..4,coords=cylindrical],t=0..2*Pi,
                orientation=[-63,-24,-51],style=surface,title="");

restart:
with(plots):
display(seq(plot3d(sqrt(h),theta=-t*2*Pi..0,h=0..4,coords=cylindrical),t=0..1,1/25),
        orientation=[-63,-24,-51],style=surface,insequence=true);

acer

Digits set to 4 means that floating-point computations are performed with 4 digits of working precision. It does not mean (either with or without rounding) that results in general will attain 4 correct places.

acer

T := table(["green" = "gruen", "red" = "rot", "blue" = "blau"]):

assigned(T["asdf"]);

                                    false

assigned(T["green"]);

                                    true

acer

If you have assigned your original inert integral of a piecewise to the name K, then you could do,

value(K) assuming continuous:
simplify(%) assuming T2>T1;

acer