restart:
assign(a,c):
assign('a'=d,b=2):

a,b,c;

                                    d, 2, c

By using uneval quotes the assignment is made to that quoted name rather than whatever (other name) it might currently evaluate to.

acer

This is not the first time that I've seen Maple do better with mixtures of sin and cos than with tan or cot.

value(convert(Int(tan(x)^(n-2)*sec(x)^2,x),sincos));

                                       (n - 1)
                               /sin(x)\       
                               |------|       
                               \cos(x)/       
                               ---------------
                                    n - 1     

int( convert(tan(x)^(n-2)*sec(x)^2, sincos), x );

                                       (n - 1)
                               /sin(x)\       
                               |------|       
                               \cos(x)/       
                               ---------------
                                    n - 1     

In this particular case, it also does a nicer job after preliminary conversion to expln.

acer

Try Ctrl-Del (Control and Delete keys at the same time).

See here (Windows, which has the above as an item for "Delete an Element") or here (Operating System links, because on OSX it is Command-Del).

acer

In a plaintext preferences file I see a HelpZoom=100 item.

On my Windows 7 I found one of these as,

cat(kernelopts(homedir),"/AppData/Roaming/Maple/18/Maple.ini")

But even if I manually edit that entry to have instead a value of 300 (say) then this appears to be ignored/clobbered when any new Help (browser) window is opened. And even if I use the Help window's menu to zoom to 300% (Ctrl-6) then upon exiting the whole GUI that new value is lost. It appears to be lost any time I open a wholly separate and new Help window, and the preferences file is re-saved with the 100 value when I exit the GUI.

It seems that this item in the preferences file is just not doing anything. To me, it looks like it was at least someone's intention, at some point, that it work. It would be useful and user-friendly if worked.

acer

It looks like this got broken between Maple 13.00 and 14.01.

If you really prefer that it not emit that error (instead of using :-combine, say) then you might consider patching it by adjusting the inert form of the procedure. For example,

restart:

unprotect(IntegrationTools:-Combine):
IntegrationTools:-Combine:=
  FromInert(
    subs(ToInert(And(DefiniteIntegral,Not(MultipleIntegral)))
         =ToInert(And(Or(IndefiniteIntegral,DefiniteIntegral),
                      Not(MultipleIntegral))),
         ToInert(eval(IntegrationTools:-Combine)))):
protect(IntegrationTools):
protect(IntegrationTools:-Combine):

IntegrationTools:-Combine( Int(sin(x),x)+Int(cos(x),x) );

                             /                   
                            |                    
                            |  sin(x) + cos(x) dx
                            |                    
                           /                

That is quite a crude use of subs, above, which apparently works out ok in my Maple 18.02 for this brief procedure. You ought to check whether you think it does what you intened. More robust and generally safe might be too get at the particular pieces for correction using op, check they are of the expected wrong form, then replace with subsop.

You would need to be extra careful about saving the modified module to archive, which can be tricky (and sometimes not practical) since doing it right can require first evaluating many other parts of the module. I don't suggest anyone who doesn't consider themselves expert try that. It's a lot simpler merely to have the fix-up be done as above, in one's initialization file.

Such changes would be better if accompanied by test examples. It's obviously risky to make changes to some command whose code is protected.

acer

The types in question are added when the module is read from archive. Also, these types can be used with the global names. These two facts together imply that you don't need the full set of actions (including rebinding of exports' names) caused by invoking with(IntegrationTools) in order just to get those types. The types will also be defined merely by causing the global symbol :-IntegrationTools to be looked up.

restart;
v := Int(sin(x), x):

type(v,:-IndefiniteIntegral);
Error, type `IndefiniteIntegral` does not exist

eval(IntegrationTools):
type(v,:-IndefiniteIntegral);
                              true

This module uses a local named IntegrationTools:-Initialize to make the calls to TypeTools:-AddType. I mention this in case you'd prefer merely to add the types yourself.

showstat(IntegrationTools::Initialize);

acer

Your Question says "list" but your code uses a set.

If your code actually used a list (square brackets) then you'd see length 9. But a set (squiggly braces) has its duplicate entries removed.

acer

These do what you seem to be asking.

subs( originvarslist =~ varslist, f );

or,

subs( Equate(originvarslist,varslist), f );

or,

subs( zip(`=`,originvarslist,varslist), f );

And you could directly assign the result to `f`, if that's your goal.

acer

If the result of a call to `int` has been assigned to `g`, then at the top-level you could test whether,

op(0,eval(g,1)) = int

in order to check whether it has returned as an unevaluated function call to `int`.

The use of 1-level eval is to prevent the active `int` from trying the computation over, especially if all relevant remember tables might have been cleared. (A note on using procedures for a similar effect, more generally.)

You can also test against :-int instead of just int, in case packages are loaded and the name rebound. Or test against inert `Int`, if you started with that and hit it with the `value` command.

I find the idea of `int` emitting an error instead of an unevaluated return to be generally poor; the unevaluated return can be quite conveniently useful in several situations.

acer

