axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Zero divisors in Expression Integer


From: Waldek Hebisch
Subject: Re: [Axiom-developer] Zero divisors in Expression Integer
Date: Sat, 6 Jan 2007 19:39:42 +0100 (CET)

Francois Maltey wrote:
> Waldek Hebisch <address@hidden> writes:
> 
> [....] 
> 
> > There is an extra difficulty: traditional numerical definitions
> > of elementary functions have branch cuts.  Branch cuts means
> > that we no longer have analytic functions and we may get
> > zero divisors even if algebraic approach would produce unique
> > answer.
>  
> > Branch cuts turn decidable problem into undecidable one:
>  
> > I am not sure how well we want to support branch cuts.  I belive
> > that in most practical cases functions are analytic, for example
> > sqrt(exp(%i*x)) is just exp(%i*x/2) (while branch cut interpretation
> > would produce artifical discontinuities).  
> 
> > In other work "correctly"
> > handling branch cuts means solving hard problem giving result
> > which probably does not match with user expectations...
> 
> > OTOH for numeric computation branch cuts seem to be accepted
> > solution.  Using one definition for symbolic computations
> > and a different one for numeric computations breaks one
> > of fundamental expectations (namely, that evaluating functions
> > at a point is a homomorphizm).
> 
> I find very important this last point of view.
> 
> I try to use and to teach almost(?) the same mathematics with a pencil
> and with a computer algebra system to my students.
>

I should probably clarify what I wrote.  I want Axiom to produce
mathematically correct results.  Since many algorithms used by
Axiom are valid only in algebraic setting corresponding packages
should use algebraic interpretation (otherwise we get wrong
results).  To handle conventions used in calculus we need higher
level packages.  Such packages may for example find out that
x is always positive, so abs(x) = x, or if x changes sign such
package must split computation into two cases, one when abs(x) = x
and the another one where abs(x) = -x, and then finally recombine
the results.  

But the case analysis may get messy (after all the problem is
undecidable) and will have to give up (say return expression 
unevaluated).  My feeling is that when analysing branch cuts
we may give up pretty quickly without loosing much of the
usefull expressions.  OTOH it may be usefull to provide special
versions of log (and friends) which do not have branch cuts
-- such versions are more usefull for complex analysis.

> A lot of formula about sqrt are right because there are the usual
> branch cuts. Without theses branch cuts I fear we can write 
> -1 = 1^(1/2) = 1 and the equal isn't so associative.
>

No, algebraic approach requires irreducible polynomial. 
x^2-1 = (x + 1)*(x - 1) is reducible.  So at low level 1^(1/2) is
illegal.  At higher level 1^(1/2) should be either rejected or
(better) rewriten as 1.
 
> I think the map notion has priority over branch cut.
> For real numbers sqrt (x^2) = abs x is an universal equality 
> because sqrt is a map. 
> 

Yes, but once we allow abs we have zero divisors -- so no function
field can allow abs.  Insted the higher level code must split the
expression into two branches (or delegate the work to a ring)
And I certainly do not want Axiom to belive that 
sqrt((x+%i*y)^2) = abs (x+%i*y)

> When we prefer to write sqrt (x^2) = x we loose the common sens of 
> mathematics and all the map abilities.
> 

IIRC some complex analysis texbooks contain formulas with sqrt which
are invalid if sqrt has branch cuts.

> I give this exercice to my students. 
> Solve in x for a real number a the equation a (a-1) x = a
> (or an other equation as this one)
> With an algebra point of view we get x = 1/(a-1).
> 
> Standard mathematics prefers : a=0 => every x is solution.
>                                a=1 => there is no solution
>                                    => x = 1 / (a-1)
> 
> 0/0 is undefined, even in a/a when a=0
>

You have a point here (Axiom currently gives the first answer).
 
> I prefer a CAS which respect (almost) all mathematics by default.
> 

This is impossible if you want to stay in a single domain.
For example, I freqently use the formula:

exp(x)-exp(y) = integrate(exp((1-s)*x)*(y-x)*exp(s*y), s=0..1)

valid when x and y are (no commuting) operators.  This formula
would be ruined by usual simplifications of exponentials.

Working with differential field we want log(exp(x)) = x.

So really each Axiom domain must implement its on simplifications.

> When the question is undecidable or isn't coded an option 
> as << NoPole >> prevents the user to be prudent. 
> The topic of the #285 bug is almost the same.
> 
> In the elemntry package I test I only simplify by default exp (log z) = z, 
> not log (exp z) = z. 
>

You are doing nice things with expressions.  But have you thought
how your work fits into Axiom design?  Note that if your domain contain
division and you fail to discover zero the you are likely to get wrong
results.  So the approach "simplify only when valid" may work only if
you do not simplify fractions.  And Axiom simplifies fractions when
working with expressions...
 
-- 
                              Waldek Hebisch
address@hidden 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]