On 14 September 2014 18:18, Waldek Hebisch <[email protected]> wrote:
> ... > Let me explain: Wirtinger derivatives are fine. But they form > effectively _bivariate_ calculus. More precisely, instead > of one complex variable we have two derivatives build from > derivatives in two real variables. It isn't necessary to take exactly this view. There are two derivatives but we do not need to think of them as built from real variables. > 'Expression' assumes single derivative per variable. > Wirtinger derivatives have > nice feature that on holomorphic functions the second derivative > is zero and can be ignored, so on holomorphic functions one can > work as in univariate setting. Yes. > 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. > 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. > 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? > 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. > But in current 'Expression' single > derivative per variable is an axiom. > I am not convinced that it needs to be an axiom. >> >> I do not want to opt out anywhere. The problem in EFSTRUC seems to be >> 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 >> ... >> 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? > 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. > So your modified > 'normalize' is not correct if you demand it to be zero test. I agree only that it remains to proven whether it is possible to include conjugate. > It is open question what your 'normalize' is doing, maybe it > is good enough to perform interesting calculations. But > I am affraid that that it is nontrivial work to check and > adapt other parts of Expression machinery. > OK. I am willing to continue to try to check this and suggest changes where necessary. > Let me add that it is quite interesting what you managed > to do with 'conjugate'. But 'D(conjugate(x)) = 0' brings > us unconfortanly close to uncomputable problems. If > we could have 'D(conjugate(x)) = 0' and retain power of > current algortiths, that would be significant progress. It seems to me that this should be one goal of FriCAS: to make significant progress ... > 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? >> >> 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. Bill. -- 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.
