Opened 4 years ago
Closed 4 years ago
#22422 closed enhancement (fixed)
Laplace transform involving timeshifts
Reported by:  mforets  Owned by:  

Priority:  major  Milestone:  sage8.0 
Component:  calculus  Keywords:  laplace, transform, symbolics, giac, heaviside 
Cc:  kcrisman, paulmasson, frederichan, rws  Merged in:  
Authors:  Marcelo Forets  Reviewers:  Paul Masson, Ralf Stephan 
Report Upstream:  N/A  Work issues:  
Branch:  f845269 (Commits, GitHub, GitLab)  Commit:  f845269bbd0cf1843286b0394fd9890fa0670ead 
Dependencies:  Stopgaps: 
Description (last modified by )
Sage allows to compute the inverse Laplace transform through Maxima's ilt
function,
sage: var('s t') sage: inverse_laplace(1/s, s, t) 1
An unevaluated expression is returned when no explicit inverse Laplace transform is computed, as in
sage: inverse_laplace(exp(s)/s, s, t) ilt(e^(s)/s, s, t)
The result in this case is h(t1), where h is the Heaviside step function. In Sage it is available as heaviside
.
The problem in this ticket is to extend the current behavior of inverse_laplace
to provide explicit expressions for proper realrational functions with any number of real exponentials linear in the transform variable s (timeshifts) in the numerator. For consistency, the direct Laplace transform with a heaviside should also work as well.
These are some approaches:
(1) Implement an inhouse solution, possibly in the lines of this answer.
(2) Add an algorithm
flag that allows to choose sympy
(similar to integration).
(3) Interface with Giac/XCAS. With this package installed, it is possible to do:
sage: giac('invlaplace(exp(s)/s, s, t)') Heaviside(t1)
IMHO, a combination of (2)(3) is the more robust approach. A small set of experiments show that (3) is, at the time of writing, more convenient than inverse_laplace_transform
of SymPy? in terms of quality of solution and execution time. Unfortunately, the giac interface does not currently support automatic translation back to the symbolic ring, as it does with SymPy? objects via SR(..).
Any recommendations?
See also:
Change History (42)
comment:1 Changed 4 years ago by
 Cc rws added
comment:2 Changed 4 years ago by
 Branch set to u/mforets/laplace_transform_involving_time_shifts
comment:3 followup: ↓ 5 Changed 4 years ago by
 Commit set to 20963880dfbc18035cea6159eb13d5c71b0fda59
 Description modified (diff)
 Status changed from new to needs_info
comment:4 followup: ↓ 6 Changed 4 years ago by
Code looking good so far but needs doctests for all code branches. Minor: you seem to change spacing, there are empty hunks in the patch, check your editor configuration.
comment:5 in reply to: ↑ 3 ; followup: ↓ 22 Changed 4 years ago by
Replying to mforets:
Needs info (please see commit message) to transform heaviside via
_giac_()
. Example:sage: f = heaviside(x); f, type(f) (heaviside(x), <type 'sage.symbolic.expression.Expression'>) sage: fg = f._giac_(); fg, type(fg) (heaviside(x), <class 'sage.interfaces.giac.GiacElement'>)But
heaviside(x)
doesn't seem to be understood by giac.
in giac it looks to be Heaviside, so you need to either translate the string or define it in giac:
giac("'heaviside:=Heaviside'") sage: giac(f).integrate(x,1,2) 2 sage: f heaviside(x) sage: type(f) <type 'sage.symbolic.expression.Expression'>
similar with giacpy_sage which have a raw conversion to sage:
sage: from giacpy_sage import * // Giac share rootdirectory:/home/freddev/sage/develop/sage.develop/local/share/giac/ // Giac share rootdirectory:/home/freddev/sage/develop/sage.develop/local/share/giac/ Help file /home/freddev/sage/develop/sage.develop/local/share/giac/doc/fr/aide_cas not found Added 0 synonyms sage: libgiac('heaviside:=Heaviside') 'Heaviside' sage: f=heaviside(x) sage: fg=libgiac(f) sage: fg.integrate(x,1,2) 2 sage: type(fg.integrate(x,1,2)) <type 'giacpy_sage.Pygen'> sage: SR(fg.integrate(x,1,2)) 2 sage: type(SR(fg.integrate(x,1,2))) <type 'sage.symbolic.expression.Expression'> sage: (fg.integrate(x,1,2)).sage() 2 sage: type((fg.integrate(x,1,2)).sage()) <type 'sage.rings.integer.Integer'>
but with Heaviside will be sent to SR as a raw string so you will need some translation back to heaviside also.
comment:6 in reply to: ↑ 4 Changed 4 years ago by
@rws: ok, I am learning such things as doctesting in days84. for the spacing issue good that you pointed this out, I'll be more careful. BTW I use Atom editor, and thanks for the prompt feedback.
@frederichan: thanks for the insight! I see that I could use the conversion at the script level. but then each new Sage function which for some reason needs it, would have to handle the conversion. does it make sense to define this at the level of the giac.py interface?
comment:7 Changed 4 years ago by
 Commit changed from 20963880dfbc18035cea6159eb13d5c71b0fda59 to a3a43d2920a234bc300771dd313f3dcb4564d513
