The behaviour of your attempt using evalf and allvalues depends upon the working precision.

restart:

sol := SolveTools:-Engine({tan(x) = x}, [x], allsolutions):

evalf[28](allvalues(sol));                                 

       [{x = -4.493409457909064175307880927}], [{x = 0.}],

           [{x = 7.725251836937707164195068933}]

That was on running 64bit Maple 17.02 on Linux.

And higher working precision seems no assurance. With `evalf[38]` I got only two solutions.

It's not clear that SolveTools[Engine] and allvalues is going to work out well for this. How about using RootFinding:-NextZero?

For your simple example, the RootOf "general solution" is not much better than the original expression tan(x)=x. With the original exression you can unapply wrt x after taking rhs-lhs, and easily feed that to NextZero. But evalf/RootOf just calls fsolve multiple times (sometimes with its avoid option) and thrashes around. Perhaps a more complicated example would illustrate the difficulties more interestingly, say one where SolveTools[Engine] did some significant alteration or reduction. Then the RootOf might be theoretically "better" than the expression itself, but could be awkward to pass off to NextZero. A multivariate system, perhaps. Or something that led to a nested RootOf, and where the original expression presented greater difficulties for numerical evaluation at a point.

acer

To date, the only released version of Maple that runs on ARM Cortex A9 architecture does so for iOS, as far as I know. And it is not a full version of Maple, but rather it is some version(s) of the Maple Player.

acer

Why do you believe that there is a value of x that satisfies you equations when z=0.5044?

eq1 := y=-26.21231979*z+15.42332896+13.22411533*exp(-0.6786*x):
eq2 := y=-25.98077423*z+14.81943362+13.53858145*exp(-0.6569*x):
q := rhs(eq1)-rhs(eq2);
plot3d( [0,q], x=-0.001..0.001, z=0.4..1.4,view=-1..1,color=[red,blue] );
plot3d( [0,q], x=-10..10, z=0.4..1.4,view=-1..1,color=[red,blue] );
Optimization:-Minimize(z,{q<=0,q>=0},x=-0.001..0.001, z=1.1..1.3);

The surfaces computed by the above plot3d calls do not seem to fall below (or touch) height 0.0 unless z is at least some value greater than 1.249641 or so. Do you have a reason to believe otherwise?

acer

Do you mean something like this?

restart: Digits:=20: N:=10000: M:=100: x_max:=2.0: r_min:=0.0:
r_max:=0.4: for n from 0 to N do r:=r_min+n/N*(r_max-r_min):
x:=evalf(x_max*rand()/10^12):
for m from 0 to M do
  x:=r*(8-2*x^2);
od:
X[n]:=x: od:
with(plots):
bifpoint:=[seq([r_min+j/N*(r_max-r_min),X[j]],j=0..N)]:
pitchf:=pointplot(bifpoint,symbol=point):display(pitchf,view=-3..3);

If you are interested in greater speed, note that these kinds of computations can be quite easily made faster by running them in a procedure and running calls to that with evalhf, or after using Compiler:-Compile, or even just with option `hfloat`. See this old post for some ideas on that.

acer

It works for me if I either use those assumptions both while integrating and simplifying, or not at all.

I got the same antiderivative as you if I left off the assumptions.

restart:

f:=sqrt(A*x^2+B*x+C)*x:
F:=int(f,x):
e:=diff(F,x):
simplify(e);

                                           (1/2)  
                           /   2          \       
                           \A x  + B x + C/      x

restart:

f:=sqrt(A*x^2+B*x+C)*x:
F:=int(f,x) assuming A>0, B^2-4*A*C<0:
e:=diff(F,x):
simplify(e) assuming A>0, B^2-4*A*C<0;

                                           (1/2)  
                           /   2          \       
                           \A x  + B x + C/      x
kernelopts(version);

          Maple 17.02, X86 64 WINDOWS, Sep 5 2013, Build ID 872941

