assume() seems to break integrate() in some cases

[Dan Swenson]

When I do:

t.integrate(t, 0, 4*a - a^2) # LaTeX: \int_{0}^{4a - a^2} t dt

I get the correct answer:

1/2*a^4 - 4*a^3 + 8*a^2

But if I first make some assumptions, then the integral fails to evaluate:

assume(a, 'real')

assume(a > 1)

assume(a < 3) # now 0 < a < 4, so 4*a - a^2 > 0

t.integrate(t, 0, 4*a - a^2) # hangs, eventually produces RuntimeError

(To me, the assumptions should make the problem easier, if anything.  But instead apparently they make it harder...)

I also get a RuntimeError if, under the above assumptions, I do:

bool(4*a - a^2 > 0)

So maybe the integrate() function is trying to determine which endpoint is greater, and that's causing it to hang?  (The top endpoint is greater under the given assumptions, but you have to do a bit of algebra to figure that out.)  Indeed, a workaround is to first do: assume(4*a - a^2 > 0). 

I have posted a version of this question at https://ask.sagemath.org/question/52382/assumption-seems-to-break-integrate-is-this-a-bug/ , and there user @eric_g suggests another workaround: .integrate(algorithm='sympy').

So, does that mean that this is a problem with Maxima?

I noticed the behavior in Sage 8.6, and @eric_g confirms the behavior in Sage 9.2.beta5.

[rjf]

In  Maxima it works just fine,

it doesn't seem to be a Maxima problem.  Though assume(t,real) is meaningless,

and the syntax for maxima would be

integrate(t,t, 0, 4*a-a^2)  not

integrate(t,0,4*a-a^2).

integrate doesn't care if the lower limit is less than the upper limit.

[Nils Bruin]

On Monday, July 27, 2020 at 4:55:39 PM UTC-7, rjf wrote:

In  Maxima it works just fine,

You should probably qualify that. Perhaps it works fine with the default settings that maxima uses, but there are combinations on settings that don't seem so unreasonable for which the failure can be observed in maxima directly:

besselexpand : true;
display2d : false;
domain : complex;
keepfloat : true;
load(to_poly_solve);
load(simplify_sum);
load(diag);
assume(a>1);
assume(a<3);
integrate(t,t, 0, 4*a-a^2);

 crashes for me. These are settings that sage probably uses.

[kcrisman]

You only need domain: complex and assume(a>1) for it to crash, in fact.  

On Tuesday, July 28, 2020 at 12:45:39 AM UTC-4, Nils Bruin wrote:

On Monday, July 27, 2020 at 4:55:39 PM UTC-7, rjf wrote:

In  Maxima it works just fine,

You should probably qualify that. Perhaps it works fine with the default settings that maxima uses, but there are combinations on settings that don't seem so unreasonable for which the failure can be observed in maxima directly:

In general, many Sage/vanilla Maxima discrepancies come from the "domain:complex" invocation.  I'm not sure why that is, but we need domain:complex for some basic stuff to work right (it's been so long the default that I can't remember any more what that is, though Trac will surely tell us).

Anyway, perhaps Dan or Eric can file a Trac ticket.  If you are able to also file a Maxima report and then link to that, that would be ideal - thanks!

[rjf]

that crashed for me.

  It reminds me of an old joke ..

<synopsis>

Man goes to doctor and says, It hurts when I do this <contortion>.

Doctor says, don't do  <contortion>.

Maxima and Macsyma before it was basically written with real variables in

mind.  It would be nice to know exactly what behavior Sage expects

that requires domain:complex.  

 It would of course be nice to fix

whatever happens to cause Maxima to go into the rabbit hole

on this problem  (stack overflow) .  To see it going into spasms,

do  :lisp (trace meval)   

and it tries to do computations with lim-epsilon,  something called prin-inf, 1.0e8.

and some newly generated symbols.

RJF

[kcrisman]

On Tuesday, July 28, 2020 at 9:02:44 PM UTC-4, rjf wrote:

that crashed for me.

  It reminds me of an old joke ..

<synopsis>

Man goes to doctor and says, It hurts when I do this <contortion>.

Doctor says, don't do  <contortion>.

Well, <contortion> probably shouldn't be in the documentation then :-)  See https://trac.sagemath.org/ticket/25636 for an impressive array of similar reports, and https://sourceforge.net/p/maxima/bugs/3442/ for at least one upstream report.

 

Maxima and Macsyma before it was basically written with real variables in

mind.  It would be nice to know exactly what behavior Sage expects

that requires domain:complex.  

 

I believe it's primarily the following, according to the Maxima documentation.  You may recall this conversation we've had several dozen times ;-) but anyway, regardless of that, I am always stumped as to why changing this setting messes up integrals.  (As opposed to the abs_integrate package we used for a while.)

Option variable: domain

Default value: real

When domain is set to complex, sqrt (x^2) will remain sqrt (x^2) instead of returning abs(x).

I don't see what integrate(t,t, 0, 4*a-a^2); has to do with simplifying square roots.   If seeing this helps you (or someone else) debug/diagnose it, that may be the key to fixing ALL of these discrepancies, for which I at least would be profoundly grateful.

[rjf]

The development of Macsyma, and Maxima, in a manner similar to that of Sage,

