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
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
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 t
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
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
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 '
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 desig
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
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}")
--
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 define
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
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.m
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 a
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 callin
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 va
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 sy
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
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, a
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?
Basicall
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
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 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 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
--~--~-~--~~
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 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
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,
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,
> 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,
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,
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 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,
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 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,
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 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
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 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
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 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,
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,
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);
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
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
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
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 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,
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 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
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,
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
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 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,
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
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,
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
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 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 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,
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 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 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 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 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:
>> 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,
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 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,
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,
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,
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,
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
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 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
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,
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 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.
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 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
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 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 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,
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 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 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,
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
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,
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 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
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 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 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 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
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,
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
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,
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
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,
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,
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 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,
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
1 - 100 of 144 matches
Mail list logo
