Naming Conventions for Dirac Delta, Heaviside Theta and Unit Step
Golam Mortuza Hossain
I am seeking your opinion to finalize the conventions
for three generalized functions that I am implementing currently.
My proposals are:
(1) These generalized functions be included in a new module as
"sage.functions.generalized"
(2) Dirac delta:
(a) represented as: "dirac_delta" [ex. dirac_delta(x) ]
(b) latex name : "\delta"
(c) dirac_delta(0) : will return a symbolic expression "dirac_delta(0)"
(3) Heaviside Theta:
(a) represented as: "heaviside_theta"
(b) latex name : "\theta"
(c) heaviside_theta(0) = 1/2
(3) Unit Step:
(a) represented as: "unit_step"
(b) latex name : "{\rm u}"
(c) unit_step(0) = 1
These conventions closely follow MMA conventions.
Thanks,
Golam
David Joyner
Hi,
I am seeking your opinion to finalize the conventions
for three generalized functions that I am implementing currently.
My proposals are:
(1) These generalized functions be included in a new module as
"sage.functions.generalized"
(2) Dirac delta:
(a) represented as: "dirac_delta" [ex. dirac_delta(x) ]
(b) latex name : "\delta"
(c) dirac_delta(0) : will return a symbolic expression "dirac_delta(0)"
(3) Heaviside Theta:
(a) represented as: "heaviside_theta"
(b) latex name : "\theta"
(c) heaviside_theta(0) = 1/2
Why not just heaviside? I've never heard of Heaviside Theta. For most
purposes, unit step and heaviside will have the same effect (eg, if you take
their Laplace transforms) so you may not even need both.
(3) Unit Step:
(a) represented as: "unit_step"
(b) latex name : "{\rm u}"
(c) unit_step(0) = 1
These conventions closely follow MMA conventions.
What is that? I googled MMA convention and found nothing relevant.
Will these generalized functions form a vector space?
Will, for example, sin(t)*unit_step(t) be defined?
If so, will you provide a plotting and _latex_ method for it?
Thanks,
Golam
Tim Lahey
What about a function undefined at 0? I use Dirac delta, Heaviside,
and the derivative
of the delta function. Having a definition at x=0 for Heaviside can
cause problems. I'd
like the limit of x=0^{-} be zero while x=0^{+} be 1. Having a
specific value at x=0
causes problems.
Also, I've never heard it called Heaviside theta, just Heaviside.
Also, the use of {\rm u} is obsolete (see Guide to LaTeX 4th edition)
and can cause
problems with the memoir class. It's better to use \mathrm{u}.
>
> Will these generalized functions form a vector space?
> Will, for example, sin(t)*unit_step(t) be defined?
> If so, will you provide a plotting and _latex_ method for it?
>
>
I really hope so. They provide the basic functions for the solution of
beam loading
problems. A Dirac delta represents an applied point load, a unit step
= distributed load,
and the derivative of a Dirac delta is a point moment.
I like the idea, but defining a value at x=0 is problematic. Different
conventions use
different values so making it an option and having it be undefined
would be my preference
as a default. I've seen conventions that define the unit step to be 0,
1/2, 1, undefined
at x = 0.
Cheers,
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey
Burcin Erocal
On Tue, 23 Jun 2009 11:53:17 -0300
Golam Mortuza Hossain <gmho...@gmail.com> wrote:
> I am seeking your opinion to finalize the conventions
> for three generalized functions that I am implementing currently.
>
> My proposals are:
>
> (1) These generalized functions be included in a new module as
>
> "sage.functions.generalized"
>
> (2) Dirac delta:
>
> (a) represented as: "dirac_delta" [ex. dirac_delta(x) ]
> (b) latex name : "\delta"
> (c) dirac_delta(0) : will return a symbolic expression
> "dirac_delta(0)"
+1 to these.
For some points below, MMA has different behavior than you suggest. I
only intend to provide more data below. I don't really use these
functions, so it would be better if other people comment on the
evaluation and printing.
> (3) Heaviside Theta:
>
> (a) represented as: "heaviside_theta"
> (b) latex name : "\theta"
> (c) heaviside_theta(0) = 1/2
MMA leaves this unevaluated, Maple returns "undefined"
In[2]:= HeavisideTheta[0]
Out[2]= HeavisideTheta[0]
> Heaviside(0);
undefined
>
> (3) Unit Step:
AFAICT, Maple doesn't define a different function for this.
> (a) represented as: "unit_step"
> (b) latex name : "{\rm u}"
MMA prints this as \theta as well:
In[3]:= TeXForm[UnitStep[x]]
Out[3]//TeXForm= \theta (x)
Cheers,
Burcin
Golam Mortuza Hossain
Correct me if I have missed your points. With your suggestions
here is the new conventions for Heaviside and unit step
(2) Heaviside:
(a) represented as: "heaviside"
(b) latex name : "\theta"
(c) heaviside(0): will return symbolic expression "heaviside(0)"
(3) unit_step = heaviside (Just an alias)
>> Will, for example, sin(t)*unit_step(t) be defined?
>> If so, will you provide a plotting and _latex_ method for it?
>>
> I really hope so.
These functions are sub-class of PrimitiveFunctions of new
symbolics. So many methods are predefined. For example,
I didn't write any code for plotting but it works.
Here is a screenshot from my Sage notebook.
http://www.math.unb.ca/~ghossain/sage-generalized-functions.png
Hopefully, it answers some of your questions. I am still working
on integration algorithm.
Cheers,
Golam
Burcin Erocal
Golam Mortuza Hossain <gmho...@gmail.com> wrote:
>
> Thanks David, Tim, Burcin!
Thank you for all the effort.
> Correct me if I have missed your points. With your suggestions
> here is the new conventions for Heaviside and unit step
>
> (2) Heaviside:
>
> (a) represented as: "heaviside"
> (b) latex name : "\theta"
> (c) heaviside(0): will return symbolic expression "heaviside(0)"
>
> (3) unit_step = heaviside (Just an alias)
FWIW, UnitStep and Heaviside are different in MMA:
Mathematica 7.0 for Linux x86 (32-bit)
Copyright 1988-2008 Wolfram Research, Inc.
In[1]:= Heaviside[0]
Out[1]= Heaviside[0]
In[2]:= UnitStep[0]
Out[2]= 1
I don't know if a separate unit_step is necessary, but I am not a fan
of aliases. :)
Cheers,
Burcin
David Joyner
Hossain<gmho...@gmail.com> wrote:
>
> Thanks David, Tim, Burcin!
>
> Correct me if I have missed your points. With your suggestions
> here is the new conventions for Heaviside and unit step
>
> (2) Heaviside:
>
> (a) represented as: "heaviside"
> (b) latex name : "\theta"
I'd prefer just "H" as the latex symbol.
> (c) heaviside(0): will return symbolic expression "heaviside(0)"
>
> (3) unit_step = heaviside (Just an alias)
>
>
>>> Will, for example, sin(t)*unit_step(t) be defined?
>>> If so, will you provide a plotting and _latex_ method for it?
>>>
>> I really hope so.
>
> These functions are sub-class of PrimitiveFunctions of new
> symbolics. So many methods are predefined. For example,
> I didn't write any code for plotting but it works.
>
> Here is a screenshot from my Sage notebook.
>
> http://www.math.unb.ca/~ghossain/sage-generalized-functions.png
Maurizio
Honestly, I don't actually know whether it means that much, but at
this point I think that it could be useful for us to follow
Mathematica in defining two different functions: Heaviside which is
undefined in 0 and that is defined as the function whose derivative is
the Dirac Delta ( see http://functions.wolfram.com/GeneralizedFunctions/HeavisideTheta/02/
) and UnitStep, which is the piecewise version of this function, so
it's numerically defined everywhere. It would be great if one could
possibly change the desired value in 0.
I think it doesn't hurt now to carry on both, because it shouldn't be
that difficult to merge them in future if we don't see any usefulness
in having them separated.
I can see that Maple use Heaviside undefined in 0, and then let the
user the chance to convert it to a piecewise function if desired. This
looks a bit unfriendly to me, and doesn't bring any real advantage.
By the way, how do we represent Dirac Delta? I know that it's not
defined in 0, but I want to point out an example. Please, remember
that the Fourier transform of any periodic function (although the use
of the transform is not proper in case of periodic functions, I know)
is formed by the summation of Dirac Deltas at different location in
the frequency spectrum, and I would love to have a graphical
representation of the spectrum of a signal. So, do you think we can
find a convenient way of plotting delta? I don't know much of them,
but I'm sure there are many similar physical problems, that would take
advantage of plotting deltas.
Thanks again
Maurizio
Maurizio
http://mathworld.wolfram.com/ImpulsePair.html
Regards
Maurizio
On 23 Giu, 23:45, Maurizio <maurizio.gran...@gmail.com> wrote:
> Many kudos for this!
>
> Honestly, I don't actually know whether it means that much, but at
> this point I think that it could be useful for us to follow
> Mathematica in defining two different functions: Heaviside which is
> undefined in 0 and that is defined as the function whose derivative is
Tim Lahey
On Jun 23, 2009, at 5:45 PM, Maurizio wrote:
>
> Many kudos for this!
>
> Honestly, I don't actually know whether it means that much, but at
> this point I think that it could be useful for us to follow
> Mathematica in defining two different functions: Heaviside which is
> undefined in 0 and that is defined as the function whose derivative is
> the Dirac Delta ( see http://functions.wolfram.com/GeneralizedFunctions/HeavisideTheta/02/
> ) and UnitStep, which is the piecewise version of this function, so
> it's numerically defined everywhere. It would be great if one could
> possibly change the desired value in 0.
>
> I think it doesn't hurt now to carry on both, because it shouldn't be
> that difficult to merge them in future if we don't see any usefulness
> in having them separated.
>
> I can see that Maple use Heaviside undefined in 0, and then let the
> user the chance to convert it to a piecewise function if desired. This
> looks a bit unfriendly to me, and doesn't bring any real advantage.
>
Technically, the Heaviside can be considered to be a piecewise function
where H(x) = 0 x<0, H(x) = 1, x>0. Maple just has a conversion between
the various representations. It comes in handy when there are multiple
pieces.
> By the way, how do we represent Dirac Delta? I know that it's not
> defined in 0, but I want to point out an example. Please, remember
> that the Fourier transform of any periodic function (although the use
> of the transform is not proper in case of periodic functions, I know)
> is formed by the summation of Dirac Deltas at different location in
> the frequency spectrum, and I would love to have a graphical
> representation of the spectrum of a signal. So, do you think we can
> find a convenient way of plotting delta? I don't know much of them,
> but I'm sure there are many similar physical problems, that would take
> advantage of plotting deltas.
Ploting Dirac deltas doesn't make much sense given its definition.
When I
work with Dirac deltas and their derivatives, I just ignore them for
plotting
purposes. I only plot their integrals and higher.
Tim Lahey
On Jun 23, 2009, at 5:46 PM, Maurizio wrote:
>
> As a clarification of what I was talking about, see this:
>
> http://mathworld.wolfram.com/ImpulsePair.html
>
> Regards
>
> Maurizio
How are they supposed to be plotted? Along with other impulses,
it would be fine, but next to any normal function, the impulses
would skew the scale and make all the other functions disappear.
David Roe
David
Maurizio
stem plot and then superimposing the rest of the plot
Maurizio
On 24 Giu, 04:21, David Roe <r...@math.harvard.edu> wrote:
> One way would be to have a vertical ray that doesn't change the scaling of
> the rest of the graph (just goes to the top of the viewing window). Not
> precisely accurate, but better than nothing.
> David
>
Tim Lahey
On Jun 24, 2009, at 1:57 AM, Maurizio wrote:
>
> I agree. We could do something like plotting all the deltas with a
> stem plot and then superimposing the rest of the plot
>
> Maurizio
>
It might give the wrong impression.
> On 24 Giu, 04:21, David Roe <r...@math.harvard.edu> wrote:
>> One way would be to have a vertical ray that doesn't change the
>> scaling of
>> the rest of the graph (just goes to the top of the viewing
>> window). Not
>> precisely accurate, but better than nothing.
>> David
If you put arrows on the top, it might give the right impression.
However, I'd like plotting Dirac deltas to be optional. So, if you're
plotting
something with Dirac deltas and other functions, you don't need to
sift through
and remove the deltas before plotting.
Golam Mortuza Hossain
On Tue, Jun 23, 2009 at 6:45 PM, Maurizio<maurizio...@gmail.com> wrote:
> Honestly, I don't actually know whether it means that much, but at
> this point I think that it could be useful for us to follow
> Mathematica in defining two different functions: Heaviside which is
> undefined in 0 and that is defined as the function whose derivative is
> the Dirac Delta ( see http://functions.wolfram.com/GeneralizedFunctions/HeavisideTheta/02/
> ) and UnitStep, which is the piecewise version of this function, so
> it's numerically defined everywhere. It would be great if one could
> possibly change the desired value in 0.
>
> I think it doesn't hurt now to carry on both, because it shouldn't be
> that difficult to merge them in future if we don't see any usefulness
> in having them separated.
If I gather properly, we are having two different step functions
(at least for now) as
(2) Heaviside:
(a) represented as: "heaviside"
(b) latex name : "H"
(c) heaviside(0): "heaviside(0)"
(3) Unit Step:
(a) represented as: "unit_step"
(b) latex name : "\mathrm{u}"
(c) unit_step(0) = 1
If there are no more suggestions for change, then I will
post a patch adding support for these functions. I have split
up the integration code involving these functions in a
separate file and will post it later.
Cheers,
Golam
David Joyner
Hossain<gmho...@gmail.com> wrote:
>
> Hi,
>
...
>
> If I gather properly, we are having two different step functions
> (at least for now) as
>
> (2) Heaviside:
> (a) represented as: "heaviside"
> (b) latex name : "H"
> (c) heaviside(0): "heaviside(0)"
>
> (3) Unit Step:
> (a) represented as: "unit_step"
> (b) latex name : "\mathrm{u}"
> (c) unit_step(0) = 1
>
> If there are no more suggestions for change, then I will
Golam Mortuza Hossain
On Thu, Jun 25, 2009 at 10:27 PM, David Joyner<wdjo...@gmail.com> wrote:
>> If I gather properly, we are having two different step functions
>> (at least for now) as
>>
>> (2) Heaviside:
>> (a) represented as: "heaviside"
>> (b) latex name : "H"
>> (c) heaviside(0): "heaviside(0)"
>>
>> (3) Unit Step:
>> (a) represented as: "unit_step"
>> (b) latex name : "\mathrm{u}"
>> (c) unit_step(0) = 1
>>
>> If there are no more suggestions for change, then I will
>
> This looks okay to me.
A patch is posted as a part of an old ticket
http://trac.sagemath.org/sage_trac/ticket/2452
Reviews are welcome.
Cheers,
Golam
David Joyner
Hossain<gmho...@gmail.com> wrote:
>
> Hi
>
...
>
> A patch is posted as a part of an old ticket
>
> http://trac.sagemath.org/sage_trac/ticket/2452
>
> Reviews are welcome.
>
> Cheers,
> Golam
>
> >
>