Using Maple 15.01 I was able to get a result in approximately 13-15 seconds, using either 32bit or 64bit Maple (both run under Windows 7). For example,

restart:
H:=Int(exp(18.1818*(Int((0.579160e-1*sqrt(x)*Ei(1., 0.500000e-4*x)
                         +(1072.23*(.999950-1.*exp(-0.500000e-4*x)))
                         /sqrt(x))/sqrt(x),
                         x = 1. .. eta))
       -9.10000*eta)/eta,
       eta = 1. .. 100.):

CodeTools:-Usage( evalf(H) );
memory used=0.78GiB, alloc change=69.49MiB, cpu time=14.26s, real time=14.32s
                        0.0004666594253

I believe that the successful method used above was `_Dexp` (double exponential), internally split across several subregions.

It can be done more quickly and accurately. But let's also run through other suggestions.

Carl characterizes `evalf/int` as only ever using Digits for determining a target accuracy. But that is not quite true. The numeric integrator allows for both the working precision (Digits, or its `digits` option) and a tolerance (its `epsilon` option) to be specified separately. Perhaps Carl was trying to express that, unless specified otherwise, the target accuracy (tolerance, epsilon) is determined from the working precision. It may happen that one has to specifiy the tolerance as being looser than what would otherwise be automatically determined from the working precision. In my opinion the most clear way to set about this is to specify all aspects explicitly.

This is what I see in 64bit Maple 15.01, for Carl's suggestion. It takes longer to find a less accurate result.

restart: # Carl Love
Digits:= 30:
#I distributed the sqrt(x) in the inner integral.
Inner:= Int(
     0.579160e-1*Ei(1., 0.500000e-4*x)+(1072.23*(.999950-1.*exp(-0.500000e-4*x)))/x,
     x = 1. .. eta,
     digits= 15
):
Int(exp(18.1818*Inner-9.10000*eta)/eta, eta = 1. .. 100., digits= 5):
CodeTools:-Usage( evalf(%) );

memory used=1.31GiB, alloc change=68.24MiB, cpu time=21.98s, real time=22.11s
                           0.00046645

This next is Markiyan's suggestion. It takes about the same time as the straight call to evalf done first above. It is (I believe) a more accurate result even though no non-default options are used. But, since no non-default options are supplied, it's not clear from just this result that it might be more accurate that the first result above. What it does do, is force an iterated single-variable method. It also succeeds by iterated single-dimension quadrature, integrals split across several subregions, failing first in method _d01ajc due to working precision being too close to accuracy and then competing with method _Dexp.

restart:
F:=eta->int((0.579160e-1*sqrt(x)*Ei(1., 0.500000e-4*x)
            +(1072.23*(.999950-1.*exp(-0.500000e-4*x)))
            /sqrt(x))/sqrt(x),
            x = 1. .. eta, numeric):
CodeTools:-Usage( int(eta->exp(18.1818*F(eta)-9.10000*eta)/eta,
                      1. .. 100., numeric) );
memory used=0.68GiB, alloc change=11.12MiB, cpu time=13.18s, real time=13.19s
                        0.0004666594270

It's probably worth stating explicitly here that another difficulty for such iterated single-dimension integrals is that the inner integral's results might not be accurate enough for the numeric method used on the outer integral to properly do error estimation or adaptive control. In the following attempt the inner integral uses the fast _d01ajc method with digits set as high as that method allows while the tolerance is set as tight as can be to match. The outer integral is left to choose its own method (_Dexp) but must naturally use a looser tolerance because it's doing 1D quadrature with inner results that are only so accurate.

restart:
H:=Int(exp(18.1818*(Int((0.579160e-1*sqrt(x)*Ei(1., 0.500000e-4*x)
                         +(1072.23*(.999950-1.*exp(-0.500000e-4*x)))
                         /sqrt(x))/sqrt(x),
                         x = 1. .. eta, digits=15, epsilon=5e-15, method=_d01ajc))
       -9.10000*eta)/eta,
       eta=1. .. 100., digits=15, epsilon=1e-13):
CodeTools:-Usage( evalf(H) );
memory used=0.53GiB, alloc change=64.49MiB, cpu time=7.52s, real time=7.52s
                      0.000466659427019435

I suspect that is quite accuarate, and a bit faster.

Now for Axel's observation that the inner integral can be solved. The result of using symbolic `int` on the inner integral produces an expression involving several calls to the special function `Ei`. That is itself just an abbreviation for an integral, albeit one which can be computed quickly and accurate via special methods. But even here it is important to note that this inner symbolic result has to be computed accurately enough, or else the outset numeric integral will be constrained in terms of how accurate it can be. (Axel's habit, I believe, is to set Digits to 15 in such situations. And indeed that might even be necessary here.) The following does exactly one call to any numeric integrator (_d01ajc, as it happens), which is successful.

restart:
Digits:=15:
Hinner:=Int((0.579160e-1*sqrt(x)*Ei(1., 0.500000e-4*x)
            +(1072.23*(.999950-1.*exp(-0.500000e-4*x)))
            /sqrt(x))/sqrt(x),
            x = 1. .. eta):