part b) This may give you some ideas. Maple should compute evalf[d](exp(y)) to within 0.6 ulps for realcons y. (You could check that for this example, of course.) Try to figure out whether and how the size of q affects the working precision and accuracy of q needed to compute sin(q) to within 0.5 error.

restart:
d:=round(log10(exp(100)));

                                    d := 43

q:=evalf[d](exp(100)):
evalf[2*d](sin(q)):evalf(%);

                                 0.9796960601

restart:                    
d:=round(log10(exp(100))) + 1;

                                    d := 44

q:=evalf[d](exp(100)):        
evalf[2*d](sin(q)):evalf(%);  

                                 0.3606268033

restart:                      
evalf[round(log10(exp(100)))+12](sin(exp(100))):evalf(%);

                                 0.1421981237

So with 44 digits accuracy in the floating-point approximation of q=exp(100) a result for sin(q) was correct to within 0.5, while 43 digits was insufficient.

I could have used ilog10(exp(100.)) instead of round(log10(exp(100))) to get the value of 43. But note that ilog10(exp(exp(100.))) will produce infinity unless Digits is increased. The following calls `shake` internally, after turning log10(exp(exp(100))) into exp(100)/ln(10).

restart:               
round(log10(exp(exp(100))));

                 11674344414002886632798167381008836736851880

Does the following give you any ideas about bounding the error in x to assure that `sin` is within 0.5? If `cos` is bounded by (-1,1) then how large can abs(cos(x)*xerror) be relative to xerror?

convert(series(sin(x+xerror),xerror,2),polynom);

                            sin(x) + cos(x) xerror

Does that lead you to any ideas about how close x+xerror must be to x, and how many digits correct there need to be in `X` a float approximation of x in order for sin(X) to differ from sin(x) by no more than 0.5?

acer

There are several ways t get the mapped assignment. Apart from what Carl and Preben showed, there is also,

restart:
Q:=Matrix([[a+b,c+d],[e+f,g+h]]):
M:=Matrix([[A,B],[C,F]]):

zip(assign,M,Q):

A,B,C,F;

                          a + b, c + d, e + f, g + h

If you are trying to evaluate expressions in A,B,C,F using those values in Q then you may not need to assign at all. By forming a list of equations you can substitute into expressions instead. This can allow you to create other additional expressions in just the names (A,B,C,F) without having to first unassign them.

restart:
Q:=Matrix([[a+b,c+d],[e+f,g+h]]):
M:=Matrix([[A,B],[C,F]]):

T:=Equate(M,Q);

               T := [A = a + b, B = c + d, C = e + f, F = g + h]

expr:=A/C+B/F;

                               expr := A/C + B/F

eval(expr, T); # without need for assignment   

                                 a + b   c + d
                                 ----- + -----
                                 e + f   g + h

expr:=A+F/B;                                

                                expr := A + F/B

eval(expr, T); # without need for assignment

                                         g + h
                                 a + b + -----
                                         c + d

map(assign,T): # yet another way to get actual assignments done

A,B,C,F;

                          a + b, c + d, e + f, g + h

acer

Your last line of code is passing `list5`, which has been assigned a Matrix as its value, to `combinat`.

acer

The underlying difficulty you appear to be having here is similar to that in an earlier question of yours.

Namely, you have code in the Actions of the PlotComponent, but that's not where you want it.

Instead, simply add the two options (for title and titlefont) into the plotting command that you use in the Action code of the Slider component.

acer

If you insert a Plot component whose id is "Plot0" and a Slider component whose id is "Slider0" then you can tie them together in the following simple way:

You don't need to change any of the Action code or Properties of the Plot component. Just leave the inserted Plot component alone. Instead, change the "Value Changed Action" of the Slider component to be just this,

  use DocumentTools in 
    SetProperty("Plot0", value, plot(GetProperty("Slider0", value)*x^2,
                                     x=-10..10, view=0..500));
  end use; 