Branch pushed to git repo; I updated commit sha1. New commits:
a3a43d2  A solution for heaviside <> Heaviside.

comment:8 followup: ↓ 9 Changed 4 years ago by
 Status changed from needs_info to needs_work
this is a patch that seems to work :)
 borrowed the
un_camel
method from the mathematica interface, hence conversion back to lowercase heaviside is not done in place  extended the conversion dictionary at
functions/generalized.py
, it does the job when calling _giac_()  todo: add doctests
comment:9 in reply to: ↑ 8 ; followup: ↓ 10 Changed 4 years ago by
Replying to mforets:
this is a patch that seems to work :)
 borrowed the
un_camel
method from the mathematica interface, hence conversion back to lowercase heaviside is not done in place
This works for heaviside
but wil create problems for Sage functions with capital letters like bessel_J
.
comment:10 in reply to: ↑ 9 Changed 4 years ago by
Replying to paulmasson:
Replying to mforets:
this is a patch that seems to work :)
 borrowed the
un_camel
method from the mathematica interface, hence conversion back to lowercase heaviside is not done in placeThis works for
heaviside
but wil create problems for Sage functions with capital letters likebessel_J
.
ok, good. so i suppose the correct way is to implement a basic parser, as suggested in giac.py interface (my comments in #):
def _sage_(self): r""" Convert a giac expression back to a Sage expression. This currently does not implement a parser for the Giac output language, therefore only very simple expressions will convert successfully. Warning: List conversion is slow. ... """ result = repr(self) # this is a string representation if str(self.type()) != 'DOM_LIST' : try: from sage.symbolic.all import SR result = giac2sage(result) # pattern matching e.g. Heaviside > heaviside return SR(result) except Exception: raise NotImplementedError("Unable to parse Giac output: %s" % result) else: return [entry.sage() for entry in self]
a first search for this kind of conversion in some other module didn't give me anything useful yet.
comment:11 followup: ↓ 14 Changed 4 years ago by
for the new keyword argument's name, i would vote for engine
instead of algorithm
.
the former is used for example in base.py. the keyword algorithm
is misleading: a given computational engine may implement different algorithms.
comment:12 Changed 4 years ago by
 Commit changed from a3a43d2920a234bc300771dd313f3dcb4564d513 to 3732a8cea8092e71d91b08aeb7cd7b8c46215aba
Branch pushed to git repo; I updated commit sha1. New commits:
3732a8c  add new doctests and a very basic parse function at giac.py

comment:13 Changed 4 years ago by
 Status changed from needs_work to needs_review
comment:14 in reply to: ↑ 11 ; followup: ↓ 18 Changed 4 years ago by
Replying to mforets:
for the new keyword argument's name, i would vote for
engine
instead ofalgorithm
. the former is used for example in base.py. the keywordalgorithm
is misleading: a given computational engine may implement different algorithms.
While the term engine
is more accurate, algorithm
is already established for a variety of commands, such as integrate
and limit
. Isn't consistency in Sage more important? Unless you're proposing we change all such instances to engine
.
comment:15 followup: ↓ 19 Changed 4 years ago by
In the function _giac2sage
, rather than recreating the conversion dictionary why not use symbol_table
from sage.libs.pynac.pynac
? That dictionary already contains all the defined conversions.
I'm also getting the Unable to parse Giac output
error often. Partly that's because more Giac conversions need to be defined. Will that happen on this ticket or a separate one?
If _un_camel
is no longer used, please remove it.
comment:16 Changed 4 years ago by
 Status changed from needs_review to needs_work
comment:17 Changed 4 years ago by
 Commit changed from 3732a8cea8092e71d91b08aeb7cd7b8c46215aba to dc35047155862deac04cca42fdc2d48f47cd20e2
comment:18 in reply to: ↑ 14 Changed 4 years ago by
Replying to paulmasson:
Replying to mforets:
for the new keyword argument's name, i would vote for
engine
instead ofalgorithm
. the former is used for example in base.py. the keywordalgorithm
is misleading: a given computational engine may implement different algorithms.While the term
engine
is more accurate,algorithm
is already established for a variety of commands, such asintegrate
andlimit
. Isn't consistency in Sage more important?
Yes, good remark.
Unless you're proposing we change all such instances to
engine
.
Not now. Perhaps a better one is interface
, since this name is used in the code and in the documentation.
comment:19 in reply to: ↑ 15 ; followup: ↓ 21 Changed 4 years ago by
Replying to paulmasson:
In the function
_giac2sage
, rather than recreating the conversion dictionary why not usesymbol_table
fromsage.libs.pynac.pynac
? That dictionary already contains all the defined conversions.
Interesting! After a first look, I don't quite understand how to use it. While in giac.py, it uses SR(result)
, in the mathematica interface (which does use symbol_table
), it calls a _sage_repr()
and then symbolic_expression_from_string
which receives a locals
dictionary. For our use case, do we need to specifically pass a locals
translation dictionary for heaviside, or it is automatically added from the definition of the function?
I'm also getting the
Unable to parse Giac output
error often. Partly that's because more Giac conversions need to be defined. Will that happen on this ticket or a separate one?
I suggest that we move on with this ticket for the basic functionality described above, and to create separate tickets to enhance the symbolics with the giac interface in separate ones (also add limit, integrate, solve). If you agree we can create a new subsection "Giac interface" under https://trac.sagemath.org/wiki/symbolics
If
_un_camel
is no longer used, please remove it.
Done.
comment:20 Changed 4 years ago by
 Commit changed from dc35047155862deac04cca42fdc2d48f47cd20e2 to 4aae4f59ba9506ad05a4209b665fae27f58dc230
Branch pushed to git repo; I updated commit sha1. New commits:
4aae4f5  Use symbol_table for giac > sage conversion.

comment:21 in reply to: ↑ 19 ; followup: ↓ 25 Changed 4 years ago by
Replying to mforets:
Replying to paulmasson:
In the function
_giac2sage
, rather than recreating the conversion dictionary why not usesymbol_table
fromsage.libs.pynac.pynac
? That dictionary already contains all the defined conversions.Interesting! After a first look, I don't quite understand how to use it. While in giac.py, it uses
SR(result)
, in the mathematica interface (which does usesymbol_table
), it calls a_sage_repr()
and thensymbolic_expression_from_string
which receives alocals
dictionary. For our use case, do we need to specifically pass alocals
translation dictionary for heaviside, or it is automatically added from the definition of the function?
Oh! it works out of the box!!
sage: from sage.libs.pynac.pynac import symbol_table sage: symbol_table['giac'].copy() {'(1+sqrt(5))/2': golden_ratio, 'Dirac': dirac_delta, 'Heaviside': heaviside, 'pi': pi}
How does the new commit look? In particular, do you suggest to add more functionality relevant for this ticket? Can you supply an example with the Unable to parse Giac output
message? Thanks.
I'm also getting the
Unable to parse Giac output
error often. Partly that's because more Giac conversions need to be defined. Will that happen on this ticket or a separate one?I suggest that we move on with this ticket for the basic functionality described above, and to create separate tickets to enhance the symbolics with the giac interface in separate ones (also add limit, integrate, solve). If you agree we can create a new subsection "Giac interface" under https://trac.sagemath.org/wiki/symbolics
If
_un_camel
is no longer used, please remove it.Done.
comment:22 in reply to: ↑ 5 Changed 4 years ago by
Replying to frederichan:
Replying to mforets:
Needs info (please see commit message) to transform heaviside via
_giac_()
. Example:sage: f = heaviside(x); f, type(f) (heaviside(x), <type 'sage.symbolic.expression.Expression'>) sage: fg = f._giac_(); fg, type(fg) (heaviside(x), <class 'sage.interfaces.giac.GiacElement'>)But
heaviside(x)
doesn't seem to be understood by giac.in giac it looks to be Heaviside, so you need to either translate the string or define it in giac:
giac("'heaviside:=Heaviside'") sage: giac(f).integrate(x,1,2) 2 sage: f heaviside(x) sage: type(f) <type 'sage.symbolic.expression.Expression'>similar with giacpy_sage which have a raw conversion to sage:
sage: from giacpy_sage import * // Giac share rootdirectory:/home/freddev/sage/develop/sage.develop/local/share/giac/ // Giac share rootdirectory:/home/freddev/sage/develop/sage.develop/local/share/giac/ Help file /home/freddev/sage/develop/sage.develop/local/share/giac/doc/fr/aide_cas not found Added 0 synonyms sage: libgiac('heaviside:=Heaviside') 'Heaviside' sage: f=heaviside(x) sage: fg=libgiac(f) sage: fg.integrate(x,1,2) 2 sage: type(fg.integrate(x,1,2)) <type 'giacpy_sage.Pygen'> sage: SR(fg.integrate(x,1,2)) 2 sage: type(SR(fg.integrate(x,1,2))) <type 'sage.symbolic.expression.Expression'> sage: (fg.integrate(x,1,2)).sage() 2 sage: type((fg.integrate(x,1,2)).sage()) <type 'sage.rings.integer.Integer'>but with Heaviside will be sent to SR as a raw string so you will need some translation back to heaviside also.
Hi Frederic,
i have a question in relation to this. In the 2nd line of src/sage/giac.py
, there is (You should prefer the cython interface: giacpy_sage and its libgiac command)
. Is this recommendation relevant to this ticket?
By the way, the 2nd option above (giacpy_sage
) in my local sage install doesn't work, clearly some package is missing (is this expected for a 'standard package'?):
sage: from giacpy_sage import *  ImportError Traceback (most recent call last) <ipythoninput1c91665cb8326> in <module>() > 1 from giacpy_sage import * ImportError: No module named giacpy_sage
A couple more remarks: I've checked for further info here but we have no libgiac
. In libs/giac.py
, i didn't understand if this code is particular for Groebner basis computations, or it is meant to be used more generally. Thanks!
comment:23 followup: ↓ 28 Changed 4 years ago by
giacpy_sage is an optional spkg, but you should be able to install it.
All the files in interfaces are pexpect interfaces for external programs. Among them some (ex: pari, gap, singular) also have a cython interface that works with the c or C++ library directly. There was a wish to prefer the cython interface when avaible.
But as giacpy_sage is optional while giac went standard recently, and as calculus have old entries with the pexepect interface of giac, I think that it is not a problem to do work like this. But indeed it is not natural to work on the pexpect interface too much.
the cython interface to giac is giacpy_sage and it superseeds the pexpect one, but your translation table could be imported by both. So when things will be decided I will update giacpy_sage also if it doesn't slow down conversions of huge expressions.
comment:24 followup: ↓ 26 Changed 4 years ago by
NB: is the local dictionnary usefull? or is it better to keep conversions in one place. It seems one can always do this
sage.libs.pynac.pynac.register_symbol(heaviside,{'giac':'Heaviside'})
if some keyword is missing.
comment:25 in reply to: ↑ 21 ; followups: ↓ 27 ↓ 29 Changed 4 years ago by
Replying to mforets:
Replying to mforets:
Replying to paulmasson:
How does the new commit look? In particular, do you suggest to add more functionality relevant for this ticket? Can you supply an example with the
Unable to parse Giac output
message? Thanks.
Where I'm seeing this error often is when an expression has extra powers of the variable of integration, as for example
inverse_laplace(s^2*exp(s)/(s1),s,t,algorithm='giac')
which returns a derivative of the Dirac delta. At some point we'll want to be able to parse an indefinite number of such derivatives: do you want to do that on this ticket or another?
I'm also getting the
Unable to parse Giac output
error often. Partly that's because more Giac conversions need to be defined. Will that happen on this ticket or a separate one?I suggest that we move on with this ticket for the basic functionality described above, and to create separate tickets to enhance the symbolics with the giac interface in separate ones (also add limit, integrate, solve). If you agree we can create a new subsection "Giac interface" under https://trac.sagemath.org/wiki/symbolics
Sounds fine. I'd be willing to include more Giac translations for special functions on a separate ticket, if you can point me to where the official list of Giac names is located. I'd also like to do some code cleanup on nearby lines pertaining to LaTeX representations in Sage, so if that doesn't bother you we can kill two birds with one stone.
comment:26 in reply to: ↑ 24 Changed 4 years ago by
Replying to frederichan:
NB: is the local dictionnary usefull? or is it better to keep conversions in one place. It seems one can always do this
sage.libs.pynac.pynac.register_symbol(heaviside,{'giac':'Heaviside'})if some keyword is missing.
I agree with Frederic on this: if there is an existing method for extending the Pynac dictionary, then we should use that instead of introducing an additional dictionary. This method should probably be added to the documentation in calculus.py
.
FYI your documentation doesn't build right now because of unbalanced double backticks. Also, single backticks are what we use for inline LaTeX rendering in ReST, not dollar signs.
comment:27 in reply to: ↑ 25 Changed 4 years ago by
Replying to paulmasson:
Replying to mforets:
Replying to mforets:
Replying to paulmasson:
How does the new commit look? In particular, do you suggest to add more functionality relevant for this ticket? Can you supply an example with the
Unable to parse Giac output
message? Thanks.Where I'm seeing this error often is when an expression has extra powers of the variable of integration, as for example
inverse_laplace(s^2*exp(s)/(s1),s,t,algorithm='giac')which returns a derivative of the Dirac delta. At some point we'll want to be able to parse an indefinite number of such derivatives: do you want to do that on this ticket or another?
I'm also getting the
Unable to parse Giac output
error often. Partly that's because more Giac conversions need to be defined. Will that happen on this ticket or a separate one?I suggest that we move on with this ticket for the basic functionality described above, and to create separate tickets to enhance the symbolics with the giac interface in separate ones (also add limit, integrate, solve). If you agree we can create a new subsection "Giac interface" under https://trac.sagemath.org/wiki/symbolics
Sounds fine. I'd be willing to include more Giac translations for special functions on a separate ticket, if you can point me to where the official list of Giac names is located.
In the file:
local/share/giac/doc/aide_cas
lines starting by #
are keywords followed by synonyms, next lines are for small doc and see also.
for full doc it is there:
http://wwwfourier.ujfgrenoble.fr/~parisse/giac/doc/en/cascmd_en/cascmd_en.html
comment:28 in reply to: ↑ 23 Changed 4 years ago by
Replying to frederichan:
giacpy_sage is an optional spkg, but you should be able to install it.
All the files in interfaces are pexpect interfaces for external programs. Among them some (ex: pari, gap, singular) also have a cython interface that works with the c or C++ library directly. There was a wish to prefer the cython interface when avaible.
But as giacpy_sage is optional while giac went standard recently, and as calculus have old entries with the pexepect interface of giac, I think that it is not a problem to do work like this. But indeed it is not natural to work on the pexpect interface too much.
the cython interface to giac is giacpy_sage and it superseeds the pexpect one, but your translation table could be imported by both. So when things will be decided I will update giacpy_sage also if it doesn't slow down conversions of huge expressions.
great, thanks for the detailed answer!
i wasn't aware about register_symbol
, yes we should use it.
on the other hand, i tried to see how locals
dictionary is used in other interfaces. i have the impression that it may be handy in some use cases, in the interactive mode. this example is from mathematica.py
:
compare
sage: ex = giac('myFun(x)') sage: ex._sage_({'myFun': sin}) sin(x)
to
sage: ex = giac('myFun(x)') sage: sage.libs.pynac.pynac.register_symbol(sin, {'giac':'myFun'}) sage: ex._sage_() sin(x)
the long import list is.. complicated.
comment:29 in reply to: ↑ 25 Changed 4 years ago by
Replying to paulmasson:
Replying to mforets:
Replying to mforets:
Replying to paulmasson:
How does the new commit look? In particular, do you suggest to add more functionality relevant for this ticket? Can you supply an example with the
Unable to parse Giac output
message? Thanks.Where I'm seeing this error often is when an expression has extra powers of the variable of integration, as for example
inverse_laplace(s^2*exp(s)/(s1),s,t,algorithm='giac')which returns a derivative of the Dirac delta. At some point we'll want to be able to parse an indefinite number of such derivatives: do you want to do that on this ticket or another?
I'm also getting the
Unable to parse Giac output
error often. Partly that's because more Giac conversions need to be defined. Will that happen on this ticket or a separate one?I suggest that we move on with this ticket for the basic functionality described above, and to create separate tickets to enhance the symbolics with the giac interface in separate ones (also add limit, integrate, solve). If you agree we can create a new subsection "Giac interface" under https://trac.sagemath.org/wiki/symbolics
Sounds fine. I'd be willing to include more Giac translations for special functions on a separate ticket, if you can point me to where the official list of Giac names is located. I'd also like to do some code cleanup on nearby lines pertaining to LaTeX representations in Sage, so if that doesn't bother you we can kill two birds with one stone.
OK. Please see the new ticket #22706. I also created a new subsection at symbolics wiki to group these tickets.
Good finding about the missing support for derivatives of dirac delta! In my opinion it is ok to solve it in a separate ticket, since originally we begun to discuss about transforming proper functions (in the jargon of control theory, meaning that deg numerator <= deg denominator).
comment:30 Changed 4 years ago by
 Commit changed from 4aae4f59ba9506ad05a4209b665fae27f58dc230 to 4f347e2b56c928faf9ba24ac8fb1efd533cfdca2
comment:31 Changed 4 years ago by
 Status changed from needs_work to needs_review
comment:32 Changed 4 years ago by
Oh, and we discussed previously on the locals
dictionary at giac.py
interface, and the consensus was to remove it. Could you please confirm? Thanks
comment:33 Changed 4 years ago by
IF you like this locals then it is OK for me, but a comment in giac.py code to remind and recommend how to use the table would be nice.
by the way why not just:
result = giac.laplace(ex, s, t)
(it looks that the conversion is also done)
comment:34 Changed 4 years ago by
 Commit changed from 4f347e2b56c928faf9ba24ac8fb1efd533cfdca2 to 0577b5b29296ed8617f4d4b9a30b7f1353f4e694
comment:35 Changed 4 years ago by
 Commit changed from 0577b5b29296ed8617f4d4b9a30b7f1353f4e694 to f5979029e901554e094d0261134112b3624d618b
Branch pushed to git repo; I updated commit sha1. New commits:
f597902  minor docstring modif

comment:36 followups: ↓ 37 ↓ 39 Changed 4 years ago by
 Milestone changed from sage7.6 to sage8.0
Doctests all pass and documentation builds.
Single backticks typeset math so they render regular words in italic. All of the code terms in giac.py
should be inside double backticks. Similarly, in calculus.py
the word "cond" should be inside double backticks and one instance of "F" needs single backticks.
The documentation added to giac.py
doesn't appear in the built documents because _sage_
is a private method. Is this a deliberate choice? How does one access the documentation for this method?
comment:37 in reply to: ↑ 36 ; followup: ↓ 40 Changed 4 years ago by
Replying to paulmasson:
Doctests all pass and documentation builds.
Single backticks typeset math so they render regular words in italic. All of the code terms in
giac.py
should be inside double backticks. Similarly, incalculus.py
the word "cond" should be inside double backticks and one instance of "F" needs single backticks.
Apart from these cosmetics I think this ticket is fine.
The documentation added to
giac.py
doesn't appear in the built documents because_sage_
is a private method. Is this a deliberate choice? How does one access the documentation for this method?
As far as I know there is no way to display such docstrings (I have struggled myself with this in the past). If something important is there it should be moved to the global documentation at the top of the file.
comment:38 Changed 4 years ago by
 Commit changed from f5979029e901554e094d0261134112b3624d618b to f845269bbd0cf1843286b0394fd9890fa0670ead
comment:39 in reply to: ↑ 36 Changed 4 years ago by
Replying to paulmasson:
Doctests all pass and documentation builds.
Single backticks typeset math so they render regular words in italic. All of the code terms in
giac.py
should be inside double backticks. Similarly, incalculus.py
the word "cond" should be inside double backticks and one instance of "F" needs single backticks.The documentation added to
giac.py
doesn't appear in the built documents because_sage_
is a private method. Is this a deliberate choice? How does one access the documentation for this method?
thanks for the feedback. for the proper string/latex formatting that's good to fix. the problem i have with ReST is that it is absurdly picky when whitespace messes up the proper format; i think it's too much for 2017 but that's way the way it is i guess..
anyway, in the new commits, both remarks have been addressed, taking into account the suggestion by rws, and improve a bit the tutorial.
comment:40 in reply to: ↑ 37 Changed 4 years ago by
Replying to rws:
As far as I know there is no way to display such docstrings (I have struggled myself with this in the past). If something important is there it should be moved to the global documentation at the top of the file.
sorry for the noise but is there a ticket for this already? just discovered that the algorithm description of solve_linear_de is great, but it is hidden (!)
comment:41 Changed 4 years ago by
 Reviewers set to Paul Masson, Ralf Stephan
 Status changed from needs_review to positive_review
Patchbot has one error but I cannot confirm it, so we're good. Paul, I dared to add your name to reviewersjust change if you don't want that.
comment:42 Changed 4 years ago by
 Branch changed from u/mforets/laplace_transform_involving_time_shifts to f845269bbd0cf1843286b0394fd9890fa0670ead
 Resolution set to fixed
 Status changed from positive_review to closed
Needs info (please see commit message) to transform heaviside via
_giac_()
. Example:But
heaviside(x)
doesn't seem to be understood by giac.New commits:
Added algorithm='sympy' (needs work) and algorithm='giac' (needs info).