Hinner:=CodeTools:-Usage( value(Hinner) ) assuming eta>1, eta<100:
memory used=21.30MiB, alloc change=17.50MiB, cpu time=437.00ms, real time=447.00ms

H:=Int(exp(18.1818*(Hinner)-9.10000*eta)/eta,
       eta = 1. .. 100., digits=15, epsilon=1e-11, method=_d01ajc):

CodeTools:-Usage( evalf(H) );
memory used=15.19MiB, alloc change=9.50MiB, cpu time=234.00ms, real time=239.00ms
                      0.000466659427127310

I find it interesting that the previous attempt fails for epsilon=1e-12 or tighter for that force method=_d01ajc, where digits=15 is as high as the hard-coded quadrature weights of that method allow.

By removing the specified method from the previous attempt a result of even greater accuracy can be obtained (but still quite quickly). Digits is set to 1000 only to ensure that the inner "symbolic" integral is an adequately accurate expression. It is the `digits` and `epsilon` options to the outer integral which are key.

restart: infolevel[`evalf/int`]:=1:
Digits:=1000:
Hinner:=Int((0.579160e-1*sqrt(x)*Ei(1., 0.500000e-4*x)
            +(1072.23*(.999950-1.*exp(-0.500000e-4*x)))
            /sqrt(x))/sqrt(x),
            x = 1. .. eta):

Hinner:=CodeTools:-Usage( value(Hinner) ) assuming eta>1, eta<100:
memory used=105.24MiB, alloc change=47.12MiB, cpu time=1.19s, real time=1.18s

H:=Int(unapply(exp(18.1818*(Hinner)-9.10000*eta)/eta, eta),
       1. .. 100., digits=26, epsilon=1e-20):

CodeTools:-Usage( evalf(H) );
evalf/int/quadexp: applying double-exponential method
From quadexp, result = .466659427019467124447527497994e-3 integrand evals = 280 error = .24538325557333259051444632402e-23
memory used=29.27MiB, alloc change=0 bytes, cpu time=327.00ms, real time=322.00ms
                0.00046665942701946712444752750

acer

For a single 3D plot you can put it into a PlotComponent and then resize that component by adjusting its properties.

For a single 2D plot (including multiple curves, etc, all shown together using plots:-display) you could also put into a PlotComponent and adjust its width and height properties.

But for such a 2D plot, perhaps it's even easier to pass the additional option size=[k,p] to the plots:-display comamnd, where k and p are positive integers representing the width and height in pixels at normal magnification. I am guessing that of all the suggestions I'm making this might be the most suitable for your situation.

For case of an Array of plots (plots:-display(Array([...])), say) the plots are shown in cells of a worksheet "table", which sizing properties of which are available through right-click context-menu (Table Properties).

acer

If you have assigned a PLOT3D structure to a name (eg, `myplot`) then such changes will not be retrofitted to the structure assigned to that name when you do right-click context-menu actions on the inlined plot.

But if you create a PlotComponent and use DocumentTools:-SetProperty to set that plot as the `value` of the component, then after such context-menu actions on the plot shown in the component you can subsequently extract a modified structure using the DocumentTools:-GetProperty command.

For example, in the attached worksheet I first created a zgrayscale plot. Then, after putting it into the PlotComponent I used the right-click menus to implment a custom "user" lighting. Then when I extract it from the component I pick off the LIGHT and AMBIENTLIGHT substructures and turn them into the syntax for the plot3d or plots:-display commands.

Note that the PlotComponent seems to retain the options set via the right-click. So if you re-rerun the worksheet the zgrayscale plot (or any 3D plot) will show with that same custom lighting inside the component.

Download lightstuff.mw

acer

It works for me if I use the method=rkf45_dae or method=rosenbrock_dae options to dsolve(...,numeric), as well as supply another initial condition.

I used Maple 14.01 for 64bit Linux.

For example, it works with the same IC D(h)(0)=Pi/2 used by Dr Subramanian.

ODE := A*(diff(h(t), t))^2+B*(diff(h(t), t))*(h(t)+C)+E*h(t)
       = F*cos(diff(h(t), t)):
ODE_SOLUTION := dsolve({ODE, h(0) = 0,D(h)(0)=Pi/2}, numeric, 
                       method=rosenbrock_dae, range = 0 .. 10, 
                       parameters = [A, B, C, E, F]):
ODE_SOLUTION('parameters'=[0,0,1,1,1]):
with(plots):
odeplot(ODE_SOLUTION,[t,h(t)],0..3);
odeplot(ODE_SOLUTION,[t,D(h)(t)],0..1);

acer

It would be nice if `int` would try more changes-of-variable by itself.

restart:

f := Int( ln(x+1)/(1+x^2), x=0..1 ):

simplify( value( IntegrationTools:-Change(f, x=sin(v)/cos(v)) ) );

                                 1         
                                 - Pi ln(2)
                                 8         

acer

Using Maple 13.01,

fsolve(unapply(.956^2-PpRM(s, .185)-PkRM(s, .895), s), 0 .. 1);

                                0.7739453931

acer