[sage-devel] Re: numerical optimization in sage
The majority of TOMLAB (80%) is code developed in C and Fortran (embedded for use in Matlab). OpenOpt is definitely not equivalent to TOMLAB. Best wishes, Marcus Tomlab Optimization Inc. http://tomopt.com/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Bug Day 4 Proposal: Oct. 20th, 2007
Hello, it has been a while since the last Bug Day and the number of tickets keep growing, so I figured it would be a good idea to do another one. As most people now have to teach/attend class I would suggest the next Sunday, Oct. 20th, instead of a weekday. Let me know what you think. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
On Thursday 11 October 2007, mabshoff wrote: Hello, it has been a while since the last Bug Day and the number of tickets keep growing, so I figured it would be a good idea to do another one. As most people now have to teach/attend class I would suggest the next Sunday, Oct. 20th, instead of a weekday. Let me know what you think. +1 -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
mabshoff wrote: Hello, it has been a while since the last Bug Day and the number of tickets keep growing, so I figured it would be a good idea to do another one. As most people now have to teach/attend class I would suggest the next Sunday, Oct. 20th, instead of a weekday. Let me know what you think. I wouldn't be able to participate in a bug day on Sunday, so I'd vote for a weekday or a Saturday, for whatever weight my vote holds. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Introductory SAGE talk in Oslo
I tied up the loose ends, and now you can find the PDF, ODP and HTML files at my website, http://folk.uio.no/georgmu/ . Visuals can be found in the directory http://folk.uio.no/georgmu/Writings/SAGE-Oslo/Graphics/ . --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Introductory SAGE talk in Oslo
On Oct 11, 3:26 pm, Georg Muntingh [EMAIL PROTECTED] wrote: I tied up the loose ends, and now you can find the PDF, ODP and HTML files at my website,http://folk.uio.no/georgmu/. Visuals can be found in the directoryhttp://folk.uio.no/georgmu/Writings/SAGE-Oslo/Graphics/ . Well, yes but Forbidden You don't have permission to access /georgmu/Writings/SAGE-Oslo/ Graphics/ActiveLearning.jpg on this server. Apache/2.2.4 (Unix) Server at folk.uio.no Port 80 :) Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
On Oct 11, 2:35 pm, Jason Grout [EMAIL PROTECTED] wrote: mabshoff wrote: Hello, it has been a while since the last Bug Day and the number of tickets keep growing, so I figured it would be a good idea to do another one. As most people now have to teach/attend class I would suggest the next Sunday, Oct. 20th, instead of a weekday. Let me know what you think. I wouldn't be able to participate in a bug day on Sunday, The initial suggestion of Sundays for Bug Days came out of a discussion at SD 5 and I think that William at least told me that he wanted to not work on Sage on Saturdays. Weekdays are tougher, especially with the huge time zone difference (at least for the Europeans) so I'd vote for a weekday or a Saturday, for whatever weight my vote holds. :), depending on your time zone at least some of us will start in Saturday and leave early on Sunday. But there are usually a sufficient number of people in IRC to do some bug hunting in a social setting. Thanks, Jason Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Introductory SAGE talk in Oslo
Excellent! Thanks. However, the pdf at http://folk.uio.no/georgmu/Writings/SAGE-Oslo/ has some black pages. Do you know why this is? +++ On 10/11/07, Georg Muntingh [EMAIL PROTECTED] wrote: I tied up the loose ends, and now you can find the PDF, ODP and HTML files at my website, http://folk.uio.no/georgmu/ . Visuals can be found in the directory http://folk.uio.no/georgmu/Writings/SAGE-Oslo/Graphics/ . --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Introductory SAGE talk in Oslo
On 10/11/07, David Joyner [EMAIL PROTECTED] wrote: Excellent! Thanks. However, the pdf at http://folk.uio.no/georgmu/Writings/SAGE-Oslo/ has some black pages. Do you know why this is? I suspect they are intentional -- a dramatic pause -- it was a very stylish talk after all. Anyway, thanks for the beautiful slides, which I've posted here: http://sagemath.org/why.html William +++ On 10/11/07, Georg Muntingh [EMAIL PROTECTED] wrote: I tied up the loose ends, and now you can find the PDF, ODP and HTML files at my website, http://folk.uio.no/georgmu/ . Visuals can be found in the directory http://folk.uio.no/georgmu/Writings/SAGE-Oslo/Graphics/ . -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Introductory SAGE talk in Oslo
Yes, that is on purpose. I use them when I change subject or when I want the audience to look at me, instead of at the screen. It is quite a smart trick. The following article neatly describes the effect of a black screen: http://www.bertdecker.com/experience/2007/03/blog_entry_date.html I agree that it looks strange outside the context of the presentation. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
On 10/11/07, mabshoff [EMAIL PROTECTED] wrote: it has been a while since the last Bug Day and the number of tickets keep growing, so I figured it would be a good idea to do another one. As most people now have to teach/attend class I would suggest the next Sunday, Oct. 20th, instead of a weekday. Let me know what you think. I wouldn't be able to participate in a bug day on Sunday, The initial suggestion of Sundays for Bug Days came out of a discussion at SD 5 and I think that William at least told me that he wanted to not work on Sage on Saturdays. Weekdays are tougher, especially with the huge time zone difference (at least for the Europeans) so I'd vote for a weekday or a Saturday, for whatever weight my vote holds. :), depending on your time zone at least some of us will start in Saturday and leave early on Sunday. But there are usually a sufficient number of people in IRC to do some bug hunting in a social setting. I think doing it on Saturday instead does make a lot of sense. There are other people (besides Jason) who couldn't do it on Sunday, but whose participation is critical. So I propose next Saturday (not this coming Saturday), i.e., Saturday October 20. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Fwd: ode_solver
-- Forwarded message -- From: Marshall Hampton [EMAIL PROTECTED] Date: Oct 10, 12:07 pm Subject: ode_solver To: sage-support I have used cython to try to speed up my function evaluations. The computation that used to take about 2400 seconds (40 minutes) now takes 38 seconds - a very nice improvement. I can more or less live with that, although as I noted before mathematica takes about 1.5 seconds, and its solution looks quite accurate. So we can do better. Josh Kantor has suggested that I try the scipy integrate command, which I hope to do soon. Maybe it will be faster. To fix the interpolation problems, I just use the line command: T = ode_solver() # lots of stuff I am leaving out t_data = T.solution show(line([[x[0],x[1][2]] for x in tdata]) In case anyone is interested in the full details, I have put a text file with a minimal version of my model up at: http://www.d.umn.edu/~mhampton/Model1.txt Marshall On Oct 5, 10:14 am, William Stein [EMAIL PROTECTED] wrote: On 10/5/07, David Joyner [EMAIL PROTECTED] wrote: I think this was written by Josh Kantor, but possibly it was William Stein. I don't understand it either. Sorry. Josh wrote it. It wraps gsl. You might be defining a function whose evaluation is really slow, e.g., if it involves symbolic calculus in any way, it could be very slow, and that would slow down everything else. So you might: (1) make sure any functions involved evaluate very very quickly. (2) consider using scipy's ode solving capabilities, which are quite fast. (3) wait for Josh to make some helpful remarks -- but only expect that if you post complete details about what you're doing. William On 10/5/07, Hamptonio [EMAIL PROTECTED] wrote: I just moved an ODE model of mine over to sage from mathematica and I am trying to use ode_solver to deal with it. Now that I am using it seriously I found a few issues. I am happy to try to help solve them but I don't know the code well yet. 1) Trivial documentation error: in runge-kutta-felhberg, fehlberg is misspelled. 2) interpolate_solution acts a little funny. I was using a 5000 point solution, and the interpolation seemed to be ignoring some points - i.e. perhaps it only uses a sample of the solution? I have a rapidly oscillating solution, and the interpolation fails pretty badly. 3) It is extremely slow. I have a rather complicated system of three variables. Mathematica's NDSolve takes about 1.5 seconds to solve it on one computer, and ode_solver takes about 2400 seconds on a better computer. I will have to learn more pyrex I guess. I was surprised by how bad the difference was. Marshall On Apr 1, 8:04 pm, David Joyner [EMAIL PROTECTED] wrote: On 1/4/07, JoshuaKantor[EMAIL PROTECTED] wrote: In response to Williams sage-2.0 plan I wanted to describe what I had done with using gsl to implement a numerical ode solver. I believe that the patch containing this will be applied after doing a recent pull or upgrade but I'm not sure(is this true?). If not .. Ideas for extension: 1. It would be nice if there was some facility for automatically converting a nth order ODE to a system of first order ones. If an n-th order ODE is simply a function of the variables x, y0=y, y1=y',...,yn = y^(n), then this is easy to write. Should the n-th order ODEs form a class? 2. It would be nice if there was some facility for automatically computing the jacobian when the functions involved are rational functions and elementary functions. Maxima has a function called hessian, as well as a determinant. Together, I think they should do what you want. 3. Numerically computing the jacobian: For the algorithms that require the jacobian It would be possible to numerically compute the jacobian, however I was wary of doing this by default. Does anyone have any knowledge about the benefits of this, can it cause instability (using the numerical jacobian instead of the exact one). I don't but I agree with you anyway. -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] DSage Zombie issue on sage.math
Hello, zombies have taken over sage.math: top - 09:48:46 up 36 days, 18:09, 17 users, load average: 2.24, 1.79, 1.44 Tasks: 864 total, 3 running, 550 sleeping, 0 stopped, 311 zombie Cpu(s): 8.1%us, 1.0%sy, 13.1%ni, 76.7%id, 1.2%wa, 0.0%hi, 0.0%si, 0.0%st They all appear to be dsage jobs started by was yesterday. Any ideas what happened? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: DSage Zombie issue on sage.math
Hi Michael, I think there is a problem with the way the individual workers are restarted which leaves them as zombie processes. I'll look into this. Cheers, Yi -- http://www.yiqiang.org On 10/11/07, mabshoff [EMAIL PROTECTED] wrote: Hello, zombies have taken over sage.math: top - 09:48:46 up 36 days, 18:09, 17 users, load average: 2.24, 1.79, 1.44 Tasks: 864 total, 3 running, 550 sleeping, 0 stopped, 311 zombie Cpu(s): 8.1%us, 1.0%sy, 13.1%ni, 76.7%id, 1.2%wa, 0.0%hi, 0.0%si, 0.0%st They all appear to be dsage jobs started by was yesterday. Any ideas what happened? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: DSage Zombie issue on sage.math
On 10/11/07, Yi Qiang [EMAIL PROTECTED] wrote: Hi Michael, I think there is a problem with the way the individual workers are restarted which leaves them as zombie processes. I'll look into this. Cheers, Yi Yep. I killed them all, since my entire huge job finished (yes!). But yeah, it would be good to make sure zombies don't get created in the future. William -- http://www.yiqiang.org On 10/11/07, mabshoff [EMAIL PROTECTED] wrote: Hello, zombies have taken over sage.math: top - 09:48:46 up 36 days, 18:09, 17 users, load average: 2.24, 1.79, 1.44 Tasks: 864 total, 3 running, 550 sleeping, 0 stopped, 311 zombie Cpu(s): 8.1%us, 1.0%sy, 13.1%ni, 76.7%id, 1.2%wa, 0.0%hi, 0.0%si, 0.0%st They all appear to be dsage jobs started by was yesterday. Any ideas what happened? Cheers, Michael -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
Saturday the 20th works for me. --Mike On 10/11/07, William Stein [EMAIL PROTECTED] wrote: On 10/11/07, mabshoff [EMAIL PROTECTED] wrote: it has been a while since the last Bug Day and the number of tickets keep growing, so I figured it would be a good idea to do another one. As most people now have to teach/attend class I would suggest the next Sunday, Oct. 20th, instead of a weekday. Let me know what you think. I wouldn't be able to participate in a bug day on Sunday, The initial suggestion of Sundays for Bug Days came out of a discussion at SD 5 and I think that William at least told me that he wanted to not work on Sage on Saturdays. Weekdays are tougher, especially with the huge time zone difference (at least for the Europeans) so I'd vote for a weekday or a Saturday, for whatever weight my vote holds. :), depending on your time zone at least some of us will start in Saturday and leave early on Sunday. But there are usually a sufficient number of people in IRC to do some bug hunting in a social setting. I think doing it on Saturday instead does make a lot of sense. There are other people (besides Jason) who couldn't do it on Sunday, but whose participation is critical. So I propose next Saturday (not this coming Saturday), i.e., Saturday October 20. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: numerical optimization in sage
On 10/11/07, medvall [EMAIL PROTECTED] wrote: The majority of TOMLAB (80%) is code developed in C and Fortran (embedded for use in Matlab). Does TOMLAB also have a Python interface? If so, how much does it cost? Thanks for writing, William OpenOpt is definitely not equivalent to TOMLAB. Best wishes, Marcus Tomlab Optimization Inc. http://tomopt.com/ -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [Pyrex] C-API implementation in Pyrex 0.9.6
On 10/11/07, Stefan Behnel [EMAIL PROTECTED] wrote:
the C-API support has been rewritten for integration in Pyrex, but not much to
...
Hi,
Can I ask a few naive questions about the C-API support, since I know that
me and _many_ of the people I work with are confused about what this support
provides? I'll just ask a few naive questions, and maybe your answers would
be useful for me to add to the faq or documentation.
(1) Suppose I would like to define a cdef'd function in a module
arith.pyx that I want
to call from other .pyx files, e.g.,
cdef int fast_gcd(int a, int b):
...
Then I basically want to do this sort of thing from other .pyx files:
from arith cimport fast_gcd
int x = fast_gcd(5,7)
Definitely in Cython/Pyrex a few months ago the above wouldn't work.
Is there a way to make it work now? And if so, what are the linking
requirements
(i.e. options to gcc or distutils)?
(2) Suppose I want to define a cdef'd function in a .pyx file, as above, but now
I want it to be callable from some external C file. E.g.,
/* this is a C function in a .c file */
int foo(blah) {
fast_gcd(...)
}
This is very natural to do because I might be mixing C and .pyx code,
and this provides a way to reach back and get at Python data directly
from C code. Is there now a way to do this?
-- William
However, I think the current implementation is a bad idea, as it pollutes the
module namespace. What a user see now is a lot of module attributes that are
nicely named like functions, but that cannot be called. Also, this means that
the C-level view on the module gets exposed to the Python level, which can be
rather confusing, depending on the naming scheme(s) in use. And given the fact
that C APIs tend to be larger and more redundant than Python APIs, e.g. to
reflect different function signatures, this is not a problem that I would want
to see ignored.
My original implementation was targeted to avoid exactly this problem, as it
exported only a single PyCObject as entry point that pointed to a function
table mapping string names to function pointers. It would have been easy to
generate the import code based on this table instead, which would have
provided the same level of binary independence.
Greg, is there any chance you could revert your changes to make the generated
modules less ugly and confusing?
Stefan
___
Pyrex mailing list
[EMAIL PROTECTED]
http://lists.copyleft.no/mailman/listinfo/pyrex
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
On Oct 11, 2007, at 5:35 AM, Jason Grout wrote: mabshoff wrote: Hello, it has been a while since the last Bug Day and the number of tickets keep growing, so I figured it would be a good idea to do another one. As most people now have to teach/attend class I would suggest the next Sunday, Oct. 20th, instead of a weekday. Let me know what you think. I wouldn't be able to participate in a bug day on Sunday, so I'd vote for a weekday or a Saturday, for whatever weight my vote holds. Same here. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
On 10/11/07, Robert Bradshaw [EMAIL PROTECTED] wrote: I wouldn't be able to participate in a bug day on Sunday, so I'd vote for a weekday or a Saturday, for whatever weight my vote holds. Same here. OK, Saturday October 20, 2007 it is: http://wiki.sagemath.org/bug4 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Fwd: [Pyrex] C-API implementation in Pyrex 0.9.6
-- Forwarded message --
From: Stefan Behnel [EMAIL PROTECTED]
Date: Oct 11, 2007 11:19 AM
Subject: Re: [Pyrex] C-API implementation in Pyrex 0.9.6
To: William Stein [EMAIL PROTECTED]
Cc: sage-devel@googlegroups.com, Greg Ewing
[EMAIL PROTECTED], Pyrex ML [EMAIL PROTECTED]
William Stein wrote:
Can I ask a few naive questions about the C-API support, since I know that
me and _many_ of the people I work with are confused about what this support
provides? I'll just ask a few naive questions, and maybe your answers would
be useful for me to add to the faq or documentation.
Sure. The main idea behind the C-API support for Pyrex/Cython is to
automate this:
http://docs.python.org/ext/using-cobjects.html
(1) Suppose I would like to define a cdef'd function in a module
arith.pyx that I want
to call from other .pyx files, e.g.,
cdef int fast_gcd(int a, int b):
...
Then I basically want to do this sort of thing from other .pyx files:
from arith cimport fast_gcd
int x = fast_gcd(5,7)
Definitely in Cython/Pyrex a few months ago the above wouldn't work.
Is there a way to make it work now?
Yes. You can export the function from arith.pyx via the api keyword (in
Pyrex 0.9.6, Cython will follow here) and it will generate a file
arith_api.h and (if you want) a .pxd file that define it. Then the above
code should work.
And if so, what are the linking
requirements (i.e. options to gcc or distutils)?
No linking required, pure runtime access.
(2) Suppose I want to define a cdef'd function in a .pyx file, as above, but
now
I want it to be callable from some external C file. E.g.,
/* this is a C function in a .c file */
int foo(blah) {
fast_gcd(...)
}
This is very natural to do because I might be mixing C and .pyx code,
and this provides a way to reach back and get at Python data directly
from C code. Is there now a way to do this?
In exactly the same way, just with a little less automatism. The arith_api.h
files defines static function pointers for each exported function and a static
function that you can call to initialise the pointers based on the Python
module. So, #including the header file and calling that function is enough to
do the above.
To make my position regarding the Pyrex 0.9.6 implementation clear: I like the
Pyrex interface to this functionality, it is better and cleaner than my
original implementation, and Cython should follow here. I just dislike the
internal implementation that leaks too much into Python space, where it simply
does not belong at all.
Stefan
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Version of sage on sage.math on October 4th
On Oct 10, 1:07 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Oct 9, 8:27 pm, William Stein [EMAIL PROTECTED] wrote: On 10/9/07, Iftikhar Burhanuddin [EMAIL PROTECTED] wrote: On Tue, 9 Oct 2007, William Stein wrote: I think thememoryleaks that we identified before (which involve ntl strings, etc.) only *maybe* got fixed in Sage-2.8.6, and certainly weren't fixed in sage-2.8.5.1, so if you ran a computation with sage-2.8.5.1 you should expect thatmemory leak. Hi Ifti, The level ofmemoryleaking in *unexpected* compared to previous versions of sage. I ran a SupersingularModule computation on September 18 (which is pre sage-2.8.5) and it ran for about a 2 weeks and consumed only about 20% on memoryon sage.math. Something seems to have changed in and around sage-2.8.5 Well, as far as I know there is only the ntl string leak. I assumed that the ntl rewrite would go in and fix the problem. So how about this in 2.8.7? Otherwise I will fix this temporarily until the ntl write goes in. * A run of computation using the SupersingularModule on sage.math running sage-2.?.? consumed 54.4% ofmemoryin 4512:26 seconds (75.2 hours) starting October 4th. I will rerun the computation with 2.8.6 and see if more leaks appeared. Hi Ifti, I reran SuperComp() from #501 with 5 iterations using a clean 2.8.6 installed from sources and the leak of 2.3MB was all in NTL glue code via str() methods except for 240 bytes leaked via python's compiler/ interpreter. So when is the ntl update coming? Cheers, Michael * A run of computation using the SupersingularModule on sage.math running sage-2.8.6 consumed 11.8% ofmemoryin 2269:50 seconds (37.8 hours) starting October 7th. ps: I should start keeping track of version numbers in my long computations. This command helps with that: sage: version() 'SAGE Version 2.8.6, Release Date: 2007-10-06' Do you have a log of when you installed new versions of sage on sage.math and what those versions were in the september-october time frame? Fortunately any Sage install is very good at tracking its entire upgrade history. On sage.math do this: SNIP Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: DSage Zombie issue on sage.math
On Oct 11, 2007, at 10:19 AM, William Stein wrote: On 10/11/07, Yi Qiang [EMAIL PROTECTED] wrote: Hi Michael, I think there is a problem with the way the individual workers are restarted which leaves them as zombie processes. I'll look into this. Cheers, Yi Yep. I killed them all, since my entire huge job finished (yes!). But yeah, it would be good to make sure zombies don't get created in the future. FWIW, zombies are fairly light-weight processes :-} They are really skeletons of what the process was: essentially enough state information so that the parent can reap them and collect the status information (I think it amounts to a process descriptor in the kernel), so even 300 of them shouldn't be a drain (despite Hollywood's unflattering depiction of them :-}). It does pay to get rid of them, of course. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Men are from Earth. Women are from Earth. Deal with it. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Sage 2.8.6: doctest failures with cython.py on sage.math
The following happens on a compiled from source 2.8.6 on sage.math:
sage -t devel/sage-main/sage/misc/cython.py
**
File cython.py, line 316:
sage: g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[1], line 1, in module
g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')###line 316:
sage: g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/misc/cython.py, line 357, in cython_lambda
create_local_c_file=False)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 303, in cython_import_all
create_local_c_file=create_local_c_file)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 286, in cython_import
return __builtin__.__import__(name)
ImportError: /tmp/Work-mabshoff/sage-2.8.5.1/local/lib/
libcblas.so: undefined symbol: ATL_ctbmv
**
File cython.py, line 317:
sage: g(2,3)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[2], line 1, in module
g(Integer(2),Integer(3))###line 317:
sage: g(2,3)
NameError: name 'g' is not defined
**
File cython.py, line 319:
sage: g(0,0)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[3], line 1, in module
g(Integer(0),Integer(0))###line 319:
sage: g(0,0)
NameError: name 'g' is not defined
**
File cython.py, line 324:
sage: f = cython_lambda('double x', 'sage.math.sin(x) + sage.a')
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[5], line 1, in module
f = cython_lambda('double x', 'sage.math.sin(x) +
sage.a')###line 324:
sage: f = cython_lambda('double x', 'sage.math.sin(x) + sage.a')
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/misc/cython.py, line 357, in cython_lambda
create_local_c_file=False)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 303, in cython_import_all
create_local_c_file=create_local_c_file)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 286, in cython_import
return __builtin__.__import__(name)
ImportError: /tmp/Work-mabshoff/sage-2.8.5.1/local/lib/
libcblas.so: undefined symbol: ATL_ctbmv
**
File cython.py, line 325:
sage: f(10)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[6], line 1, in module
f(Integer(10))###line 325:
sage: f(10)
TypeError: lambda() takes exactly 2 arguments (1 given)
**
File cython.py, line 328:
sage: f(10)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[8], line 1, in module
f(Integer(10))###line 328:
sage: f(10)
TypeError: lambda() takes exactly 2 arguments (1 given)
**
1 items had failures:
6 of 9 in __main__.example_4
I haven't seen a ticket for this one. Should we open one?
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.8.6: doctest failures with cython.py on sage.math
Weird. cython.py passes all tests for me under an upgraded 2.8.5 -
2.8.6 from source install.
--Mike
On 10/11/07, mabshoff [EMAIL PROTECTED] wrote:
The following happens on a compiled from source 2.8.6 on sage.math:
sage -t devel/sage-main/sage/misc/cython.py
**
File cython.py, line 316:
sage: g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[1], line 1, in module
g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')###line 316:
sage: g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/misc/cython.py, line 357, in cython_lambda
create_local_c_file=False)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 303, in cython_import_all
create_local_c_file=create_local_c_file)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 286, in cython_import
return __builtin__.__import__(name)
ImportError: /tmp/Work-mabshoff/sage-2.8.5.1/local/lib/
libcblas.so: undefined symbol: ATL_ctbmv
**
File cython.py, line 317:
sage: g(2,3)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[2], line 1, in module
g(Integer(2),Integer(3))###line 317:
sage: g(2,3)
NameError: name 'g' is not defined
**
File cython.py, line 319:
sage: g(0,0)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[3], line 1, in module
g(Integer(0),Integer(0))###line 319:
sage: g(0,0)
NameError: name 'g' is not defined
**
File cython.py, line 324:
sage: f = cython_lambda('double x', 'sage.math.sin(x) + sage.a')
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[5], line 1, in module
f = cython_lambda('double x', 'sage.math.sin(x) +
sage.a')###line 324:
sage: f = cython_lambda('double x', 'sage.math.sin(x) + sage.a')
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/misc/cython.py, line 357, in cython_lambda
create_local_c_file=False)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 303, in cython_import_all
create_local_c_file=create_local_c_file)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 286, in cython_import
return __builtin__.__import__(name)
ImportError: /tmp/Work-mabshoff/sage-2.8.5.1/local/lib/
libcblas.so: undefined symbol: ATL_ctbmv
**
File cython.py, line 325:
sage: f(10)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[6], line 1, in module
f(Integer(10))###line 325:
sage: f(10)
TypeError: lambda() takes exactly 2 arguments (1 given)
**
File cython.py, line 328:
sage: f(10)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[8], line 1, in module
f(Integer(10))###line 328:
sage: f(10)
TypeError: lambda() takes exactly 2 arguments (1 given)
**
1 items had failures:
6 of 9 in __main__.example_4
I haven't seen a ticket for this one. Should we open one?
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this
[sage-devel] Re: DSage Zombie issue on sage.math
Yup, you are right. The processes are dead but have an entry in the process table. I fixed this issue btw. Cheers, Yi -- http://www.yiqiang.org On 10/11/07, Justin C. Walker [EMAIL PROTECTED] wrote: On Oct 11, 2007, at 10:19 AM, William Stein wrote: On 10/11/07, Yi Qiang [EMAIL PROTECTED] wrote: Hi Michael, I think there is a problem with the way the individual workers are restarted which leaves them as zombie processes. I'll look into this. Cheers, Yi Yep. I killed them all, since my entire huge job finished (yes!). But yeah, it would be good to make sure zombies don't get created in the future. FWIW, zombies are fairly light-weight processes :-} They are really skeletons of what the process was: essentially enough state information so that the parent can reap them and collect the status information (I think it amounts to a process descriptor in the kernel), so even 300 of them shouldn't be a drain (despite Hollywood's unflattering depiction of them :-}). It does pay to get rid of them, of course. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Men are from Earth. Women are from Earth. Deal with it. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.8.6: doctest failures with cython.py on sage.math
On Oct 12, 2:05 am, Mike Hansen [EMAIL PROTECTED] wrote:
Weird. cython.py passes all tests for me under an upgraded 2.8.5 -
2.8.6 from source install.
--Mike
Hi Mike,
I just reran
[EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.6$ ./sage -t devel/sage-
main/sage/misc/cython.py
sage -t devel/sage-main/sage/misc/cython.py
[4.6 s]
--
All tests passed!
Total time for all tests: 4.6 seconds
And it works. For a reason see below.
Cheers,
Michael
On 10/11/07, mabshoff [EMAIL PROTECTED] wrote:
The following happens on a compiled from source 2.8.6 on sage.math:
sage -t devel/sage-main/sage/misc/cython.py
**
File cython.py, line 316:
sage: g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[1], line 1, in module
g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')###line 316:
sage: g = cython_lambda('double x, double y', 'x*x + y*y + x + y +
17*x + 3.2')
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/misc/cython.py, line 357, in cython_lambda
create_local_c_file=False)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 303, in cython_import_all
create_local_c_file=create_local_c_file)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 286, in cython_import
return __builtin__.__import__(name)
ImportError: /tmp/Work-mabshoff/sage-2.8.5.1/local/lib/
libcblas.so: undefined symbol: ATL_ctbmv
**
File cython.py, line 317:
sage: g(2,3)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[2], line 1, in module
g(Integer(2),Integer(3))###line 317:
sage: g(2,3)
NameError: name 'g' is not defined
**
File cython.py, line 319:
sage: g(0,0)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[3], line 1, in module
g(Integer(0),Integer(0))###line 319:
sage: g(0,0)
NameError: name 'g' is not defined
**
File cython.py, line 324:
sage: f = cython_lambda('double x', 'sage.math.sin(x) + sage.a')
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[5], line 1, in module
f = cython_lambda('double x', 'sage.math.sin(x) +
sage.a')###line 324:
sage: f = cython_lambda('double x', 'sage.math.sin(x) + sage.a')
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/misc/cython.py, line 357, in cython_lambda
create_local_c_file=False)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 303, in cython_import_all
create_local_c_file=create_local_c_file)
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/site-
packages/sage/server/support.py, line 286, in cython_import
return __builtin__.__import__(name)
ImportError: /tmp/Work-mabshoff/sage-2.8.5.1/local/lib/
libcblas.so: undefined symbol: ATL_ctbmv
Notice the 2.8.5.1 here - I source sage-env from 2.8.5.1 and that
build has ATLAS installed. Why ./sage -testall doesn't see
LD_LIBRARY_PATH properly in this case I do not know. I have
[EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.6$ env | grep LD_L
LD_LIBRARY_PATH=/tmp/Work-mabshoff/sage-2.8.5.1/local/lib/openmpi:/tmp/
Work-mabshoff/sage-2.8.5.1/local/lib/
before I start sage from the 2.8.6 directory.
Sorry for the noise.
**
File cython.py, line 325:
sage: f(10)
Exception raised:
Traceback (most recent call last):
File /tmp/Work-mabshoff/sage-2.8.6/local/lib/python2.5/
doctest.py, line 1212, in __run
compileflags, 1) in test.globs
File doctest __main__.example_4[6], line 1, in module
[sage-devel] Fwd: [Pyrex] C-API implementation in Pyrex 0.9.6
-- Forwarded message --
From: Greg Ewing [EMAIL PROTECTED]
Date: Oct 11, 2007 4:58 PM
Subject: Re: [Pyrex] C-API implementation in Pyrex 0.9.6
To: William Stein [EMAIL PROTECTED]
Cc: sage-devel@googlegroups.com, Pyrex ML [EMAIL PROTECTED]
William Stein wrote:
(1) Suppose I would like to define a cdef'd function in a module
arith.pyx that I want
to call from other .pyx files, e.g.,
cdef int fast_gcd(int a, int b):
...
Then I basically want to do this sort of thing from other .pyx files:
from arith cimport fast_gcd
int x = fast_gcd(5,7)
Yes. You can do that by declaring fast_gcd in a .pxd file, e.g.
# arith.pxd
cdef int fast_gcd(int, int)
# arith.pyx
cdef int fast_gcd(int a, int b):
...
# anothermodule.pyx
from arith cimport fast_gcd
x = fast_gcd(5,7)
That's all you need to do. No linking is required.
(2) Suppose I want to define a cdef'd function in a .pyx file, as above, but
now
I want it to be callable from some external C file. E.g.,
/* this is a C function in a .c file */
int foo(blah) {
fast_gcd(...)
}
1) Declare the function as api in the .pyx file:
# arith.pyx
cdef api int fast_gcd(int a, int b):
...
2) Include the generated header in your C code and call the
importing function:
/* somefile.c */
#include arith_api.h
...
int x
import_arith()
x = fast_gcd(p, q)
In this case, the object file produced by compiling arith.pyx
needs to be linked against the object file produced by compiling
somefile.c, either statically or dynamically.
--
Greg
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 4 Proposal: Oct. 20th, 2007
On Oct 12, 3:03 am, John Voight [EMAIL PROTECTED] wrote: Cool, count me in! JV Hello, if you are going to participate please add yourself to the list of participants at the bottom of http://wiki.sagemath.org/bug4 Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: hg
On 10/11/07, John Voight [EMAIL PROTECTED] wrote: Is this supposed to happen? That should definitely not happen. It's likely a bug of some sort. Could you try just removing the file /home/was/s/devel/sage-main/.hg/hgrc? You should make your own ~jvoight/.hgrc file. Please let me know if that works. If so, I need to make sure to remove .hg/hgrc from the sage distro. Thanks for reporting this problem. William [EMAIL PROTECTED]:~$ sage -clone voight Now cloning the current SAGE library branch... hg clone sage sage-voight Not trusting file /home/was/s/devel/sage-main/.hg/hgrc from untrusted user was, group was abort: Permission denied: sage-voight Error cloning real0m0.094s user0m0.048s sys 0m0.044s (I was trying to follow along the Programming Guide to add the function nfbasis, which returns the basis and the discriminant: def nfbasis_d(self, long flag=0, p=0): cdef gen _p cdef GEN g, d if p != 0: _p = self.pari(p) g = _p.g else: g = GENNULL d = self.pari(0) _sig_on nfb = self.new_gen(nfbasis(self.g, d.g, flag, g)) return nfb, d I wanted to test it out first before submitting a patch...) Yours, John Voight Assistant Professor of Mathematics University of Vermont [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cems.uvm.edu/~voight/ -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
