[sage-devel] Re: Seeking opinion on an issue for #6756 (*diff* derivative )
On Sep 8, 1:23 pm, Nils Bruin wrote: > However, it is done under an assumption (documented with examples) > > that arguments of the function are independent for the purpose of > > applying chain rule. > > > An example situation where above assumption is violated, is > > > > sage: f(x,x).diff(x) > > > > Isn't f(x,x) an expression? I would think E.diff(x) would mean > "the derivative of x:-> E" with respect to x. If not enough of f is > known to further expand it, one should just leave it unevaluated. Yes, that is the default behavior. The issue is what to do when a user explicitly ask to apply chain rule by over-riding default setting but provides f(x,x) as the function? Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Seeking opinion on an issue for #6756 (*diff* derivative )
Hi, I am seeking opinion from sage-devel about the following issue on #6756. You can read the comments at http://trac.sagemath.org/sage_trac/ticket/6756 In brief, new *diff* implementation has an option (not the default behaviour) by which an user can request to apply chain rule even with *diff* format. This is useful and sometime needed for many Physics problems. However, it is done under an assumption (documented with examples) that arguments of the function are independent for the purpose of applying chain rule. An example situation where above assumption is violated, is sage: f(x,x).diff(x) During implementation stage, I had posted this issue here http://groups.google.com/group/sage-devel/browse_thread/thread/c8d257981e3e3d98 Now my question: what is best approach to deal with this? Options are (1) Remove the feature entirely (as asked by Burcin) (2) Document the behaviour with examples how the output can be affected for the situations where the assumption is violated. Given Sage allows documented simplifications like -- sage: x/x 1 -- which is incorrect for x=0, it seemed natural to me go for option (2). However, I don't mind going for (1) if thats what sage-devels decide. Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Prototype library interface with Maxima/ECL
Hi Nils, On Mon, Sep 7, 2009 at 2:24 AM, Nils Bruin wrote: > For other people interested in maxima-as-a-library: I personally don't > have a clue what the right way forward is from here. What > functionality do we need from maxima? Is a minimal functionality > library the right way to go, a la the "myint" example above? Or would > we be served with a fully functional .. IMO, minimal but functional library would be the right way to go. >From my personal experience, trying to do one small step at a time leads to much further distance in long run rather than trying to do everything at one go. Given, you already have a working "integrate" interface, my suggestion would be to a make a small algorithm interface. We are in the process of reorganizing integrate code so that any integration algorithm written for Sage can be hooked up easily by simply adding just a line like algorithm_table['ecl-maxima'] = _ecl_maxima_integrator Then users well be able to access your interface as sage: integrate( f(x), x, algorithm="ecl-maxima") You may have a look at the patch http://trac.sagemath.org/sage_trac/ticket/6465 Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: log(x) versus ln(x)
Hi, On Sun, Sep 6, 2009 at 6:35 PM, William Stein wrote: > sage: ln(x) > ln(x) > sage: log(x) > log(x) > > That should make most people happy. Just a comment: having two different symbolic log functions in pynac will imply (by default) - sage: log(x) - ln(x) log(x) - ln(x) - I mean symbolically they are not equal to each other given they will have different serial no. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Prototype library interface with Maxima/ECL
Hi Nils, On Sat, Sep 5, 2009 at 4:22 PM, Nils Bruin wrote: > At present, the wrapping is very incomplete and inefficient on the > sage side. The construction and traversing on the ECL side doesn't > look too inefficient (simpler interface). > > > Perhaps this experiment is useful for someone who wants to improve > integration or other functions that rely on interfacing with maxima Thanks for you great work! I am interested in trying out your patches. I have a rather naive question: is it possible to put your library interface in parallel with the current interface? I mean does the pexpect interface need to be taken down to activate your interface? Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Unique variable names and their domains
Hi, On Sat, Sep 5, 2009 at 2:06 AM, Robert Bradshaw wrote: > > As for temporary_symbolic_variable, how about SR.new_variable() which > would always produce a variable that's never been used before? +1 May be just SR.new_var() to be consistent with current SR.var() and optionally domain=RR(or 'real') keyword can be passed to get a new but real symbol. Meanwhile, I managed to hack GiNaC to allow updating domain as well as latex name of an already defined symbol. This makes redefining var faster and much easier to manage unique names. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Unique variable names and their domains
Hi, On Fri, Sep 4, 2009 at 4:30 PM, Maurizio wrote: > I beg your pardon for asking silly questions... would you please > explain which is the reason for having different variables with the > same name... and even more, with different domains? Incidentally, thats the way GiNaC symbols are designed. > I could be wrong but this looks me more like a confusing thing, rather > than a feature... am I wrong? I agree. We should try to avoid the confusion and in fact thats what my aim is. Basically, we need to ensure the uniqueness by managing a symbol registry with domain info within Sage even though GiNaC doesn't enforce such behavior. So, I guess we are going for the case (1). Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Unique variable names and their domains
Hi,
On Fri, Sep 4, 2009 at 3:48 PM, William Stein wrote:
> Feature request -- can you make it so the *docstring* for the variable
> can be specified? I will have to do this soon anyways if you don't,
> since it is needed for the units package.
> E.g.,
>
> meter = var('meter', docstring="A meter is...", latex_name="m")
Trying to simply overwrite __doc__ method didn't seem to
work. So, I guess, I will leave that for you.
> I don't know. I'm curious -- what does Maxima do? Note that if
> Maxima can't do this, i.e. ,have one variable name with two domains,
> it will make using Maxima for anything more complicated,
With the current interface, maxima variables are constructed
using "repr(x)". So both will be treated as the same.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Unique variable names and their domains
Hi,
I am working on a patch that exposes few more properties
of GiNaC symbols in Sage. This will allow users to specify
their domains as well as custom latex_names.
Using Stan's example, it would be possible to do
---
sui = var('sui', domain='real', latex_name="\\color{red}\\s_{u,i}")
---
However, there are some issues that needs to be discussed.
It seem that in GiNaC, its not possible to update the domain
of an already defined variable. On the hand one can have
different variables with same name (but different serial).
Thus, we need to move pynac symbol directory within Sage to allow
flexible usage but still keep unique variable names.
Consider the following situation
-
sage: xc = var('x')
sage: xr = var('x', domain='real')
sage: xc
x
sage: xr
x
sage x
x
-
Here we have two choices
(1)
-
sage xr is xc
True
sage: xr - xc
0
-
(2)
---
sage: xr is xc
False
sage: xr - xc
x - x
---
Now my question is whether we should allow (2) or (1) ?
See also Burcin's this mail for related discussion
http://groups.google.com/group/pynac-devel/browse_thread/thread/76868c8ad5ae5b70
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Dangerous mixing of different domains for symbolic variables
Hi, > On Wed, Sep 2, 2009 at 12:13 PM, kcrisman wrote: >> Very interesting. Continuing from the above code: >> >> sage: assume(a,'complex') >> sage: x.conjugate().simplify() >> -I*b + conjugate(a) >> >> Clearly we were not calling declare. Is there any way to do this for >> ANY globally defined variable, though? It seems overkill to put it in >> var(), and one wouldn't want it to conflict with (say) assume >> (n,'integer') or something. I played around little bit to fix this bug. Unfortunately, it doesn't seem that we can avoid calling "declare()" in maxima for each (complex) variable defined in sage. The best thing we can do is to delay the declaration into maxima until we actually need to call maxima to do some computation. This way can avoid slowing down stuffs. Maxima-interface experts: Is it possible to append such declaration statements into maxima init string or similar? Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: super commutative and noncommutative rings
Hi Burcin,
On Fri, Sep 4, 2009 at 7:33 AM, Burcin Erocal wrote:
> Is there anybody else interested in a wrapper for the noncommutative
> functionality provided by Singular?
>
> Singular's capabilities are described in the manual here:
>
> http://www.singular.uni-kl.de/Manual/latest/sing_356.htm#SEC397
>
> If you're interested please write back with the following information
> - what exactly are your needs
> - ideas for a possible user interface (example Sage session)
> - if you can contribute to the development (testing patches and
> designing an interface is also a contribution)
Great! In quantum physics, one needs to work with quantum operator
that are non-commuting objects. There, we often need to check whether
commutator or anti-commutator of two composite operators are zero or not.
An example session would be:
--
sage: A,B = nc_var('A,B')
sage: a,b,c,d = var('a,b,c,d')
sage: C = a*A + b*A*A
sage: D = d*B
sage: commutator(C, D)
a*d*commutator(A,B) + b*d*A*commutator(A,B) + b*d*commutator(A,B)*A
sage: commuator.define([A,B], 1)
sage commutator(A, B)
1
sage: commutator(C,D)
a*d + 2*b*d*A
Thanks,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Embedded SVG editor in the notebook?
Hi,
On Fri, Sep 4, 2009 at 2:17 AM, Pat LeSmithe wrote:
> By the way, how about syntax highlighting for equations?
That would be really good. If not equation then at least the inline
comments should be in different color to improve readability.
> jsMath can
> easily do color:
>
> http://www.math.union.edu/~dpvc/jsMath/examples/extensions.html
>
> Would this be useful for teaching? I'm not sure about how to add color
> attributes to symbolic variables.
I am finishing up some enhancement for symbolic variables. Surprisingly,
following works nicely in notebook even now
---
sage: var('theta', latex_name="\\color{red}{\\theta}")
---
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: symbolic variable treated as sqrt(-1) when it shouldn't be
Hi,
On Thu, Sep 3, 2009 at 5:00 PM, William A. Stein wrote:
>>> sage: var('i')
>>> i
>>> sage: a = i^2
>>> sage: a.simplify_full()
>>> -1
> I think my email must have not been clear. I think it's an instance
> of a *HUGE BUG* in Sage. No more, no less. It's a bug, because
> irregardless of anything being predefined, it makes no sense that
> simplifying via *maxima* would just happen to decide that the formal
> variable "i" is sqrt(-1), even though it isn't with Ginac.
This seems to be a problem with the way Sage convert back
maxima-returned string intro SR. So Maxima is NOT doing anything
wrong.
---
sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string
sage: symbolic_expression_from_maxima_string('%i')
I
sage: symbolic_expression_from_maxima_string('i')
I
---
So as you see, we are converting both '%i' and 'i' to imaginary 'I'
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Dangerous mixing of different domains for symbolic variables
Hi, On Wed, Sep 2, 2009 at 12:13 PM, kcrisman wrote: >> FWIW in order for conjugate & friends to recognize variables as >> complex, probably it is necessary to declare them as such >> (i.e. declare(foo, complex)). I think domain:complex won't have >> the same effect. Maybe Sage is already calling declare. > > Very interesting. Continuing from the above code: > > sage: assume(a,'complex') > sage: x.conjugate().simplify() > -I*b + conjugate(a) > > Clearly we were not calling declare. Is there any way to do this for > ANY globally defined variable, though? It seems overkill to put it in > var(), and one wouldn't want it to conflict with (say) assume > (n,'integer') or something. In any case, current var() needs an upgrade. We now have three tickets against it (1) Custom typesetting: http://trac.sagemath.org/sage_trac/ticket/6403 (2) Custom domain: http://trac.sagemath.org/sage_trac/ticket/6559 (3) Syncing domain of variables with maxima: http://trac.sagemath.org/sage_trac/ticket/6862 I did bit of work on the first two and unless someone else fixes the third one, may be I will have a look at it. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Dangerous mixing of different domains for symbolic variables
Hi, This is from sage-support On Sep 1, 11:35 pm, Mani chandra wrote: > sage: x = a + I*b sage: real(x.conjugate().simplify()) real_part(a) + imag_part(b) sage: real(x.conjugate()) real_part(a) - imag_part(b) - This seems to be happening because maxima(via simplify) treats variables as real whereas pynac treats as complex. -- sage: x.conjugate() conjugate(a) - I*conjugate(b) sage: x.conjugate().simplify() a - I*b -- William mentioned in this thread http://groups.google.com/group/sage-support/browse_thread/thread/7bf451cf8202e085/10e81a803518f17c that Sage does attempt to make default domain for maxima to be complex. So something must be going horribly wrong. Here is the trac ticket http://trac.sagemath.org/sage_trac/ticket/6862 Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Formal sums... but not the ones we have !
Hi Nathann, On Mon, Aug 31, 2009 at 5:59 AM, Nathann Cohen > Is there a way in Sage to define a Formal sum ? Something like > sum( a_i, i \in [0,...5] ) or even worse, sum(a_e, e\in g.edges()) for > g a graph, etc. For formal or symbolic sum, you need to make it a SFunction sub-class of new symbolics. Unfortunately, it is yet to be implemented/ported to the new symbolics and it would be great if you could do this, See this ticket for related discussion http://trac.sagemath.org/sage_trac/ticket/3587 I think, symbolic sum implementation would be very similar to symbolic "integrate" implementation. Please have a look at the patch http://trac.sagemath.org/sage_trac/ticket/6465 > I insist it should be a "formal sum", as it should not return sum > ( [a_i for i in range(6) ] ) or sum( [a_e for e in g.edges() ] ) , but > rather an abstract formula for this. It could be evaluated at any > moment, giving different results if the a_i have changed or if the > graph has changed meanwhile. In the _eval_ method of the new class, you can decide on the situation where you want to evaluate explicitly or leave it symbolic. If you want to leave it symbolic then just "return None" . Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: behavior of log for nonpositive integers
Hi, On Fri, Aug 28, 2009 at 11:02 AM, kcrisman wrote: > > I'm working on #6388, Thanks for taking the effort on this bug. > sage: a = Integer(-1) > sage: a.log() > ValueError about input being negative > sage: log(-1) > Same ValueError, since preparser turns -1 into Integer(-1) > sage: log(SR(-1)) > I*pi > sage: log(CC(-1)) > 3.14...*I > > Would anything break if a.log() returned a symbolic answer as above? > Alternately, one could place a check in the global log() for > nonpositive integers and make them symbolic before moving on. Or one > could leave the existing behavior and just document it better. Please return a log value for integer and float arguments that is consistent with rest of the Sage. As you said, for CC and SR arguments, log() returns acceptable answer. So it would be desirable that we get compatible answers also for integer and floats. Currently, we get - sage: log(-1.0) NaN sage: log(-1 + 0*I) pi*I sage: log(-1) ... ValueError: self must be positive - > Something similar happens for input zero, except here SR(0) and CC(0) > give various forms of infinity while the request is for log(0) as an > answer. I guess, a consistent convention of "-oo" is perfectly acceptable for log(0). My main concern was that it is raising error instead of returning at the least, unevaluated symbolic expression. Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Linear Programming and MIP... Let's start something huge !
Hi, On Thu, Aug 27, 2009 at 1:00 AM, William Stein wrote: > > On Wed, Aug 26, 2009 at 7:56 PM, Robert > Bradshaw wrote: x[1], and then x[1] would create another symbolic variable x[1][1]. >>> >>> That sounds pretty easy to implement by defining __getitem__ for >>> symbolic variables, and making it cache its answer using a dictionary. >> >> I've advocated for this before--I think it's a great idea. >> > > Yes, this makes a lot of sense to me, since it's very common in > mathematics to have expressions like x_i, where i is some variable. Does GiNaC/pynac's native "indexed object" help here? http://www.ginac.de/tutorial/Indexed-objects.html#Indexed-objects If so then it may be a good idea to expose these to sage by wrapping them suitably. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Coersion issue from tuple/list to SR (was Re: Explicit variable of integration
Hi,
On Wed, Aug 26, 2009 at 2:10 PM, Robert
Bradshaw wrote:
>>
>> I agree. Personally, I would prefer to wait until we have
>> a proper coersion model from tuple/list to SR.
>
> I don't think coercion is the way to go about it...
May be.
What would be your suggestion to handle this?
Basically, what we need is some construct that would allow
tuple to become arguments of any symbolic functions of new
symbolics, "integrate" being one of them. So for example,
we should be able to call
-
sage: f(x,y,z) = function('f', x, y, z)
sage: f(x, (a,b), (c,d,e))
f(x, (a,b), (c,d,e))
--
An easy way of doing this would be to use a dummy function
like
-
sage: symbolic_tuple = function('symbolic_tuple')
-
(A) Tuple to SR:
--
a = (x,y,z)
b = symbolic_tuple(*a)
--
*b* is just an symbolic expression that can be manipulated
as usual.
(B) SR to tuple
--
b = symbolic_tuple(x,y,z)
a = b.operands()
--
*a* is now regular python tuple
I would be happy to hear any comments on this before
I start coding.
> what does x + (2,"yo") mean?
Personally, I would want (leave it as is)
--
sage: x + (2, "yo")
x + (2, "yo")
---
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Explicit variable of integration
Hi, On Tue, Aug 25, 2009 at 9:44 PM, kcrisman wrote: >> > While (1) and (2) syntaxes are encouraged, (3) will >> > remain valid until we sort out the coersion issue >> > and update all doctests, tutorial etc. BTW, I did update >> > some of the doctests including the docstrings that you get >> > via "integrate?" >> >> Sounds like we should throw a deprecation warning on it. >> > > Yes, this would definitely require it. I agree. Personally, I would prefer to wait until we have a proper coersion model from tuple/list to SR. So that we can enforce it within a definite time-frame after issuing the warning. > Your work on symbolics is impressive and valuable, Golam - keep it up! Thanks! Frankly, I am just trying to strengthen the tiny corner of Sage that are needed for my own work. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Explicit variable of integration
Hi, On Tue, Aug 25, 2009 at 8:09 PM, William Stein wrote: > > On Tue, Aug 25, 2009 at 3:44 PM, Jason Grout > wrote: >> I noticed the other day that integrate(sin(x), (x, 0, pi)) seemed to >> just hang. There was no error--it just hung. > > That is WEIRD given that maxima doesn't go interactive or anything and > works fine: I guess, above format for providing limits is not supported in current "integrate". Integrate hangs for generic "integrate(f(x), (x, a, b))". It seems that it is treating entire "(x,a,b)" as a variable of integration! Above issue should not be there with the posted patches. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: enhance usability of symbolic expressions?
Hi,
On Aug 19, 10:30 am, Harald Schilly wrote:
> here is another "report a problem" message from the notebook
> interface. It's not a bug (i think) but it gives insight in how Sage
> is used and over what users stumble when using it for simple things.
>
> --
> This doesn't work:
>
> var('k')
> u = 1 + k
> k = 1
> u.n()
> --
>
> Comment:
> I think n() could be made more intelligent in a way that it searches
> the globals()? Or not .n(), but a new method ".evaluate()" or
> something that does this? Any ideas? Just u.subs(globals()) didn't
> work for me.
Here goes another easy way of doing above.
---
sage: eval(repr(u))
2
---
It could also work for functions
---
sage: f(x) = function('f', x)
sage: h = f(x) + f(x).diff(x)
sage: h
diff(f(x), x, 1) + f(x)
sage: f(x) = sin(x)
sage: eval(repr(h))
sin(x) + cos(x)
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Using MPIR or GMP with multiple memory managers
Hi, On Mon, Aug 24, 2009 at 11:57 AM, William Stein wrote: > Anyway, patch up at > > http://trac.sagemath.org/sage_trac/ticket/6818 Once above is merged following (possibly duplicate) bug should be closed http://trac.sagemath.org/sage_trac/ticket/4731 Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: verifying visual look of ReST in docstrings
On Sun, Aug 23, 2009 at 4:46 PM, William Stein wrote: > > Thanks for finding this bug. Can you report it to trac, please? Here it goes http://trac.sagemath.org/sage_trac/ticket/6815 Cheers, --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: verifying visual look of ReST in docstrings
Hi, On Sun, Aug 23, 2009 at 2:02 AM, William Stein wrote: > If you did "sage -br" you do *not* have to restart the notebook server -- > it suffices to just do "Action --> Restart Worksheet". Thats a cool feature. I noticed that restarting worksheet seems to disable latex typesetting even though "Typeset" box is checked. I need to un-check and then re-check the "Typeset" box to get it working again. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: It takes too long to check "x in list" in symbolics!
Hi. On Fri, Aug 21, 2009 at 5:47 PM, William Stein wrote: > >> Personally, I am for accepting pynac's answer by default as it >> would massively speed up test like "if x in list" for symbolics. > > We must default to pynac, in my opinion. The question then just becomes > how to make pynac's comparison better. Cool. I just opened a ticket http://trac.sagemath.org/sage_trac/ticket/6799 I will try to see how much breakage is caused by a brutal swich-over. Having something like a ".full_simplify()" within pynac should be a gradual and long-term goal for sage symbolics. Some relevant comments are in here http://www.ginac.de/FAQ.html#sincos Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Symbolic signum (sgn) function and Kronecker delta in Sage
Hi, Do we have symbolic Kronecker delta in Sage? While I could find signum (sgn) function but it returns wrong answer for symbolic input. sage: sgn(x) 1 These are very useful for symbolic computation in Physics. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Explicit variable of integration
Hi, > http://trac.sagemath.org/sage_trac/ticket/6465 Patches are up and reviews are welcome. While (1) and (2) syntaxes are encouraged, (3) will remain valid until we sort out the coersion issue and update all doctests, tutorial etc. BTW, I did update some of the doctests including the docstrings that you get via "integrate?" Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: It takes too long to check "x in list" in symbolics!
Hi, On Thu, Aug 20, 2009 at 3:03 PM, Jason Grout wrote: >> I guess, a policy decision is involved here as to whether use mathematical >> identities by default or as an option during comparison. To clarify: >> >> ex = sin(x)^2 + cos(x)^2 - 1 >> >> In pynac, for above expression "ex.is_zero()" test will result False by >> default >> where as current maxima based comparison will return True. >> >> Personally, I feel we should have a flag something like >> >> (1) ex.is_zero(use_identity=False) >> > perhaps ex.is_zero(simplify=False) ? Yes, thats even better. So the next BIG question is what should be the *default* value of this flag for comparison? In other words, by default do we call maxima or accept pynac's False return as definitive? Personally, I am for accepting pynac's answer by default as it would massively speed up test like "if x in list" for symbolics. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: It takes too long to check "x in list" in symbolics!
Hi,
On Thu, Aug 20, 2009 at 1:28 PM, William Stein wrote:
>
> On Thu, Aug 20, 2009 at 4:11 AM, Golam Mortuza
> Hossain wrote:
>>
>> Hi,
>>
>> It takes too long to check whether x is in a list in new symbolics
>>
>> -
>> sage: var('x,x1,x2,x3,x4')
>> (x, x1, x2, x3, x4)
>> sage: f = function('f')
>> sage: mylist = [x1,x2,x3,x4,f(x1),f(x2),f(x3),f(x4)]
>>
>> sage: timeit('x in mylist')
>> 5 loops, best of 3: 461 ms per loop
>>
>>
>> If your program needs to check it couple of more times
>> --
>> sage: timeit('x in mylist')
>> 5 loops, best of 3: 1.26 s per loop
>> sage: timeit('x in mylist')
>> 5 loops, best of 3: 3.4 s per loop
>> --
>>
>> For a comparison
>> -
>> sage: timeit('x1 in mylist')
>> 625 loops, best of 3: 473 ns per loop
>> -
>>
>> Reason for this huge discrepancy stems from the fact that
>> except for last example, in all previous cases maxima is called
>> to check the equality.
>>
>> Thus it seems, new symbolics depends on maxima for basic
>> operations even now.
>>
>> I don't know the rationale behind this design given pynac has
>> a method to compare two symbolic expression (ex1.is_equal(ex2)).
>>
>> In any case, this design ensures writing a program in new symbolics
>> where some basic tests like "if x in list" needs to done, is no better than
>> old symbolics.
>>
>
> That's not for any list, but it is for the one you constructed.
That why I wrote "symbolics" in the title :-). BTW, I encountered
this while doing my own work using sage. So I consider this as
a serious drawback.
> I
> think to get the new symbolics out at some point we finally gave in
> and made the compare method fall back to Maxima (in case several
> pynac-based methods failed) so that massive amounts of user code and
> doctests wouldn't break. Fixing this is obviously something that
> needs to be done. Hopefully you will do it! :-)
I guess, a policy decision is involved here as to whether use mathematical
identities by default or as an option during comparison. To clarify:
ex = sin(x)^2 + cos(x)^2 - 1
In pynac, for above expression "ex.is_zero()" test will result False by default
where as current maxima based comparison will return True.
Personally, I feel we should have a flag something like
(1) ex.is_zero(use_identity=False)
or may be a new method
(2) ex.is_trivially_zero()
So that users/developers can make their choice depending on their need.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: What's the view on updating Maxima?
Hi, On Thu, Aug 20, 2009 at 8:08 AM, Dr. David Kirkby wrote: >>> A decision needs to be made about updating Maxima. First a few facts. >>> * I've created packages for *almost* the latest versions of ECL and Maxima. >>> >>> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.3/ >>> http://sage.math.washington.edu/home/kirkby/Solaris-fixes/maxima-5.19.0/ >>> >>> Both have had an updates in the last week. I can easily update these, >>> but don't wish to waste my time unless these are likely to get put into >>> Sage. (The updates in both cases are minor anyway). >>> >>> I've created trac tickets >>> >>> update ECL >>> http://sagetrac.org/sage_trac/ticket/6564 >>> >>> update Maxima >>> http://sagetrac.org/sage_trac/ticket/6699 >>> >>> This is clearly going to need some work by different people. So a >>> decision needs to be made really on whether an update takes place. >>> Otherwise, there is no point people wasting time re-writing the doctests >>> and any other changes that are necessary. >> >> >> +1 >> >> IMO, we should definitely upgrade to the latest versions of both. >> Could you please give the number (roughly) of doctest failures in all? > > I got 56 failures on Solaris. A log can be found at > > http://sagetrac.org/sage_trac/attachment/ticket/6709/test.log Thanks! From the log it seems to me that maxima does mostly better now than what it did earlier. > http://sagetrac.org/sage_trac/ticket/6699 > > is marked as '[with spkg; needs work]' but there is nothing I can do to > it. The package itself installs ok, and executes roughly how one would > expect. > It needs a bit more work than most packages and it is work for the most > part I'm unable to do. (I'm not a mathematician). As you said the spkg's are fine. We just need to patch the doctest failures. It seems around 14 files need fixes. I would suggest we post several different patches fixing different files. Then different people can work independently. If its OK with you then I can take three files "calculus/calculus.py", "calculus/functional.py" and "symbolic/expression.py" for fixing as I am working with them currently. I can then attach the patch for these to your ticket. For the cases where fixing seems non-trivial, we can discuss here how to deal with them. BTW, it would be good if you could update them to the latest upstream version so that no more changes would be needed for now. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] It takes too long to check "x in list" in symbolics!
Hi,
It takes too long to check whether x is in a list in new symbolics
-
sage: var('x,x1,x2,x3,x4')
(x, x1, x2, x3, x4)
sage: f = function('f')
sage: mylist = [x1,x2,x3,x4,f(x1),f(x2),f(x3),f(x4)]
sage: timeit('x in mylist')
5 loops, best of 3: 461 ms per loop
If your program needs to check it couple of more times
--
sage: timeit('x in mylist')
5 loops, best of 3: 1.26 s per loop
sage: timeit('x in mylist')
5 loops, best of 3: 3.4 s per loop
--
For a comparison
-
sage: timeit('x1 in mylist')
625 loops, best of 3: 473 ns per loop
-
Reason for this huge discrepancy stems from the fact that
except for last example, in all previous cases maxima is called
to check the equality.
Thus it seems, new symbolics depends on maxima for basic
operations even now.
I don't know the rationale behind this design given pynac has
a method to compare two symbolic expression (ex1.is_equal(ex2)).
In any case, this design ensures writing a program in new symbolics
where some basic tests like "if x in list" needs to done, is no better than
old symbolics.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: What's the view on updating Maxima?
Hi, On Thu, Aug 20, 2009 at 6:45 AM, Dr. David Kirkby wrote: > > A decision needs to be made about updating Maxima. First a few facts. > > > * The version of Maxima (5.16.3) in Sage is quite old. > * The version of ECL (9.4.1) in Sage is quite old. > * The old ECL 9.4.1 will not build on Solaris with a SPARC processor. > * The updated ECL will not work with the old Maxima due to a bug in the > old Maxima. > * I've created packages for *almost* the latest versions of ECL and Maxima. > > http://sage.math.washington.edu/home/kirkby/Solaris-fixes/ecl-9.8.3/ > http://sage.math.washington.edu/home/kirkby/Solaris-fixes/maxima-5.19.0/ > > Both have had an updates in the last week. I can easily update these, > but don't wish to waste my time unless these are likely to get put into > Sage. (The updates in both cases are minor anyway). > > I've created trac tickets > > update ECL > http://sagetrac.org/sage_trac/ticket/6564 > > update Maxima > http://sagetrac.org/sage_trac/ticket/6699 > > Others have tested these and find the .spkg's work, but the new maxima > creates many doctest failures. > > One very nice one is this: > > sage: integral( exp(-x^2)*ln(x), x, 0, oo) > Expected: > integrate(e^(-x^2)*log(x), x, 0, +Infinity) > Got: > -1/4*(euler_gamma + 2*log(2))*sqrt(pi) > > Another less nice one is this: > > sage: 'gcd' in m.trait_names() > Expected: > True > Got: > False > > > > This is clearly going to need some work by different people. So a > decision needs to be made really on whether an update takes place. > Otherwise, there is no point people wasting time re-writing the doctests > and any other changes that are necessary. +1 IMO, we should definitely upgrade to the latest versions of both. Could you please give the number (roughly) of doctest failures in all? Best, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Serious bug in integral using Maxima?
Hi, On Wed, Aug 19, 2009 at 2:30 PM, William Stein wrote: > > On Tue, Aug 18, 2009 at 11:00 PM, Ondrej Certik wrote: >> >> well, I would interpret it differently: >> >> int f(x) d(x^2) = int f(x) 2 x dx >> = 2 integrate(x*f(x),x) > > That's exactly what I meant. I was just being very sloppy because I > was in a hurry. The point is that "int f(x) d(x^2) = int f(x) 2 x > dx" seems very reasonable. We could easily make Sage use this > interpretation even though Maxima doesn't. It woud be an additional > 2-3 lines of code in calculus.py. > > I am equally for either: > > (1) raising an error like Mathematica does > and > (2) Use the interpretation that Ondrej and I agree upon above. > > I favor (1) a little bit more than (2), because it's clear that there > is some confusion over this issue Hmm, could you please clarify a bit? When you say "raise an error" do you mean (A) (damn the user!!) --- sage: integrate( sin(x), x^2) TypeError: blah.. blah... --- or (B) (leave it symbolic) --- sage: integrate(f(x), x^2) integrate( sin(x), x^2) --- (A) will have some bad consequences like - sage: h = sin(x) + integrate( sin(x), x) sage: h.subs(x==2*x) sin(2*x) - cos(2*x) - will work but - sage: h = sin(x) + integrate( sin(x)/x, x) sage: h.subs(x==2*x) ... TypeError: . - It would be bad if we don't allow even constant scaling of variable in the integration. I guess, there are no ambiguity when it is an expression containing single variable and we should process it as you and Ondrej suggested. For other cases, we leave it symbolic as Robert (Dodier) suggested. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Explicit variable of integration
Hi,
On Tue, Aug 18, 2009 at 8:02 PM, Jason Grout wrote:
>
> Fredrik Johansson wrote:
>>> Given we are moving to a new settings, I am proposing that we make
>>> integration syntax bit stricter and consistent now. In particular, we allow
>>> only
>>> following inputs as valid
>>>
>>> (1) integrate( f(x), x)
>>> (2) integrate( f(x), (x,a,b) )
>>> (3) integrate( f(x), x, a, b)
>>
>> I suggest getting rid of (3) if only to support the following syntax
>> for multiple integrals without ambiguity:
>>
>> integrate(f(x,y,z), (x,a,b), (y,c,d), (z,e,f))
>>
>
> Technically, that's unambiguous now, as it's easy to tell the difference
> between a tuple (x, a, b) and a number or symbolic variable.
>
> However, I think you're right that it is confusing to students to have
> the above notation and (3).
I agree that if we want to support multiple integrals in future then
we should get rid of (3).
There are some technical issues for implementing (2) in new symbolics
directly. As it stands, tuple can't be coerce to SR of pynac.
---
sage: x,a,b = var('x,a,b')
sage: f = function('f')
sage: f(x, (x,a,b) )
.
TypeError: cannot coerce arguments: no canonical coercion from to Symbolic Ring
-
I know a quick-hack that bypasses this by using a dummy function
say
-
sage: symbolic_tuple = function('')
sage: xab = symbolic_tuple(x,a,b)
sage: f(x, xab)
f(x, (x, a, b))
-
I guess, there may be a better solution.
Burcin, do you have any comments/suggestions on this?
Thanks
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Serious bug in integral using Maxima?
On Wed, Aug 19, 2009 at 3:17 AM, Robert Dodier wrote: > > William Stein wrote: > >> Unless you can give a explanation of what you want integrating wrt x^2 >> to mean, I think we should also raise an error in Sage. > > That would be unfortunate. Faced with some unrecognized construct, > the mathematical thing to do is to just leave it be. Whether it's > meaningful is for the user to decide. You don't know what > integrate(f(x), g(x)) means. Why not let someone else come > up with an interpretation? Why must you close that door? > > Incidentally, integrate(f(x), g(x)) = integrate(f(g^(-1)(y)), y), when > g^(-1) is well defined, seems plausible. I'm not saying Sage should > apply such an identity, only that Sage should not prevent the user > from applying it. +1 Yes, I think now I agree with you. It is better to return it un-evaluated than raising an error. As you, Ondrej and Simon pointed out that for some g, it has un-ambiguous interpretation and may be Sage should apply the identity where possible (definitely for expression with single variable) before passing it to maxima. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Serious bug in integral using Maxima?
Hi,
On Tue, Aug 18, 2009 at 9:27 PM, William Stein wrote:
>
>> --
>> sage: f(x) = function('f',x)
>>
>> sage: f(x).integral(x)
>> integrate(f(x), x)
>>
>> sage: f(x).integral(x^2)
>> x^2*f(x)
>> ---
>
> Indeed, what does that mean? If forced to, I would interpret this as
>
> int f(x) d(x^2) = int f(x) 2 x dx
> = 2x integrate(f(x),x)
>
> So I think the Sage/Maxima answer of x^2*f(x) is bizarre.
>
> Matheamatica just considers this input to be invalid:
>
> sage: mathematica.eval('Integrate[f[x],x^2]')
>
> 2
> Integrate::ilim: Invalid integration variable or limit(s) in x .
>
> 2
> Integrate[f[x], x ]
>
> Unless you can give a explanation of what you want integrating wrt x^2
> to mean, I think we should also raise an error in Sage.
I tried that input out of curiosity during testing. I was expecting
a TypeError but instead I got an answer !!
I agree, we should raise an error. Ironically, in "calculus.py" the raise
error line (556) has been commented out for some reason.
---
elif not is_SymbolicVariable(v):
v = var(repr(v))
#raise TypeError, 'must integrate with respect to a variable'
-
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Serious bug in integral using Maxima?
Hi, On Tue, Aug 18, 2009 at 8:42 PM, rjf wrote: > > did you mean to integrate with respect to "x^2" ? Yes. > Well, x^2 doesn't occur in f(x). So let's rename x^2 as y. > What is the integral of f(x) with respect to y? > > It is y*f(x). > > substituting back x^2 for y, you get x^2*f(x). Are you saying during integration maxima is not aware that "x^2" is the square of "x"? Take following examples: -- (%i4) integrate(log(x), x); (%o4)x log(x) - x (%i5) integrate(log(x^2), x^2); 2 (%o5) 2 x log(x) -- "log" is certainly aware of it. > Certainly Maxima expects "the variable of integration" as > the second argument. Anything else is asking for trouble. Then maxima should throw error instead of giving a wrong answer silently. This is rather bizarre given maxima is known to be over-cautious during integration and sometime it asks too many questions, even something like (%i6) integrate(1/x, x, 0, 1); Is x + 1 positive, negative, or zero? Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Explicit variable of integration
Hi, On Tue, Aug 18, 2009 at 3:03 PM, William Stein wrote: > > On Tue, Aug 18, 2009 at 11:00 AM, Nick Alexander wrote: >> (2) integrate( f(x), (x,a,b) ) (3) integrate( f(x), x, a, b) >> >> Let's just choose one. I'm torn, but prefer (3) with a and b optional >> variables. >> >> Nick >> > > Hmm. If I had to choose one of these: > >> (1) integrate( f(x), x) >> (2) integrate( f(x), (x,a,b) ) >> (3) integrate( f(x), x, a, b) > > I would choose only (2) or (1) and get rid of (3)! Why? Simply > because that is far more consistent with plotting (which in turn was > meant to be consistent with Mathematica). I suspect 3 is more like > Maple. > > So I prefer (1) and (2). Personally, I too prefer (1) and (2) but we need to keep (3) (at least behind the scene as maxima would return in this form and we may need to re-use it) Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Explicit variable of integration
Hi, I am preparing patches that will resolve http://trac.sagemath.org/sage_trac/ticket/6465 and will also move symbolic integration as a sub-class of SFunction into new symbolics. Currently, Sage allows omitting variable of integration for convenience. However, this convenience comes at a hefty price by making Sage syntax highly inconsistent. On top of this, it mask genuine typing error as a valid input. For example: "integrate(f(x), x, a, )" is treated as "integrate(f(x), x, x, a)" where user may have wanted to type "integrate(f(x), x, a, b)" but missed the "b". Given we are moving to a new settings, I am proposing that we make integration syntax bit stricter and consistent now. In particular, we allow only following inputs as valid (1) integrate( f(x), x) (2) integrate( f(x), (x,a,b) ) (3) integrate( f(x), x, a, b) Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Serious bug in integral using Maxima?
Hi,
While testing new integral SFunction class for Sage,
I encountered this weird bug.
--
sage: f(x) = function('f',x)
sage: f(x).integral(x)
integrate(f(x), x)
sage: f(x).integral(x^2)
x^2*f(x)
---
It appears to be a Maxima bug
--
(%i10) integrate(f(x), x^2);
2
(%o10) x f(x)
--
However, even "integral" of calculus.py seems to do crazy thing as well.
In line 566, it does
elif not is_SymbolicVariable(v):
v = var(repr(v))
Above imply
sage: v = var(repr(x^2))
sage: v
x^2
sage: v.diff(x)
0
---
The next commented out line in calculus.py seems to be the right
thing do here!!
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Sage/Pynac diff derivative with patches (was Re: Is new symbolic derivative ...)
Hi,
On Wed, Aug 5, 2009 at 7:25 AM, Burcin Erocal wrote:
> IIRC, you wrote that your implementation can coexist with the current
> one in Sage. Why don't you submit your changes so people can try out
> both approaches?
Here goes the patches for Sage-4.1.1. I am seeking review from both
pynac and sage volunteers. I am attaching the pynac patch
with this mail and marking a CC to pynac-devel.
Necessary instructions and needed patch are posted in the trac.
http://trac.sagemath.org/sage_trac/ticket/6756
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
# HG changeset patch
# User Golam Mortuza Hossain
# Date 1250425297 10800
# Node ID 6ecd738aa8a4241ccf6dd1d212e1c2e69b350711
# Parent 2e94e1e945b4bbc017c91ff1030e1f7e8f87fb6d
Implement *diff* format symbolic derivative
diff -r 2e94e1e945b4 -r 6ecd738aa8a4 ginac/fderivative.cpp
--- a/ginac/fderivative.cpp Sat Aug 01 04:09:34 2009 +0200
+++ b/ginac/fderivative.cpp Sun Aug 16 09:21:37 2009 -0300
@@ -22,6 +22,12 @@
#include
+#include "ex.h"
+#include "numeric.h"
+#include "relational.h"
+#include "symbol.h"
+#include "add.h"
+#include "mul.h"
#include "fderivative.h"
#include "operators.h"
#include "archive.h"
@@ -277,4 +283,305 @@
return res;
}
+//
+// Implementation of *diff* format symbolic derivative
+// Golam Mortuza Hossain (gmhoss...@gmail.com) 14-08-2009
+//
+
+/* Append all symbols and conditionally functions of *e* in the list *l* */
+void list_symbols_and_functions(const ex & e, lst & l, bool only_symbols)
+{
+if (is_a(e))
+l.append(e);
+else {
+if (!only_symbols && is_a(e))
+l.append(e);
+for(const_iterator ei = e.begin(); ei != e.end(); ++ei)
+list_symbols_and_functions(*ei, l, only_symbols);
+}
+}
+
+/* Check whether the expression contains the given symbol */
+bool has_symbol(const ex & e, const symbol & s)
+{
+if (e.is_equal(s))
+return true;
+else
+for(const_iterator ei = e.begin(); ei != e.end(); ++ei)
+if (has_symbol(*ei, s))
+return true;
+return false;
+}
+
+/* Check whether the expression has any symbol listed in *l* */
+bool ex_is_independent(const ex & e, const lst & l)
+{
+for(lst::const_iterator li = l.begin(); li != l.end(); ++li)
+if (has_symbol(e, ex_to(*li)))
+return false;
+return true;
+}
+
+/* Construct a new sorted exvector seq for diff. */
+exvector get_new_diff_seq(const exvector & seq, const ex & e, const ex & n)
+{
+exvector nseq;
+size_t num = seq.size();
+
+// First differentiation
+if (num == 1) {
+if (is_a(n) && ex_to(n).is_nonneg_integer()
+&& is_a(e) && !has_symbol(seq[0], ex_to(e))) {
+nseq.push_back(_ex0);
+return nseq;
+}
+nseq = seq;
+nseq.push_back(e);
+nseq.push_back(n);
+return nseq;
+}
+
+// Check for existing variable
+lst l;
+for (size_t i=1; i(n) && ex_to(n).is_nonneg_integer()
+&& is_a(e) && !has_symbol(seq[0], ex_to(e))) {
+nseq.push_back(_ex0);
+return nseq;
+}
+l.append(e); l.sort();
+bool got_it = false;
+size_t i=0, j;
+nseq.push_back(seq[0]);
+
+for (lst::const_iterator li = l.begin(); li != l.end(); ++li) {
+if(got_it) {
+j = 2*i - 1;
+nseq.push_back(seq[j]);
+nseq.push_back(seq[j+1]);
+} else {
+if(e.is_equal(*li)) {
+nseq.push_back(e);
+nseq.push_back(n);
+got_it = true;
+} else {
+j = 2*i + 1;
+nseq.push_back(seq[j]);
+nseq.push_back(seq[j+1]);
+}
+}
+i++;
+}
+return nseq;
+}
+
+/* Symbolically evaluate given diff seq.
+ It does:
+(1) If it is diff of diff then merge two seq's
+(2) remove diff var x if it acts 0 times
+(3) Put the seq in preferred sorted order
+*/
+exvector symbolic_eval_diff_seq(const exvector & orig_seq)
+{
+ex f = orig_seq[0];
+exvector seq;
+if (is_a(f) && ex_to(f).get_serial()
+ == diff_derivative_SERIAL::serial)
+for (const_iterator fi = f.begin(); fi != f.end(); ++fi)
+ seq.push_back(*fi);
+else
+seq.push_back(f);
+
+size_t num = orig_seq.size();
+for (size_t i=1; i(re
[sage-devel] Re: Sage to Maxima Conversion Error /w differentiating a function
On Mon, Aug 17, 2009 at 6:29 AM, Harald Schilly wrote:
>
> From the notebook's "report a problem" bugtracker:
>
> The conversion of a sage expression to maxima depends of the argument
> order of previous defined functions. For example:
>
> var('x y t')
> L=function('L', t, x, y)
> m1=maxima(diff(L,t))
> L=function('L', x, y, t)
> m2=maxima(diff(L,t))
> m2 delivers the wrong expression!
> --
> var('x y t')
> L=function('L', t, x, y)
> m1=maxima(diff(L,t))
> L=function('L', x, y, t)
> m2=maxima(diff(L,t))
> print m1
> print m2
>
> expect result m1 in all cases, no matter of the argument order!!!
>
> May be it is essential to solve this issue due to the fact that sage
> uses maxima to solve differential equations. In this case changing the
> operator sequence within L should not change the result.
>
> Note from me: This applies to 4.1 and I can confirm it in 4.1.1
This error stems from "D" to "diff" derivative conversion (unavoidable
for using Maxima) and has been reported at
http://trac.sagemath.org/sage_trac/ticket/6376
I will post, hopefully today, a new native implementation of "diff"
derivative for Sage/pynac. This will provide a solution to this issue
by avoiding the conversion.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Symbolic n-th derivative and integral (anti-derivative)
Hi,
While waiting for next Sage final release, I enhanced the
new symbolic "diff" implementation to support symbolic n-th
derivative. So one can now work with them by calling the new
diff derivative directly (with strict syntax)
sage: f(x) = function('f',x); n,m=var('n,m')
sage: h = symbolic_diff(f(x), x, n); h
diff(f(x), x, n)
-
"h" can be explicitly evaluated as
---
sage: h.subs(f(x)==x^2).subs(n==1)
2*x
---
It can be differentiated standard way
---
sage: h.diff(x)
diff(f(x), x, n + 1)
--
and can be integrated (via Maxima)
--
sage: h.integral(x)
diff(f(x), x, n - 1)
---
It can also be further differentiated m-th time
-
sage: symbolic_diff(h, x, m)
diff(f(x), x, m + n)
-
Now to have a unified approach (as suggested by Maurizio) for
derivative and anti-derivative (integral) following is a valid input
-
sage: symbolic_diff(h, x, -1)
diff(f(x), x, n - 1)
-
which is same as h.integral(x)!
Once the symbolic integration is moved to pynac SFunction class,
I am planning to enable calling integral directly from new
symbolic_diff.
I would appreciate if you have any further comments/suggestions
on this approach or any pitfalls I should worry about.
BTW, I have put the new derivative code in "fderivative.cpp" file of pynac as
second implementation of abstract derivative. In case, it would
be desirable to put the new code in a new file then please let me know.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Question on partial derivative of "f(x, x)" w.r.t. "x"
Hi Simon, On Sun, Aug 9, 2009 at 4:24 PM, Simon King wrote: >> Now if I say "f(x, x) = x" then from the output above I would >> get "2". > > Is it *possible* to say "f(x,x)=x"? What is it supposed to mean? I came there starting from "f(x,y) = (x+y)/2". So f(x,x) = x. However, as you have clearly demonstrated, this issue goes deeper than what I had in my mind earlier. > - A function on one variable x, written down in an odd way? > - A function whose domain is the diagonal in CC^2 ? > - Or is it "get two input parameters, pick one and return it"? > > Apparently, it is the third option: > sage: f(x,x)=x > sage: f > (x, x) |--> x > sage: f(2,1) > 1 > > This seems odd to me. Yes, this clearly looks like a bug to me! Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Question on partial derivative of "f(x, x)" w.r.t. "x"
Hi William, On Sun, Aug 9, 2009 at 3:24 PM, William Stein wrote: >> >> I encountered this issue while testing out new "diff" derivative >> implementation. So it would be good to know the right approach >> for handling this issue. > > What do *you* think the right approach is? Frankly, I am not too sure either. However, it seems reasonable to me to not to apply chain rule here as one is supposed to freeze the "other" variable (which happens to be same here) while applying chain rule. Even Maple and Wolfram alpha gives the same answer!! Maxima behaves rather gracefully as it does not evaluate anyway. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Question on partial derivative of "f(x, x)" w.r.t. "x"
Hi, If I compute partial derivative of f(x, x) w.r.t. x in Sage then I get - sage: f(x, x).diff(x) D[0](f)(x, x) + D[1](f)(x, x) - Now if I say "f(x, x) = x" then from the output above I would get "2". On the other hand, had I computed it directly, I would get "1" -- sage: (x).diff(x) 1 -- I encountered this issue while testing out new "diff" derivative implementation. So it would be good to know the right approach for handling this issue. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi Burcin, On Wed, Aug 5, 2009 at 7:25 AM, Burcin Erocal wrote: >> (1) Breaks substitution: > > We could either use the existing CallableSymbolicExpressionRing > implementation and force the user to give names to the arguments, to > get something like: I would appreciate if you implement a solution for this issue. >> Let me claim: Integrating an expression involving new symbolic >> derivative is at best EQUAL and often MORE computationally EXPENSIVE >> than its "diff" counterpart. > > Are you saying that if we stop evaluating (partial) derivatives, > integrating them would be easier? :) I said that in bold, it would be EXPENSIVE means it requires more computational steps. >> (4) Causes Maxima interface to break: >> http://trac.sagemath.org/sage_trac/ticket/6376 > > This is a serious bug in the maxima interface. It has nothing to do > with how we denote derivatives, if we use partial derivaties or > unevaluated ones. For the record, diff format derivative is NOT affected by this bug. >> (4) Gives mathematically non-sensical results: >> http://trac.sagemath.org/sage_trac/ticket/6465 > > This is also an independent problem. With recent changes in pynac, you > stated that you fixed this: Yep, and it is because you are now asking for derivative to be carried out w.r.t. a variable such as "x". I guess, you might agree that by these changes you have pointed out a deficiency in the pynac "D" derivative concept where derivative is specified by paramaters such as 0,1 compared to the "diff" concept where derivative is specified by variables such as "x", "y". > IIRC, you wrote that your implementation can coexist with the current > one in Sage. Why don't you submit your changes so people can try out > both approaches? Sure. I am waiting for the next Sage release as I want to avoid re-basing again. I have implemented this using pynac-0.1.9.a1 and sage-4.0.2. Given, you have now moved back to pynac-0.1.8.p2, I need to backport pynac changes and forward-port Sage changes. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
On Tue, Aug 4, 2009 at 1:02 PM, Nick Alexander wrote: > > Can you pattern match on it? It's really irritating to do subs/ > pattern matching on the existing derivatives. Yep! In fact, that was the main reason for doing so :-). The new "diff" derivative is really a symbolic "function". So regular pattern matching/substitution will work without any extra effort. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi,
On Mon, Jul 20, 2009 at 4:37 PM, Golam Mortuza
Hossain wrote:
> On Sun, Jul 19, 2009 at 3:11 PM, William Stein wrote:
>> At first glance doing this sounds like a really good idea. How hard
>> would it be for you to make a mock-up prototype of this to more
>> clearly demonstrate it? I'm definitely not opposed.
>
> OK, here is a prototype implementation.
>
> This is based on the principle that we stop applying chain rule
> when we hit a symbolic function and whose derivative isn't defined
> in sage/pynac.
> Notes: This is not the fastest implementation but my current priority
> is to get my work done even if it takes bit longer rather than not
> able to do at all.
I am back again on this issue :-) I just completed a native c++
implementation of "diff" format derivative in pynac.
This is around 15 times faster than my original prototype implementation.
This is even faster than pynac D derivative. Here are the output
from my sage session:
--
sage: f(x) = function('f', x)
sage: f(x).diff(x)
D[0](f)(x)
sage: timeit('f(x).diff(x)')
625 loops, best of 3: 89.9 µs per loop
sage: timeit('f(x).diff(x,100)')
125 loops, best of 3: 2.68 ms per loop
sage: from sage.symbolic.pynac import set_diff_derivative_level
sage: set_diff_derivative_level(1)
sage: f(x).diff(x)
diff(f(x), x, 1)
sage: timeit('f(x).diff(x)')
625 loops, best of 3: 83.9 µs per loop
sage: timeit('f(x).diff(x,100)')
625 loops, best of 3: 513 µs per loop
--
This implementation also supports applying chain-rule (where
make sense) on-demand.
--
sage: g(x) = function('g',x)
sage: f(g(x)).diff(x)
diff(f(g(x)), x, 1)
sage: set_diff_derivative_level(2)
sage: f(g(x)).diff(x)
diff(f(g(x)), g(x), 1)*diff(g(x), x, 1)
sage: f(x+x^2).diff(x)
diff(f(x^2 + x), x, 1)
---
This would be useful for example in computing symbolic
functional derivative.
BTW, what is the final decision on the default derivative format
in Sage?
Note: As you can see this implementation ensures both
formats can happily co-exist with each other and user
can switch between the different formats in run-time.
However, we need to make a decision on the default
format as symbolic integration algorithm would depend
on the derivative format.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: reviews for symbolics bug fixes
Hi Burcin, On Sat, Aug 1, 2009 at 9:09 AM, Burcin Erocal wrote: > Note that the new package also supports a flag to disable chain rule > for symbolic functions. This will definitely be useful for constructs > such as symbolic integrals, sums, products, limits, etc. > > It should also pave the way for a fix to #6465. Maybe you can take that > up again? Thanks Burcin. OK, I got that (#6465) fixed using the option for disabling chain rule. I will wait for the next release before I put up a patch. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: reviews for Sage 4.1.1.rc1
Hi, On Sat, Aug 1, 2009 at 10:21 PM, Minh Nguyen wrote: > > The Sage 4.1.1 release cycle is now in 4.1.1.rc1, which hasn't been > released yet. As this release candidate is for stabilizing Sage and > fixing bugs, I thought I should outline below a number of bug fixes > which would be good to get into Sage 4.1.1. There are about 5 tickets > relating to symbolics which need review: > > #6243 http://trac.sagemath.org/sage_trac/ticket/6243 > #6344 http://trac.sagemath.org/sage_trac/ticket/6344 > #6377 http://trac.sagemath.org/sage_trac/ticket/6377 > #6401 http://trac.sagemath.org/sage_trac/ticket/6401 > #6404 http://trac.sagemath.org/sage_trac/ticket/6404 > > Ticket #6404 fixes a typesetting bug, but it also updates the Pynac > spkg. The spkg update is crucial for reviewing tickets #6243, #6377 > and #6401. These four tickets cannot be reviewed in isolation from > each other. Golam has expressed an interest in reviewing them at Minh, I just finished reviewing #6243, #6377, #6401 and #6404. The new pynac spkg fixes several issues and it should be included. There are several related issues that still need some future work and I have noted some of them in the comments. Note: I tested these against my sage-4.1 stable. So please check whether they apply/passes doctests cleanly on 4.1.1rc1. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: reviews for symbolics bug fixes
Hi, On Sat, Aug 1, 2009 at 2:54 AM, Burcin Erocal wrote: > > I just uploaded a new pynac package and patches which fix > > #6404 conjugate typesetting > #6401 typesetting real and imag > #6243 fderivative hash collision > #6377 exp evaluation at infinity > > on trac. The package is here: > > http://sage.math.washington.edu/home/burcin/pynac/pynac-0.1.8.p2.spkg > > It would be good to include these in the 4.1.1 release. Are there any > volunteers for reviews? Thanks Burcin. Surely, it would be good to have them fixed in the next release. If no one else reviews it within next couple of days then I will be happy to do so, as I am travelling right now. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Strange timeit output while using maxima interface
Thanks Minh and Simon!
On Mon, Jul 27, 2009 at 8:13 AM, Simon King wrote:
>> -
>> sage: f(x) = function('f',x);
>> sage: timeit('bool( f(x) == 0 )')
>> 5 loops, best of 3: 71.6 ms per loop
>> sage: timeit('bool( f(x) == 0 )')
>> 5 loops, best of 3: 89.1 ms per loop
>
> Finally someone comes up with a very short example of this
> phenomenon!
>
> The code that I posted there was far too complicated, I guess. But
> later, I posted trac ticket #4731 with a much simpler code, see
> http://trac.sagemath.org/sage_trac/ticket/4731
>
> Appararently nobody was ever working on it.
Yeah. Thats what it seems :-)
I did bit more digging trying to pin-point the culprit. In a fresh
sage prompt if I try the following:
--
sage: timeit('integrate(sin(x)/x, x)')
5 loops, best of 3: 524 ms per loop
--
where as if I try above directly in the maxima
(./sage -sh && cd local/bin && ./maxima )
---
(%i2) integrate( sin(x)/x, x);
Evaluation took 0.0120 seconds (0.0100 elapsed)
...
(%i3) integrate( sin(x)/x, x);
Evaluation took 0.0080 seconds (0.0090 elapsed)
...
---
Assuming time reported in both systems can be
compared, I made two observations:
(1) Repeated use of same command within maxima (directly)
shows no degradation of evaluation time where as doing
the same within Sage clearly shows progressive degradation.
(2) In a fresh prompt: for the same computation, maxima took
120 ms where as the Sage reports 524ms!!
Am I doing something terribly wrong? Or is it just because of
pexpect overhead?
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Strange timeit output while using maxima interface
Hi,
While doing some symbolic computations that require
Maxima interface, "timeit" reports progressively
longer duration for the same computation.
-
sage: f(x) = function('f',x);
sage: timeit('bool( f(x) == 0 )')
5 loops, best of 3: 71.6 ms per loop
sage: timeit('bool( f(x) == 0 )')
5 loops, best of 3: 89.1 ms per loop
sage: timeit('bool( f(x) == 0 )')
5 loops, best of 3: 101 ms per loop
sage: timeit('bool( f(x) == 0 )')
5 loops, best of 3: 127 ms per loop
sage: timeit('bool( f(x) == 0 )')
5 loops, best of 3: 159 ms per loop
sage: timeit('bool( f(x) == 0 )')
5 loops, best of 3: 231 ms per loop
sage: timeit('bool( f(x) == 0 )')
5 loops, best of 3: 305 ms per loop
---
Is something leaking in the maxima interface?
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi,
On Thu, Jul 23, 2009 at 3:06 PM, Burcin Erocal wrote:
> I am not opposed to having the unevaluated diff as an alternative
> operator.
Thanks Burcin. Surely, it helps to have both derivatives available to
Sage users. As Tim said, similar options are available to Maple users.
It is easy to put a flag that will instruct which derivative to use.
For example, in my prototype I could add another condition
// No derivative defined and user wants diff format? Then dont apply chain rule
if (opt.derivative_f == NULL && use_diff_format) {
.
...
}
The next question is then whether we evaluate symbolic derivative
using "D" by default or we store them un-evaluated using "diff"
and evaluate them in terms of "D" only on-demand?
Mock-up usage could look like
--
sage: diff( f(x), x)
diff( f(x), x, 1)
sage: diff( f(x), x, D_format=True)
D[0](f)(x)
--
Given pynac "D" construct doesn't store enough information
for guaranteed conversion to "diff" format, personally I don't
see any way out other than storing symbolic derivative
un-evaluated by default.
Cheers,
Golam,
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi Burcin, I am sorry if I have hurt you by my earlier statements in this thread. Best, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi, On Wed, Jul 22, 2009 at 11:49 PM, Bill Page wrote: >> - >> h = f(x^2).diff(x)*(x+1/x) >> >> sage: h.subs(f(x^2)==1) >> 2*(x + 1/x)*x*D[0](f)(x^2) >> >> sage: h.subs(f(x^2).diff(x)==0) >> 2*(x + 1/x)*x*D[0](f)(x^2) >> - > > It does not make sense to ask to "substitute" 'f(x^2)=1' into 'h' > because 'f(x^2)' is an expression - not a function. May be I didn't understand you properly. Are you saying substituting an expression (f(x^2)) within an expression (h) by a constant is invalid? If so, then isn't: "(x+x^2).subs(x==1)" invalid as well? Anyway, it does not help whether you substitute by a constant or by an expression, the problem remains. Within sage the only way I know, to do above substitution is to do --- sage: h.subs(f(x^2).diff(x)/(2*x)==0) 0 --- However, even using such ugly tricks, I have encountered issues in substituting expression that contains new derivative. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi, On Wed, Jul 22, 2009 at 9:25 PM, Maurizio wrote: >> (5) Looses information irrecoverably: >> >> From "D[0](f)(x-a)" its not possible to decide whether original >> variable of differentiation was "x" as in f(x-a).diff(x) or "a" >> as in -f(x-a).diff(a). This again affects integration algorithm. >> > > Is this caused by the representation or by how the information is > stored? > In case its just representation, it should be trivial to fix. > In case the information is not stored... Well, I don't think this is > possible, it does not make sense that the definition of a derivative > doesn't include the variable of derivation. Unfortunately, it is the later. Pynac fderivative doesn't store variable of differentiation by design. This is the reason why it must continue applying chain rule until the end. > At the very end, my personal opinion is that the community should plan > the work on derivatives AND integrals at the same time, otherwise it > does not make sense to stick with some derivatives we are not going to > support in the long term (integrals are going to take a lot of time > probably). I agree. Both Sage derivative and anti-derivative should be made compatible to each other by design from the very beginning. Having them in two separate sub-system can make thing only worse. Regarding Maxima, I strongly believe that Sage needs Maxima for symbolic integration for quite some time. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi, On Wed, Jul 22, 2009 at 7:47 AM, Burcin Erocal wrote: >> > Inability to substitute the argument of D[] has ensured that >> > I am forced out from using new sage symbolics for my own work. > > As I said above, you could have added a short term workaround for this, > once you start using cython to call pynac internals. As someone said, talk is cheap. FYI, I spent two full days trying to find a work-around that really works. May be I did stupid way but I would like to invite you to substitute f(x^2)=1 in the following simple expression by using any sage algorithm - h = f(x^2).diff(x)*(x+1/x) sage: h.subs(f(x^2)==1) 2*(x + 1/x)*x*D[0](f)(x^2) sage: h.subs(f(x^2).diff(x)==0) 2*(x + 1/x)*x*D[0](f)(x^2) - > I believe the effort could be better spent fixing the bugs you listed > above. Thanks for letting know your "belief". If Sage development is dictated by someone's belief rather than user's need, then I really shouldn't argue anymore. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi, On Mon, Jul 20, 2009 at 8:31 PM, Robert Bradshaw wrote: >> On Sun, Jul 19, 2009 at 3:11 PM, William Stein >> wrote: > Or should we just restore old "diff" by simply sub-classing it > from SFunction like what is being done for "integration" > and others? >>> >>> At first glance doing this sounds like a really good idea. How hard >>> would it be for you to make a mock-up prototype of this to more >>> clearly demonstrate it? I'm definitely not opposed. >> >> OK, here is a prototype implementation. >> >> This is based on the principle that we stop applying chain rule >> when we hit a symbolic function and whose derivative isn't defined >> in sage/pynac. > > Excellent idea! Thanks Robert. Its now up to Sage policy maker to decide whether to continue with pynac fderivative. Inability to substitute the argument of D[] has ensured that I am forced out from using new sage symbolics for my own work. Cheers, Golam, --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi,
On Sun, Jul 19, 2009 at 3:11 PM, William Stein wrote:
>>> Or should we just restore old "diff" by simply sub-classing it
>>> from SFunction like what is being done for "integration"
>>> and others?
>
> At first glance doing this sounds like a really good idea. How hard
> would it be for you to make a mock-up prototype of this to more
> clearly demonstrate it? I'm definitely not opposed.
OK, here is a prototype implementation.
This is based on the principle that we stop applying chain rule
when we hit a symbolic function and whose derivative isn't defined
in sage/pynac.
These are the output from my sage console
-
sage: f(x) = function('f',x)
sage: f(x).diff(x)
diff(f(x), x, 1)
sage: f(x).diff(x,2)
diff(f(x), x, 2)
sage: sin(cos(f(x))).diff(x)
-sin(f(x))*cos(cos(f(x)))*diff(f(x), x, 1)
sage: f(sin(x)).diff(x)
diff(f(sin(x)), x, 1)
-
I have done three things:
(1) Defined a symbolic derivative wrapper SFunction (attached).
Frankly, this is not much different than: diff = function('diff')
(2) Added a small wrapper cython function in symbolic/pynac.pyx as
cdef public object py_derivative(unsigned id, object var, object args) except +:
"""
"""
cdef SFunction func = get_sfunction_from_serial(id)
assert(func is not None)
from sage.symbolic.derivative import newdiff
return newdiff(func(*args), var)
(3) Added a condition in "function.cpp" in pynac such that it calls
"py_derivative" instead of applying chain rule when it hits
a symbolic function and whose derivative function is not defined.
// No derivative defined? Then dont apply chain rule
if (opt.derivative_f == NULL) {
// convert seq to a PyTuple of Expressions
PyObject* args = exvector_to_PyTuple(seq);
PyObject* dvar = ex_to_pyExpression(s);
PyObject* pyresult = py_derivative(serial, dvar, args);
Py_DECREF(args);
Py_DECREF(dvar);
if (!pyresult) {
throw(std::runtime_error("function::derivative():
python function raised exception"));
}
// convert output Expression to an ex
ex result = pyExpression_to_ex(pyresult);
Py_DECREF(pyresult);
if (PyErr_Occurred()) {
throw(std::runtime_error("function::derivative():
python function (pyExpression_to_ex) raised exception"));
}
return result;
Notes: This is not the fastest implementation but my current priority
is to get my work done even if it takes bit longer rather than not
able to do at all.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
"""
Symbolic Derivative
"""
from sage.symbolic.function import SFunction, sfunctions_funcs
class SymbolicDerivative(SFunction):
def __init__(self, *args, **kwds):
"""
EXAMPLES::
"""
kwds['built_in_function'] = True
for name in sfunctions_funcs:
if hasattr(self, "_%s_"%name):
kwds['%s_func'%name] = getattr(self, "_%s_"%name)
SFunction.__init__(self, "diff", *args, **kwds)
def _eval_(self, *args, **kwds):
"""
Returns the results of symbolic evaluation
"""
# Two arguments comes only from pynac call. Others are
# self call.
if len(args) != 2:
return None
f = args[0]
x = args[1]
if x not in f.args():
return 0
if f.operator() == newdiff:
nargs = list(f.operands())
new_var = True
n = len(nargs)
for j in range(1,n,2):
if x == nargs[j]:
nargs[j+1] = nargs[j+1] + 1
new_var = False
break
if new_var:
nargs.append(x)
nargs.append(1)
return self.__call__(*nargs)
return self.__call__(f, x, 1)
newdiff = SymbolicDerivative()
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi, On Sun, Jul 19, 2009 at 3:11 PM, William Stein wrote: > > At first glance doing this sounds like a really good idea. How hard > would it be for you to make a mock-up prototype of this to more > clearly demonstrate it? I'm definitely not opposed. I need bit of help. How does one convert Ginac symbol to python object? For example: I could find examples of converting Ginac seq to python arguments as: PyObject* args = exvector_to_PyTuple(seq); However, I couldn't find an example for doing the same with Ginac symbol. Basically, I need to pass the variable of differentiation to python/cython function as PyObject* pyresult = py_derivative(serial, var, args); Thanks Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is new symbolic derivative really worth the efforts?
Hi, On Sun, Jul 19, 2009 at 3:11 PM, William Stein wrote: >> On Jul 19, 2009, at 12:08 PM, Golam Mortuza Hossain wrote: >>> >>> My question now is it really worth solving all of the >>> above issue to keep working with fderivative of pynac? >>> >>> Or should we just restore old "diff" by simply sub-classing it >>> from SFunction like what is being done for "integration" >>> and others? > > At first glance doing this sounds like a really good idea. How hard > would it be for you to make a mock-up prototype of this to more > clearly demonstrate it? I'm definitely not opposed. Thanks. OK, I will come up with a prototype "diff" hopefully soon. I might need to ask some sage-pynac interface related questions as my current understanding of this interface is limited. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Is new symbolic derivative really worth the efforts?
Hi, I have spent considerable amount of time in last one month working with new symbolics. Overall, I am impressed with it. However, my experience with new derivative makes me wonder whether the pynac "fderivative" construct is really worth the efforts! While implementing functional derivative and integration algorithm for generalized function using new symbolics, I have been brought to near a dead end because of new derivative. It (1) Breaks substitution: Arguments of derivative can't be substituted http://trac.sagemath.org/sage_trac/ticket/6480 (2) Nightmare for writing integration algorithm: If h = f(g(x)).diff(x) then integrate(h, x) is trivial. However, in new symbolics to do so, one needs compute integrate( D[0](f)(g(x, y))*D[0](g)(x, y), x) Let me claim: Integrating an expression involving new symbolic derivative is at best EQUAL and often MORE computationally EXPENSIVE than its "diff" counterpart. (4) Causes Maxima interface to break: http://trac.sagemath.org/sage_trac/ticket/6376 (4) Gives mathematically non-sensical results: http://trac.sagemath.org/sage_trac/ticket/6465 (5) Looses information irrecoverably: >From "D[0](f)(x-a)" its not possible to decide whether original variable of differentiation was "x" as in f(x-a).diff(x) or "a" as in -f(x-a).diff(a). This again affects integration algorithm. (6) Compact? It is true that this format is sometime compact but consider the counter example: -- sage: f( g(x) + h(x) ).diff(x) (D[0](g)(x) + D[0](h)(x))*D[0](f)(g(x) + h(x)) -- In old symbolics it takes less space to print - sage: f( g(x) + h(x) ).diff(x) diff(f(h(x) + g(x)), x, 1) - (7) Printing issues: We are still debating on this in separate thread. My question now is it really worth solving all of the above issue to keep working with fderivative of pynac? Or should we just restore old "diff" by simply sub-classing it from SFunction like what is being done for "integration" and others? Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: typesetting partial derivatives
Hi,
On Sat, Jul 18, 2009 at 8:49 PM, Jason Grout wrote:
> OLD:
>
> sage: var('x,y')
> sage: f = function('f')
> sage: f(x).derivative(x)
> D[0](f)(x)
> sage: f(x,x).derivative(x,2)
> D[0, 0](f)(x, x) + 2*D[0, 1](f)(x, x) + D[1, 1](f)(x, x)
>
>
> NEW:
>
> sage: f(x).derivative(x)
> D[1](f)(x)
> sage: f(x,x).derivative(x,2)
> D[2, 0](f)(x, x) + 2*D[1, 1](f)(x, x) + D[0, 2](f)(x, x)
The latex version looks good to me. Also, new text-mode
output is compact compared to the previous one.
My concern however is that above text mode output (like the previous
one) is not recognized by Sage as valid input.
Consider a user's perspective who is seeing "D[0](f)(x)" for
the first time.
(1) As Sage recommends, the user will try "D?"
sage: D?
Object `D` not found.
(2) User thinks may be docstring is not there. He then
tries to figure out what does it really do. So he tries
"sin" in place of "f"
-
sage: D[0](sin)(x)
...
NameError: name 'D' is not defined
-
Now you can imagine the kind of "first impression" it makes
to an user.
My 2 cents:
(1) Text-mode output for the proposed "D[2, 0](f)(x, x)" be of the form
D( f(x, x), [2, 0] )
(2) Add a new derivative function "D" which is exposed to users. This
will be similar to current "diff" but instead it will act using parameters
"[2,0]".
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Custom definitions for latex style
Hi,
On Jun 25, 9:05 am, Burcin Erocal wrote:
> On Thu, 25 Jun 2009 13:22:46 +0200
>
> Stan Schymanski wrote:
>
> > I have been asked to forward the below to the sage-devel list. Ticket
> > #6290 introduced a way to custom-define thelatexstyle of functions,
> > but it would be great if something similar was made possible for any
> > variable. Is there a way for this already? I used to do it in the
> > following way, but now I get an error message:
>
> > sage: var('hi kunsati delyui')
> > sage: hi._latex_ = lambda: 'h_i' # Matric suction
> > head in layer i (=pcapvec)
> > sage: kunsati._latex_ = lambda: 'K_{unsat,i}' # Unsaturated
> > hydraulic conductivity in layer i
> > sage: delyui._latex_ = lambda: '\delta_{yu,i}' # Soil layer
> > thickness in layer i
> > Traceback (most recent call last):
> > ...
> > AttributeError: 'sage.symbolic.expression.Expression' object attribute
> > '_latex_' is read-only
>
> Since Expression is a cython class, you cannot overwrite the _latex_()
> method.
>
> Pynac supports settinglatexnames forvariablesat creation, but this
> functionality is not exposed in the wrapper. Another solution by
> hacking latex_variable_name() might be possible, but I would like to
> avoid that if possible.
I was looking into Pynac/Ginac code to see how difficult it would be
to expose the Ginac's Tex_name feature for variables.
(1) Pynac allows to specify Tex_name while defining variables.
(2) Currently, pynac is patched to effectively use
latex_variable_name
for printing latex as it is better than Ginac's default print_latex
for variables
I suggest following changes:
(1) Compute latex string for variable using Sage's
"latex_variable_name"
while defining it unless user provides a latex string.
(2) Store this latex string in Ginac symbol framework and use Ginac's
print_latex method.
This would be more efficient than the current approach. For example,
if variable "alpha123" appears 10 times in an expression, currently
"latex_variable_name" function is called 10 times to typeset the
the same as "\\alpha_{123}".
On the other hand, if we store the string in Ginac then we need
to call "latex_variable_name" just once regardless of how many
times the variable appears in the expression.
BTW, I already have a hackish but working implementation
for above.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Real domain for symbolic variables
Hi,
In new symbolics, the default symbolic variables are complex.
However, sometime it is useful/desirable to make the domain of
variables to be real.
Currently, there are no way to specify the domain of variables
in Sage although underlying Ginac allows it. For example: following
would to be good to have.
--
sage: var('x,y,z', domain='real')
--
Also, "assume" should be fixed so that it updates the domain.
Currently it doesn't do so.
sage: conjugate(x)
conjugate(x)
sage: assume(x, 'real')
sage: assumptions()
[x is real]
sage: conjugate(x)
conjugate(x)
I could implement above rather easily by exposing underlying Ginac
feature. However, I am not sure how to submit patches for pynac/ginac
as its not under "devel/sage".
Cheers
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] .is_zero() method for symbolic expression involving derivative
Hi, If a symbolic expression contains symbolic derivative then checking whether it is zero, raises error: -- sage: x.diff(x,2).is_zero() True sage: f(x).diff(x).is_zero() NotImplementedError: derivative -- This fails because new symbolics tries to convert it to maxima expression for checking the relation. This is rather disturbing as its works fine for other expressions without invoking maxima. Increasingly it appears to me that FDerivative construct is not so well integrated with rest of the new symbolics (pynac). Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Substitute method for argument of derivative operator
Hi, On Fri, Jul 10, 2009 at 9:58 AM, Burcin Erocal wrote: > > I'll try to spare some time for pynac this weekend, and look at the > changes you need for the derivatives to work. Thanks! > I'm not convinced that > adding a new field to the function_options class to switch the > application of the chain rule on/off is really necessary at this point. > I might just add a quick hack to special case the integral function you > define, unless someone comes up with other examples where disabling the > chain rule is needed. There are at least three other functions for which new derivative returns mathematically wrong results because it uses chain rule blindly (1) limit( f(x), x=a) (2) laplace( f(t), t, s) (3) inverse_laplace ( F(s), s, t) Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Substitute method for argument of derivative operator
Hi Burcin,
On Wed, Jul 8, 2009 at 11:02 AM, Burcin Erocal wrote:
> If you share your code creating an SFunction called 'integral', I can
> produce patches for Sage and pynac to special case that function when
> computing derivatives. (Much like what is done for Order in the pynac
> code right now.)
Thanks for looking into this. I am attaching prototype integration
class and integration code for generalized function that you can play with.
Sub-classing integration from SFunction class, makes few thing really
easy. For example numerical approximation .n() works like a charm
--
sage: integrate( exp(x)/x, x, 1, 10)
integrate(e^x/x, x, 1, 10)
sage: integrate( exp(x)/x, x, 1, 10).n()
2490.33385842557
--
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
"""
Symbolic Integration
AUTHORS:
* Golam Mortuza Hossain (2009-07-08)
"""
##########
#
# Copyright (C) 2009 Golam Mortuza Hossain
#
# Distributed under the terms of the GNU General Public License (GPL v2+)
# http://www.gnu.org/licenses/
#
##
from sage.symbolic.ring import SR
from sage.symbolic.function import SFunction, sfunctions_funcs
from generalized_function import generalized_function_integrator
def maxima_integrator(*args, **kwds):
"""
Maxima Integrator
"""
from sage.calculus.calculus import integral as maxima_integral
# Ask maxima_integral to raise NotImplementedError if it fails
# to integrate, so that other algorithm can be tried.
kwds['raise_error'] = True
return maxima_integral(*args, **kwds)
def sympy_integrator(*args, **kwds):
"""
Sympy Integrator
"""
from sage.calculus.calculus import integral as sympy_integral
kwds['algorithm'] = "sympy"
# Check whether sympy could evaluate the integral
try:
return sympy_integral(*args, **kwds)
except:
raise NotImplementedError, "Sympy failed to integrate"
#
# List of integrator
#
integrator_list = \
[
generalized_function_integrator,
maxima_integrator,
sympy_integrator,
]
class SymbolicIntegration(SFunction):
def __init__(self, *args, **kwds):
"""
EXAMPLES::
"""
kwds['built_in_function'] = True
for name in sfunctions_funcs:
if hasattr(self, "_%s_"%name):
kwds['%s_func'%name] = getattr(self, "_%s_"%name)
SFunction.__init__(self, "integrate", *args, **kwds)
#from sage.symbolic.pynac import register_symbol
#register_symbol(self, self._conversions)
def _eval_(self, *args, **kwds):
"""
Returns the results of symvolic evaluation of the integral
EXAMPLES::
"""
for integrator in integrator_list:
try:
return integrator(*args, **kwds)
except NotImplementedError:
pass
return None
def _evalf_(self, f, x, a, b, **kwds):
"""
Returns the results of numerical evaluation of the inetgral
EXAMPLES::
"""
from sage.calculus.calculus import nintegral
return nintegral(f, x, a, b)[0]
def _print_latex_(self, f, x, a=None, b=None, **kwds):
r"""
Return LaTeX expression for integration of a symbolic function.
EXAMPLES::
sage: from sage.calculus.calculus import _integrate_latex_
sage: var('x,a,b')
(x, a, b)
sage: f(x) = function('f',x)
sage: _integrate_latex_(f(x),x)
'\\int f\\left(x\\right)\\,{d x}'
sage: _integrate_latex_(f(x),x,a,b)
'\\int_{a}^{b} f\\left(x\\right)\\,{d x}'
"""
from sage.misc.latex import latex
# Check whether its a definite integral
if a is not None:
return "\\int_{%s}^{%s} %s\\,{d %s}"%(latex(a), latex(b), latex(f), latex(x))
# Typeset as indefinite integral
return "\\int %s\\,{d %s}"%(latex(f), latex(x))
def _diff_derivat
[sage-devel] Re: Substitute method for argument of derivative operator
Hi Burcin, On Wed, Jul 8, 2009 at 11:02 AM, Burcin Erocal wrote: >> (2) New D derivative operator does not know how to act >> on symbolic integration ( #6465 ). So right now it is not >> possible to compute "S.diff(epsilon)" >> >> I have spent last two days in trying to fix this. I believe >> this is much more serious issue than the previous one >> and this requires changes in both pynac and sage. >> Pynac needs to check for special differentiation rules for >> function like "integrate( f(x,y), x)" before applying chain rules. >> Current "_derivative_" method of SFunction class is inadequate >> for this as it is called after chain rule has been applied. > > > >> So, I guess (1) and (2) need real work mostly in pynac. I was >> glancing through ginac code. Ginac seems to apply diff() method >> properly to its own integral() method. > > Do you think it's worth wrapping the integral class from pynac instead > of creating a new SFunction called integral? Not really. See below for my comments. > Maybe we can arrange things so that I make the necessary changes in > pynac, and you work with a new package and write the Sage code on top > of that. > > I started putting alpha pynac packages here > > http://sage.math.washington.edu/home/burcin/pynac/ > > during SD16. E.g., pynac-0.1.9.a1.spkg was meant to be used for > merging the SFunction and PrimitiveFunction classes. > > If you share your code creating an SFunction called 'integral', I can > produce patches for Sage and pynac to special case that function when > computing derivatives. (Much like what is done for Order in the pynac > code right now.) I agree, we need something like Order in pynac. My suggestions are following: Let's have a new method for SFunction class say _diff_derivative_ Pynac should check first whether this method is defined. If not then it can go ahead with chain rule for its arguments. "_diff_derivative_" can be very similar to current "_derivative_" method. Instead of passing "diff_param" keyword it should pass "diff_var" keyword This would be backward compatible. This will solve not only the current issue but it will have wider applications. In future, it would allow Sage users to define their own custom differentiation rule for their symbolic functions. If you implement above in pynac then I can replicate the same in sage. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Integration in new Sage symbolics
Hi, On Wed, Jul 8, 2009 at 10:34 AM, Burcin Erocal wrote: > > On Mon, 6 Jul 2009 23:56:00 -0300 > Golam Mortuza Hossain wrote: > >> As you suggested, I am working with a prototype symbolic integration >> class for hooking up my integration code using its _eval_ method. I >> could expand the class definition but I would like to avoid effort >> duplication. > > Your prototype class can be the real thing. :) I'd be happy to review > your code when you submit it. Sure, I can expand my prototype and post patch for this. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Substitute method for argument of derivative operator
Hi, On Tue, Jul 7, 2009 at 10:29 PM, William Stein wrote: >> In new symbolics, if I do the same I get >> >> sage: g >> D[0](f)(x) >> sage: g.subs_expr(f(x)==f(x)+df(x)) >> D[0](f)(x) >> - >> >> Is there a way to do this in new symbolics? It seems >> to be a road block in implementing calculus of variations >> in new symbolics. > > I don't see any way to do this yet, which is frustrating. This was as > close as I got, which is really awful: > > sage: g.operator().change_function(f(x)+df(x))(x) > D[0](f)(x) + D[0](df)(x) I got another workaround - for n in range(max): S = S.subs_expr(f(x).diff(x,n)==(f(x)+df(x)).diff(x,n)) - It gets my work done as I know 'max' for my problems. However, I think we need a proper solution not a workaround. > I really hope once we get these issues sorted out and you implement > calculus of variations, that you include it in Sage. Definitely! Right now, I see four issues that need to be sorted out before calculus of variations can be implemented in Sage. (1) Improved .subs_expr() method so that one can vary a functional of the form S0 = L( q(t), q(t).diff(t) ).integral(t, -oo, oo) to S = L( q(t) + dq(t), (q(t)+dq(t)).diff(t) ).integral(t, -oo, oo) where dq(t) = epsilon*f(t), f(t) a test function. (2) New D derivative operator does not know how to act on symbolic integration ( #6465 ). So right now it is not possible to compute "S.diff(epsilon)" I have spent last two days in trying to fix this. I believe this is much more serious issue than the previous one and this requires changes in both pynac and sage. Pynac needs to check for special differentiation rules for function like "integrate( f(x,y), x)" before applying chain rules. Current "_derivative_" method of SFunction class is inadequate for this as it is called after chain rule has been applied. (3) In physics, we always use test function "f(t)" to be Dirac delta. This is DONE and will be part of sage-4.1 (4) We also need integration algorithm where integrand involves Dirac delta. This is mostly ready and I will post a ticket once new symbolic integration class is cleaned up so that it can be hooked up properly. So, I guess (1) and (2) need real work mostly in pynac. I was glancing through ginac code. Ginac seems to apply diff() method properly to its own integral() method. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Integration in new Sage symbolics
Hi, On Tue, Jun 23, 2009 at 12:55 PM, Burcin Erocal wrote: >> > I plan to move the integrate() and sum() (after #3587) constructs >> > to be symbolic functions (i.e., subclasses of SFunction from >> > sage.symbolic.function), as opposed to regular python functions in >> > sage.calculus.calculus. This will allow us to have real symbolic >> > integrals and sums in Sage and define custom methods for evaluation, >> > which can/should be more involved than just wrapping those of >> > maxima or sympy. Burcin: I am wondering whether you could give an update on sub-classing symbolic integration? As you suggested, I am working with a prototype symbolic integration class for hooking up my integration code using its _eval_ method. I could expand the class definition but I would like to avoid effort duplication. >> Where do you propose to put the integration algorithm files? >> Something like > > sage/symbolic/integration/generalized_functions.py in this case? How do you include modules from a new directory in Sage? I tried as you suggested but sage somehow is not finding the module. Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Consistent Sage syntax (was Re: What are *DIS*advantages of ... )
On Mon, Jul 6, 2009 at 11:16 PM, rjf wrote: > > allowing (a,b,c) to be a list of 3 items means that > (x+y) could either be a list of one item, namely x+y > or the expression x+y itself. > > So it is probably a bad idea unless you think that singleton lists are > the same as their first element. > > And I suspect that you don't want to think that. Thanks for your comments. I am not sure though, I understand it properly. Could you please elaborate above point? Say for example: what are the issues that can arise in parsing "integrate( f(x), (x,a,b) )" as "integrate( f(x), x, a, b)"? Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Consistent Sage syntax (was Re: What are *DIS*advantages of ... )
Hi, On Mon, Jul 6, 2009 at 11:45 AM, Jason Grout wrote: >>> I think Sage is less consistent in syntax and less powerful than MMA in >>> some things, like plotting and differential equations. >> >> Jason, its great that you brought out this issue about inconsistent syntax. >> It would be really good if we make some efforts to make sage syntax >> more consistent. >> >> For example, >> >> (1) integral and numerical_integral: >> >> integral( sin(x), x, 0, pi) is valid syntax but >> numerical_integration(sin(x), x, 0, pi) is not. > > And plot(x, (x, 0, pi)) is valid, but integral(sin(x), (x, 0, pi)) is not. Are there any obvious issue in supporting this syntax (along with current syntax) for integral and numerical_integral? I am currently working with symbolic integration and if there are no objection in supporting the above syntax then I will add the support for it. It may be a good idea to keep a wiki for list of functions those are exposed to users and needs some tweaks to make them coherent. It will improve the usability of Sage. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: What are *DIS*advantages of Sage compared to the 3 M's ?
Hi On Mon, Jul 6, 2009 at 10:49 AM, Jason Grout wrote: > > I think Sage is less consistent in syntax and less powerful than MMA in > some things, like plotting and differential equations. Jason, its great that you brought out this issue about inconsistent syntax. It would be really good if we make some efforts to make sage syntax more consistent. For example, (1) integral and numerical_integral: integral( sin(x), x, 0, pi) is valid syntax but numerical_integration(sin(x), x, 0, pi) is not. (2) desolve and desolve_laplace desolve ( f(x).diff(x,2) + f(x) == 0, f(x), [0, 0, 1] ) is valid desolve_laplace with same arguments raises error and there are many more. I guess, in most cases only minor tweaks are needed. It reminds me the success of Ubuntu. Under the hood its like any other Linux distro but little tweaks at the user interaction level to make it more coherent, greatly improves its usability. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Substitute method for argument of derivative operator
Hi all,
It seems none of the current substitute methods for symbolic
expressions works for the argument of the derivative operator.
In computing functional derivative, I need to vary
a functional. For example, in sage-3.4 I can do as follows
---
sage: f(x) = function('f',x)
sage: df(x) = function('df',x)
sage: g = f(x).diff(x)
sage: g
diff(f(x), x, 1)
sage: g.subs_expr(f(x)==f(x)+df(x))
diff(f(x) + df(x), x, 1)
---
In new symbolics, if I do the same I get
sage: g
D[0](f)(x)
sage: g.subs_expr(f(x)==f(x)+df(x))
D[0](f)(x)
-
Is there a way to do this in new symbolics? It seems
to be a road block in implementing calculus of variations
in new symbolics.
Thanks,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: "D", "diff" derivative conversion and _maxima_init_ bug
Hi, On Fri, Jul 3, 2009 at 11:01 AM, William Stein wrote: > > On Fri, Jul 3, 2009 at 2:21 PM, Golam Mortuza > Hossain wrote: >> >> On Fri, Jul 3, 2009 at 12:14 AM, Robert >> Bradshaw wrote: >>> I thought the consensus was that the D[n], though more powerful, was >>> far less intuitive and so we were going to go with "diff(f(x,y), x)" >>> or even "(df/dx)(x,y)" for printing. >> >> No. If I gather properly, the consensus was to use D[n] :-) > > No it wasn't. > > In case you're having trouble with your email client, I'm forwarding > my message from June 16. In response to the message below, several > messages later you called for another vote (I don't know why), which > had the same conclusion. > Sorry for the confusion. I guess, I mean the the same what you are saying. The consensus was NOT to use old "diff" format output and typesetting using "\partial". So in this sense, I refer them as "D" format derivative where variable of differentiation is indicated by its position (in arguments of the function) and not by its expression as in "diff" format. Hope this clarifies. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: "D", "diff" derivative conversion and _maxima_init_ bug
On Fri, Jul 3, 2009 at 12:14 AM, Robert
Bradshaw wrote:
> I thought the consensus was that the D[n], though more powerful, was
> far less intuitive and so we were going to go with "diff(f(x,y), x)"
> or even "(df/dx)(x,y)" for printing.
No. If I gather properly, the consensus was to use D[n] :-)
In any case, given new symbolics uses D derivative internally,
we need a conversion method between these two formats.
Unfortunately, the conversion is not one-to-one.
Consequently, integral (using maxima) that used work
in sage 3.4 doesn't work anymore. For example:
---
sage: var('x,a'); f(x) = function('f',x)
sage: g = f(x-a).diff(x)
sage: integrate(g, x)
---
doesn't work in new symbolics.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] "D", "diff" derivative conversion and _maxima_init_ bug
Hi all, I have been looking into this critical bug http://trac.sagemath.org/sage_trac/ticket/6376 (This bug affects me badly and in fact I need to use sage-3.4 for my own work to avoid this) This bug is related with "D" <-> "diff" conversion for symbolic functions. Following are my observations and a proposal to deal with this bug. [o] D <-> diff conversion is NOT one-to-one Ex: (A) diff( f(x-a), x) => D[0] f(x-a) (B) D[0](f)(x-a )=> (i) diff( f(x-a), x) (ii) - diff( f(x-a), a) So conversion is tricky. Here are my proposals to deal with this: (1) Keep current conversion when arguments are all symbolic variables. This way solving differential eqn and others will work as usual via maxima. (2) Do not convert D to diff format when an argument is an expression. In that case pass it to maxima as another symbolic function of the form D( f(x-a), [0] ) From maxima output, we can then convert it back to D format. (3) Finally, let's represent (text-mode) D derivative as D( f(x,y), [0,0,1] ) ( which is represented now as D[0,0,1](f)(x,y) ) or optionally D( f(x,y), [(0,2), (1,1)] ) This form has several advantages: (i) Above is a valid form of python function and one can copy-paste sage output from one cell to another as vaild sage input. Currently this is not the case. (ii) Sage output often contains terms like "D[0](f)(g(x))". However, right now there is no way one can enter above in Sage directly. I will be happy to implement this if we can reach consensus. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: trac server won't accept patches
On Mon, Jun 29, 2009 at 11:21 AM, William Stein wrote: > I tried restarting trac. We'll see if this makes any difference. Thanks, I could do it now. If it happens again then it could be that in somewhere open file handles are not being closed properly. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: trac server won't accept patches
Hi, On Mon, Jun 29, 2009 at 3:30 AM, Dan Drake wrote: > I mentioned this on IRC, but in case no one sees: the trac server won't > let me upload a patch. It complains: > > Trac detected an internal error: > > OSError: [Errno 24] Too many open files: > '/home/sage/wiki/trac/sage_trac/attachments/ticket/6429/trac_6429_line_numbers.patch' I am also getting the same error even now. Can anyone please look at this issue? Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Expression evaluation in new Symbolics
Hi, On Mon, Jun 29, 2009 at 7:53 AM, Burcin Erocal wrote: >> Case B: >> --- >> sin(1.57); f(x) = sin(x); f(1.57) >> 0.99682931835 >> sin(1.57) >> - >> >> For some reasons, sin(1.57) does not get evaluated in case B. >> >> This is in contrast to sage 3.4 where both cases result numerical >> evaluation of sin(1.57). > > It is a bug in pynac I fixed last week at SD 16, as a part of the > effort to refactor symbolic functions. I will try to clean this up, > and submit it along with a few other fixes to pynac this week. Thanks. It helps a lot to know this. I am looking forward to see the updated version. Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Expression evaluation in new Symbolics
Hi, Are the following evaluations in new symbolics expected by design (or a bug)? Case A: --- sage: sin(1.57); f = sin; f(1.57) 0:99682931835 0:99682931835 --- Case B: --- sin(1.57); f(x) = sin(x); f(1.57) 0.99682931835 sin(1.57) - For some reasons, sin(1.57) does not get evaluated in case B. This is in contrast to sage 3.4 where both cases result numerical evaluation of sin(1.57). Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Naming Conventions for Dirac Delta, Heaviside Theta and Unit Step
Hi
On Thu, Jun 25, 2009 at 10:27 PM, David Joyner 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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: problem with complex_plot and real_part
Hi
On Thu, Jun 25, 2009 at 11:31 PM, Nick Alexander wrote:
>
> Can someone verify that this is a bug? Any hope a fix? (This is with
> sage-4.0.2 on sage.math.)
>
> {{{
> sage: complex_plot((x^2 + I).sqrt().real_part(), (-2, 2), (-2, 2))
> ---
...
> RuntimeError: cannot find SFunction in table
> }}}
It seems, its not just complex_plot issue. It is happening for other
plots. For example, the following works fine in 3.4 but fails with
the same error in 4.0.2
-
sage: x,y=var('x,y'); plot3d( log(x+I*y).imag(), (x,-2,2), (y,-2,2))
...
RuntimeError: cannot find SFunction in table
-
This seems to be a pynac issue.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Naming Conventions for Dirac Delta, Heaviside Theta and Unit Step
Hi,
On Tue, Jun 23, 2009 at 6:45 PM, Maurizio 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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: typesetting partial derivatives
Hi Burcin,
On Wed, Jun 24, 2009 at 6:54 PM, Burcin Erocal wrote:
> I attached a patch to the trac ticket that contains an initial attempt
> at the MMA notation:
>
> http://trac.sagemath.org/sage_trac/ticket/6344
>
>
> It doesn't work well for text mode:
>
> sage: f = function('f')
> sage: f(x).derivative(x,3)
> f^{(3)}(x)
My suggestion would be to split out "text-mode" (repr) output
for another ticket. Current text-mode output expression from Sage
in this case is not a valid input expression of Sage. For example,
if I do copy-n-paste output like "D[0](f)(x)" to another cell then
Sage doesn't recognize it.
I guess, implementing latex output would be easier one. I did
a quick-hack MMA style. It worked fine and with primes
it appears to be in "textbook style".
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: typesetting partial derivatives
Hi
On Tue, Jun 23, 2009 at 9:00 PM, Burcin Erocal wrote:
> If there are no objections to the above definition of "hybrid approach",
> the options for default printing are:
>
> 1) Mathematica style
> 2) Maple style
> 3) hybrid
>
> I still vote for 1, MMA style. To state the reasons again, it's
> consistent, and concise.
Burcin, I am giving you my vote also, for implementing MMA
style typesetting as the default one for partial derivatives. Please
have those {'} and {''} and may be even {'''} notations.
So I would urge you to go ahead with the implementation.
It wouldn't be difficult to add other choices later as options
to users (some of the codes are already there).
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Naming Conventions for Dirac Delta, Heaviside Theta and Unit Step
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" (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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Naming Conventions for Dirac Delta, Heaviside Theta and Unit Step
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
(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
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Integration in new Sage symbolics
On Mon, Jun 22, 2009 at 10:28 AM, Burcin Erocal wrote: >> I am wondering whether there is any policy/framework >> for hooking-up a specialized integration code as a part >> of integration algorithm in new symbolic? > > There isn't any, yet. That should change this week though. :) > > I plan to move the integrate() and sum() (after #3587) constructs to be > symbolic functions (i.e., subclasses of SFunction from > sage.symbolic.function), as opposed to regular python functions in > sage.calculus.calculus. This will allow us to have real symbolic > integrals and sums in Sage and define custom methods for evaluation, > which can/should be more involved than just wrapping those of > maxima or sympy. +1, I agree, this is badly needed. We should ask maxima/sympy to compute an integral when algorithm within Sage fails. That way one can implement the integration algorithm within Sage which are not yet implemented in maxima/sympy. Currently, I am using a hackish approach while implementing integration algorithm involving generalized functions (Dirac delta, Heaviside theta and Unit step) as follows --- from sage.functions.generalized import integrate_generalized_functions try: return integrate_generalized_functions(expression, v, a, b) except NotImplementedError: return maxima_integral(expression, v, a, b) --- As you suggested, I agree that I should split the integration code from the function definition file. Where do you propose to put the integration algorithm files? Something like sage/symbolic/integration/algorithm_x.py Cheers, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Nasty simplify() bug in symbolics
Hi,
It seems that there is a major bug in new symbolics simplify()
method involving "D" and symbolic function (Sage-4.0.1).
---
sage: f(x) = function('f',x)
sage: f(-x).diff(x)
-D[0](f)(-x)
sage: f(-x).diff(x).simplify()
-D[0](f)(x)
---
Notice that simplify() causes f(-x) to become f(x).
Also it seems that the order of operands is getting messed up
sage: x,y = var('x,y')
sage: f(x,y) = function('f',x,y)
sage: f(-y,-x).diff(x)
-D[1](f)(-y, -x)
sage: f(-y,-x).diff(x).simplify()
-D[1](f)(x, y)
I suspect that somewhere ".arguments()" method is used
to evaluate the function rather than the ".operands()" method.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Integration in new Sage symbolics
Hi, I am wondering whether there is any policy/framework for hooking-up a specialized integration code as a part of integration algorithm in new symbolic? I have been writing code for integration involving Dirac delta generalized function to include the same in Sage. The form of integrand that I am implementing is integrand =f(x)*dirac_delta( g(x) ).diff(x,n) where f(x) is any arbitrary function and as g(x) is a real-valued function with real roots of the eqn "g(x) = 0". I now have codes for doing the above integration fairly well for common situations. I can call the sub-routine directly to evaluate the integration. So my question: what is the preferred way to hook up the code in new symbolic? Thanks, Golam --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Dirac delta in new symbolics
Hi,
On Wed, Jun 17, 2009 at 8:56 AM, Burcin Erocal 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() == ""
False
-
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Dirac delta in new symbolics
Hi, 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: typesetting partial derivatives
Hi,
On Tue, Jun 16, 2009 at 2:20 PM, kcrisman wrote:
>
>> So the conclusion is that we will go with the Mathematica style notation.
>
> Does that also apply to Golam's earlier comment
>
> (a) If we all agree that there is no ambiguity when the particular
> argument is a "symbolic variable" or "symbolic function" then
> we should typeset them as those found in text-books.
> Ex:
> (1) D[0,0,0] (f)(x,y) => \frac{\partial^3}{\partial x^3} f
> (x,y)
> (2) D[0] (f)(g(x,y), h(z)) => \frac{\partial}{\partial
> g(x,y)} f(g(x,y), h(y))
>
> so that we will no longer see nicely typeset partial derivatives even
> in case (a)(1) (or even Leibniz notation at all?), or is it only in
> the case (b) "when the argument is an expression"? Thanks for the
> clarification.
As Burcin pointed out that even MMA uses different Tex-ing scheme
for some situations such as F'[x] for D[F[x],x]. So strictly speaking even
MMA uses hybrid approach.
I guess, we should aim for doing better than MMA/Maple.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Defining symbolic function with custom latex_name
Hi,
On Tue, Jun 9, 2009 at 9:12 PM, Nick Alexander wrote:
>
>> (2) keyword "latex_name": If I understand correctly, the new
>> "SFunction" class can be given keyboard argument
>> "latex_name=LaTeX". It would be really cool if we could define a
>> symbolic function as
>>
>> riemann(x) = function('riemann', x, latex_name="\\mathcal{R}")
>
> That's the function I want.
A patch is posted and reviews are welcome.
http://trac.sagemath.org/sage_trac/ticket/6290
This will allow keyword arguments to pass down to underlying
SFunction class in new symbolics.
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
