@nm The usual thing would be to utilize something like libpng.

I see such a dll in the gstreamer folder in the bin.X86_64_WINDOWS folder of my Maple 18 (but not so with Linux 64bit).

It would be nice if this could be used by ImageTools:-Read.

[edit] This is indeed an oft requested feature. It may be of interest that DocumentTools:-SetProperty could apply a PNG image to a LabelComponent as far back as Maple 11.

@Carl Love The following are both results as "false", in Maple 18.01 (with no updated Physics add-on/patch).

restart:
with(Physics):
Physics:-Setup(mathematicalnotation = true):
Physics:-Setup(anticommutativeprefix = psi): 
ap1 := Physics:-Creation(psi, 1, notation = explicit):
am1 := Physics:-Annihilation(psi, 1, notation = explicit):
ap2 := Physics:-Creation(psi, 2, notation = explicit):
am2 := Physics:-Annihilation(psi, 2, notation = explicit):
z1 := ap1 . am1 . ap2:

type(z1, specfunc(anything, `.`));
                             false

type(z1, ('`.`')(anything, anything));
                             false

kernelopts(version);
   Maple 18.01, X86 64 WINDOWS, Mar 28 2014, Build ID 935137

But in Maple 17.02 those results were both "true". Now, those both use `.` and not :-`.` so it seems that loading the Physics package has rebound `.`. I don't know what that package's author intends. In Maple 17.02 z1 comes out as a function call of Physics:-`.`, while in stock Maple 18.01 it comes out as a function call of Physics:-`*`.

I suggest that you use Embedded Components instead of Maplets , if you can, because amongst other things,

- It is much easier to code and learn.

- The resulting worksheet can run in the free MaplePlayer.

- The resulting worksheet can run inside Maple TA (and even be made "gradeable".

- The resulting worksheet can run under MapleNet (and, I am guessing) perhaps even in a browser, pluginless).

Now, you could set it up all by hand, the code behind some collection of Embedded Components.

Or you might be able to just write a procedure that accepts all the aspects/answers/choices as arguments and then draws its inferences and then draws/prints the Graph. And call the Explore command on a function call to that procedure.

ps. the parse command turns "12" into the integer 12, in Maple.

acer

Since your `err` is a procedure rather than an expression, should not that instead be called like, 

GlobalSolve(err, 0 .. 1, 1 .. 20, 150 .. 250, 0 .. 1, 100 .. 15000, 0 .. .5, 0 .. 1, .5 .. 2, 1 .. 5);

Before you can get to that, you may have to deal with the case that the local `st1` inside `err` might not evaluate at certain values of t, for some parameter choices. Eg,

sol(parameters=[0.5, 10.0, 175.0, 175.0, 0.5, 200.0, 0.25, 0.5, 1.0, 2.5]):

sol(0.3);
  [t(0.3) = 0.3, y1(t)(0.3) = 0.210884321724614, y2(t)(0.3) = 0.,

    y3(t)(0.3) = 0.154662986526318, y4(t)(0.3) = 0.0455187827608038,

    y5(t)(0.3) = 0.0204226050767382, y6(t)(0.3) = 216.084667209242]

sol(0.6);
Error, (in unknown) cannot evaluate the solution further right of .41822011, probably a singularity

What do you want the objective procedure `err` to do, in such cases? Return infinity or a very large value? Do you know any tighter parameter ranges that allow you to push t up to 3600?

acer

@Sujaan Kunalan In your original post you had an equation with -2x_3, which would make the [1,3] entry of the Matrix as being -2. How come you are now using it as -1 instead?

@Markiyan Hirnyk As I mentioned, the results are to be consider as a union of a kind.

Perhaps it makes it a little more clear to evaluate at a=1, which you showed `solve` handling directly.

restart:
ee := 1/x < abs((x+4)/(x*a+2)):                

T := [ solve(ee) ]:                            

G := map(simplify,map(solve,T,x,parametric))[]:

remove(type,eval([G],a=1),identical([]));  

                                                            1/2
                                                          17
    [[[x < -4]], [[x = -4]], [[-2 < x, x < 0]], [[- 3/2 + ----- < x]],
                                                            2

        [[-4 < x, x < -2]]]

solve(`or`(seq(`and`(op(z)), z=map(op,%))));
                                                             1/2
                                                           17
    RealRange(-infinity, Open(-2)), RealRange(Open(- 3/2 + -----), infinity),
                                                             2

        RealRange(Open(-2), Open(0))

To do that kind of conjoining and simplification of the piecewise structures within G itself is more irritating. (I suppose that is the kind of thing that often goes on inside `solve`. And what I did might even have to be adjusted for other values of `a`, depending on the nesting.)

The reason I showed construction of G above is that it contains inequalities with simply `x` on one side and expressions with only `a` on the other side. That's in contrast to T above, which is not "solved for x" in this sense.

@Mac Dude I think that it would be simple to just use the read command (on a file with actual Maple statements rather than strings, and skip parse altogether).

If script.mpl contains the plaintext statements,

read "dat.mpl";
a,b,c;

and if plaintext file dat.mpl contains the line,

a,b,c := 1,2,3;

then executing the command line maple on script.mpl goes like,

$ maple18 -F script.mpl
    |\^/|     Maple 18 (X86 64 LINUX)
._|\|   |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2014
 \  MAPLE  /  All rights reserved. Maple is a trademark of
 <____ ____>  Waterloo Maple Inc.
      |       Type ? for help.
> read "dat.mpl";
                              a, b, c := 1, 2, 3

> a,b,c;
                                    1, 2, 3

A good place to start would be to understand the instructor's original code, by studying what it does.

