-
-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Laplace transform involving time-shifts #22422
Comments
Commit: |
comment:3
Needs info (please see commit message) to transform heaviside via
But New commits:
|
This comment has been minimized.
This comment has been minimized.
Author: Marcelo Forets |
comment:4
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
Replying to @mforets:
in giac it looks to be Heaviside, so you need to either translate the string or define it in giac:
similar with giacpy_sage which have a raw conversion to sage:
but with Heaviside will be sent to SR as a raw string so you will need some translation back to heaviside also. |
comment:6
@rwst: 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-IMJPRG: 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? |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:8
this is a patch that seems to work :)
|
comment:9
Replying to @mforets:
This works for |
comment:10
Replying to @paulmasson:
ok, good. so i suppose the correct way is to implement a basic parser, as suggested in giac.py interface (my comments in #):
a first search for this kind of conversion in some other module didn't give me anything useful yet. |
comment:11
for the new keyword argument's name, i would vote for |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:14
Replying to @mforets:
While the term |
comment:15
In the function I'm also getting the If |
comment:26
Replying to @frederichan-IMJPRG:
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 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
Replying to @paulmasson:
In the file: http://www-fourier.ujf-grenoble.fr/~parisse/giac/doc/en/cascmd_en/cascmd_en.html |
comment:28
Replying to @frederichan-IMJPRG:
great, thanks for the detailed answer! i wasn't aware about on the other hand, i tried to see how compare
to
the long import list is.. complicated. |
comment:29
Replying to @paulmasson:
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:32
Oh, and we discussed previously on the |
comment:33
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: |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:36
Doctests all pass and documentation builds. Single backticks typeset math so they render regular words in italic. All of the code terms in The documentation added to |
comment:37
Replying to @paulmasson:
Apart from these cosmetics I think this ticket is fine.
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:39
Replying to @paulmasson:
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
Replying to @rwst:
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 (!) |
Reviewer: Paul Masson, Ralf Stephan |
comment:41
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. |
Changed branch from u/mforets/laplace_transform_involving_time_shifts to |
Sage allows to compute the inverse Laplace transform through Maxima's
ilt
function,An unevaluated expression is returned when no explicit inverse Laplace transform is computed, as in
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 choosesympy
(similar to integration).(3) Interface with Giac/XCAS. With this package installed, it is possible to do:
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:
CC: @kcrisman @paulmasson @frederichan-IMJPRG @rwst
Component: calculus
Keywords: laplace, transform, symbolics, giac, heaviside
Author: Marcelo Forets
Branch/Commit:
f845269
Reviewer: Paul Masson, Ralf Stephan
Issue created by migration from https://trac.sagemath.org/ticket/22422
The text was updated successfully, but these errors were encountered: