Opened 5 years ago
Closed 4 years ago
#20084 closed defect (fixed)
residue: mathematically wrong output
Reported by:  behackl  Owned by:  

Priority:  major  Milestone:  sage8.0 
Component:  symbolics  Keywords:  
Cc:  rws, cheuberg  Merged in:  
Authors:  Benjamin Hackl  Reviewers:  Frédéric Chapoton 
Report Upstream:  N/A  Work issues:  
Branch:  68fea61 (Commits, GitHub, GitLab)  Commit:  68fea61960a41972282076686c2c59611c496a07 
Dependencies:  Stopgaps: 
Description
The complex function f(s) = 1/(1  2^(s))
has poles of residue 1/log(2)
at s = 2*k*pi*I/log(2)
for all integers k
.
Currently sage recognize these poles just at s=0
:
sage: f(s).residue(s==0) 1/log(2) sage: f(s).residue(s==2*pi*I/log(2)) 0
In essence, this happens because the series
method does not recognize the pole. The priority is critical because mathematically wrong output is produced.
Change History (12)
comment:1 Changed 5 years ago by
comment:2 Changed 5 years ago by
 Branch set to u/behackl/symbolics/residue/expcomplexpoles
 Commit set to 45d16e2c9301626ff1da1bb229f955209f17e93a
 Status changed from new to needs_info
This is just the quick workaround from above.
New commits:
45d16e2  simplify substituted expression before series expansion

comment:3 Changed 5 years ago by
 Status changed from needs_info to needs_work
Please add an example doctest to illustrate what you're fixing.
comment:4 Changed 5 years ago by
 Commit changed from 45d16e2c9301626ff1da1bb229f955209f17e93a to 87193643462062096a9b48dd07c76765bb525002
Branch pushed to git repo; I updated commit sha1. New commits:
8719364  add a doctest

comment:5 Changed 5 years ago by
Is it ready for review?
comment:6 followup: ↓ 7 Changed 4 years ago by
update from the future:
sage: (1/(1  2^x)).residue(x == 2*pi*I/log(2)) 1/log(2) sage: version() 'SageMath version 7.6.beta6, Release Date: 20170303'
some updates in series
may affect that now it can recognize the pole without having to call canonicalize_radical()
?
comment:7 in reply to: ↑ 6 ; followup: ↓ 8 Changed 4 years ago by
Yes, I have faint memory of improving something with series
itself some time ago; thanks for reminding me.
Actually, there are more problems with residue
. Take, for example,
sage: (1/sqrt(x^2)).residue(x==0) 0 sage: (1/sqrt(x^2)).canonicalize_radical().residue(x==0) 1
(Note that this is, in some sense, a pathological example.)
The ideal fix in this case (IMHO) would be to throw an error that the residue could not be computed as the "correct" branch of the root could not be chosen automatically. I think that just applying canonicalize_radical
before computing the residue just introduces more grief as the user looses all control over which branch is chosen.
In any case: the original problem reported with this ticket is solved, so this is probably just wontfix. Other opinions?
Replying to mforets:
update from the future:
sage: (1/(1  2^x)).residue(x == 2*pi*I/log(2)) 1/log(2) sage: version() 'SageMath version 7.6.beta6, Release Date: 20170303'some updates in
series
may affect that now it can recognize the pole without having to callcanonicalize_radical()
?
comment:8 in reply to: ↑ 7 Changed 4 years ago by
Replying to behackl:
Yes, I have faint memory of improving something with
series
itself some time ago; thanks for reminding me. ... In any case: the original problem reported with this ticket is solved, so this is probably just wontfix. Other opinions?
cool. for what i've been told from other tickets, i suppose this one should should still provide the test (not wontfix):
Check that :trac:`20084` is fixed:: sage: (1/(1  2^x)).residue(x == 2*pi*I/log(2)) 1/log(2)
Actually, there are more problems with residue. ... (Note that this is, in some sense, a pathological example.)
yes. one could come up with other examples (e.g. examples involving log(z)). i agree that just applying canonicalize_radical
is not a good idea for the reason you stated. but is there a simple way to identify these cases without much hurdle? does this belong to series
method or is sth that can be done at the level of residue
?
comment:9 Changed 4 years ago by
@behackl : if you remove the canonicalize_radical
keeping the test, i can review it! (or the other way round).
wrt handling pathological examples, yes IMO it is a relevant future task, although as pointed out before i cannot help right now, since i'm not visualizing a workaround :/
comment:10 Changed 4 years ago by
 Branch changed from u/behackl/symbolics/residue/expcomplexpoles to public/20084
 Commit changed from 87193643462062096a9b48dd07c76765bb525002 to 68fea61960a41972282076686c2c59611c496a07
 Reviewers set to Frédéric Chapoton
 Status changed from needs_work to positive_review
comment:11 Changed 4 years ago by
 Milestone changed from sage7.1 to sage8.0
 Priority changed from critical to major
comment:12 Changed 4 years ago by
 Branch changed from public/20084 to 68fea61960a41972282076686c2c59611c496a07
 Resolution set to fixed
 Status changed from positive_review to closed
The most elegant solution would of course be the automatic simplification of expressions like
2^(something/log(2)) > exp(something)
, such thatHowever, I'm not sure if that can be achieved so easily.
A second suggestion would be something like {{{diff diff git a/src/sage/symbolic/expression.pyx b/src/sage/symbolic/expression.pyx index 3a5c864..175bcad 100644  a/src/sage/symbolic/expression.pyx +++ b/src/sage/symbolic/expression.pyx @@ 4076,7 +4076,7 @@ cdef class Expression(CommutativeRingElement?):
+ return self.subs({x: x+a}).canonicalize_radical().series(x == 0, 0).coefficient(x, 1)
}}}