Opened 5 years ago

Closed 4 years ago

# residue: mathematically wrong output

Reported by: Owned by: behackl major sage-8.0 symbolics rws, cheuberg Benjamin Hackl Frédéric Chapoton N/A 68fea61 68fea61960a41972282076686c2c59611c496a07

### 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.

### comment:1 Changed 5 years ago by behackl

The most elegant solution would of course be the automatic simplification of expressions like `2^(something/log(2)) --> exp(something)`, such that

```sage: 2^(2*pi*I/log(2))
1
```

However, I'm not sure if that can be achieved so easily.

A second suggestion would be something like

• ## src/sage/symbolic/expression.pyx

```diff --git a/src/sage/symbolic/expression.pyx b/src/sage/symbolic/expression.pyx
 a cdef class Expression(CommutativeRingElement): a = 0 if a == infinity: return (-self.subs({x: 1/x}) / x**2).residue(x == 0) return self.subs({x: x+a}).series(x == 0, 0).coefficient(x, -1) return self.subs({x: x+a}).canonicalize_radical().series(x == 0, 0).coefficient(x, -1) def taylor(self, *args): r"""

where there are several ways to refine this approach:

• introduce an additional keyword that could disable this additional simplification such that performance does not suffer necessarily,
• only try to simplify for complex arguments of `a`

and so on.

Thoughts?

Last edited 5 years ago by behackl (previous) (diff)

### comment:2 Changed 5 years ago by behackl

• Authors set to Benjamin Hackl
• Branch set to u/behackl/symbolics/residue/exp-complex-poles
• 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 was

• Status changed from needs_info to needs_work

### comment:4 Changed 5 years ago by git

• Commit changed from 45d16e2c9301626ff1da1bb229f955209f17e93a to 87193643462062096a9b48dd07c76765bb525002

Branch pushed to git repo; I updated commit sha1. New commits:

 ​8719364 `add a doctest`

### comment:6 follow-up: ↓ 7 Changed 4 years ago by 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: 2017-03-03'
```

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 ; follow-up: ↓ 8 Changed 4 years ago by behackl

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
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?

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: 2017-03-03'
```

some updates in `series` may affect that now it can recognize the pole without having to call `canonicalize_radical()`?

### comment:8 in reply to: ↑ 7 Changed 4 years ago by mforets

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 mforets

@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 chapoton

• Branch changed from u/behackl/symbolics/residue/exp-complex-poles to public/20084
• Commit changed from 87193643462062096a9b48dd07c76765bb525002 to 68fea61960a41972282076686c2c59611c496a07
• Reviewers set to Frédéric Chapoton
• Status changed from needs_work to positive_review

looks good to me

New commits:

 ​311e284 `Merge branch 'u/behackl/symbolics/residue/exp-complex-poles' in 8.0.b6` ​68fea61 `trac 20084 back to just adding an example`

### comment:11 Changed 4 years ago by chapoton

• Milestone changed from sage-7.1 to sage-8.0
• Priority changed from critical to major

### comment:12 Changed 4 years ago by vbraun

• Branch changed from public/20084 to 68fea61960a41972282076686c2c59611c496a07
• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.