Of course, you can alter the range used for the `view` option, as desired.

That should result in a worksheet in which someone can use the Slider immediately upon launch or re-opening.

On the other hand, issuing the following command in Maple 17 should also make a worksheet that can be used either immediately or after closing and re-opening.

Explore(plot(a*x^2,x=-10..10,view=0..1000),
        parameters=[a=0.0..10.0], newsheet, showbanner=false);

Also, the table which contains all the embedded components inserted via an `Explore` call (with or without the `newsheet` option) could be copied & pasted even within the current open worksheet. Any originally inserted components and any `Explore` call which created them could be removed, and then the copy&pasted instance should still run ok.

Note that, if the thing being explored (be it function call or expression) depends on some earlier assignments in the session then those may have to be reproduced when re-opening the worksheet. The Startup Region can provide a way to make this automatic, in such cases.

acer

With luck I entered it all correctly.

restart:

dsys:=diff(x(t),t)=0.2*x(t)*(1-0.5*x(t))-(1.5*x(t)*y(t))/(1+0.116*x(t)),
      diff(y(t),t)=(1.3*x(t)*y(t))/(1+0.1*x(t))-0.8*y(t):
ics:=x(0)=1,y(0)=2:

P1:=DEtools[DEplot]({dsys},[x(t),y(t)],t=0..50,x=-1..3,y=-1..3,
                    [[ics]],linecolor=green,maxfun=10^5,arrows=small):

F:=proc(par)
  DEtools[DEplot]({dsys},[x(t),y(t)],t=0..50,x=-1..3,y=-1..3,
                  [[ics]],linecolor=blue,maxfun=10^5,arrows=small,
                  method=classical[foreuler],stepsize=par);
end proc:

plots:-display(P1,F(0.005));

Explore(plots:-display(P1,F(stepsize)),
        parameters=[stepsize=0.005..1.0]);

acer

Click the "New" tab beside "Popular". Then click on the rightmost of the 5 buttons at the bottom, the one which looks like a blue circle with a white downward pointing triangle in it. Pressing that will scroll down the full list by a "page" (10 items, say).

acer

One sensible appraoch, as Carl has shown, is to generate a sequence of `plot` calls, where each one sets its own color. And then `plots:-display` can handle the title. This could serve you well, if you also wanted to have differing linestyles, etc.

Another approach, which I believe works for providing multiple curve colors for the given problem, is to make just a single call to `plot` command using its own specification for handling multiple curves. This provides the immediate support of the palette functionality of plots:-setcolors to get differing colors for multiple curves using either system color palettes or user-defined lists as palette.

The final line in the procedure could be, (pasted here in plaintext 1D Maple notation)

  plot([seq]([seq]([T, eval(X[c], Sol[T])],
                   T = 600 .. 1200, 50),
             c = [CH4, CO2, H2O, H2, CO]),
        title='Frações*molares*dos*compostos*por*variação*de*temperatura')

acer

If the `m~` in your `eqnl1x` is an assumed local then you could try, say,

  globeqnl1x := convert(eqnl1x, `global`):

# and then

  eval(globeqnl1x, [`m~`=1]);

# or

  subs( `m~`=1, globeqnl1x );

Or you could try and pick out the locals of `eqnl1x` using the `indets` command, and figure out which one equals the local `m~` (by testing for equality with global :-`m~` after conversion to `global`, perhaps) and assign that to a new name to use instead for the substitution process. Ie,something perhaps like,

usem := select(u->convert(u,`global`)=:-`m~`,indets(eqnl1x,`local`))[1];
subs( usem=1, eqnl1x );

acer

For question 1, you have forgotten to load DocumentTools, or to call it as DocumentTools:-SetProperty, in the Startup Code region.

For question 2, add the option,

  refresh=true

to the SetProperty command. Ie, change,

   SetProperty(Button1, enabled, false);

to

   SetProperty(Button1, enabled, false, refresh=true);

acer