Hi,
I am wondering whether anyone is implementing
Functional derivative using pynac in Sage?
http://en.wikipedia.org/wiki/Functional_derivative
While searching through sage-devel list, I found that Tim Lahey
had some mention about implementing variational calculus
in Sage. Are there any recent
Hi Tim,
On Sun, Apr 26, 2009 at 3:36 PM, Tim Lahey wrote:
> I decided to wait until pynac had stabilized a bit and was better
> integrated into the Sage which appears to be around the 4.0 timeframe.
> Plus, I've been busy with other things. I have code that I implemented
> in Maple and I've been
Hi,
On Sun, Apr 26, 2009 at 7:43 PM, Tim Lahey wrote:
> I do it from a mathematical perspective. The code to do the variation
> itself is
Thanks Tim. I played around further with current Sage to see what
stuffs need to be improved in implementing functional derivative in Sage.
I followed t
Hi,
On Sat, May 2, 2009 at 5:20 PM, William Stein wrote:
>
> On Sat, May 2, 2009 at 12:54 PM, Maurizio wrote:
>> I had previously been interested in implementing delta dirac function
>> in pynac, especially for Laplace transform, so maybe I can give you a
>> couple of references.
Thanks for th
Hi Michael,
On Wed, May 6, 2009 at 3:37 AM, mabshoff wrote:
>
> All the bits are in the usual place in
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
I am wondering whether pre-compiled binaries of sage-3.4.2 for
Ubuntu and others will be available? I am thinking of t
Hi,
On Thu, May 7, 2009 at 10:44 AM, mabshoff wrote:
>> > All the bits are in the usual place in
>>
>> > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>
> Binaries have been build and should show up in the next 24 hours on
> the main sage site and then mirror out.
Are th
Hi Rob,
On Sat, May 9, 2009 at 2:00 AM, Rob Beezer wrote:
> I'd really like to hear about any glaring omissions, or gross
> misunderstandings of categories, vector spaces, modules, rings and/or
> fields. Draft copy at
>
> http://buzzard.ups.edu/sage/quickref-linalg.pdf
It looks pretty good! Sp
Hi,
On Sun, May 17, 2009 at 2:02 AM, William Stein wrote:
> I posted a bunch of photos from SAge Days 15 here:
>
> http://sage.math.washington.edu/home/wstein/sagedays15/photos/
>
> Also, the rest of the video is now posted here:
>
> http://sage.math.washington.edu/home/wstein/sagedays15/
I gu
Hi,
Is there a way to remove literally hundreds of old snapshots from
Sage notebook (other than doing "rm -f .sage/.../snapshots/*)?
I am trying to backup my .sage directory into a thumb-drive.
It seems, Sage creates literally Gigabytes of snapshots
even for couple of sage worksheets amounting o
Hi,
It seems, recent switch to new symbolics has caused several
typesetting regressions in sage-4.0 (compared 3.4.*).
Here are the list of regressions which I have encountered so far.
(1) Typesetting of sec(x), csc(x), cot(x) are broken. It puts an
extra "\mbox" around them unlike for sin, co
Hi Burcin,
On Fri, Jun 5, 2009 at 12:39 PM, Burcin Erocal wrote:
>> (3) symbolic "diff" now returns a rather incomprehensible output
>> ---
>> f(x) = function('f',x)
>> diff(f(x),x)
>> D[0](f)(x)
>> ---
>> What does that '0' really means? Typeset version also looks similar.
>
> This is a
Hi Mike,
On Fri, Jun 5, 2009 at 4:45 PM, Mike Hansen wrote:
>
>> D[0](f) seems strange when there is only one argument.
>
> f could be a function of many variables.
>
>> I still hate the notation. It's also fairly non-standard notation. At
>> least in Maple, it's mostly optional. Some functions r
On Fri, Jun 5, 2009 at 6:25 PM, Mike Hansen wrote:
>> IMO, it is alright if GiNaC uses this particular format for internal
>> processing.
>> However, printing the output (either the raw or the typeset version) in the
>> new
>> format ("D[0](f)") is at best confusing.
>
> It's not just a matter o
Hi,
(1) pynac .conjugate() method returns wrong answer:
f(x) = function('f',x)
f(x).conjugate()
--
f(conjugate(x))
Above is certainly not true. For example: f(x) = I + x implies
f(x).conjugate() = -I + conjugate(x) which is not equal to
f(conjugate(x))
(2) view() causes SI
Hi,
On Fri, Jun 5, 2009 at 7:09 PM, Mike Hansen wrote:
> The _latex_ from Expressions calls GiNaC which as code for assembling
> latex code from the expression tree. The thing that corresponds to
> SymbolicFunctionEvaluation is roughly sage.symbolic.function.SFunction
> and PrimitiveFunction.
Hi,
On Tue, Jun 9, 2009 at 9:45 PM, Jason Grout wrote:
>> (4) Should we switch to old maxima format for "diff"?
>
> Can you clarify with an example what you mean? In other words, can you
> give an example of the "new" way and the "old" way?
In new symbolics, "df(x)/dx" is
(a) represented as:
Hi Carl,
On Wed, Jun 10, 2009 at 4:49 PM, Carl Witty wrote:
> Is it even possible to use the old typesetting format with the new
> symbolic representation? For example, "df(sin(x)*cos(x))/dx" is
> represented as -(sin(x)^2 - cos(x)^2)*D[0](f)(sin(x)*cos(x)); it seems
> likely to be difficult to
Hi
On Wed, Jun 10, 2009 at 7:23 PM, Mike Hansen wrote:
> On Wed, Jun 10, 2009 at 3:16 PM, Jason Grout
> wrote:
>> I agree with Robert---functions have ordered, named parameters (thanks
>> to your patch that deprecated not specifying the order of variables!),
>> so we should be able to convert ba
Hi
On Sun, Jun 14, 2009 at 4:38 PM, Burcin Erocal wrote:
> There were long discussion about the typesetting of partial derivatives
> in the new system, but I don't think we got to a conclusion yet.
I am afraid, we might never reach a conclusion in this regard :-)
It seems to be a classic case wh
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) = fun
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 variab
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
my
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
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
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 beco
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 mov
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_del
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 "he
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
> c
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).d
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
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))
>
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) Uni
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
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
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
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
--~--~-~--~~--
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 observati
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] :-)
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,
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) = fun
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
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 go
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.
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.
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 implemen
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
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
>> t
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:
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 t
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 f
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 g
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
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)
> sa
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
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?
>>>
>>
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 G
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
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 do
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 cyth
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 algorith
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)
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
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
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 lo
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 com
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
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
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 wa
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
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
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
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(
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
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 clear
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 = sym
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
w.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.c
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);
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 hef
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
>>
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
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
>
> in
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 mathema
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
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
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
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
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/
>>> h
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
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
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 docstr
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
--~--~-~--~~~---~--~
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 comp
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 thou
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-dev
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
--~--~-~--~~
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:
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
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
>> > v
1 - 100 of 144 matches
Mail list logo
