Re: Re: Factor 2 error in Inverse Laplace Transform
- To: mathgroup at smc.vnet.net
- Subject: [mg51407] Re: [mg51373] Re: Factor 2 error in Inverse Laplace Transform
- From: DrBob <drbob at bigfoot.com>
- Date: Sat, 16 Oct 2004 04:20:42 -0400 (EDT)
- References: <ck87ta$9mf$1@smc.vnet.net> <ckajqc$m6v$1@smc.vnet.net> <200410120557.BAA19233@smc.vnet.net> <cklmaj$f00$1@smc.vnet.net> <200410150647.CAA05270@smc.vnet.net>
- Reply-to: drbob at bigfoot.com
- Sender: owner-wri-mathgroup at wolfram.com
I don't use the Laplace functions often enough to gain an appreciation for their usefulness (in case that is possible). All I see are posts that point out failures.
I fear satisfied users may not realize how often they are getting wrong answers. If they aren't checking every answer, they're living in a fool's paradise.
>> Unfortunately, I do not see a process in place where reasonable suggestions are accepted
and handled to make the improvements.
Amen.
Bobby
On Fri, 15 Oct 2004 02:47:16 -0400 (EDT), Peter Valko <p-valko at tamu.edu> wrote:
> Bob,
>
>
> 1) " If this works in a single example, that doesn't mean it's a
> reliable strategy in general."
>
> I am sorry if my previous message gave you the false impression that
> it is enough safeguard to insert Apart before doing
> InverseLaplaceTransform.
> That was just an example to show that going through different paths,
> the function InverseLaplaceTransform can come up with the wrong or
> right answer.
>
> In general, the safeguard has to be inserted into the code of
> InverseLaplaceTransform itself. Whenever the convolution theorem is
> used to obtain the result, the algorithm needs to check whether
> DiracDelta (or its derivatives) are involved and need to do things
> differently, if the answer is yes. Another fix should be inserted
> regarding the inverse of Log[s] and or the transform (or rather
> generalized transform) of 1/t.
>
>
> 2) " Everything I've seen on the group in three years says the Laplace
> functions are unreliable."
>
> If this statement is true it is very unfortunate. In fact the
> LaplaceTransform and its inverse are both extremely powerful functions
> and represent the quintessence of what a CAS is good for. Both these
> functions rely heavily on Mathematica's integration package and I
> think it is needless to tell this Group that Integrate is one of the
> greatest things in Mathematica.
>
> As far as I understand LaplaceTransform causes little trouble (in fact
> it is quite good.) Most of the haevy usage and most of the problems
> are related to InverseLaplaceTransform.
>
> There are various reasons why InverseLaplaceTransform might have a bad
> reputation.
>i) Oftentimes the user knows a certain result but Mathematica rather
> gives back the expression unevaluated. This is embarassing, but it can
> be easily fixed by teaching Mathematica more and more Laplace
> transform pairs. Andre Mallet posted some fixes on MathSource for
> version 4.1 and it is my understanding that some of those fixes made
> it into version 5.
> Recently Urs Graf published an excellent book (Applied Laplace
> Transforms and z-Transforms for Scientists and Engineers, 2004,
> Birkhauser) on the subject. In his package he "teaches" Mathematica a
> lot of pairs (especially those involving Bessel functions and other
> special functions either in the original or in the transform or both.)
> Also he uses a more elaborate concept of "pseudo functions", showing
> that if you really miss something you can always create it in
> Mathematica.
>
> ii) More embarrasing is (at least for me) if Mathematica comes up with
> a "pseudo answer", which still contains an unevaluated "Integrate". I
> think this happens inadvertently and should be eliminated.
>
> iii) Finally in certain cases Mathematica comes up with an answer that
> is just deadly wrong. This is the most dangerous situation and it is
> almost always related to the interpretation of the integral of a
> DiracDelta or one of its derivatives, or to the integral of the log
> function. These problems could be easily fixed. (Unfortunately, I do
> not see a process in place where reasonable suggestions are accepted
> and handled to make the improvements.)
>
> Additional remarks:
>
> In my opinion teaching more and more pairs to Mathematica is not the
> real solution. In fact the more and more the function
> InverseLaplaceTransform is relying on general rules and calling the
> Integrate function, the more and more powerful it will be. This is the
> strength of Mathematica: applying very simple and general rules.
> However, if there is a glitch in one of the general rules, it MUST be
> corrected soon, because it effects more and more results and destroys
> the reputation of an extreemly valuable tool.
>
> In MathSource there is a function available called GWR. This function
> can calculate the inverse of a Laplace transform at a given value of
> time with any required accuracy. I use it often to check an "analytic"
> result coming out from InverseLaplaceTransform and this check always
> reveals if there is a problem (somewhat similarly to making a plot if
> you are not sure about a limit...)
>Regards
> Peter
>
>
>
>
> DrBob <drbob at bigfoot.com> wrote in message news:<cklmaj$f00$1 at smc.vnet.net>...
>> >> I suggest to put a little "safeguard" into InverseLaplaceTransform and
>> >> force it to avoid this trap.
>> > Problem 3a:
>> > InverseLaplaceTransform[Apart[s/(1+s)^(3/2)],s,t]
>>
>> If this works in a single example, that doesn't mean it's a reliable strategy in general.
>>
>> Everything I've seen on the group in three years says the Laplace functions are unreliable.
>>
>> You'd best check every answer.
>>
>> Bobby
>>
>> On Tue, 12 Oct 2004 01:57:50 -0400 (EDT), Peter Valko <p-valko at tamu.edu> wrote:
>>
>> > Maxim,
>> >
>> > As far as your Log example is considered, it really shows
>> > inconsistency.
>> > The other examples are also interesting, but you make very general
>> > comments and they bother me a bit. Somehow I feel they are unfair.
>> >
>> > For instance, in your second example, first you consider the
>> > input-output pair
>> > In[1]=
>> > Integrate[DiracDelta[x - a], {x, 0, 1}]
>> > Out[1]=
>> > UnitStep[1 - a]*UnitStep[a]
>> > then you are substituting a->1 into the result and Mathematica gives 0.
>> >
>> > You compare this to the pair
>> > In[2]=
>> > Integrate[DiracDelta[x], {x, 0, 1}]
>> > Out[2]=
>> > 1/2
>> >
>> > and draw the conclusion that something is wrong.
>> > I respectfully disaggree with you.
>> >
>> > In the Help of Integrate, Mathematica explicitely warns us:
>> > "When an integrand depends on a parameter, the indefinite integral
>> > should be considered valid for "generic" values of the parameter. For
>> > certain values the reported integral may be meaningless,..."
>> >
>> > In general, it is extremely easy to ask Mathematica to "derive" a parametric
>> > result, and then to substitute something very special into the
>> > parameter to obtain contradiction.
>> >
>> > Personally, I am not really interested in that.
>> > My examples try to mimic the situation when a user wants to solve a
>> > specific problem, arrives at a Laplace transform and tries to find the
>> > original using the "InverseLaplaceTransform" service of Mathematica.
>> > In such a situation a factor of 2 error is dangerous and I think with
>> > a little modification Mathematica could avoid it.
>> >
>> > For instance here is Problem 3:
>> > InverseLaplaceTransform[s/(1+s)^(3/2),s,t]
>> > It gives an answer that is wrong by a factor of two, while
>> > Problem 3a:
>> > InverseLaplaceTransform[Apart[s/(1+s)^(3/2)],s,t]
>> > gives the right answer because then Mathematica finds other rules to apply and
>> > they are correct.
>> >I suggest to put a little "safeguard" into InverseLaplaceTransform and
>> > force it to avoid this trap. This can be done without redefining
>> > DiracDelta and UnitStep. (Those are used extensively by Mathematica and
>> > therefore any change would impact the whole system in too many ways.)
>> >
>> > Regards
>> > Peter
>> >
>> >
>> >
>> > ab_def at prontomail.com (Maxim) wrote in message news:<ckajqc$m6v$1 at smc.vnet.net>...
>> >> p-valko at tamu.edu (Peter Valko) wrote in message news:<ck87ta$9mf$1 at smc.vnet.net>...
>> >> > Hi,
>> >> >
>> >> > InverseLaplaceTransform is an extremely useful part of Mathematica
>> >> > (since v 4.1).
>> >> > However, in the following simple problem it gives the wrong answer:
>> >> > Problem 1:
>> >> > InverseLaplaceTransform[s/(s+1),s,t]
>> >> > -1/(2*E^t)+DiracDelta[t]
>> >> > where the factor 2 is completely wrong.
>> >> >
>> >> > To see that I slightly rewrite Problem 1 into
>> >> > Problem 1a:
>> >> > InverseLaplaceTransform[Apart[s/(s+1)],s,t]
>> >> > and then I get the correct answer:
>> >> > -E^(-t)+DiracDelta[t]
>> >> >
>> >> > Of course one can "Unprotect" InverseLaplaceTransform and teach it to
>> >> > give the correct answer but that is not the point.
>> >> > (Also one can start a long debate about the meaning of DiracDelta in
>> >> > Mathematica, but that is also not the point here. )
>> >> >
>> >> > There are several similar simple examples when the wrong factor of two
>> >> > shows up, for instance
>> >> > Problem 2:
>> >> > InverseLaplaceTransform[ s ArcTan[1/s],s,t]
>> >> >
>> >> > Using the Trace one can find out that all these "factor 2" errors have
>> >> > a common origin.
>> >> > Solving Problem 1 Mathematica calculates the convolution integral
>> >> >
>> >> > Integrate[E^(-t+x)*Derivative[1][DiracDelta][x],{x,0,t}]
>> >> >
>> >> > and because the lower limit is exactly zero,the factor 2 shows up in
>> >> > -1/(2*E^t), that is Mathematica "halves" the Dirac delta and all its
>> >> > derivatives at the origin.
>> >> >
>> >> > I think the InverseLaplaceTransform function could be much improved if
>> >> > the above convolution integral would be evaluated more carefully.
>> >> >
>> >> > For instance, doing it in two steps:
>> >> > res1=Integrate[E^(-t+x)*Derivative[1][DiracDelta][x],{x,-eps,t},
>> >> > Assumptions -> eps>0];
>> >> > res2=res1/.eps -> 0
>> >> > would give the right result.
>> >> > (This caution is necessary only, if generalized functions are involved
>> >> > in the integration.)
>> >> >
>> >> > I wonder if further examples/suggestions are welcome in this group
>> >> > regarding InverseLaplaceTransform???
>> >> >
>> >> > Peter
>> >>
>> >> I'd say that this is two messes mixed together. One is a rather poor
>> >> implementation of integral transforms, especially when there are
>> >> generalized functions involved. For example:
>> >>
>> >> In[1]:=
>> >> LaplaceTransform[InverseLaplaceTransform[Log[p], p, t], t, p] - Log[p]
>> >> LaplaceTransform[InverseLaplaceTransform[PolyGamma[p], p, t], t, p] -
>> >> PolyGamma[p]
>> >>
>> >> Out[1]=
>> >> EulerGamma
>> >>
>> >> Out[2]=
>> >> EulerGamma
>> >>
>> >> We can see that LaplaceTransform/InverseLaplaceTransform aren't
>> >> consistenly defined for these functions (here Mathematica doesn't
>> >> internally take integrals of distributions). Another issue is the
>> >> question of how the integral of DiracDelta on [0,a] should be
>> >> interpreted:
>> >>
>> >> In[3]:=
>> >> Integrate[DiracDelta[x], {x, 0, 1}]
>> >> Integrate[DiracDelta[x - a], {x, 0, 1}]
>> >> Integrate[DiracDelta[x - 1], {x, 1, 2}]
>> >>
>> >> Out[3]=
>> >> 1/2
>> >>
>> >> Out[4]=
>> >> UnitStep[1 - a]*UnitStep[a]
>> >>
>> >> Out[5]=
>> >> 0
>> >>
>> >> The value of the first integral is by convention taken to be 1/2;
>> >> however, substituting a=0 into Out[4] we obtain 1, and making the
>> >> change of variables x->x-1 (the third integral) we get 0. Similarly
>> >> for the integrals of the DiracDelta derivatives:
>> >>
>> >> In[6]:=
>> >> Integrate[DiracDelta'[x]*phi[x], {x, -eps, Infinity}]
>> >> Integrate[DiracDelta'[x]*phi[x], {x, 0, Infinity}]
>> >> Integrate[DiracDelta'[x]*x, {x, 0, Infinity}]
>> >>
>> >> Out[6]=
>> >> (-DiracDelta[eps])*phi[0] - phi'[0]
>> >>
>> >> Out[7]=
>> >> 0
>> >>
>> >> Out[8]=
>> >> -(1/2)
>> >>
>> >> The value of the first integral for eps<0 is incorrect in any case,
>> >> and Out[7] and Out[8] are not consistent with each other.
>> >>
>> >> Maxim Rytin
>> >> m.r at inbox.ru
>> >
>> >
>> >
>> >
>
>
>
>
--
DrBob at bigfoot.com
www.eclecticdreams.net
- References:
- Re: Factor 2 error in Inverse Laplace Transform
- From: p-valko@tamu.edu (Peter Valko)
- Re: Factor 2 error in Inverse Laplace Transform
- From: p-valko@tamu.edu (Peter Valko)
- Re: Factor 2 error in Inverse Laplace Transform