It is PDEtools:-declare:-`PDEtools/declare` which you can view by, say,

showstat((PDEtools::declare)::`PDEtools/declare`);

or by,

kernelopts(opaquemodules=false):              
interface(verboseproc=3):
eval((PDEtools:-declare):-`PDEtools/declare`);

One way to discover this is to issue stopat(PDEtools:-declare), run an example to get into the debugger, then step into the call to `PDEtools/declare`, and then query `where` in the debugger.

acer

The behaviour of embedding the content into the current document is new to Maple 17. See here.

acer

The function `_d01amc` in the external nag dynamic library (libnag.so, nag.dll) gets passed an integrand function, and the nag function calls that and passes it the various values of `x` (double precision). That function then calls back to Maple for evaluation of the integrand at that value of `x`.

There are two modes in which this can occur: the default EvalhfDataProc and EvalMapleProc a fallback software float arbitrary precision mode. There are userinfo statements which state which are being tried under `evalf/int` (and Optimization too).

It wasn't always the case, but in Maple 17 a non-evalhf'able integrand can be used with method=_d01amc. The failure in an initial evalhf callback is caught, and the software float eval callback may then be tried.

restart:
infolevel[`evalf/int`]:=2:

T:=proc(xi) []; exp(-(xi-0.0)^2)*exp(xi) end proc: # The empty list stymies evalhf

evalf(Int(T,-infinity..infinity,method=_d01amc)); 

  evalf/int/control: integrating on -infinity .. infinity the integrand
  proc(xi)  ...  end;
  Control: Entering NAGInt
  trying d01amc (nag_1d_quad_inf)
  d01amc: trying evalhf callbacks
  d01amc: trying eval callbacks
  d01amc: result=2.27587579446874644
  d01amc: abserr=.207787272088890576e-11; num_subint=7; fun_count=390
  result=2.27587579446874644

                                     2.275875794

So, what happened with the original example? As others have pointed out, it failed because the second multiplicand in the integrand expression can overflow, and a NaN can be the final result. Eg. a a problem point x=935.0,

T(935.0);

                                   -379266
                     9.373433646 10

evalhf(%);
     
                               0.

evalhf(T(935.0));

                        Float(undefined)

evalhf(DBL_MAX);

                                         307
                    9.9999999000000001 10   

evalhf(exp(-935.0^2)), exp(-935.0^2);

                                     -379672
                   0., 8.064141315 10       

evalhf(exp(935.0)), exp(935.0);

                                              406
               Float(infinity), 1.162359795 10   

evalhf(exp(-935.0^2)*exp(935.0)), exp(-935.0^2)*exp(935.0);

                                              -379266
              Float(undefined), 9.373433646 10       

And the above is what makes the orignal example fail out in evalhf callback mode.

restart:

T:=proc(xi) exp(-(xi-0.0)^2)*exp(xi) end proc:

evalf(Int(T,-infinity..infinity,method=_d01amc)); 

Error, (in evalf/int) NE_QUAD_ROUNDOFF_TOL:
  Round-off error prevents the requested tolerance from
  being achieved:  epsabs = 5.0e-013,  epsrel =  5.0e-010.

I don't see why the behaviour cannot be improved. That is, perhaps the arbitrary precision (software float) `eval` callback mode could be tried if the above round-off error were caught during the initial evalhf callback mode. It may just be that the round-off error could get added to the "catch" statements which trap non-evalhf'ability.

acer

The Explore command emits Embedded Components, which are not supported by the Classic interface.

acer

Try having that Button's action instead be,

Do(%Plot3=(plots:-display(%Plot3,
                          plot([[%Slider2,%Slider1]],style=point,colour=blue,
                               symbol=solidcircle,symbolsize=18),gridlines=false)));

Another possibility is to have a checkbox rather than that button, so that the action code behind all the sliders could query that and, if it's true/selected, incorporate the vertex into the plots they generate. This could introduce you to the operator form of Maple's `if` command.

nb. There is a mistake in the slider code for controlling value `a`. Make its argument to the plot call be,

  %Slider0*(x-%Slider2)^2+%Slider1

instead of your current,

  %Slider0*x(x-%Slider2)^2+%Slider2

acer

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