Oscar Benjamin

> What about writing a new `laplace_transfrorm_functions` that has a dictionary of transform pairs as an additional argument? That seems reasonable. The existing `laplace_transform` function could be extended with an...

That seems like a good start. There are more rules here that could also be added although it doesn't all have to be done in one go: https://en.wikipedia.org/wiki/List_of_Laplace_transforms

Sounds good to me. Ideally we should try to implement these using pattern-matching as much as possible.

> is there a specific reason pattern matching is the preferred solution? Ideally the code just looks like the same table of rules that you just linked to and then...

Are there any situations where you need to be careful about applying linearity because not all of the integrals converge? For example: ```python In [10]: integrate(1/(x+2) - 1/(x+1), (x, 0,...

> Could you give me some feedback there? You've used `max(l_a)` which will bomb out if you have symbolic expressions: ```python In [7]: max([Symbol('x'), 1]) --------------------------------------------------------------------------- TypeError: cannot determine truth...

Something like this: ```python In [3]: laplace_transform(exp(t), t, s) Out[3]: ⎛ 1 ⎞ ⎜─────, 1, s > 1⎟ ⎝s - 1 ⎠ ```

The `laplace_transform` function is just a function so you can add arguments to it. Or are you actually asking about `LaplaceTransform`? Is it necessary to change LaplaceTransform?

Seems to be an assumptions problem: ```python In [4]: u[0]._assumptions['commutative'] Out[4]: False In [5]: u[0].is_commutative Out[5]: True ``` Looks like the fix is ```diff diff --git a/sympy/tensor/indexed.py b/sympy/tensor/indexed.py index 8119a2a..9c9b6f3...

> Should we try to merge this for the release, or is it too late for that? Can the docs not just be live updated any time?