Bill Page wrote:
>
> On 14 September 2014 18:18, Waldek Hebisch <[email protected]> wrote:
>
> > But once you have 'abs' and 'conjugate' in 'Expression' assumption
> > that all functions are holomorphic is unsound.
>
> conjugate is sufficient since we want abs(x)=sqrt(x*conjugate(x)).
>
> We should not make the assumption that all functions are holomorphic.
Yes.
>
> > So using only one Wirtinger derivative in 'Expression' is unsound.
>
> Thank you for explaining what you meant by "unsound".
>
> > To make it sound you need to handle _both_ derivatives.
>
> Yes.
>
> > But then you get something quite different than 'Expression'.
>
> That is not clear to me. I think it is (almost) the same.
Some people say that mutivariate calculus is almost the
same as univariate. But there are significant differences.
Having two Wirtinger derivatives we have bivariate calculus
instead of univariate one.
>
> > In Axiom
> > spirit one could define new domain which uses Wirtinger
> > derivatives (say special variant of 'Complex').
>
> You mean maybe that
>
> Complex Expression Integer
>
> could export a symbolic conjugate and Wirtinger derivatives? This
> seems awkward to me. Wouldn't we also need to redefine FunctionSpace?
Yes.
>
> > Or
> > we could follow M-s and use assumption system and
> > runtime test to decide if we can use single Wirtinger
> > derivative.
>
> No. I've used this and I don't like it.
>
> If we have a good conjugate function then we may define other
> nonholomorphic functions like
>
> real(x) = x/2 + conjugate(x)/2
>
> so assumptions are not needed.
I do not understand why you say "so assumptions are not needed".
IMO one of main simplifications for 'real' is replacing
'real(x)' by 'x' when 'x' is real. Clearly assumptions
make such simplification more powerful.
> >> that it assumes that f(x) cannot be independent of x
> >
> > Which is _fundamental_ assumption in 'Expression'.
> >
>
> I am not convinced that it is fundamental
Theoretical foundation of advanced expression manipulations
is theory of differential fields (and rings). There are
multivariate extensions, but several results is univariate-only.
> >> ...
> >> The example shows that normalize now normalizes expressions containing
> >> conjugate successfully, but of course more testing is needed.
> >
> > Correctness of 'normalize' is a theorem. In particular, 'normalize'
> > is a zero test "modulo constants". You dropped one of main
> > assumption of this theorem.
>
> Which assumption specifically?
That we work with differential field with one derivative per
variable.
>
> > Richardson theorem tells you that
> > once you drop this assumption you no longer can have computable
> > zero test (even "modulo constants").
>
> My (probably limited) understanding is that Richardson's theorem
> forbids abs. Note: abs is already in Expression. I only want to add
> conjugate.
Well, if you want "proper" handling already 'abs' is problematic.
'conjugate' just adds a new method of defining 'abs'. So why
I do not oppose to 'abs'? For 'abs' applied to real arguments
there is a way to sidestep the problem. Namely, 'abs(x)' is
either 'x' or '-x' (with overlap when 'x' is 0). So given
expression containing 'abs' is equivalent to a alternative
of finitely many cases, each case containing no 'abs'. By
Richardson in general we can not decide which case is the
right one. But for many problems doing computations
simultaneously on all cases gives us conservative approximation.
Also, when 'x' is not 0, then 'abs(x)/x' is a "piecewise constant"
(its derivative is 0). This means that problems with with 'abs'
can be reduced to "constants". We still have problem with
"constants" (that is expressions with derivative 0) containing
'abs'. But they are lessened by fact that we do almost no
simplifications of 'abs' -- in many calculations 'abs' behaves
like undefined function. There are gaps in this argument, and
our implementation has no explicit treatment of cases (which
may lead to problems with zero divisors). However, there is
reasonably clear way to eliminate exisiting unsoudness.
This argument break down when we have 'abs' of complex argument.
So currently using 'abs' of complex argument is potentially
unsound (in principle can lead to wrong results). Once
we use first Wirtinger derivative as derivative of 'conjugate',
to be consistent we need to use first Wirtinger derivative as
a derivative of 'abs'. But this is inconsistent with treatment
of 'abs' as a real function.
Note1: Richardson theorem says that we can not have complete
handling of 'abs' or 'conjugate'. What I wrote above about
'abs' outlines one approach which is incomplete but computable.
Similarely, for 'conjugate' we need to find incomplete, but
computable approximation.
Note2: if derivative of 'conjugate' is left undefined, there
are plausible arguments that this does not lead to wrong
results.
> > But expression machinery to avoid Richardson theorem
> > must make some restricions. Current theory basically
> > forbids 'conjugate'. To admit conjugate we need some
> > extra restrictions.
>
> Why do you say that it forbids conjugate. Can you give a reference?
Because we assume univariate setting (more precisely single
derivative per variable). To be more precise: there are
no obvious problems with leaving derivative of 'conjugate'
undefined. But _any_ definition of derivative leads to
two independent derivatives per variable.
>
> >>
> >> I am not aware of any assumptions that are needed.
> >
> > Consider:
> >
> > (3) -> conjugate(log(complex(-1.0, 0)))
> >
> > (3) - 3.1415926535_897932385 %i
> > Type:
> > Complex(Float)
> > (4) -> log(conjugate(complex(-1.0, 0)))
> >
> > (4) 3.1415926535_897932385 %i
> > Type:
> > Complex(Float)
> >
> > Do you still think that all users always want
> > 'conjugate(log(x)) = log(conjugate(x))'? I would say
> > to perform this transformation we need apropriate
> > assumptions.
>
> log of negative number is multi-valued. The result above is not any
> worse than returning -2 for sqrt(4) or similar in the case of inverse
> trig functions.
Sure. But you can find a lot of folks who call such behaviour
a bug. Certainly it would be nice to be able to disable
such transformations. But then you will have problems with
chain rule.
--
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.