See if you can add a sensible comment (in Maple, using a line starting with a # symbol) for each line of the code. (There aren't very many lines of code.)

The idea is that someone unfamiliar with the method should be able to understand the method and the code, by reading your comments.

But by having to write such comments, you end up understanding what it does. At that point, understanding the modification task will be much easier.

If you hope for people here to help modify the code then you're likely going to have to provide it in a form other than an image (or image within pdf). Few people will want to type it out themselves.

The image shows 2D Math. I suggest you work with 1D Maple Notation and a Worksheet for this, not 2D Math input mode and a Document. This is a programming assignment, after all. (Search Maple's help, or this site, for instructions on switching those two preferences.)

acer

Are you trying to open the worksheet off of the MapleCloud, from within Maple? If so then do you usually login to the MapleCloud using a Google ID?

Or are you pointing your browser at a URL which is supposed to link to a worksheet (off a course website, say)?

acer

restart:
ee := abs(exp(2*Pi*I*x)+exp(2*Pi*I*y)):     

int( combine(evalc(ee)), [x=0..1, y=0..1] );

                                      4
                                     ----
                                      Pi

acer

Have you tried with fsolve's `avoid` option?

Is, build up a set of the solutions generated so far. Then call fsilve on the total range of interest. If a new solution is returned then augment the set. Repeat, until it fails to find another distinct root.

That is what Student:-Calculus1:-Roots command does, so you could just try using that.

For such problems with just one varying "parameter" there are other techniques. Searching this site should reveal links to convenient front-end to using Rootfinding:-Nextzero to sweep a range for all roots. Rootfinding:-Analytic has also been used.

acer

@Aakanksha The code I posted runs as expected in the Standard GUI of my Maple 9.50. Does it not run for you? (The plots take about 20 seconds or so.)

Here is the second plot, in which the real component is red and the imaginary component is blue. This was done at default working precision, and I get pretty much the same at Digits=300.

@Aakanksha It does not seem that your `capacity` is purely real-valued for the range L=1..4. That kind of thing will prevent `plot` from being able to produce a single curve for your expression, as is.

If the code below I delayed assignment of the various parameters with floats, and kept the upper index of the summation as `NN` an unknown name so that it could do symbolic summation. (The results seem to concur with those obtained using numeric upper index 100, with `add` or `sum`.) This made `capacity` faster to plot, and more compact.

The code produces a red curve for the real part, and a blue curve for the imaginary part of `capacity`.

Do you have some reason -- physical grounds of the problem, say -- to think that `capacity` should be real-valued with L=1..4 ?

The float values given to `k` and `L` get into the various exponents in your expression, so I suppose then that you really do want principal roots and not real-valued surds.

restart:

N1:=sum(((yo^((b-a+2*p-1)/2)*z^((b-a+2*p-1)/2)*GAMMA((1-(b-a+2*p))/2))
        /(p!*GAMMA(p-a+1)*GAMMA(1+((1-(b-a+2*p))/2)))),p=0..NN):
N2:=sum(((yo^((b+a+2*p-1)/2)*z^((b+a+2*p-1)/2)*GAMMA((1-(b+a+2*p))/2))
        /(p!*GAMMA(p+a+1)*GAMMA(1+((1-(b+a+2*p))/2)))),p=0..NN):
N1:=eval(N1,NN=100):
N2:=eval(N2,NN=100):

x:=(Pi*csc(a*Pi))/(GAMMA(m*L)*GAMMA(k)):

c:=x*(N1-N2):

cc:=log[2](1+1/c):

me:=MeijerG([[],[1-((b+1)/2)]],[[-(b+1)/2,a/2,-a/2],[]],(z*yo)):

m1:=((z*yo)^((b+1)/2))/(GAMMA(m*L)*GAMMA(k)):
m:=2; k:=24.503; a:=k-m*L; b:=k+m*L-1;
z:=(k*m)/10^(0.1*15):

yo:=10^(0.1*10):

pp:=m1*me:

capacity:=cc*pp;

plot([Re,Im](capacity),L=-4..4, color=[red,blue],
     adaptive=false, numpoints=200);

plot([Re,Im](capacity),L=0..4, color=[red,blue],
     adaptive=false, numpoints=200);

Digits:=200:
plot([Re,Im](capacity),L=0..4, color=[red,blue],
      adaptive=false, numpoints=40);
Digits:=10:

By the way, do you have an old version of Maple? If so, which one is it?

@casperyc You may wish to recompute the rank using a (weakest, fastest) Normalizer that can correctly determine that all pivot choices were not hidden zeroes. Note that we could find other examples for which `simplify` is not strong enough (either as Normalizer or as check on the Determinant).

Also note that for some other examples you may get a division-by-zero error while simplifying the determinant computed (as you did it) via the RREF. Trouble starts in pivot selection, and in the most severe case your check might produce just an error message.

And all the above is only trying to deal with identifying pivots that simplify identically to zero. This topic can become far more complicated if you also wish to account for sets of values of the indeterminate names which make the rank even smaller (because they make all pivot choices zero for some given row's pivot determinantion step). Technically, your rank=8 answer is true only under a set of caveats (on the indeterminates) that none of the pivots used become zero.

@Stephan That is worth remembering. Thanks for sharing. To summarize with a smaller example,

restart:

P := piecewise( x<=t, 1/a, x>t, (1+b)/a ):

#simplify( P*a ); simplify( P*a, piecewise );
#expand( P*a ); combine( P*a );

convert( P*a, piecewise, x );
                             /   1        x <= t
                            {                   
                             \ 1 + b      t < x