We had discussions earlier on having Dirac delta distribution
included in Sage. Now that we have switched to new symbolics,
let me bring this issue once again.
Is anyone working in implementing Dirac delta in new symbolics?
While working with my own Physics problems in Sage, I often find
myself constrained for not having Dirac delta. If no one is working
on it then I will implement at least some properties that I need.
If someone is already working on it then I will be happy to
collaborate.
Thanks,
Golam
I don't know anyone working on this atm. You could do this as part of
#2452 on trac. The example code I wrote for Maurizio is here:
http://sage.math.washington.edu/home/burcin/pynac/dirac.py
You probably need to put those evalf functions in the appropriate
PrimitiveFunction class, and add other properties as desired.
Thanks for volunteering!
Cheers,
Burcin
>
> Glad to see this issue coming out again :)
>
> I just would like to point out that Burcin recently highlighted
> ( http://groups.google.com/group/sage-devel/msg/368c6c89935b85ad )
> that there was a discussion ongoing with Mike Hansen about changing
> the design of SFunction.
>
> I am wondering if that's still pending, or it has been done, so that
> some documentation to new design could be helpful, given that Dirac
> delta implementation should rely on that.
Mike moved the PrimitiveFunction class to derive from SFunction, and
added code so you can define the optional methods for printing,
derivation, conjugation, etc. as methods of your subclass. As I said
(or tried to say, I write these messages in a hurry) in my previous
message, as long as you subclass PrimitiveFunction, things should be
fine.
In the future I would like to merge SFunction and PrimitiveFunction.
Since I don't see the necessity of having two levels there, and I am
bothered by the PrimitiveFunction name. It suggests something
mathematical to me.
Cheers,
Burcin
On Wed, Jun 17, 2009 at 8:56 AM, Burcin Erocal<bur...@erocal.org> wrote:
> I don't know anyone working on this atm. You could do this as part of
> #2452 on trac. The example code I wrote for Maurizio is here:
>
> http://sage.math.washington.edu/home/burcin/pynac/dirac.py
>
> You probably need to put those evalf functions in the appropriate
> PrimitiveFunction class, and add other properties as desired.
Thanks Burcin! I have started working on this and have a
working prototype for three functions "dirac_delta",
"heaviside_theta" and "unit_step". New symbolic structures turned
out to be pretty handy.
I have couple of issues:
(1) Assumptions:
How does the assumption framework work in new symbolic?
For example:
------
1 > 0
-
True
---
a=var('a');
a > 0
-
a > 0
---
assume(a>0)
a > 0
-
a > 0
--------
I was expecting a "True" in last line but that doesn't seem to happen.
(2) How should the expression "operator" be tested
to check whether its multiplication or addition?
-----
ex = x1*x2
ex.operator() == "<built-in function mul>"
False
-----
Cheers,
Golam
On Thu, Jun 18, 2009 at 12:59 PM, Golam Mortuza Hossain
<gmho...@gmail.com> wrote:
>
> Hi,
> (1) Assumptions:
> How does the assumption framework work in new symbolic?
These are all done via Maxima.
>
> For example:
> ------
> 1 > 0
> -
> True
> ---
> a=var('a');
> a > 0
> -
> a > 0
> ---
> assume(a>0)
> a > 0
> -
> a > 0
> --------
> I was expecting a "True" in last line but that doesn't seem to happen.
sage: a = var('a')
sage: assume(a>0)
sage: a > 0
a > 0
sage: bool(a > 0)
True
sage: forget(a > 0)
sage: bool(a > 0)
False
> (2) How should the expression "operator" be tested
> to check whether its multiplication or addition?
> -----
> ex = x1*x2
> ex.operator() == "<built-in function mul>"
> False
> -----
sage: import operator
sage: x1, x2 = var('x1,x2')
sage: (x1*x2).operator() is operator.mul
True
sage: (x1+x2).operator() is operator.add
True
--Mike