was/is essentially the accumulation of contributions from many hands.

Sometimes pieces added later have unanticipated effects on older

code. So this is not entirely unexpected.

I think that the assume() code, has been from early implementation

rather disappointing from the perspective of reliability, specification,

algorithms, and interfaces.

Trying to accumulate information about types   (A is real) and geometry

(A>1)  and algebra (A^3 > B^4)  and trigonometry (sinh(a+b)>0),  and decide

which deductions to make as data is stored, or as accessed... is difficult,

if not techically impossible to do completely.  The documentation points out that the

deduction mechanism is "not very strong".

It is an area that could probably benefit from additional thoughtful improvement.

Cylindrical algebraic decomposition, an area of relevance, touches some

of the issues.  Getting the work to not interfere with integrate() is probably

another issue (I hope just a fixable bug!)

As for posting trac bug reports for Sage, I think that posting

bugs that have been specifically traced to Maxima, should be

reported in some reproducible form to a current stand-alone

version of Maxima.  I don't know if this is done

routinely but it seems advisable.  A few people

(I'm one) look at Sage from time to time, but reporting a

"maxima" bug just to "sage" is not a great strategy unless

there are people to look at it.  

I  have disagreements with the treatment of simplification

when "domain:complex"  is set in maxima, so it is hard to 

"fix" behaviors which are "features".  This is hardly unique

to maxima; I have a collection of such situations for

Mathematica.

   I guess I still haven't seen an explanation of what

behavior in maxima is expected by setting domain to complex.

The only behavior documented is, as you point out,

not something that would obviously affect the integration

code.  But even more obviously, it does affect it.

It may be worth pointing out that there are two largely

separate bodies of code ,, symbolic "antidifferentiation"

which is done by pattern matching, some simple methods,

and some Risch-algorithm style code.  (source code sinint.lisp other stuff)

 The other  definite integration, which

uses methods from complex variables.(source code defint.lisp, limit.lisp)

The original versions of the code were written by different people.

The assume() code was written by yet another.

RJF

.

[William]

On Wednesday, July 29, 2020 at 11:48:58 AM UTC-7, rjf wrote:

   I guess I still haven't seen an explanation of what

behavior in maxima is expected by setting domain to complex.

There was a long thread about this a few years ago.   Here it is:

https://groups.google.com/forum/#!searchin/sage-devel/domain$3Acomplex|sort:date/sage-devel/p8hOeDKa754/Pd1y8s8PCQAJ

[Sébastien Labbé]

Would it be hard to implement both:

.integrate(algorithm='maxima_domain_real')
.integrate(algorithm='maxima_domain_complex')

?

[Nils Bruin]

No, as mentioned on the thread linked by William, we could have a context manager that sets "domain: real" and back on the maxima_calculus instance. People should just not do silly things with it, like leaking the context in an iterator.

[kcrisman]

And we now have such contexts, apparently. 

[kcrisman]

On Wednesday, July 29, 2020 at 2:48:58 PM UTC-4, rjf wrote:

The development of Macsyma, and Maxima, in a manner similar to that of Sage,

was/is essentially the accumulation of contributions from many hands.

Sometimes pieces added later have unanticipated effects on older

code. So this is not entirely unexpected.

I think that the assume() code, has been from early implementation

rather disappointing from the perspective of reliability, specification,

algorithms, and interfaces.

Trying to accumulate information about types   (A is real) and geometry

(A>1)  and algebra (A^3 > B^4)  and trigonometry (sinh(a+b)>0),  and decide

which deductions to make as data is stored, or as accessed... is difficult,

if not techically impossible to do completely.  The documentation points out that the

deduction mechanism is "not very strong".

Totally.  I think it's just the confusion about how such non-simplification could impact it.  Doubtless someone tacitly relied upon this somewhere for certain antiderivatives under certain assumptions, and just left it in place for all of them.

 

As for posting trac bug reports for Sage, I think that posting

bugs that have been specifically traced to Maxima, should be

reported in some reproducible form to a current stand-alone

Of course, I was not suggesting that you personally should do this.  I even suggested that the people who had originally diagnosed it might be best placed to do so.

 

version of Maxima.  I don't know if this is done

routinely but it seems advisable.  A few people

We do try to do so fairly routinely - note the bug I linked to, for instance.  I do know that for me personally, trying to remember my login and password for Sourceforge is extra cognitive load, as is the slightly different markup needed on that site.  I suppose I should have the browser remember my login, at least :-)

 

The original versions of the code were written by different people.

The assume() code was written by yet another.

 Understood.

[rjf]

Thanks for posting a link to that old (5 year old) report.

The notion that you are computing in the complex domain  (functions of many complex variables??)

is really not enough.  Because (as noted) there are multiple branches of common

functions, choosing one of them (behind the scenes, on the fly) may not work.

How to fix?

 I've mentioned it previously, I assume.  Represent the multiplicity of

answers.   Sqrt(x^2)  is  a pair,  {-x, x}.   Log(r^2)   is 2 log(r)+2*n*i*pi or something like that..

No one does it.  A project for some student?

RJF

On Thursday, July 23, 2020 at 4:32:14 PM UTC-7, Dan Swenson wrote: