The problem is that trigin1 strips the imaginary part because it assumes that it contains only "garbage" that would simplify to zero. It should actually never do that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The commit says you used radcan. Are you sure that's right? radcan sometimes chooses an unexpected branch which is sometimes wrong. I have a vague memory that I removed calls to radcan in various places because that's what was happening to produce incorrect results.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fair point about radcan in general, but I think we don't need to worry here, for two reasons.
rischint already "radcans" the integrand before it does any real work (intsetup), and uses it in a few other spots too, so by the time this code runs everything's been through radcan anyway. I'm not adding it to a radcan-free path.
I only use it as a test, never in the output. risplit gives me the real and imaginary parts of the antiderivative and I return those unchanged. radcan just helps decide whether a part's derivative is zero, so we can drop it as a constant of integration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds good. I do wonder now if the existing radcans cause issues. Seems that it's ok. There aren't a lot (if any?) issues on rischint producing bad answers. But haven't checked the bug list in a while for this.
The mailing list does have examples of radcan simplifying things to zero, but you wouldn't get that by hand because you wouldn't choose those branch cuts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been working on fixing some bugs that are caused by rischint using radcan. Mostly wrong signs in antiderivatives and definite integrals, due to sqrt(x^2) becoming x instead of abs(x) for real x. This will fix tons of bugs in one commit :) Expect a message to the mailing list soon ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is that
trigin1strips the imaginary part because it assumes that it contains only "garbage" that would simplify to zero. It should actually never do that.Fixed by commit [40a2ab].
Related
Commit: [40a2ab]
The commit says you used radcan. Are you sure that's right? radcan sometimes chooses an unexpected branch which is sometimes wrong. I have a vague memory that I removed calls to radcan in various places because that's what was happening to produce incorrect results.
Fair point about
radcanin general, but I think we don't need to worry here, for two reasons.rischintalready "radcans" the integrand before it does any real work (intsetup), and uses it in a few other spots too, so by the time this code runs everything's been throughradcananyway. I'm not adding it to a radcan-free path.risplitgives me the real and imaginary parts of the antiderivative and I return those unchanged.radcanjust helps decide whether a part's derivative is zero, so we can drop it as a constant of integration.Sounds good. I do wonder now if the existing radcans cause issues. Seems that it's ok. There aren't a lot (if any?) issues on rischint producing bad answers. But haven't checked the bug list in a while for this.
The mailing list does have examples of radcan simplifying things to zero, but you wouldn't get that by hand because you wouldn't choose those branch cuts.
I've been working on fixing some bugs that are caused by
rischintusingradcan. Mostly wrong signs in antiderivatives and definite integrals, due tosqrt(x^2)becomingxinstead ofabs(x)for realx. This will fix tons of bugs in one commit :) Expect a message to the mailing list soon ...