Dear Waldek,

* I'm really trying to understand, please bear with me...

* I delete some text so that the amount of text to read stays managable.  I
  hope I do not put text out of context...

> > Now, I see one other possibility: change the branch cuts of the numeric
> > functions.  I.e., we could start with symbolics and deduce numerics from
> > them.
> 
> Unfortunatly no, we have two non isomorphic domains: Expression which is a
> differential field and numeric functions.  There are partial isomorfizms
> which in many cases allows to pass between then, but the correspondence can
> not be perfect (more details later).

I think this is what I need to understand better...

> > It seems to me that [there are two] different problem[s]: defining
> >
> >   acos z == 4*atan(sqrt((1-z)/2)/(1+sqrt(1-((1-z)/2))))
> >
> > or
> >
> >   acos z == atan(sqrt((1-z^2)/z)
> >
> > is not a matter of simplification, but rather definition.  I'm completely
> > happy with the second definition, as long as it is consistent with numerics
> > and with identities that are applied automatically.
> >
> > Simplifying square roots or acos cos x is in my opinion a quite different
> > business: yes, we want to do that, but whenever we do it, we need to
> > analyse the domains of validity.
> 
> Well, in differential field we have to simplify, otherwise we may divide by
> zero.

I don't understand: of course we want that "perfect" simplifications or
normalisations like sin asin z = z and asin z = 2*atan(z/(sqrt(1-z^2)+1)) are
performed.  But neither asin sin z nor sqrt(z^2) are equal to zero, are they?

Since we (seem to) need to simplify asin sin z to z in integration code, we
will need to have assumptions there, I'm not arguing about that.  Eg.

  sqrt(z^2) gives two cases, namely z for re z >= 0 and -z for re z < 0.

And I do understand that

> (however, even relatively simple functions may produce infinite number of
> conditions).

but at least one can try...

> > Sorry, I do not understand.  Do we rely on sin being 1-1 in the range of
> > integration?  In what way?
> 
> From analitical point of view Expression consists of meromorfic
> functions in some unspecified domain (due to principle of unique
> continuation exact domain does not matter).  Given acos(sin(2*z))
> normalize gives:
> 
>         - 4z + %pi
>    (1)  ----------
>              2
> 
> and this is probably what we use.

Yes, I think so.

> OTOH any numercal acos(sin(2*z)) is going to give dirferent result:
> normalized version is 1 to 1, while numeric is not (due to sin(2*z)
> not beeing 1 to 1).

Yes.  Thus, acos(sin(2*z)) in Float is a different function then acos(sin(2*z))
in EXPR INT.  Actually, acos$Float is pretty close to acos$HyperSpec, but
normalize acos z is a *very* different function:

-- from the HyperSpec:
acos0(z: Complex Float): Complex Float == complexNumeric 
eval(%pi/2+%i*log(%i*z+sqrt(1-z^2)), 'z, z)

-- disagrees at real x with |x| > 1.0 with acos0
-- negative x-axis: acos0 - acos1 = %pi
-- positive x-axis: acos0 - acos1 = -%pi
acos1(z: Complex Float): Complex Float == acos z

-- disagrees with acos0 in 
-- positive y-axis: acos0 - acos2 = %pi
-- quadrant II:     acos0 - acos2 = %pi
-- negative x-axis: acos0 - acos2 = %pi
-- quadrant III:    acos0 - acos2 = %pi
-- agrees with acos0 in quadrant I and IV, positive x-axis
acos2(z: Complex Float): Complex Float == complexNumeric eval(normalize acos 
'z, 'z, z)

> Whant is more: it is impossible to find (read: choose branch cuts to
> get) meromorphic version of acos(sin(2*z)) which agrees with numeric
> one.

Sorry, again I do not understand.  Are you saying that no matter how we define
normalize acos z and branch cuts of acos$Float (in a sensible way, in
particular such that cos acos z = z), we will always find a function f such
that

  normalize acos f z and acos$Float f z 

disagree?  If so, why?

But actually, I cannot quite believe this.  If we take

acos z == 4*atan(sqrt((1-z)/2)/(1+sqrt((1+z)/2)))

as definition in Float, and also as normalized form of acos, then things should
stay correct.  Except of course, that the definition is horrible
perfomancewise...  Maybe you could elaborate?

(Just to make it clear: I do understand that we *also* need to perform
transformations that are not true everywhere.  But I'd like to keep those
separated from simplifications performed automatically, and whenever they are
performed, the other "branches" should also be computed)

I asked for a "good" normalized form of acos z in sci.math.symbolic, and was
asked why exactly the constant

acos z == %pi/2-asin(z)
       == 2*atan 1 - 2*atan(z/(sqrt(1-z^2)+1))

would be bad.  Could you elaborate a little?


Martin

Remark: I noticed that

myacos2 z  == normalize acos z
ex2 := normalize(myacos2(sin(2*z))*cos(z));
numeric(integrate(ex2, z=0..4*%pi/3, "noPole")::EXPR INT)
romberg(z +-> numeric eval(ex2, 'z, z), 0, 4*%pi/3, 0.1, 0.1, 10, 20)

actually agree, i.e., both give 8.894847934...

However:

-- disagrees, giving 8.894847934 and - 2.281876971
ex0c := normalize(myacos0c(sin(2*z))*cos(z));
numeric(integrate(ex0c, z=0..4*%pi/3, "noPole")::EXPR INT)
romberg(z +-> real complexNumeric eval(ex0c, 'z, z), 0, 4*%pi/3, 0.1, 0.1, 10, 
20)
-- error
-- romberg(z +-> numeric eval(ex0c, 'z, z), 0, 4*%pi/3, 0.1, 0.1, 10, 20)

-- disagrees, giving 3.453449841 and - 2.281876971
ex3b := normalize(myacos3b(sin(2*z))*cos(z));
numeric(integrate(ex3b, z=0..4*%pi/3, "noPole")::EXPR INT)
romberg(z +-> numeric eval(ex3b, 'z, z), 0, 4*%pi/3, 0.1, 0.1, 10, 20)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to