Bill Page wrote:
>
> On 8 September 2014 15:15, Waldek Hebisch <[email protected]> wrote:
> > Bill Page wrote:
> >>
> >> I would like to include:
> >>
> >>   2) my code for adding conjugate to special functions
> >>       http://axiom-wiki.newsynthesis.org/SandBoxFunctionalSpecialFunction
> >
> > Definitions you gave are debatable.  In particular
> > 'D(conjugate(x), x) = 0' may lead to troubles.  For example,
> > 'D(conjugate(conjugate(x)), x)' should be equal to 'D(x, x) = 1'
> > regardless how we compute it.  Consider:
> >
> > y := operator 'y
> > D(conjugate(y(x)), x)
> >
> > substituting 'conjugate(x)' for 'y(x)' and derivative of
> > 'conjugate(x)' for derivative of 'y(x)' should give derivative
> > of 'conjugate(conjugate(x))'.
> >
> 
> The code that I wrote for conjugate assumes that operators always
> represent holomorphic functions, while conjugate itself is explicitly
> not holomorphic so a substitution such as you suggest does not make
> sense.

You clearly allow non-holomorphic arguments to conjugate, otherwise
'conjugate(conjugate(x))' would be illegal.  Rather, you assume
that conjugate will be always pushed onto variables/parameters
and that _in context of differentiation_ we will substitute
only holomorphic functions for variables.  But in other
context you allow non-holomorphic things.  Pushing conjugate
to variables in itself is debatable:

(14) -> conjugate(log(-1))

         ________
   (14)  log(- 1)
                                                    Type: Expression(Integer)
(15) -> eval(conjugate(log(x)), x = -1)

   (15)  log(- 1)
                                                    Type: Expression(Integer)

you get different result depending on when exactly we plug in
constant argument to logarithm.

You have:

(21) -> conjugate(log(conjugate(x) + x))

             _
   (21)  log(x + x)
                                                    Type: Expression(Integer)

but when real part of x is negative we are on the conventional
branch cut of logarithm and some folks may be upset by such
simplification (not that unlike previous example where problem
set was of lower dimension here we have problem on open set).

> 
> The reason that I wanted D(conjugate(x), x) = 0 is to have D
> correspond to the first Wirtinger derivative that I mentioned in
> another email chain.  It is not clear to me that this could result in
> nasty bugs.  Maybe this is possible in the cases where the chain rule
> is applied since in that case the conjugate Wirtinger derivative would
> be required.

But chain rule is applied automatically when computing derivatives.
Consider:

(13) -> D(abs(x + conjugate(x)), x)

            _
            x + x
   (13)  -----------
              _
         2abs(x + x)
                                                    Type: Expression(Integer)

complex (Wirtinger) derivative of the above is twice of the above.

> 
> > If what I wrote looks like nitpicking let me note that FriCAS
> > blindly applies rather complex transformations.  For example
> > during integration internal form is quite different than
> > user input and final result.  Inconsistency in derivative
> > rule will bring all kinds of nasty bugs.
> >
> > We probably can leave derivative of 'conjugate' unevaluated.
> 
> Maybe only as a last resort.  (This is what Maple does.)

Actually, it seems that even leaving derivatives of conjugate
unevaluated we need to be careful.  Namely, given
a differential Ring R_0 and any formal operation f we can form
differential ring R_1 where f and all its derivative remain
unevaluated.  But we want to have _some_ simplification
so we divide R_1 by appropriate equivalence relation.
For the result to be a differential ring equivalence
classes should be cosets of a differential ideal, in
particular set of elements of R_1 equivalent to 0
should be a differential ideal.  So we need to make
sure that simplifications are consistent with
derivative.

> > But even that needs some thought to make sure there are
> > no inconsistency.  Signaling error would be safe from
> > correctness point of view, but would significantly limit
> > usefulness -- code handling expressions assumes that it
> > can freely compute derivatives, so when dealing with
> > 'conjugate' we would routinely get errors deep inside
> > library code.
> >
> 
> I would like to collect some examples of such errors.


With your current code:

(24) -> normalize(exp(conjugate(x)+x)+exp(x) + exp(conjugate(x)))
   _
 
   >> Error detected within library code:
   Hidden constant detected

With derivative of 'conjugate' changes to error:

(1) -> integrate(exp(conjugate(y)*x), x)
 
   >> Error detected within library code:
   differentiating conjugate

(3) -> normalize(exp(conjugate(y)*x)+exp(x))
 
   >> Error detected within library code:
   differentiating conjugate

(3) -> limit(exp(conjugate(y)*x), x=%plusInfinity)
 
   >> Error detected within library code:
   differentiating conjugate

(3) -> series(conjugate(x), x=1)

 
   >> Error detected within library code:
   differentiating conjugate

-- 
                              Waldek Hebisch
[email protected] 

-- 
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to