From: Christopher.Creutzig@mathworks.com   
      
   On 6/24/15 9:11 AM, Waldek Hebisch wrote:   
      
   > You ignore the fact that symbolic computations usualy do not   
   > depend on choice of branches: from symbolic point of view to   
   > branches are indistingushable.  Once correct symbolic result   
   > is obtained, to solve analytic problem one may need to   
   > determine branches.  Choice of branches is specific to given   
   > problem and frequently requires information not present in   
   > symbolic version.  Of course, once you have concrete analytic   
   > problem you need clear choice of branches.  But usually such   
   > choice can be separated from other considerations.  In particular   
   > you can produce useful symbolic results without caring about   
   > branches.   
      
   Whether such results are “useful” depends on what you want to use them   
   for. If, for example, you ask a CAS for all x such that sin(x)=1/2, what   
   do you expect to get? asin(1/2) might be one option, but those of us who   
   (like me) believe that even for symbolic calculations, functions should   
   be single-valued and that we want consistency between symbolic   
   computations and numerical evaluations, probably regard asin(1/2) as   
   just another way of writing π/6 and prefer a solution set somewhat like   
      
   { PI          |         }       { 5 PI          |         }   
   { -- + 2 PI k | k in Z_ } union { ---- + 2 PI k | k in Z_ }   
   {  6          |         }       {   6           |         }   
      
   I look at functions as, well, relations that have exactly one output for   
   each permissible input (which I think is kind of the standard   
   definition). From there, I have seen papers on symbolic definite   
   integration that simply break down for complex inputs because the   
   analysis completely ignores branch cuts along the way. Branch cuts in   
   functions the user does not see in either input or output. (“Break down”   
   in the sense that the symbolic results in the end have completely   
   different values from numerical integration, due to branch cuts.)   
      
   > Once you are dealing with arbitrary expressions numeric branches   
   > frequently are bogus.   
      
   In which sense? That these branch cuts do not match the reality modeled?   
      
   That is a model error. If we want to interpret things inside a formula   
   as functions (which in the end, most of us do), then we need to impose   
   branch cuts at some point. I don't know whether there is a better way to   
   do this, but I only know of three ways it is done in practice:   
      
   * Some authors simply ignore the problem. In some cases, the reader is   
     left to figure out what to use where, and in some cases the end   
     results may simply not be usable at all for applications that require   
     some form of consistency with, well, functions.   
      
   * Some authors opt to compute with multi-valued functions for a while,   
     often indicating that by using a notation like Log or Asin instead   
     of log or asin, and afterwards explicitly resolve this. I like this   
     strategy personally, at least when done well, but have not seen a   
     computer program applying it by itself.   
      
     A variation of this theme is papers saying “for an arbitrarily chosen   
     branch.”   
      
   * The author (or, frequently, the software they use) defines which   
     branch cuts they are going to use. (This definition may be different   
     in different parts of the paper, although it usually is not.) Whenever   
     a computation actually needs multiple values (such as “all x such   
     that x*exp(x)=y”), explicitly name the set of all branches.   
      
   > Let me recall expression that I already showed in the past:   
   >   
   > (1/(sqrt(x*y) - sqrt(x)*sqrt(y)))*(sqrt(x*y) - sqrt(x)*sqrt(y))   
   > * (sqrt(x*y) + sqrt(x)*sqrt(y))*(1/(sqrt(x*y) + sqrt(x)*sqrt(y)))   
   >   
   > Depending on order of operations (which can be changed using   
   > parentheses) you get 1 or 0.  Do you thing that CAS should   
   > forbid division because expression may be 0?  Maybe in the   
   > future CAS will do so, but currently it is inpractical   
   > (would exclude too many useful computations).   
      
   I'm not sure what the connection is between branch cuts and the reality   
   that standard simplification rules tend to ignore that some inputs (such   
   as the one you just gave) are actually undefined and return some defined   
   value.   
      
   FWIW, I fully agree with you, and would even like to name a simpler   
   example: Simplifying x/x to 1 is not really valid as far as interpreting   
   the expression as a function goes (it extends the definition range), but   
   if our CASs stopped doing this kind of simplification, we would, as you   
   said, exclude too many useful computations.   
      
   > Coming buck to "correct" results for integral 64.  The   
   > piecewise constant factors appearing in result if used automatically   
   > in further computations may easily lead to wrong result.   
      
   I am not sure I fully understand what exactly you mean by “wrong result”   
   here. Not including piecewise constants that stem from branch cuts can   
   easily lead to wrong results, I see that – e.g., a definite integral   
   might be computed and the piecewise constants might be the only   
   indication that the indefinite integral does indeed have a   
   discontinuity. I have seen that happen, although it has been a while and   
   I no longer have the examples at hand.   
      
   > In other words, FriCAS produces useful result for integral 64.   
   > If it is more or less useful than results from other integrators   
   > depends on your criteria.  You clearly prefer results containing   
   > piecewise contant factors, but there are other points of view.   
      
   D'accord.   
      
   > For numeric purposes FriCAS indeed has 'logGamma' function.   
   > However, there is no need for separate symbolic 'logGamma'.   
      
   I disagree. log(Gamma(-2/3)) ≠ logGamma(-2/3). Perhaps our   
   interpretations of the meaning and implications of the word “symbolic”   
   are just too different.   
      
   > Well, when you plug in specific instances you need to check that   
   > they are admissible.  And when you use numeric code you need to   
   > check that it uses correct branches.  Simply assuming that   
   > you have "the same expressions" so you get the same results   
   > is not enough.   
      
   In my mind, ideally, it should be.   
      
      
   Christopher   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)