On Monday, April 17, 2017 at 7:56:55 AM UTC+8, Richard Fateman wrote:   
   > On 4/16/2017 1:19 PM, clicliclic wrote:   
   > >   
   >   
   > >   
   > > This kind of dangerous inconsistency is only found in systems whose   
   > > design reaches back to the 1960's to 80's. It would simply constitute a   
   > > bug in Maple, Mathematica, Derive, and Sympy.   
   >   
   > I think that this is wishful thinking.   
   >   
   > We routinely expect algebraic identities to hold.   
   > After all, these systems are called Computer Algebra Systems.   
   >   
   >   
   > Analytically (x^2-1)/(x-1)  differs from x+1   when x=-1.   
   > Just about every system "simplifies" one to the other, and   
   > if it didn't, the system would be rather weak.   
      
   That depends on the domain of computation.  If we are talking   
   about fractions of univariate polynomial, then the simplification   
   is reasonable, and necessary if you want canonical representation.   
   If you view it as expression, which explicitly allows discontinuity of   
   domain of definition, then the simplification will be wrong, more   
   work has be done in this domain of computation.   
      
   > The Maple (version 7) command   
   > simplify(sqrt(x^2))  returns csgn(x)*x .   
   > A moment's consideration should tell you that sqrt(x^2) has   
   > two values, -x  and x.  It is irrelevant where x is   
   > located in the complex plane, and thus csgn(x),  its   
   > "sign" in the complex plane, doesn't really affect   
   > the mathematical answer.   
      
   Similarly, sqrt(x) can be interpreted as both roots of x   
   or the principal branch root.   
      
   > There are endless inconsistencies in Mathematica.   
   >   
   > One of the principles behind coherent semantic   
   > discourse  (as we might hope to achieve in writing   
   > mathematics and in conveying our intentions for   
   > computing to a CAS) is support of Referential   
   > Transparency.  (Lots of discussion -- try googling).   
   >   
   > What this means for Mathematica and its Simplify   
   > functionality is this:   
   >   
   > f[a]   
   >   
   > and   
   >   
   > Simplify[ f[x]] /. x-> a   
   >   
   > must give the same result for various definitions of f and a.   
   >   
   > Before reading further, decide if you agree with this.   
   > (for those unfamiliar with Mathematica syntax, here's a version   
   > in Maple-ish syntax.   
   >   
   > subst(x=a, simplify(f(x))   
   >   
   > Using our previous example, let's   
   > define in Mathematica,   
   >   f[x_]:=(x^2-1)/(x-1)  suppose a=1.   
   >   
   > Mathematica fails.   
   > Maple, too.   
   >   
   > While sympy is newer, I have seen rather little   
   > evidence that it differs in mathematical correctness   
   > from earlier systems. Its major benefit seem to be   
   > that it is more accessible from python's popular   
   > ecosystem than previously packaged systems.   
   >   
   >   
   >  From the perspective of "Mathematical Knowledge Management"   
   > this is a flaw.  This problem was, in internal discussions,   
   > acknowledged by the Macsyma people at MIT at least as early   
   > as 1971. Doing it "right" is quite challenging. It was   
   > clear from the outset that Maple wasn't going to do it.   
   > Same for Mathematica, decades later.   
   > I have not tried it, but I fully expect sympy to   
   > fail to be referentially transparent as well.   
   >   
   > It would be nice to address complex analysis correctly, but   
   > there is the hope that -- if one can reduce a question in   
   > complex analysis to algebra -- that one can make headway   
   > in some computation.   
   >   
   > If you want an analytic "solution" to an integration problem,   
   > you can consider how to translate it to a solvable question   
   > in algebra  (perhaps via Risch method).  But you must address   
   > the translation from analysis to (perhaps several?) algebraic   
   > problems first.   
   >   
   > This message is getting way to long but here's a thought.   
   >   
   > If you (or your program)   
   >   are clever enough to realize that there are two ALGEBRAIC   
   > solutions depending on the domain of x,  then do this   
   > assume(xp>0);   
   > integrate(log(xp)*log(xp^2),xp)   
   > assume(xn<0);   
   > integrate(log(xn)*log(xn^2),xn);   
      
   The problem is that, since you 'assume(xp>0)', it means   
   you already assume xp is real instead of complex.   
      
   > This resolution, phrased exactly this way,   
   > is I think, correctly handled in   
   > Maxima.  One of those "old" systems.   
   >   
   > reminder: the Risch methods are ALGEBRAIC in nature.   
   >   
   > Basically, this is not enough -- I would hope that a discussion   
   > of functions (of one complex variable) in the complex plane would   
   > have to have descriptions of branch cuts and surfaces etc.  And   
   > for functions of several complex variables, I'm unaware of any   
   > satisfactory computationally-oriented references.   
   >   
   > RJF   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)