[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread Nick Alexander
Ted Kosan [EMAIL PROTECTED] writes: In SAGE, I have ended up using the numerical_approx() method as an equivalent to N[] and //N in Mathematica, but I have found it not to be as quick and easy to use. I use RR(expr) and find it at least as usable as the N[expr] notation of Mathematica. Nick

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread Hamptonio
I agree that RR(expr) works well as an N(expr) replacement. It would be nice for mathematica migrators to actually have N() defined, although that does clutter up the namespace more. I hadn't realized that mathematica was so unusual in its behavior in this regard. However, there's another

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread Bobby Moretti
Hi all, So far I've been refraining from posting here, since I don't have strong feelings one way or the other, but the discussion so far has been great and I'd like to leave a few comments. On 7/8/07, William Stein [EMAIL PROTECTED] wrote: Hi, Thanks for all the feedback from everybody

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread boothby
-1 to single-letter functions in the namespace. Also note that RDF(expr) works too, and is marginally to extremely faster, depending on the precision that RR is using. On Tue, 10 Jul 2007, Hamptonio wrote: I agree that RR(expr) works well as an N(expr) replacement. It would be nice for

[sage-devel] Re: posets sagex

2007-07-10 Thread Robert Bradshaw
Yes, Python extension types implement _richcmp_, not the __le__, etc. See the extensive comments in element.pyx to understand how to implement this. - Robert On Jul 10, 2007, at 9:54 AM, [EMAIL PROTECTED] wrote: I'm trying to implement a poset class in sagex. The following output

[sage-devel] Re: posets sagex

2007-07-10 Thread Carl Witty
On Jul 10, 9:54 am, [EMAIL PROTECTED] wrote: I'm trying to implement a poset class in sagex. The following output indicates to me that __cmp__ gets called on the sagex class no matter what. This means that partial ordering cannot be implemented in sagex (rather, it can, but can't take

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread Hamptonio
Perhaps it would help to start with a fairly clean namespace and then have some modules which would imitate various environments. So for example, there might be a simple command like: set_style('mathematica') which would define the N() function, and some other favorite mathematica functions.

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread David Harvey
I don't really like the idea of modules that imitate various environments, i.e. I don't think it's possible or desirable for us to try to look specifically like any other system. Mathematica semantics are so different from SAGE's, it would be misleading to suggest anything like that. But I

[sage-devel] get_unsafe()

2007-07-10 Thread Justin C. Walker
Hi, all, A question of style and SAGE etiquette: the Matrix class (from sage.matrix.matrix0) declares a cdef'd function get_unsafe(). It's not declared public, and it's not clear from a quick scan of the programming guide how that affects its visibility. So: - what code can call such a

[sage-devel] Re: get_unsafe()

2007-07-10 Thread Robert Bradshaw
Any code that cimports Matrix can call this method. Basically, get_unsafe gets the i,j-th entry _without_ any bounds checking, but is the fastest way to generically get an entry of a matrix. If you are writing an method that goes through each (or many) entries of a matrix, it is the thing

[sage-devel] Re: get_unsafe()

2007-07-10 Thread Justin C. Walker
On Jul 10, 2007, at 2:45 PM, Robert Bradshaw wrote: Any code that cimports Matrix can call this method. Basically, get_unsafe gets the i,j-th entry _without_ any bounds checking, but is the fastest way to generically get an entry of a matrix. This is currently a .py file. Using 'cimport'

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread William Stein
On 7/10/07, David Harvey [EMAIL PROTECTED] wrote: I don't really like the idea of modules that imitate various environments, i.e. I don't think it's possible or desirable for us to try to look specifically like any other system. Mathematica semantics are so different from SAGE's, it would be

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread Justin C. Walker
On Jul 10, 2007, at 2:20 PM, David Harvey wrote: I don't really like the idea of modules that imitate various environments, i.e. I don't think it's possible or desirable for us to try to look specifically like any other system. Mathematica semantics are so different from SAGE's, it would

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread Robert Bradshaw
Though I am against having all single-letter symbolic variables defined, I want to put a comment in for having a well-populated global namespace at startup. I like this so I can get right to work with out having to import a bunch of stuff too (let alone remember where things are). This is

[sage-devel] Re: predefined symbolic variable names

2007-07-10 Thread Justin C. Walker
On Jul 10, 2007, at 2:54 PM, William Stein wrote: On 7/10/07, David Harvey [EMAIL PROTECTED] wrote: [snip] But I *do* like the idea of the clean initial namespace, which gets subsequently polluted on demand when requested by the user. I do not think this should be the default for

[sage-devel] Re: get_unsafe()

2007-07-10 Thread Robert Bradshaw
On Jul 10, 2007, at 2:52 PM, Justin C. Walker wrote: On Jul 10, 2007, at 2:45 PM, Robert Bradshaw wrote: Any code that cimports Matrix can call this method. Basically, get_unsafe gets the i,j-th entry _without_ any bounds checking, but is the fastest way to generically get an entry of a

[sage-devel] Re: get_unsafe()

2007-07-10 Thread William Stein
On 7/10/07, Justin C. Walker [EMAIL PROTECTED] wrote: On Jul 10, 2007, at 2:45 PM, Robert Bradshaw wrote: Any code that cimports Matrix can call this method. Basically, get_unsafe gets the i,j-th entry _without_ any bounds checking, but is the fastest way to generically get an entry of a

[sage-devel] Re: get_unsafe()

2007-07-10 Thread Justin C. Walker
On Jul 10, 2007, at 15:12 , William Stein wrote: On 7/10/07, Justin C. Walker [EMAIL PROTECTED] wrote: On Jul 10, 2007, at 2:45 PM, Robert Bradshaw wrote: [snip] You can write a Python wrapper for get_unsafe, e.g., I just tried this by adding this to matrix0.pyx (try the attached patch).

[sage-devel] Re: 2.7 alpha^2?

2007-07-10 Thread Yi Qiang
Hi guys, I am just catching up on sage-devel reading. To figure out the next available port, I used the follow snippet in DSage: try: s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('', NEW_CLIENT_PORT)) port_used =

[sage-devel] Re: posets sagex

2007-07-10 Thread Nick Alexander
[EMAIL PROTECTED] writes: I'm trying to implement a poset class in sagex. The following output indicates to me that __cmp__ gets called on the sagex class no matter what. This means that partial ordering cannot be implemented in sagex (rather, it can, but can't take advantage of the

[sage-devel] Re: posets sagex

2007-07-10 Thread William Stein
On 7/10/07, Nick Alexander [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I'm trying to implement a poset class in sagex. The following output indicates to me that __cmp__ gets called on the sagex class no matter what. This means that partial ordering cannot be implemented in

[sage-devel] Re: posets sagex

2007-07-10 Thread Nick Alexander
William Stein [EMAIL PROTECTED] writes: On 7/10/07, Nick Alexander [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I'm trying to implement a poset class in sagex. The following output indicates to me that __cmp__ gets called on the sagex class no matter what. This means that

[sage-devel] New version of SageX

2007-07-10 Thread Robert Bradshaw
See http://sage.math.washington.edu/home/robertwb/sagex/ . The biggest change is updating to Pyrex 0.9.5.1a (see http:// www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/ CHANGES.txt ), plus a couple of other minor changes (including bugfixes from Jim Kleckner and Joel Mohler).