[sage-devel] Sage at EuroSciPy?
Hi all, Is anybody planning to be at EuroScipy 2014 next week in Cambridge? https://www.euroscipy.org/2014/ Any Sage or SageMathCloud projects that could benefit from an impromptu sprint? All the best, Joris -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: SageManifolds: differential geometry and tensor calculus in Sage
This is a very nice package! Are you aware of #9439 (hyperbolic geometry) and #10132 (surfaces embedded in R^3) which are somewhat related? As for #10132, I can see the functionality of that patch being subsumed into this package, once the extrinsic manifold geometry has been implemented. J. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: (abs(sin(x))^2).simplify_full()
Hi Michael,
Thanks for your message. I'm still a little confused about the way Sage
handles assumptions, can you maybe shine your light on this?
On Monday, July 1, 2013 8:55:43 PM UTC+1, Michael Orlitzky wrote:
sage: u = var('u')
sage: assume(u, 'real')
This makes an assumption in Maxima, where most of the symbolic algebra
takes place.
As far as I can tell, setting domain to complex in maxima has the effect
that sin, cos, etc are now seen as de facto complex-valued functions, even
when the input x is assumed to be real. This is probably why maxima refuses
to simplify abs(cos(x))^2 + abs(sin(x))^2 to 1.
sage: u = var('u', domain='real')
This sets a flag in pynac, which does nothing as far as I can tell.
But the example in my original message works -- this really confuses me.
Clearly, simplify_trig invokes maxima to do the simplification, so why does
setting this flag in pynac make it work? Are functions of real variables
treated differently from functions taking a complex argument?
Thanks!
Joris
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: (abs(sin(x))^2).simplify_full()
But the example in my original message works -- this really confuses me. Clearly, simplify_trig invokes maxima to do the simplification, so why does setting this flag in pynac make it work? Are functions of real variables treated differently from functions taking a complex argument? OK, I understand this now -- when defining a function of a real argument the abs is simply not taken into account because of the square following it, so that the trig simplification can take its course as before. I still think it would be a good idea to have the simplify_* methods take into account the domain of definition to avoid problems like this. Presumably I'm missing a whole lot of context here, feel free to point me to tickets where the opposite point has been made. J. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Changes in Maxima behavior
Hi all,
Following RJF's suggestion, I played around with Maxima for a little while
to see where the problem arises. As far as I can tell, this is again a
problem with the fact that simplify_radical gets called in simplify_full
(see #12737). The problem that I'm seeing used to be absent when
simplify_radical still set the domain to 'real' before invoking radcan, but
now that it no longer does that, the problem has become apparent, see below.
First of all, I simplified the example in the original post to
sage: u, v = var('u, v', domain='real')
sage: sqrt(-1/(u^2+v^2-1)).simplify_radical() # This will hang
The problem is with the fact that the domain of the symbolic variables is
complex:
sage: maxima.interact()
maxima: forget()
[]
maxima: domain
complex
maxima: assume(x 0)
[x0]
maxima: assume(y 0)
[y0]
maxima: radcan(sqrt(-1/(x^2 + y^2 - 1)))
Setting the domain to 'real' fixes the problem:
sage: maxima.interact()
maxima: domain: real
real
maxima: radcan(sqrt(-1/(x^2 + y^2 - 1)))
%i/sqrt(y^2+x^2-1)
The upshot seems to be that this is not really a bug, but again an annoying
consequence of simplify_radical not really being a simplify_ method, and
this should be fixed once #11912 and #12737 are approved. Therefore I won't
open a new ticket, but I'll just add to the discussion of those patches.
All the best,
Joris
On Friday, June 28, 2013 1:09:49 PM UTC+1, Joris Vankerschaver wrote:
Hi all,
I've been out of the Sage loop for a while, but upon upgrading to 5.10, I
found that Maxima seems to choke on the following innocuous code which used
to run fine. I'm posting this here, because this issue came up while I was
working on #10132, and also because it affects usability.
sage: u, v = var('u,v')
sage: assume(u, 'real')
sage: assume(v, 'real')
sage: assume(u^2 + v^2 1)
sage: n = vector((u/sqrt(-u^2 - v^2 + 1), v/sqrt(-u^2 - v^2 + 1), 1))
sage: norm = n.norm(); norm
sqrt(abs(u/sqrt(-u^2 - v^2 + 1))^2 + abs(v/sqrt(-u^2 - v^2 + 1))^2 + 1)
sage: norm.simplify_full()
The last command just sits there on 5.10, and consumes all the resources
(more specifically, /Users/Joris/sage/local/bin/sage-cleaner consumes all
the available memory). In Sage 5.3, the last command just would return
I/sqrt(u^2 + v^2 - 1) which is not very nice but at least it's short and
fast.
Is this known? Is there something I can do to avoid this?
All the best,
Joris
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: _cleanup method in DifferentialForms class
Hi Dox, In addition to the link that Leif provided, it would be good to open a ticket on trac first with a description of the changes you propose to make. Let me know if you need any further help. I'd be happy to review your patch when you're done. All the best, Joris On Friday, June 28, 2013 3:36:24 PM UTC+1, Dox wrote: I could try to change something... However, What is the way to provide a patch? Is it through github? On Friday, 28 June 2013 09:36:47 UTC-4, Joris Vankerschaver wrote: Symbolic expressions have a .is_trivial_zero() method which is more suitable for use here. It doesn't try anything advanced so it has predictable runtime. I just wanted to say that I had no idea that this function existed when I wrote that code, and it seems like a good idea to use it here. If anybody wants to fix this, great, otherwise I'll do it myself in a few days when I have time. All the best, Joris -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: (abs(sin(x))^2).simplify_full()
On Friday, February 15, 2013 11:31:41 AM UTC, Julius wrote:
With sage 5.6
sage: assume(x, 'real')
sage: (abs(sin(x))^2).simplify_full()
abs(sin(x))^2
For trigonometric simplifications, this is very inconvenient. For example
sage: (abs(sin(x))^2 + abs(cos(x))^2).simplify_full().simplify_trig()
abs(sin(x))^2 + abs(cos(x))^2
I totally agree that this is very inconvenient. When faced with a trig
problem it doesn't take a lot of symbolic manipulations to arrive at
something which is full of these expressions, and if we have no way of
doing these obvious simplifications then that limits the usefulness of
doing symbolic manipulations. For instance, the majority of the docstrings
in trac #10132 now fail, for no good mathematical reason.
The behavior is also inconsistent, for reasons that I don't fully get. For
instance, this will fail:
sage: u = var('u')
sage: assume(u, 'real')
sage: (abs(cos(u))^2 + abs(sin(u))^2).simplify_trig()
abs(sin(u))^2 + abs(cos(u))^2
but this will work:
sage: u = var('u', domain='real')
sage: (abs(cos(u))^2 + abs(sin(u))^2).simplify_trig()
1
I don't know enough about the Maxima interface and the assumptions that
went into changing this behavior from sage 5.5 to 5.6, but is there maybe a
way we can set domain to real for symbolic functions over the reals before
passing the whole thing to maxima for the simplification?
J.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Changes in Maxima behavior
Hi all,
I've been out of the Sage loop for a while, but upon upgrading to 5.10, I
found that Maxima seems to choke on the following innocuous code which used
to run fine. I'm posting this here, because this issue came up while I was
working on #10132, and also because it affects usability.
sage: u, v = var('u,v')
sage: assume(u, 'real')
sage: assume(v, 'real')
sage: assume(u^2 + v^2 1)
sage: n = vector((u/sqrt(-u^2 - v^2 + 1), v/sqrt(-u^2 - v^2 + 1), 1))
sage: norm = n.norm(); norm
sqrt(abs(u/sqrt(-u^2 - v^2 + 1))^2 + abs(v/sqrt(-u^2 - v^2 + 1))^2 + 1)
sage: norm.simplify_full()
The last command just sits there on 5.10, and consumes all the resources
(more specifically, /Users/Joris/sage/local/bin/sage-cleaner consumes all
the available memory). In Sage 5.3, the last command just would return
I/sqrt(u^2 + v^2 - 1) which is not very nice but at least it's short and
fast.
Is this known? Is there something I can do to avoid this?
All the best,
Joris
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: _cleanup method in DifferentialForms class
Symbolic expressions have a .is_trivial_zero() method which is more suitable for use here. It doesn't try anything advanced so it has predictable runtime. I just wanted to say that I had no idea that this function existed when I wrote that code, and it seems like a good idea to use it here. If anybody wants to fix this, great, otherwise I'll do it myself in a few days when I have time. All the best, Joris -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Bunch of small changes to sage/gsl/interpolation.pyx
Thanks everybody! I've gone ahead and changed the list method to return a copy rather than a reference. This seemed like the most minimal change I could make. Robert, how would I go about returning a list with copy-on-write semantics? Is there a standard container that does this? All the best, Joris On Wednesday, September 26, 2012 12:09:52 AM UTC+1, Robert Bradshaw wrote: +1 to a copy. There could be another method, say points(), that returns an (immutable) tuple. Even more sophisticated, one could return a list with copy-on-write semantics. On Tue, Sep 25, 2012 at 3:38 PM, mhampton hamp...@gmail.com javascript: wrote: It seems safer to return a copy and not a reference. The documentation does make it clear that it returns a reference, so it can't really be called a bug. My guess is that there isn't any code out there that exploits that though, so I would vote to not bother with a deprecation warning. -Marshall Hampton On Tuesday, September 25, 2012 5:28:26 AM UTC-5, Joris Vankerschaver wrote: Hi everybody, I made two small changes to the Sage interface for cubic spline interpolation (found in sage/gsl/interpolation.pyx). The first is at http://trac.sagemath.org/sage_trac/ticket/13519 and concerns a small bug which prevents splines from being recomputed when the interpolation points are changed. The patch just adds two lines to the relevant methods, along with a bunch of doctests, and should be a breeze to review. The other patch is at http://trac.sagemath.org/sage_trac/ticket/13520 and simply exposes two methods from GSL for spline integration and computation of the derivatives. One thing that I noticed when working on this patch is that Spline.list returns a reference to the spline interpolation points (this is actually noted in the documentation), allowing one again to change the interpolation points without forcing the spline to be recomputed. This issue was brought up in #12036 when doctest coverage was addressed, and I've opened a ticket about this at http://trac.sagemath.org/sage_trac/ticket/13530 My question is, can I just change Spline.list() to return a copy of the list of interpolation points, rather than a reference? Strictly speaking, this would alter the interface and so a DepreciationWarning of some sort would be appropriate but I can't imagine that anybody is relying on this (buggy) behavior. Still, maybe there are other reasons for not making this change -- please let me know if this is the case. With best wishes, Joris Vankerschaver -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-...@googlegroups.comjavascript:. To unsubscribe from this group, send email to sage-devel+...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Bunch of small changes to sage/gsl/interpolation.pyx
Hi everybody, I made two small changes to the Sage interface for cubic spline interpolation (found in sage/gsl/interpolation.pyx). The first is at http://trac.sagemath.org/sage_trac/ticket/13519 and concerns a small bug which prevents splines from being recomputed when the interpolation points are changed. The patch just adds two lines to the relevant methods, along with a bunch of doctests, and should be a breeze to review. The other patch is at http://trac.sagemath.org/sage_trac/ticket/13520 and simply exposes two methods from GSL for spline integration and computation of the derivatives. One thing that I noticed when working on this patch is that Spline.list returns a reference to the spline interpolation points (this is actually noted in the documentation), allowing one again to change the interpolation points without forcing the spline to be recomputed. This issue was brought up in #12036 when doctest coverage was addressed, and I've opened a ticket about this at http://trac.sagemath.org/sage_trac/ticket/13530 My question is, can I just change Spline.list() to return a copy of the list of interpolation points, rather than a reference? Strictly speaking, this would alter the interface and so a DepreciationWarning of some sort would be appropriate but I can't imagine that anybody is relying on this (buggy) behavior. Still, maybe there are other reasons for not making this change -- please let me know if this is the case. With best wishes, Joris Vankerschaver -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Anyone developing Differential System and Cartan--Kaehler in sage?
Hi Abraham, This sounds like a great project -- I've always wanted to read the Bryant/Griffiths books on EDS but I've always been too lazy to do the computations myself and get a proper grip on the subjects. Such a Sage package could be a great help. I'm not entirely happy with the way that the current implementation of DifferentialForms relies so much on CoordinatePatch, and I'm sure there's room for improvement here. All the best, Joris On Dec 15, 5:42 pm, adsmith abrahamdavidsm...@gmail.com wrote: On Dec 15, 8:48 am, Jason Grout jason-s...@creativetrax.com wrote: On 12/15/11 7:38 AM, adsmith wrote: I'm not an expert in the area, but ishttp://www.sagemath.org/doc/reference/tensor.htmlusefulto you? You can see fromhttp://trac.sagemath.org/sage_trac/ticket/9650someof the people involved in that code. Thanks, Jason Hi Jason, Thanks for the tip. That is a start, and I'll dig into that code a bit. The great advantage of the packages I want to emulate is that they have no notion of coordinates at all, just a graded ideal defined by a set of generators. Now, I'm sure with Tensor's coordinate patch system, one could make an interface that automatically generates and completely hides the underlying coordinates, but ideally they need not exist at all. -- 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 URL: http://www.sagemath.org
[sage-devel] Re: Problems with symbolic vector arithmetic
Hi David, Thanks for pointing out the problem and at the same time providing a very elegant solution! I've gone ahead and made this into #11549, and I've taken the liberty of cc-ing you and Robert Bradshaw on this (since he reviewed the original vector class). All the best, Joris On 26 jun, 12:15, David Roe r...@math.harvard.edu wrote: The implementation in sage/modules/vector_symbolic_dense just inherits from FreeModuleElement_generic_dense, without overriding any methods like _add_ or _new_c. In particular, the arithmetic operations in FreeModuleElement_generic_dense hard-code the class, so that arithmetic always creates a new FreeModuleElement_generic_dense (as you're seeing). The simplest solution may be to change cdef _new_c(self, object v): # Create a new dense free module element with minimal overhead and # no type checking. cdef FreeModuleElement_generic_dense x x = PY_NEW(FreeModuleElement_generic_dense) in FreeModuleElement_generic_dense to cdef _new_c(self, object v): # Create a new dense free module element with minimal overhead and # no type checking. cdef FreeModuleElement_generic_dense x x = FreeModuleElement_generic_densePY_NEW(objectPY_TYPE(self)) David On Sat, Jun 25, 2011 at 13:56, Joris Vankerschaver joris.vankerscha...@gmail.com wrote: Dear all, I'm playing around with #11335 which was included in Sage 4.7.1.alpha3. In this patch, I added a symbolic vector class, with the aim of providing simplification methods that act elementwise on symbolic vectors. The symbolic vector class derives from sage.modules.free_module_element.FreeModuleElement_generic_dense and so far only provides methods for simplification, so it's pretty simple. However, it looks like this simple design is not sufficient to ensure that the result of simple arithmetic operators stays in the same vector space: sage: v = vector(SR, [1]) sage: w = vector(SR, [x]) sage: type(v) class 'sage.modules.vector_symbolic_dense.Vector_symbolic_dense' sage: type(w) class 'sage.modules.vector_symbolic_dense.Vector_symbolic_dense' sage: type(v + w) type 'sage.modules.free_module_element.FreeModuleElement_generic_dense' I have no idea what the matter is, though. The coercion model reports that arithmetic should be performed directly: sage: cm = sage.structure.element.get_coercion_model() sage: cm.explain(v, w, operator.add) Identical parents, arithmetic performed immediately. Result lives in Vector space of dimension 1 over Symbolic Ring Vector space of dimension 1 over Symbolic Ring Any idea where things went wrong? Thanks! Joris -- 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 URL:http://www.sagemath.org -- 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 URL: http://www.sagemath.org
[sage-devel] Re: DAE solver on Sage.
On May 4, 10:04 pm, Thierry Dumont tdum...@math.univ-lyon1.fr wrote: Do you mean that it is possible to define the RHS as a Cython *callback* function? or is there an other trick ? Can you give me a pointer to that ? The code can for instance be found in the file sage/gsl/ode.pyx (the gsl directory has other classes where this construction is also used), and relies on the following trick: the ode solver does not call the RHS defined by the user, but instead calls a C function called c_f cdef int c_f(double t,double* y, double* dydt,void *params): The array params contains as its first argument a pointer (suitably wrapped) to the user-defined RHS (which could be written in Python). If you check the default implementation of c_f, you will see that this function does nothing else but unpacking the RHS and calling it, so that the user never even has to know about c_f. Now, if you do want to provide a compiled RHS, all you have to do is supply your own c_f implementation. This is what the docs have to say (ellipses for readability): sage: ode_solver? Unfortunately because Python functions are used, this solver is slow on systems that require many function evaluations. It is possible to pass a compiled function by deriving from the class ``ode_sysem`` and overloading ``c_f`` and ``c_j`` with C functions that specify the system. The following will work in the notebook: (...) cdef class van_der_pol(sage.gsl.ode.ode_system): cdef int c_f(self,double t, double *y,double *dydt): dydt[0]=y[1] dydt[1]=-y[0]-1000*y[1]*(y[0]*y[0]-1) return GSL_SUCCESS cdef int c_j(self, double t,double *y,double *dfdy,double *dfdt): (...) I hope this helps. When I first saw this, I thought it was a very elegant trick to ensure that you have both speed and readability. All the best, Joris -- 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 URL: http://www.sagemath.org
[sage-devel] Re: DAE solver on Sage.
On May 5, 2:56 am, Guilherme guito...@gmail.com wrote: IDA is shown as the last on the series DASSL - DASPK - IDA. Sundials is C ++(?) coded. Could you handle Mass matrix with DASSL? DASSL handles implicit ODEs of the form F(t, x, x') = 0, so I think it would work for non-constant mass matrices too, but an adapted solver might be better. I quite like your suggestion of IDA through the Sundials package. It is recommended by the experts, the interface is clean (DASSL basically consists of one Fortran function which takes 15 arguments, all of which have to be in a very specific form) and is relatively well updated (the last version dates from 2006). It is also licensed under the BSD license. On the downside, I think that writing a Python wrapper around even a small part of its functionality might prove to be quite an undertaking. By contrast, DASSL is much easier to understand. I will try to put my C++ wrapper on github in a week or so, after I've cleaned everything up, so you can have a look. All the best, J. -- 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 URL: http://www.sagemath.org
[sage-devel] Re: DAE solver on Sage.
On May 3, 11:23 pm, Thierry Dumont tdum...@math.univ-lyon1.fr wrote: 1) it takes time to do this, 2) we have to solve the callback problem: such program make a lot of callbacks (to the rhs of the system): AFAIK, there are no simple method to make this work fast enough (the ODE solver in Sage is extremely slow, too). Is it really that slow? The ode_solver class, for instance, allows you to define the RHS as a cython function, and behind the scenes a pointer to the RHS is then passed around as it were any other compiled function. I don't think this would be too much slower than a generic C implementation. I haven't done any speed tests, but I always find the ode_solver class to be very fast. J. -- 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 URL: http://www.sagemath.org
[sage-devel] Re: DAE solver on Sage.
On 3 mei, 15:13, Guilherme guito...@gmail.com wrote: Is there any DAE solver readily available to Sage? I wrote a C++ wrapper around DASSL some time ago, but unfortunately this was for personal use and I never put any time into writing documentation and making sure that all the options work well, etc. I don't think that writing a Sage extension around the C++ module or even the original Fortran would be that hard, but I don't think I can do this within a reasonable amount of time. I would be very willing to exchange ideas and share code, though, if DASSL is anything that you could use. With best wishes, Joris -- 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 URL: http://www.sagemath.org
[sage-devel] Multidimensional root finding with GSL
Dear all, Has there been any effort so far in wrapping the root-finding routines in GSL? Or are there better alternatives for numerical root finding of vector-valued functions in Sage? All I could find is this mission statement, but it doesn't look as if this was ever completed (I'd love to be wrong): http://wiki.sagemath.org/days4/projects/numerical I wouldn't mind wrapping these beasts myself (using, say, the code in sage/gsl/ode as a starting point), but I have no experience with Cython so it will take some time... All the best, Joris -- 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 URL: http://www.sagemath.org
[sage-devel] Callable symbolic expressions and vector functions
Dear all,
Is there a reason why Sage doesn't allow you to define vector
functions using the following short hand:
sage: Q = var('x, y, z')
sage: f(Q) = [x - z, y - z]
sage: f
Q |-- (x - z, y - z)
I would have expected/liked the last line to be
sage: f
(x, y, z) |-- (x - z, y - z)
This would help us to deal with vector functions in a more systematic
way. More specifically, it would be a great help in FEM, Lagrangian/
Hamiltonian mechanics, etc, where you have one function to begin with,
which is then subjected to a great deal of easily formalizable
symbolic computations.
Looking forward to your comments!
Joris
--
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
URL: http://www.sagemath.org
[sage-devel] Re: Callable symbolic expressions and vector functions
On 10 dec, 13:25, Jason Grout jason-s...@creativetrax.com wrote:
3. If you *really* want to use Q like you did above, you could do this:
sage: Q=var('x,y,z')
sage: f(*Q)=(x-z,y-z)
sage: f
(x, y, z) |-- (x - z, y - z)
This is exactly what I need, but thanks also for the explanation of
what goes on behind the scenes! I had a few follow-questions, but I
can figure it out from here knowing what the preparser does.
Thanks a lot!
Joris
--
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
URL: http://www.sagemath.org
[sage-devel] Bessel functions
Dear all,
I wanted to compute some good old Bessel functions, and came upon the
following behavior. I did not want to open trac tickets for all of
this, since I didn't know (apart from 1) whether this behavior is
intentional or not.
1) Sage uses a function Bessel which does some input checking and
then calls bessel_{I, J, K, Y} to compute the relevant function. The
Bessel method takes an optional algorithm argument which defaults to
pari. However, bessel_Y only uses maxima or scipy and raises an
error when another algorithm is specified.
I've opened a trac ticket (#10239) about this.
It would be good to have bessel_Y use pari to do the computations, but
judging from the fact that bessel_{I, J, K} use pari by default while
bessel_Y doesn't, I suspect that there are some difficulties in doing
so.
2) The current bessel_Y implementation has a funny way of dealing with
complex-valued Bessel functions. When the algorithm is scipy, the
computation works fine, but when the algorithm is maxima (the
default), the computation fails, since the result of the maxima
computation is coerced into the reals. In bessel_Y, the relevant line
is
RR(maxima.eval(bessel_y(%s,%s)%(float(nu),float(z
Maxima does handle complex-valued Bessel functions, so extending this
function to deal with complex arguments should work.
3) I find it confusing to have the spherical Hankel functions defined
in Sage, but not the ordinary Hankel functions. Did I overlook these
guys anywhere? Anyway, since the latter are just linear combinations
of the Bessel J and Y functions, it shouldn't be difficult to define
them.
I'm interested in hearing what you think. I know that there are some
stability issues with computing Bessel functions for complex
arguments, so I want to thread carefully
All the best,
Joris
--
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
URL: http://www.sagemath.org
