[sage-devel] Re: predefined symbolic variable names
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 --~--~-~--~~~---~--~~ 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: predefined symbolic variable names
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 environment that behaves that way - python itself! If you multiply 1.0*1, the answer is a float. -Marshall On Jul 10, 1:39 am, Nick Alexander [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ 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: predefined symbolic variable names
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 about symbolic variables,
special functions, etc. For now (i.e., the very near term), I think
the best thing to do is:
(1) remove all predefined *symbolic* variables except x,
leave in e, pi, and I:
-- everybody basically wants this.
This is fine. I'm not sure which approach is better. There will be
lots of Maple/Mathematica users who will find it bizarre that they
have to manually declare their variables, but I guess there's nothing
wrong with that.
(2) don't make any changes to how special functions behave.
-- doesn't seem necessary.
I agree. RR(expr) is very easy to use. As is float(expr).
(3) don't make any changes to how floating point literals behave.
-- basically put making any changes here on hold, since
substantial discussion still hasn't revealed a
sufficiently good solution.
If one wants purely C-library float special functions,
doing, e.g.,
from math import sin, cos, tan
etc., works very well right now. And using float(2.5) or 2.5r
works fine now.
Agreed.
I'm intrigued by Marshall's remark about What I think is bad is
that something like 1.0*sin(1) is not numerical - in mathematica
the sin(1) would be forced into a numerical type.
Here's what Maxima/Mathematica/Maple/Mupad do:
sage: maxima.eval('2.5*sin(1)')
'2.5*sin(1)'
sage: mathematica.eval('2.5*Sin[1]')
2.10368
sage: maple.eval('2.5*sin(1)')
'2.5*sin(1)'
sage: mupad.eval('2.5*sin(1)')
2.5 sin(1)
Here's what SAGE does:
sage: 2.5*sin(1)
2.50*sin(1)
Here's what REDUCE does -- which is totally different
(and nuts, IMHO):
1: 2.5*sin(1);
5*sin(1)
--
2
So Mathematica is in fact the only system that makes sin(1)
symbolic but 2.5*sin(1) numerical. I.e., Maple, SAGE, Mupad,
and Reduce all tend toward 2.5*sin(1) being as symbolic as
possible for some reason.
From an implementation point of view, given the SAGE rules,
it makes way more sense for 2.5*sin(1) to remain symbolic,
since:
(1) this is what the backend simplification system (maxima) does,
and
(2) 2.5 * sin(1) in SAGE is computed by making 2.5 symbolic,
then doing the multiply formally.
I'm not saying we shouldn't find a way to make 2.5 * sin(1) possibly
be numerical. I'm just remarking that this is a complicated issue
and it definitely deserves further discussion.
I actually really like Mathematica's behavior on this one. I think
it's worth considering. From a pragmatic point of view, it seems to me
that if I'm multiplying something symbolic by something approximate, I
don't want to see anything symbolic in the result, since my result is
inherently limited by the approximation. It's less clear in the case
of addition.
I think ultimately we will need to get feedback from a broader group
of users. What we as developers think is best might not actually
correspond to what most people who will be using SAGE want and expect.
~Bobby
-- William
--
Bobby Moretti
[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: predefined symbolic variable names
-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 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 environment that behaves that way - python itself! If you multiply 1.0*1, the answer is a float. -Marshall On Jul 10, 1:39 am, Nick Alexander [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ 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: posets sagex
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 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 comparison overloading that python offers). I'm working with Bruhat ordering on permutations, but I've pared the example down to the following: %sagex cdef class po_sagex: def __init__(self): pass def __le__(self, other): return False sage: a = po_sagex() sage: b = po_sagex() sage: print a = b True sage: print b = a False (note -- sometimes, True and False switch places in this example) class po_python: def __init__(self): pass def __le__(self, other): return False sage: c = po_python() sage: d = po_python() sage: print c = d False sage: print d = c False To work around this, I tried to implement a robust __cmp__ which returns None if the objects are incomparable, and no dice -- it barfs if __cmp__ doesn't return an integer. --~--~-~--~~~---~--~~ 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: posets sagex
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 advantage of the comparison overloading that python offers). You need to implement __richcmp__ and _richcmp_c_impl. See sage/rings/ real_mpfi.pyx for an example. (You can also implement __cmp__ and _cmp_c_impl, which will be used for cmp().) Carl --~--~-~--~~~---~--~~ 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: predefined symbolic variable names
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. Conceivably it would even change the behavior
of symbolic objects so that 1.0*sin(1) would evaluate to a numerical
answer, although that seems like more of a pain to implement.
-Marshall
On Jul 10, 10:58 am, [EMAIL PROTECTED] wrote:
-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 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 environment that behaves that
way - python itself! If you multiply 1.0*1, the answer is a float.
-Marshall
On Jul 10, 1:39 am, Nick Alexander [EMAIL PROTECTED] wrote:
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
--~--~-~--~~~---~--~~
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: predefined symbolic variable names
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 *do* like the idea of the clean initial
namespace, which gets subsequently polluted on demand when requested by
the user.
david
On Jul 11, 2007, at 7:15 AM, Hamptonio wrote:
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. Conceivably it would even change the behavior
of symbolic objects so that 1.0*sin(1) would evaluate to a numerical
answer, although that seems like more of a pain to implement.
-Marshall
--~--~-~--~~~---~--~~
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] get_unsafe()
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 'method'? - is it ok to add public to its declarations? I imagine we don't want code littered with get_unsaf()'s, so is there consensus on where it's reasonable to use it? Thanks. Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- My wife 'n kids 'n dogs are gone, I can't get Jesus on the phone, But Ol' Milwaukee's Best is my best friend. --- --~--~-~--~~~---~--~~ 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: get_unsafe()
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 to use if you can. For instance, if one is doing for i from 0 = i M._ncols then it is a waste to do bounds checking on the i every time. Magnitude(s) faster than M[i,j]. - Robert On Jul 10, 2007, at 2:38 PM, Justin C. Walker wrote: 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 'method'? - is it ok to add public to its declarations? I imagine we don't want code littered with get_unsaf()'s, so is there consensus on where it's reasonable to use it? Thanks. Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- My wife 'n kids 'n dogs are gone, I can't get Jesus on the phone, But Ol' Milwaukee's Best is my best friend. --- --~--~-~--~~~---~--~~ 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: get_unsafe()
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' means it has to be a .pyx, right? Is it sufficient to just change the name (he asked, work-aversely)? If you are writing an method that goes through each (or many) entries of a matrix, it is the thing to use if you can. For instance, if one is doing for i from 0 = i M._ncols then it is a waste to do bounds checking on the i every time. Magnitude(s) faster than M[i,j]. That's for me! Justin -- Justin C. Walker, Curmudgeon-At-Large, Director Institute for the Enhancement of the Director's Income The path of least resistance: it's not just for electricity any more. --~--~-~--~~~---~--~~ 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: predefined symbolic variable names
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 misleading to suggest anything like that. I agree completely with this. We should learn a lot about how Mathematica/Maple, etc., work, and why, but then make a _choice_ for SAGE that is a reasonable trade-off between various options. Python is flexible enough that individual users can always create such customizations for themselves. For example, people who like N being make it numeric might just put this in their .sage/init.sage file: N = RDF 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 everybody, because it is less user friendly. Many people might be annoyed by having to type from sage.all import plot first, just to try out drawing a plot. Then they realize halfway into a plot command that they also need to import sin, and line, and point, and other things they forgot. For interactive work for many peopl it would be very painful. However, it would likely be very easy to support what you want in some form. For example, I just implemented something; see attached patch, which you can apply by typing hg_scripts.apply(265-scripts.patch) in SAGE. The effect of this patch is that when you set the environment variable SAGE_IMPORTALL to no, e.g., via export SAGE_IMPORTALL=no then the SAGE command line has exactly the behavior you requested: $ export SAGE_IMPORTALL=no $ sage Loading SAGE library. Current Mercurial branch is: tomorrow sage: 2/3 2/3 sage: 22.50303 22.50303 sage: EllipticCurve --- type 'exceptions.NameError' Traceback (most recent call last) /Users/was/ipython console in module() type 'exceptions.NameError': name 'EllipticCurve' is not defined sage: from sage.all import EllipticCurve sage: EllipticCurve function EllipticCurve at 0xb70be30 -- By the way, a related new feature in SAGE-2.7 is that you can turn the preparser on or off at any time from the command line: sage: preparser(on=False) sage: 2/3 0 sage: preparser(on=True) sage: 2/3 2/3 -- William --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~--- 265-scripts.patch Description: Binary data
[sage-devel] Re: predefined symbolic variable names
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 be misleading to suggest anything like that. I agree. Even suggesting that such a thing is possible could lead to support headaches, as those with a strong background in My Favorite CAS try to get precisely the semantics they are used to. I think it is better to suggest that one can use a startup file of the user's own devising to try to emulate what they like about MFCAS, without claiming that it's really feasible. But I *do* like the idea of the clean initial namespace, which gets subsequently polluted on demand when requested by the user. Yeah! Let the polluters clean up their own sandboxes :-} Justin -- Justin C. Walker, Curmudgeon-At-Large, Director Institute for the Enhancement of the Director's Income The path of least resistance: it's not just for electricity any more. --~--~-~--~~~---~--~~ 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: predefined symbolic variable names
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 especially true of the notebook, where
when I restart I would have to remember to go to the right cell(s)
and re-import everything (often the case when doing development). I
think the key is the lack of ambiguity: unlike, say, a or f or
E which may mean different things depending on what I'm working on,
I always want EllipticCurve to stand for the one in sage/schemes/
elliptic_curves/constructor.py. It also makes it a lot easier to
explain how to do things to newcomers and get them going quickly
(which, hopefully, will be a large percentage of SAGE users for some
time to come).
That being said, I don't want to fill the global namespace with
everything possible, but I think (with the OO nature of Python) one
should be able to do all but the most technical things without having
to type an import statement.
- Robert
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 be misleading to suggest
anything like that. But I *do* like the idea of the clean initial
namespace, which gets subsequently polluted on demand when
requested by
the user.
david
On Jul 11, 2007, at 7:15 AM, Hamptonio wrote:
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. Conceivably it would even change the behavior
of symbolic objects so that 1.0*sin(1) would evaluate to a numerical
answer, although that seems like more of a pain to implement.
-Marshall
--~--~-~--~~~---~--~~
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: predefined symbolic variable names
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 everybody, because it is less user friendly. Many people might be annoyed by having to type from sage.all import plot Just to keep this ball rolling around a bit longer, I don't think that David's suggestion necessarily leads to this. It's one thing to have SAGE functionality at the ready at startup. It's another to have a lot of optional environmentally friendly names cluttering up the namespace. This started with the discussion of predefining the symbolic calculus variables by default. I think that has been the thrust of most of the comments so far. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds If you're not confused, You're not paying attention --~--~-~--~~~---~--~~ 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: get_unsafe()
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 matrix. This is currently a .py file. Using 'cimport' means it has to be a .pyx, right? Is it sufficient to just change the name (he asked, work-aversely)? Declaring something public simply generates a .h file, so it could interface with other c code. cimport is the alternative (cleaner) way to import something from one pyrex file to another. Neither will get you what you want in pure python. If you are writing an method that goes through each (or many) entries of a matrix, it is the thing to use if you can. For instance, if one is doing for i from 0 = i M._ncols then it is a waste to do bounds checking on the i every time. Magnitude(s) faster than M[i,j]. That's for me! Unfortunately, since you're using python, you can't get faster than M [i,j] anyways. What M[i,j] does is - turn i, j into (slower) python ints (which you already have in a .py file anyway) - create a 2-element tuple (i,j) - (indirectly) call the __getitem__ method - split the tuple and extract the c-int values - locate, (possibly create), and return the corresponding entry In pyrex, you can avoid all but the last step using get_unsafe, but from python it would have to do steps 1-4 as part of the (python) method call anyways, so you unfortunately wouldn't have any gain. On the other hand, Pyrex is extremely easy to learn once you know Python :). - 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: get_unsafe()
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 matrix. This is currently a .py file. Using 'cimport' means it has to be a .pyx, right? Is it sufficient to just change the name (he asked, work-aversely)? I think there is no possible way to use get_unsafe from a .py file directly. The public declaration doesn't do what you think. See http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/overview.html#PublicDecls and search for public. If you are writing an method that goes through each (or many) entries of a matrix, it is the thing to use if you can. For instance, if one is doing for i from 0 = i M._ncols then it is a waste to do bounds checking on the i every time. Magnitude(s) faster than M[i,j]. That's for me! 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). Note that it's actually *not* faster -- it's slower in some cases -- I think this is because calling __getitem__ goes through slots, but the Python method that wraps get_unsafe doesn't. You probably want to create a small .pyx file that contains the code you want to be fast, and call it from your .py file. Just copy something already done, and add something to setup.py (again copying what is there). William --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~--- 5259.patch Description: Binary data
[sage-devel] Re: get_unsafe()
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). Note that it's actually *not* faster -- it's slower in some cases -- I think this is because calling __getitem__ goes through slots, but the Python method that wraps get_unsafe doesn't. You probably want to create a small .pyx file that contains the code you want to be fast, and call it from your .py file. Just copy something already done, and add something to setup.py (again copying what is there). Thanks! This is what I am trying, based on Robert's previous comments. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Some people have a mental horizon of radius zero, and call it their point of view. -- David Hilbert --~--~-~--~~~---~--~~ 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: 2.7 alpha^2?
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 = True
except socket.error, msg:
port_used = False
where NEW_CLIENT_PORT is the next port you want to try. This way you
can quickly find an open port you can listen on.
-Yi
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
(2) There are some issues remaining with the new SAGE notebook:
(a) Auto-opening of next available port needs to be implemented
(b) I suspect running two SAGE notebooks from the same directory
might not correctly give a lock message.
I'll give (a) a shot -- dunno if I'll get to (b) tonight.
--~--~-~--~~~---~--~~
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: posets sagex
[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 comparison overloading that python offers). sagex and newer versions of pyrex do different things here. I think what you want can be done, but you should talk to Robert Bradshaw. The keywords are richcmp, IIRC. Nick --~--~-~--~~~---~--~~ 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: posets sagex
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 sagex (rather, it can, but can't take advantage of the comparison overloading that python offers). sagex and newer versions of pyrex do different things here. I think what you want can be done, but you should talk to Robert Bradshaw. The keywords are richcmp, IIRC. Actually, neither Robert Bradshaw or I made any changes to the __cmp__ - related code in SageX versus Pyrex, so they should behave identically unless something was done in Pyrex recently. And even then, Robert just told me that No, I haven't changed anything. We do have special _cmp_c_impl, etc. in element.pyx that calls canonical_coercion for you though. BTW, I got Pyrex 0.9.5.1a successfully merged into SageX! So -- soon pyrex and sagex should be merged again. William --~--~-~--~~~---~--~~ 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: posets sagex
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 partial ordering cannot be implemented in sagex (rather, it can, but can't take advantage of the comparison overloading that python offers). sagex and newer versions of pyrex do different things here. I think what you want can be done, but you should talk to Robert Bradshaw. The keywords are richcmp, IIRC. Actually, neither Robert Bradshaw or I made any changes to the __cmp__ - related code in SageX versus Pyrex, so they should behave identically unless something was done in Pyrex recently. IIRC, that is the case. I really meant it when I said newer versions of pyrex. Nick --~--~-~--~~~---~--~~ 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] New version of SageX
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). There is now an extra command-line option: --pre-import module. It compiles with the assumption that all undeclared names come from module. Of course this may lead to runtime name errors, but will be very useful in the notebook. I also implemented Gonzalo's suggestion to add an option to use gcc's __builtin_expect() to give branch prediction hints (specifically that raising errors are unlikely). Surprisingly, this actually made things slower in some cases, so I commented those out. If anyone could take a look at this and has some insight as to why this is the case, I would really like to know 'cause it's just baffling me. - 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/ -~--~~~~--~~--~--~---
