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 . On Wednesday, July 29, 2020 at 5:10:56 AM UTC-7, kcrisman wrote: > > > > 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. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/15913891-0d49-47e9-9003-52872b349726o%40googlegroups.com.
