Just look here.

acer

Just some observations:

> I1:=int( 1/x^p, x=1..infinity ):

> value( I1 ) assuming p<0;

                                   infinity

> value( I1 ) assuming p<1, p>0;
                                   infinity

> gorp:=value( I1 ) assuming p<1;
                                 infinity p - infinity
                         gorp := ---------------------
                                         p - 1

> eval(gorp,p=1/2);
                                   undefined

> limit(gorp,p=1/2);
                                   infinity

> limit(gorp,p=a) assuming a<1;
                                   infinity

If I had to guess, then I'd wonder whether int() is not taking some limit, in some subcase. Or perhaps it goes to unnecessary trouble just because it does not notice some common behaviour over more than a single subregion (eg. p<0 and 0<p<1). One can see it take longer, and collect garbage, when using only the assumption p<1.

Ok, so I peeked a little. The unsimplified result is obtained by the FTOC integrator. So one could look harder at why IntegrationTools:-Definite:-Integrators:-Asymptotic:-EstimateInternal and friends are not getting the simpler result of `infinity` prior to the FTOC integrator's being used. It is the "Asymptotic" integrator that gets the simple `infinity` result for the assumption p<0. So without looking harder I'll stick with the guess for now, that the Asymptotic integrator gets confused, possibly through not noticing commonality of two regions of interest...

acer

John,

I like your idea, and I hope that you feel encouraged rather than discouraged. You saw a shortcoming or weakness in Maple, and proposed a way to a solution. That it may benefit from discussion is natural, I think. But it's very good for such activity and proposals to go on here. Good for users, not just for "maple". I hope that your attitude to this idea, or others you have, stays positive.

I have one or two other similar proposals (which I keep meaning to blog about). But I feel that these things might be better on sourgeforge or a similar place. For one thing, there may be a need for collaboration and source revision, and that's the sort of thing that should be done right -- in a tried and tested way. Otherwise, the gatekeeping could be very onerous.

On the subject of LaTeX export support, it seems to me that conversion of worksheets and Documents is in more need of heavy work. I'm comparing that to the `latex`() command in the Library. Of course that increases the amount of needed effort by a great deal. I wonder who feels that an "expression or object" LaTeX converter should be distinct from the GUI's LaTeX exporter.

acer

This is a nice analysis. (Somehow I figured that the OP might not be interested in such forensics, but then I didn't have nearly as nice and clear a process as you've shown. I also goofed and typo'd x>Pi/2 instead of a>Pi/2, and so which wouldn't have helped.)

But now it raises a question. How much would be involved in training `solve` to be so smart (for a restricted class of problems, no doubt)? Even if I set _EnvConditionalSolutions to be 'true' I can't get `solve` to return a nice piecewise solution. It seems that `int` has made more progress in recent releases of Maple than has `solve`, in this sort of respect.

Hopefully the OP will also pay attention to your comment about RootOf and subsequent numeric evaluation. The same goes for quite a bit of subsequent symbolic computation too, of course (which is part of why we have RootOf). I should have been more clear about why I called an explicit solution wallpaper.

acer

This is a nice analysis. (Somehow I figured that the OP might not be interested in such forensics, but then I didn't have nearly as nice and clear a process as you've shown. I also goofed and typo'd x>Pi/2 instead of a>Pi/2, and so which wouldn't have helped.)

But now it raises a question. How much would be involved in training `solve` to be so smart (for a restricted class of problems, no doubt)? Even if I set _EnvConditionalSolutions to be 'true' I can't get `solve` to return a nice piecewise solution. It seems that `int` has made more progress in recent releases of Maple than has `solve`, in this sort of respect.

Hopefully the OP will also pay attention to your comment about RootOf and subsequent numeric evaluation. The same goes for quite a bit of subsequent symbolic computation too, of course (which is part of why we have RootOf). I should have been more clear about why I called an explicit solution wallpaper.

acer

> length(sol);
                                   11401819

So, no, I won't paste it. It's pages and pages and pages in length. Here's another way that you might obtain it, with some smarter management of the common subexpressions. Take that RootOf result, which I think was,

RootOf((2*a*Pi^2+Pi^2-4*a^2*Pi-4*a^2)*_Z^4+(4*a*Pi+4*a^2*Pi)*_Z^3+(-Pi^2-2*a*
Pi^2-a^2*Pi^2+4*a^2)*_Z^2+(-4*a*Pi-4*a^2*Pi)*_Z-4*a^2)

Now solve the general quartic, for explicit roots, and substitute in those coefficients. Test at some random value of `a`.

eq:=a*(x/sqrt(x^2-1)+2*x/(Pi*sqrt(x^2-1))-1-2/(Pi*x))=1;
solg:=[solve(C0*x^4+C1*x^3+C2*x^2+C3*x+C4,x,Explicit)]:
newsol:=subs({C0=(2*a*Pi^2+Pi^2-4*a^2*Pi-4*a^2),
 C1=(4*a*Pi+4*a^2*Pi),C2=(-Pi^2-2*a*Pi^2-a^2*Pi^2+4*a^2),
 C3=(-4*a*Pi-4*a^2*Pi),C4=-4*a^2},solg);
seq(evalf(subs(x=newsol[i],a=3,lhs(eq)-rhs(eq))),i=1..nops(newsol));

If I'm not mistaken, that newsol is a list of 4 elements, each of which satisfies `eq` the original eq.

acer

> length(sol);
                                   11401819

So, no, I won't paste it. It's pages and pages and pages in length. Here's another way that you might obtain it, with some smarter management of the common subexpressions. Take that RootOf result, which I think was,

RootOf((2*a*Pi^2+Pi^2-4*a^2*Pi-4*a^2)*_Z^4+(4*a*Pi+4*a^2*Pi)*_Z^3+(-Pi^2-2*a*
Pi^2-a^2*Pi^2+4*a^2)*_Z^2+(-4*a*Pi-4*a^2*Pi)*_Z-4*a^2)

Now solve the general quartic, for explicit roots, and substitute in those coefficients. Test at some random value of `a`.

eq:=a*(x/sqrt(x^2-1)+2*x/(Pi*sqrt(x^2-1))-1-2/(Pi*x))=1;
solg:=[solve(C0*x^4+C1*x^3+C2*x^2+C3*x+C4,x,Explicit)]:
newsol:=subs({C0=(2*a*Pi^2+Pi^2-4*a^2*Pi-4*a^2),
 C1=(4*a*Pi+4*a^2*Pi),C2=(-Pi^2-2*a*Pi^2-a^2*Pi^2+4*a^2),
 C3=(-4*a*Pi-4*a^2*Pi),C4=-4*a^2},solg);
seq(evalf(subs(x=newsol[i],a=3,lhs(eq)-rhs(eq))),i=1..nops(newsol));

If I'm not mistaken, that newsol is a list of 4 elements, each of which satisfies `eq` the original eq.

acer

You might also help maple out, by informing it of some extra information about `a`. For example,

sol:=[solve(eq,x,Explicit)] assuming a>0;

(I am not 100% sure, but the Warning may be related to Maple's not knowing anything about `a`. It might also actually be innocuous here.) Or perhaps you want a solution where x>1, or where x>Pi/2, etc, which could also be supplied as additional assumptions. Or, you could take your original RootOf() result, which represents the roots of a 4th degree polynomial, and try hitting that with allvalues().  It's just a question, but if you have no such extra information then how would you choose amongst the 4 explicit roots?

acer

You might also help maple out, by informing it of some extra information about `a`. For example,

sol:=[solve(eq,x,Explicit)] assuming a>0;

(I am not 100% sure, but the Warning may be related to Maple's not knowing anything about `a`. It might also actually be innocuous here.) Or perhaps you want a solution where x>1, or where x>Pi/2, etc, which could also be supplied as additional assumptions. Or, you could take your original RootOf() result, which represents the roots of a 4th degree polynomial, and try hitting that with allvalues().  It's just a question, but if you have no such extra information then how would you choose amongst the 4 explicit roots?

acer

Hi John,

Do you mean, more inert instances like,

_Inert_LESSEQ
_Inert_LESSTHAN
_Inert_STRING
_Inert_EXPSEQ
_Inert_RANGE

What about Limit() calls, which may produce,

    _Inert_FUNCTION(_Inert_NAME("Limit",...))

The same might be asked of Product() calls. But maybe that should be posed as a more general question. Would you want to mark up and treat specially these particular sorts of _Inert_FUNCTION,

_Inert_FUNCTION(_Inert_ASSIGNEDNAME("exp",...))
_Inert_FUNCTION(_Inert_ASSIGNEDNAME("BesselJ",...))

and so on, in ways analogous to how you treat

_Inert_FUNCTION(_Inert_ASSIGNEDNAME("conjugate",...))
_Inert_FUNCTION(_Inert_ASSIGNEDNAME("abs",...))

It's not clear to me whether (or how) you might want to treat these:

_Inert_UNEVAL
_Inert_ATTRIBUTE
_Inert_SERIES

acer

Suppose that I am editing a plaintext file using vim. In my ~/.vimrc file I have a macro like this,

" run maple on current file
map ,mm :!maple -s -F %

Now, while editing file foo.mpl, I type (without first hitting the Esc key)

   ,mm

That starts a TTY maple session, reading in the contents of the current file/buffer. When I quit that maple session, I am back in vim.

With more effort and ingenuity, one could fashion a vim macro that could set libname and enable a savelib() call embedded in the plaintext. So a source file containing procedure or module definitions could be made to load into private .mla archives, all done from within the vim session.

acer

Suppose that I am editing a plaintext file using vim. In my ~/.vimrc file I have a macro like this,

" run maple on current file
map ,mm :!maple -s -F %

Now, while editing file foo.mpl, I type (without first hitting the Esc key)

   ,mm

That starts a TTY maple session, reading in the contents of the current file/buffer. When I quit that maple session, I am back in vim.

With more effort and ingenuity, one could fashion a vim macro that could set libname and enable a savelib() call embedded in the plaintext. So a source file containing procedure or module definitions could be made to load into private .mla archives, all done from within the vim session.

acer

> f:=x->ln(2-cos(x)+sqrt(3+cos(x)*(cos(x)-4))):
> r:=(n,p)->(1/Pi)*int((1-exp(-abs(n)*f(x))*cos(p*x))/sinh(f(x)),x=0..Pi):

> r(0,1);

                                      1/2
 
> r(1,1);

                                      2
                                     ----
                                      Pi
 
> r(1,3);

                                  46/3 - 4 Pi
                                  -----------
                                      Pi
 
> r(2,5);

                                  2236   97 Pi
                                - ---- + -----
                                   15      2
                                --------------
                                      Pi

> kernelopts(version);
             Maple 11.02, X86 64 LINUX, Nov 9 2007 Build ID 330022

acer

In general this is not a good way. It does nothing to run avoid choosing as pivots some entries whose values are expression that are actually equal to zero. Such as hidden zeros can then propagate in the denominators of a row reduced with that pivot. When the resubstitution is done, the results can then be expressions for which any evaluation will immediately result in "error, division by zero".

acer

In general this is not a good way. It does nothing to run avoid choosing as pivots some entries whose values are expression that are actually equal to zero. Such as hidden zeros can then propagate in the denominators of a row reduced with that pivot. When the resubstitution is done, the results can then be expressions for which any evaluation will immediately result in "error, division by zero".

acer