Waldek Hebisch <[EMAIL PROTECTED]> writes: > Let me say that I am pretty sceptical about changing current _symbolic_ > formulas (as I wrote for numerics the proposed changes are OK).
I realized this, and I see your point. I am hoping to have both. Now, one of my goals is to have numeric integrate(ex, x=a..b) = romberg(ex, a, b, ...) and also, that draw produces consistent results. You say that acos z == 4*atan(sqrt((1-z)/2)/(1+sqrt(1-((1-z)/2)))) is not good, and I was unable to find something better, perhaps there isn't such a formula. (You already mentioned that defining acos z == %pi/2 - 2*atan(z/(sqrt(1-z^2)+1)) doesn't make you happy either - because of the constant... Curiously, using this latter definition for integrate(acos(sin(2*z))*cos(z), z= 0..4*%pi/3) gives the same result as is currently given...) 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. Of course, the cost would then be that we loose comparability with other systems, but I think this is acceptable as long we are consistent ourselves. I guess, the main difficulty is to find formulas such that "desired identities" hold. > integrate(sqrt(1 - z)*sqrt(sqrt(1 + z^2)), z) > > Axiom used to simplify the integrand to: > > sqrt((1 - z)*sqrt(1 + z^2)) > > which quickly hits unimplemented branch in Bronstein algorithm: > > >> Error detected within library code: > integralBasis: possible wild ramification > > However, currently simplification sqrt(x)*sqrt(y) = sqrt(x*y) is > blocked and (IIRC) the original form needs more than week to > arrive to the same conclusion. It seems to me that this is a different problem: 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. Actually, FriCAS does a little of this, when it returns a list of results, doesn't it. > > In the testsuite I found the integral > > > > in211:=integrate(acos(sin(2*z))*cos(z), z= 0..4*%pi/3) > > Do not count on correct result from this integral, the > values of integrand go trough branch (2*z changes > from 0 to (8/3)*%pi, which is more than %pi and on interal > longer than %pi sin is not 1 to 1). Sorry, I do not understand. Do we rely on sin being 1-1 in the range of integration? In what way? Are the transformations in k2elem the only ones used? Would you agree to adapt branch cuts of numerical functions to agree with the "normalized" functions? (i.e., do things the other way round) At least integrate(acos(sin(2*z))*cos(z), z= 0..4*%pi/3) would then be correct... I think we should revert the documentation patch, because it's complete bogus, it seems... (because of the mistake in the definition of the branchcuts of atan, and because of the inconsistency with symbolics) Sorry for so many questions, I thought this task would be rather straightforward, but it turned out to be quite complex... Martin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
