Opened 3 years ago

Closed 2 years ago

#22422 closed enhancement (fixed)

Laplace transform involving time-shifts

Reported by: mforets Owned by:
Priority: major Milestone: sage-8.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) Commit: f845269bbd0cf1843286b0394fd9890fa0670ead
Dependencies: Stopgaps:

Description (last modified by mforets)

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(t-1), 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 real-rational functions with any number of real exponentials linear in the transform variable s (time-shifts) in the numerator. For consistency, the direct Laplace transform with a heaviside should also work as well.

These are some approaches:

(1) Implement an in-house 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(t-1)

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 3 years ago by paulmasson

  • Cc rws added

comment:2 Changed 3 years ago by mforets

  • Branch set to u/mforets/laplace_transform_involving_time_shifts

comment:3 follow-up: Changed 3 years ago by mforets

  • Authors set to Marcelo Forets
  • Commit set to 20963880dfbc18035cea6159eb13d5c71b0fda59
  • Description modified (diff)
  • Status changed from new to needs_info

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.


New commits:

2096388Added algorithm='sympy' (needs work) and algorithm='giac' (needs info).

comment:4 follow-up: Changed 3 years ago by rws

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 ; follow-up: Changed 3 years ago by 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 root-directory:/home/fred-dev/sage/develop/sage.develop/local/share/giac/
// Giac share root-directory:/home/fred-dev/sage/develop/sage.develop/local/share/giac/
Help file /home/fred-dev/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 3 years ago by mforets

@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 3 years ago by git

  • Commit changed from 20963880dfbc18035cea6159eb13d5c71b0fda59 to a3a43d2920a234bc300771dd313f3dcb4564d513

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

a3a43d2A solution for heaviside <-> Heaviside.

comment:8 follow-up: Changed 3 years ago by mforets

  • 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_()
  • to-do: add doctests

comment:9 in reply to: ↑ 8 ; follow-up: Changed 3 years ago by 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 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 3 years ago by mforets

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 place

This works for heaviside but wil create problems for Sage functions with capital letters like bessel_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 follow-up: Changed 3 years ago by mforets

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 3 years ago by git

  • Commit changed from a3a43d2920a234bc300771dd313f3dcb4564d513 to 3732a8cea8092e71d91b08aeb7cd7b8c46215aba

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

3732a8cadd new doctests and a very basic parse function at giac.py

comment:13 Changed 3 years ago by mforets

  • Status changed from needs_work to needs_review

comment:14 in reply to: ↑ 11 ; follow-up: Changed 3 years ago by paulmasson

Replying to mforets:

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.

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 follow-up: Changed 3 years ago by paulmasson

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 3 years ago by mforets

  • Status changed from needs_review to needs_work

comment:17 Changed 3 years ago by git

  • Commit changed from 3732a8cea8092e71d91b08aeb7cd7b8c46215aba to dc35047155862deac04cca42fdc2d48f47cd20e2

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

1454679delete unused un_camel function
dc35047use keyword algorithm in calculus.py

comment:18 in reply to: ↑ 14 Changed 3 years ago by mforets

Replying to paulmasson:

Replying to mforets:

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.

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?

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 ; follow-up: Changed 3 years ago by mforets

Replying to paulmasson:

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.

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 2 years ago by git

  • Commit changed from dc35047155862deac04cca42fdc2d48f47cd20e2 to 4aae4f59ba9506ad05a4209b665fae27f58dc230

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

4aae4f5Use symbol_table for giac -> sage conversion.

comment:21 in reply to: ↑ 19 ; follow-up: Changed 2 years ago by mforets

Replying to mforets:

Replying to paulmasson:

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.

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?

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 2 years ago by mforets

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 root-directory:/home/fred-dev/sage/develop/sage.develop/local/share/giac/
// Giac share root-directory:/home/fred-dev/sage/develop/sage.develop/local/share/giac/
Help file /home/fred-dev/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)
<ipython-input-1-c91665cb8326> 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 follow-up: Changed 2 years ago by 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.

comment:24 follow-up: Changed 2 years ago by 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.

comment:25 in reply to: ↑ 21 ; follow-ups: Changed 2 years ago by 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)/(s-1),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 2 years ago by paulmasson

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 2 years ago by frederichan

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)/(s-1),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://www-fourier.ujf-grenoble.fr/~parisse/giac/doc/en/cascmd_en/cascmd_en.html

comment:28 in reply to: ↑ 23 Changed 2 years ago by mforets

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 2 years ago by mforets

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)/(s-1),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 2 years ago by git

  • Commit changed from 4aae4f59ba9506ad05a4209b665fae27f58dc230 to 4f347e2b56c928faf9ba24ac8fb1efd533cfdca2

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

c1f20cbdocstring improvements
4f347e2fix another typo in docstring

comment:31 Changed 2 years ago by mforets

  • Status changed from needs_work to needs_review

comment:32 Changed 2 years ago by mforets

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 2 years ago by frederichan

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 2 years ago by git

  • Commit changed from 4f347e2b56c928faf9ba24ac8fb1efd533cfdca2 to 0577b5b29296ed8617f4d4b9a30b7f1353f4e694

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

5936013simplify calls to giac
0577b5badd register_symbol explanation and example to giac.py

comment:35 Changed 2 years ago by git

  • Commit changed from 0577b5b29296ed8617f4d4b9a30b7f1353f4e694 to f5979029e901554e094d0261134112b3624d618b

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

f597902minor docstring modif

comment:36 follow-ups: Changed 2 years ago by paulmasson

  • Milestone changed from sage-7.6 to sage-8.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 ; follow-up: Changed 2 years ago by rws

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, in calculus.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 2 years ago by git

  • Commit changed from f5979029e901554e094d0261134112b3624d618b to f845269bbd0cf1843286b0394fd9890fa0670ead

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

e4fc9e0fix some double backticks
8267dfdadded conversions and cleanup to giac.py doc
caae8dfadd 2 seealso blocks
f845269fix authors string

comment:39 in reply to: ↑ 36 Changed 2 years ago by mforets

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

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 2 years ago by mforets

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 2 years ago by rws

  • 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 reviewers---just change if you don't want that.

comment:42 Changed 2 years ago by vbraun

  • Branch changed from u/mforets/laplace_transform_involving_time_shifts to f845269bbd0cf1843286b0394fd9890fa0670ead
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.