[sage-devel] Re: numerical optimization in sage
On Sep 20, 12:03 am, David Joyner [EMAIL PROTECTED] wrote: I have no ideas, but would like to mention the OS constraint solver eclipsehttp://eclipse.crosscoreop.com/ probably belongs to the same family of programs. This was mentioned at the GAP conference but I've forgotten why now. (Maybe Marc Roeder used it?) If I understand correctly, eclipse uses its own language, like GAMS or AMPL do, while OpenOpt is equivalent to TOMLAB for MATLAB - it uses 100% pure Python (+numpy) code (TOMLAB uses 100% MATLAB code). Best regards, D. http://openopt.blogspot.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] Re: number fields
On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED] wrote: On Sep 19, 2007, at 9:20 PM, Bill Hart wrote: My personal opinion is that SAGE should distinguish between an abstact number field and an embedded number field right from the start. I agree, and like David Harvey's suggestion of how to handle this. An abstract number field should be basically a number field defined by a polynomial with no embedding specified. If you like, it can be thought of as David Harvey suggested, as a number field embedded into itself, i.e. any function which relies on an embedding should map the generator x, say, of the field, to itself, not an element of the complex numbers, or any other field. The number field then exists as an abstract field apart from any embedding into C, Omega or any other field you might like to embed it into. And this enables you to embed the field into a variety of other fields, not just C. Here is how such a system would work (let's restrict for now to absolute extensions of Q, though it is possible to have any abstract number field as the base field with some not too technical modifications of the following): 1) A number field K would be defined by a monic polynomial f(x) \in Q[x] for some `symbol' x. The symbol x would stand for an *unspecified* root of f, thought of as the generator of K/Q. Is the requirement that f be monic too strong (or could we just normalize behind the scene perhaps?) Could do. 2) An element of K should be specified as an explicit polynomial expression in the nome x with coefficients in Q. In fact it is really an element of Q[x]/f(x), but any representative will do to specify the element of K uniquely. To test equality of two elements g1 and g2 of K, specified as polynomials in Q[x], one then simply reduces them mod f to see if they are the same. Since f is monic, this should be well defined. 3) One may specify an element of K as a *root* of a polynomial s(y) iff precisely one root of s lies in K=Q[x]. Internally the system would represent this element as a polynomial expression in x, uniquely identifying the element as an element of K. If more than one root of s lies in K then a function should exist to find all the roots of s *as elements of K*, i.e. it should give explicit polynomial expressions in x for all the roots of s that lie in K. This would enable one to specify an element of K as a specific root of s. Basically I think that function should have the syntax polroots(K, f) where K is the field and f is the polynomial. If none of the roots of f are in K, this should return an empty list. polroots should return a list of the roots of K as polynomial expression in the generator x of K. Personally, I like the notation f.roots(K), where f.roots() == f.roots (f.base_ring()) Yes, some of my notation is a bit unintuitive. It's the general idea that I'm presenting here which is suppose to be worth something. 4) One may specify an element of K as an expression involving radicals iff this uniquely identifies an element of K. E.g. if we are in the field defined by the polynomial x^3-3 then 3^(1/3) would simply be a synonym for x. Again the system will represent this element internally as a polynomial expression in x. If an expression involves radicals of objects which are actually coerced to be elements of K then the expression should return a list of all the possible elements of K the expression could represent (expressed as polynomials in x). If no such expression exists in K, the list should be empty. Things that sometimes return lists, and sometimes not, are messy to deal with. Especially if I write something like a^(1/3)+1 and the first part returns a list... sqrt has an optional parameter 'all' (which is false by default) that does this (though not very consistently). It also has an 'extend' parameter (by default true) which will give the result in an extension if one doesn't exist in the current field (though making an arbitrary choice). Is this the kind of stuff you are looking for (though in much more generality)? Yeah perhaps radicals should just be meaningless unless you have a number field embedded in C, in which case they should just return the root with the least argument. 5) A function should exist to determine if a given element of K is a root of a given polynomial. Similarly a function should exist to determine if two elements of K are conjugate. 6) In the case that K is Galois, one ought to be able to compute the Galois group of K. This should be represented by the group of elements of K Galois conjugate to x. To apply a Galois automorphism sigma (represented as an element of Q[x]/f) to an element g (represented by a polynomial in x, thought of as an element of Q[x]/f) of K, one simply takes g(sigma(x))/f, i.e. if g is the polynomial representing the element g of K that one is applying sigma
[sage-devel] Re: Regarding range and '..' operator
On 19-Sep-07, at 8:09 PM, William Stein wrote: On 9/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am rather fond of the '..' operator, though I can see why people wouldn't want to add it as an official part of sage. This got me to I think the decision about whether or not to include something like this is definitely not decided yet. I personally also really like the [a..b] notation, since I really enjoyed using it in Magma, and I think perhaps the complaints about 0 or 1-based are misplaced, because with the [a..b] notation one is being completely explicit about the lower endpoint. Also, the closed brackets very very very strongly suggest include the endpoint, like the do in standard mathematical notation. Also, I was not convinced that preparsing [a..b] is not possible in general (though Nick was worried about this).\ It's not that it's not possible, it's that soon you have to parse arbitrary python code, or accept that you can break the preprocessor. I am going to wait a while to see what brews up, even though the majority vote was against [a..b]. At a minimum I would like to implement that for the preparser (or have somebody else do so), and see what it feels like to use in practice in Sage. I think tomorrow I will do this, and perhaps refactor the preparser slightly while I am there. It seems like we should be able to use open and half open intervals, so not only [1..2] and (0..3) are valid but also are [0..2) and (0..2] are. In fact, I will try to specify an encoding to range that allows for something like [0, 2, .. 8) which should be [0, 2, 4, 6] by my calculation. As for iterators versus lists, I favour distinct notations for distinct ideas. Perhaps [ and )? I don't know. 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: number fields
On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED] wrote: To define an abstract number field, something like K = number_field(QQ, x^3-3*x^2+1) could work. Eventually one will want to be able to do adjoin(K, y^5+7*y-1), compositum(L, M), etc. Would/could these functions return lists too, if, say, the intersection of L and M was not Q? Yeah, thinking about it some more, I think these functions really only make sense if everything is embedded in another field. In particular they should make sense if everything is embedded in an algebraic closure of Q. But one might need to specify the field they are embedded in, since ideally number fields should be allowed to be specified with more than one embedding. I suppose that one could limit the number of embeddings of K to 1 and then just clone K and give the clone a different embedding. But whatever means is used to clone K it should be able to specify an isomorphism between the two copies so that one can easily go from the elements of one embedding field to the other. For example it would be nice to embed K into its Galois closure and then think of this as being identified with a subfield of Q bar. This would require K to be simultaneously embedded in Q bar and in the Galois closure of K. Of course one's wish list always grows longer than one's lifespan and ability to implement. Bill. --~--~-~--~~~---~--~~ 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: Regarding range and '..' operator
On 19-Sep-07, at 11:48 PM, Nick Alexander wrote: On 19-Sep-07, at 8:09 PM, William Stein wrote: On 9/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am rather fond of the '..' operator, though I can see why people wouldn't want to add it as an official part of sage. This got me to I think the decision about whether or not to include something like this is definitely not decided yet. I personally also really like the [a..b] notation, since I really enjoyed using it in Magma, and I think perhaps the complaints about 0 or 1-based are misplaced, because with the [a..b] notation one is being completely explicit about the lower endpoint. Also, the closed brackets very very very strongly suggest include the endpoint, like the do in standard mathematical notation. Also, I was not convinced that preparsing [a..b] is not possible in general (though Nick was worried about this).\ It's not that it's not possible, it's that soon you have to parse arbitrary python code, or accept that you can break the preprocessor. I am going to wait a while to see what brews up, even though the majority vote was against [a..b]. At a minimum I would like to implement that for the preparser (or have somebody else do so), and see what it feels like to use in practice in Sage. I think tomorrow I will do this, and perhaps refactor the preparser slightly while I am there. It seems like we should be able to use open and half open intervals, so not only [1..2] and (0..3) are valid but also are [0..2) and (0..2] are. Having just read this, and thought about the ubiquity of parentheses, I think I'll try for [1..2] and ]2..3[ instead :) It looks alien, but it's more likely to parse. Although in mathematical python code, square brackets are very common too :) 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: number fields
On Sep 19, 2007, at 11:39 PM, Bill Hart wrote: On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED] wrote: Personally, I like the notation f.roots(K), where f.roots() == f.roots (f.base_ring()) Yes, some of my notation is a bit unintuitive. It's the general idea that I'm presenting here which is suppose to be worth something. Yes, and I think the idea is down the right road (though I have to admit I don't have the experience using these things compared to lots of people on this list). 4) One may specify an element of K as an expression involving radicals iff this uniquely identifies an element of K. E.g. if we are in the field defined by the polynomial x^3-3 then 3^(1/3) would simply be a synonym for x. Again the system will represent this element internally as a polynomial expression in x. If an expression involves radicals of objects which are actually coerced to be elements of K then the expression should return a list of all the possible elements of K the expression could represent (expressed as polynomials in x). If no such expression exists in K, the list should be empty. Things that sometimes return lists, and sometimes not, are messy to deal with. Especially if I write something like a^(1/3)+1 and the first part returns a list... sqrt has an optional parameter 'all' (which is false by default) that does this (though not very consistently). It also has an 'extend' parameter (by default true) which will give the result in an extension if one doesn't exist in the current field (though making an arbitrary choice). Is this the kind of stuff you are looking for (though in much more generality)? Yeah perhaps radicals should just be meaningless unless you have a number field embedded in C, in which case they should just return the root with the least argument. I think it should give something, but the choice might be arbitrary, and one would be able to make the choice manually if one wanted. 5) A function should exist to determine if a given element of K is a root of a given polynomial. Similarly a function should exist to determine if two elements of K are conjugate. 6) In the case that K is Galois, one ought to be able to compute the Galois group of K. This should be represented by the group of elements of K Galois conjugate to x. To apply a Galois automorphism sigma (represented as an element of Q[x]/f) to an element g (represented by a polynomial in x, thought of as an element of Q[x]/f) of K, one simply takes g(sigma(x))/f, i.e. if g is the polynomial representing the element g of K that one is applying sigma to, and sigma(x) is the polynomial representing the application of the Galois automorphism sigma to the generator x of K, then one simply composes the polynomials g and sigma(x) and then reduces modulo f to get the element sigma(g) of K. Perhaps I'm showing my naivety here, but I thought computing Galois groups was a hard problem in general. Aren't the Galois conjugates of x the other roots of f, and if so (by the pigeonhole principle) I don't see how they would be enough to identify elements of Gal(K/Q)? If K is Galois then all the roots of the min poly of the generator are in the field. That means by definition that they have an expression as polynomials in the generator. As for there being more elements in the Galois group of a polynomial than there are roots of the polynomial, I agree that this can happen in general. In general an element of the Galois group of a polynomial has to be represented by its action on *all* of the roots of the polynomial. But isn't it the case that if the field is Galois then since the Galois automorphisms are precisely that - automorphisms - that their action on the field is fully characterised by their action on a generator of the field, which because of the fact that the field is Galois, must be other elements of the field (specifically other roots of the defining polynomial as you noted). Doesn't this then give a proof that the automorphisms of a Galois field can be represented by their action on the generator of the field, i.e. there aren't too many of them. Yeah, I realized shortly after I posted that if Q[x]/f is Galois, then f has exactly as many elements as |Gal(K/Q)| and since the group is is transitive, so the Galois conjugates of one root of f are exactly enough to specify an element. For some reason the picture I had in my head was f being a (generic) polynomial whose closure was K and looking at the permutation of a root of f, which of course doesn't work in general. One could also implement something like Allan Steel's algebraic closure as well. That seems reasonable and important though it becomes slightly complicated. The algebraic closure just gets implemented as an abstract algebraic field containing all the fields and elements one has defined over K so far with randomly chosen embeddings of those things into the
[sage-devel] Re: numerical optimization in sage
if I understand correctly, eclipse has its own language, like AMPL or GAMS, while OpenOpt uses Python (+NumPy), like TOMLAB is based on MATLAB. Best regards, Dmitrey http://openopt.blogspot.com/ P.S. I had some troubles with sending the message, sorry if you got it for twice. On Sep 20, 12:03 am, David Joyner [EMAIL PROTECTED] wrote: I have no ideas, but would like to mention the OS constraint solver eclipsehttp://eclipse.crosscoreop.com/ probably belongs to the same family of programs. This was mentioned at the GAP conference but I've forgotten why now. (Maybe Marc Roeder used it?) On 9/19/07, William Stein [EMAIL PROTECTED] wrote: For numerical people -- thoughts about this? -- Forwarded message -- From: dmitrey [EMAIL PROTECTED] Date: Sep 19, 2007 11:04 AM Subject: are you interested in SciKits.openopt - new numerical optimization soft? To: [EMAIL PROTECTED] Hallo mr. William Stein, I have already contacted you before summer 2007 about GSoC So I was taken to scipy dev team (and I have write access to scipy svn). Here is new project from scipy dev team: scikits. http://scipy.org/scipy/scikits/ While numpy/scipy allows connection of only copyleft-free code, scikits allows any OSI-approved software. openopt is one of scikits and has BSD license, as well as some own BSD-licensed solvers and connections to lots of others. I decided to inform you because maybe you or someone from your mailing lists could be interested in the software. I don't know what's your most suitable mail list for announcement. Could you inform me about this, or would you prefer to make the announce by yourself? Here's announcement by Alan G Isaac, another scipy dev team member: http://mail.python.org/pipermail/python-list/2007-September/456953.html OpenOpt home page for now is http://scipy.org/scipy/scikits/wiki/OpenOpt Best regards, Dmitrey dmitrey.kroshko at scipy dot org ICQ 275976670 (invisible) http://openopt.blogspot.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: Regarding range and '..' operator
On Sep 19, 2007, at 11:48 PM, Nick Alexander wrote: On 19-Sep-07, at 8:09 PM, William Stein wrote: On 9/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am rather fond of the '..' operator, though I can see why people wouldn't want to add it as an official part of sage. This got me to I think the decision about whether or not to include something like this is definitely not decided yet. I personally also really like the [a..b] notation, since I really enjoyed using it in Magma, and I think perhaps the complaints about 0 or 1-based are misplaced, because with the [a..b] notation one is being completely explicit about the lower endpoint. Also, the closed brackets very very very strongly suggest include the endpoint, like the do in standard mathematical notation. Also, I was not convinced that preparsing [a..b] is not possible in general (though Nick was worried about this).\ It's not that it's not possible, it's that soon you have to parse arbitrary python code, or accept that you can break the preprocessor. I think in this case we don't have to use any python semantics. I am going to wait a while to see what brews up, even though the majority vote was against [a..b]. At a minimum I would like to implement that for the preparser (or have somebody else do so), and see what it feels like to use in practice in Sage. I think tomorrow I will do this, and perhaps refactor the preparser slightly while I am there. I've actually already started doing this (almost done). Refactoring the preparser is very needed though, and perhaps another implementation to play with would be good. Sorry, should have posted that I was working on this. It seems like we should be able to use open and half open intervals, so not only [1..2] and (0..3) are valid but also are [0..2) and (0..2] are. The half-open idea is an interesting one, but unbalanced ()'s and []'s in code hurts my eyes. In fact, I will try to specify an encoding to range that allows for something like [0, 2, .. 8) which should be [0, 2, 4, 6] by my calculation. I was thinking this too, must be a good idea :-). As for iterators versus lists, I favour distinct notations for distinct ideas. Perhaps [ and )? I don't know. I think using [] to specify lists is clean and pythonic. We are basically extending the grammar list_display ::= [ [listmaker] ] by making a new kind of listmaker (currently listmaker is a comma- separated list of expressions or a list comprehension). I think the symmetry of [1,2, .., 5] == [1,2,3,4,5] is good too. As for iterators, Python uses ()'s to make iterators (as well as tuples). So (1,2,...,5) != (1,2,3,4,5), but for i in (1,2,...,5) would act exactly the same as for i in (1,2,3,4,5). - 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: patch with a function irange
William Stein wrote: I personally think the idea of irange is very sensible.The srange function I wrote isn't very good, since it is too slow (it's not in Cython, etc.). It would be nice if irange were implemented from the start to be highly optimized, and if there were further discussion about it before it goes into Sage, given how many interesting opinions and ideas people had about ranges during the recent discussion. I'm sorry. I should have given it some more thoughts. It is perfectly possible to express irange in terms of srange: def irange(start, stop, step=1): return srange(start, stop, step, include_endpoint=True) As simple as that. So optimizing srange is all that is needed. Jaap --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~--- irange_improved.hg Description: Binary data
[sage-devel] Re: number fields
On 20 Sep, 08:22, Robert Bradshaw [EMAIL PROTECTED] wrote: Yeah perhaps radicals should just be meaningless unless you have a number field embedded in C, in which case they should just return the root with the least argument. I think it should give something, but the choice might be arbitrary, and one would be able to make the choice manually if one wanted. Well the important thing is that in the abstract number field setting, a radical should only return a result if the element you are taking the nth root of is an nth power in the number field. But with no embedding into the complex numbers to refer to, how do you make a choice of nth root? You could just return a random nth root I suppose. Either that, or you have to return all the possible values. So long as the user can do both, I suppose there is no harm. I personally don't like the idea of my CAS making arbitrary choices for me where there is no convention on which to make those choices. But that is just me. So long as both options exist, I guess it will all be good. I believe I recall an algorithm based on Hensel lifting which efficiently finds roots in number fields, should they exist. I'm thinking that adjoin(K, y^3-2*y+7) is not so stupid after all. But I still didn't think of an algorithm. I think Pari implements one though via its function rnfequation. You can define a relative number field by a polynomial pol over a number field nf and then ask it to give an absolute equation apol. It even supplies an equation for the generator of nf in terms of a root of apol. Nice. Bill. --~--~-~--~~~---~--~~ 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] Burlington, VT on May 30-31, 2008
Hello, If there is a Sage user/developer who is interested in representing Sage -- especially for purposes of teaching -- at an MAA, etc., meeting in ** Burlington, VT on May 30-31, 2008, ** please send me an email.Certainly people on the organizing committee for that meeting _may_ be interesting in putting together a Sage-related component, if there were a speaker or speakers available. -- 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: number fields
On 20 Sep, 06:39, Robert Bradshaw [EMAIL PROTECTED] wrote: Carl Witty did an implementation of the Algebraic Reals by letting every element be specified by a polynomial and an interval containing a single root. I've been wondering if the same approach could be feasible for Qbar, the main difficulty being that the product of two balls in C is not a ball (though it is close for small enough epsilon). This might be much faster, for instance proving inequality is done by numerical verification (with adaptive root refinement) and if that fails it falls back to trying to deduce equality algebraically. I don't think it can fall back to deducing equality algebraically. That is tantamount to recomputing everything algebraically from the start. It would be very difficult to implement. You'd need the numerical approximation method to always succeed, otherwise you may as well do everything algebraically from the start. But I don't see where the complexity would be in doing it algebraically. I agree things couldn't be done algebraically in Pari since it doesn't have fast polynomial arithmetic. But we are assuming that SAGE will have it. Surely in order to verify two elements are not equal, one needs expressions for those elements as complex numbers. Sure, once you have those expressions, if they differ by a fair bit then you can easily decide equality. But one first has to get those expressions, and that may require you to work to quite a high precision. In the algebraic model, to determine equality, one would simply need to do two compositions of polynomials, one subtraction and a reduction modulo a certain polynomial. These should all be fairly much instantaneous operations. Moreover, if you already had reduced polynomial expressions for your elements then it is just a comparison of polynomials, which might just boil down to comparing two integers if they are sufficiently different. Also, even if you don't have such polynomial expressions one can make comparison much faster by checking whether the result is zero as the polynomial is being reduced. As soon as it turns out to be different to zero, one returns false. Sure, proving equality has the full complexity, but this is also a problem with the adaptive root refinement method. If you could implement this faster using adaptive root refinement, then you definitely should. But I'm unconvinced that it would be faster. Bill. --~--~-~--~~~---~--~~ 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: patch with a function irange
On 9/20/07, Jaap Spies [EMAIL PROTECTED] wrote: Forgot to add a few examples: Thanks. This is now trac #706: http://trac.sagemath.org/sage_trac/ticket/706 sage: v = irange(0,5); v [0, 1, 2, 3, 4, 5] sage: v = irange(1,10); v [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] sage: v = irange(10,-1,-1); v [10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0, -1] sage: v = irange(1,8, 1/2); v [1, 3/2, 2, 5/2, 3, 7/2, 4, 9/2, 5, 11/2, 6, 13/2, 7, 15/2, 8] sage: v = irange(1,2, 0.4); v [1, 1.40, 1.80] sage: v = irange(1, 2, 0.5); v [1, 1.50, 2] sage: v = irange(1, 2, -0.5); v [] sage: v = irange(2, -2, -0.5); v [2, 1.50, 1.00, 0.500, 0.000, -0.500, -1.00, -1.50, -2] sage: v = irange(10,1); v [] sage: v = irange(10,10); v [10] sage: v = irange(10); v Traceback (most recent call last): ... TypeError: irange() takes at least 2 arguments (1 given) sage: v = irange(0.5, 2.5, 0.5); v [0.500, 1.00, 1.50, 2.00, 2.50] sage: [n^2 for n in irange(-1, 10)] [1, 0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100] And this one from the calculus thread! -- I think that the Python convention of not including the upper bound in a sum is a real problem. sage: sum(i for i in range(1,10)) 45 I understand this is a fundamental convention in Python, and that it is very natural for people used to malloc(), but I worry that this will be a constant headache for students (and professors!). sage: sum(i for i in irange(1, 10)) 55 Jaap -- 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: Regarding range and '..' operator
William Stein wrote: Robert: I think using [] to specify lists is clean and pythonic. We are basically extending the grammar list_display ::= [ [listmaker] ] Yep. It make sense. It's possibly not even completely unreasonable that this notation could eventually (and I mean in a long long time) make its way into Python. http://www.python.org/dev/peps/pep-0204/ Range literals didn't make it. Mainly because of the 'wrong and confusing' notation with the slice operator ':'. Maybe a PEP introducing the '..' will eventually be acceptable? Jaap --~--~-~--~~~---~--~~ 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: number fields
The two things that Allan's method seems to allow that the embedding into C won't directly allow are: 1) Return an absolute number field which contains all the elements defined so far. 2) Compute a splitting field of a given field. Numbers 1 and 2 could be implemented independently though. Allan says number 1 is very expensive and probably not practical if the absolute degree of the resulting field is 20. So no surprises there. Number 2 is also going to be expensive, but it is with Allan's system too. So for Qbar at least there is no advantage that I can see of doing things Allan's way. Bill. On 20 Sep, 17:38, Bill Hart [EMAIL PROTECTED] wrote: No wait. I'm missing something important here. As you say, computing Galois groups is a very hard problem (probably impractical for polynomials of degree 50 according to the Magma documentation). But computing a Galois closure of a field is going to be equivalent, since then one could compute the Galois group of the original polynomial by looking at the action of the Galois group of the Galois closure on the generator of the Galois closure. What you suggest is in fact going to be faster. Each element of the algebraic closure will be specified as a minimum polynomial and a root of that polynomial computed to sufficient precision to distinguish it from the other roots of that polynomial. To compare two elements, one first compares their minimum polynomials. If they are the same, one then compares the roots. It is unfortunate that this forces the implementation to pick a particular root at random when using radicals. The only question I now have is, what is the difference between this idea and embedding a number field in CC? Is it just that roots are automatically computed to sufficient precision to distinguish them from their conjugates? I guess we need to look at the functions that Allan Steel's implementation provides for Qbar and check that each of them can be implemented with such a scheme. Bill. --~--~-~--~~~---~--~~ 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] newbie development questions
I have two newbie development questions. 1. When I make changes to, say, devel/sage-branch/sage/graphs/graph.py, I don't see those changes available in SAGE. For example, I added a function to the Graph class, but I couldn't access that function when I started up SAGE. Eventually I accidentally did sage -b branch, which looked like it copied and recompiled the graph.py file in the build directory and my changes worked fine. To see changes that I make in the source files, is that the proper procedure? (i.e., do sage -b branch before launching sage, even though devel/sage already points to sage-branch?) 2. Something seems wrong with my mercurial installation. I can't figure out where something might be misconfigured, though. I get errors about hgext/hct when using hg_sage inside of sage, but when running hg outside of sage, everything seems fine. I can find hct.py in /usr/local/lib/python2.5/site-packages/hgext/. Does anyone have any idea where I can poke to find out what's wrong? I'm running Ubuntu. Here's some relevant info: $ sage -- | SAGE Version 2.8.4.2, Release Date: 2007-09-13 | | Type notebook() for the GUI, and license() for information.| -- Loading SAGE library. Current Mercurial branch is: graphs hg_sage: hg_sage.status() Getting status of modified or unknown files: cd /home/grout/sage/sage-2.8.3/devel/sage hg status *** failed to import extension hgext/hct: No module named hgext/hct *** failed to import extension hgext/hct: No module named hgext/hct M sage/graphs/graph.py --- Branch: graphs sage: Exiting SAGE (CPU time 0m0.01s, Wall time 0m23.53s). $ cd /home/grout/sage/sage-2.8.3/devel/sage hg status M sage/graphs/graph.py [EMAIL PROTECTED]:~/sage/sage-2.8.3/devel/sage$ cat /home/grout/.hgrc [ui] username = Jason Grout [EMAIL PROTECTED] ignore=~/.hgignore [extensions] #hgext.convert= $ ls -las /usr/local/lib/python2.5/site-packages/hgext/hct.py 4 -rw-r--r-- 1 root staff 1151 2007-09-06 16:23 /usr/local/lib/python2.5/site-packages/hgext/hct.py $ 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: newbie development questions
On 9/20/07, Jason Grout [EMAIL PROTECTED] wrote: I have two newbie development questions. 1. When I make changes to, say, devel/sage-branch/sage/graphs/graph.py, I don't see those changes available in SAGE. For example, I added a function to the Graph class, but I couldn't access that function when I started up SAGE. Eventually I accidentally did sage -b branch, which looked like it copied and recompiled the graph.py file in the build directory and my changes worked fine. To see changes that I make in the source files, is that the proper procedure? (i.e., do sage -b branch before launching sage, even though devel/sage already points to sage-branch?) Do sage -br everytime. 2. Something seems wrong with my mercurial installation. I can't figure out where something might be misconfigured, though. I get errors about hgext/hct when using hg_sage inside of sage, but when running hg outside of sage, everything seems fine. I can find hct.py in /usr/local/lib/python2.5/site-packages/hgext/. Does anyone have any idea where I can poke to find out what's wrong? I'm running Ubuntu. Here's some relevant info: $ sage -- | SAGE Version 2.8.4.2, Release Date: 2007-09-13 | | Type notebook() for the GUI, and license() for information.| -- Loading SAGE library. Current Mercurial branch is: graphs hg_sage: hg_sage.status() Getting status of modified or unknown files: cd /home/grout/sage/sage-2.8.3/devel/sage hg status *** failed to import extension hgext/hct: No module named hgext/hct *** failed to import extension hgext/hct: No module named hgext/hct M sage/graphs/graph.py --- Branch: graphs sage: Exiting SAGE (CPU time 0m0.01s, Wall time 0m23.53s). $ cd /home/grout/sage/sage-2.8.3/devel/sage hg status M sage/graphs/graph.py [EMAIL PROTECTED]:~/sage/sage-2.8.3/devel/sage$ cat /home/grout/.hgrc [ui] username = Jason Grout [EMAIL PROTECTED] ignore=~/.hgignore [extensions] #hgext.convert= $ ls -las /usr/local/lib/python2.5/site-packages/hgext/hct.py 4 -rw-r--r-- 1 root staff 1151 2007-09-06 16:23 /usr/local/lib/python2.5/site-packages/hgext/hct.py $ Thanks, Jason -- 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: newbie development questions
Maybe I can offer more words of advice. The source revision system
used by sage is Mercurial:
http://www.genunix.org/wiki/index.php/Mercurial
The commands listed there have their equivalents in sage-land:
$ hg ci
becomes
$ sage -hg ci
The 'devel' directory contains all the different branches. When you
are running sage, you are running a single branch. The link 'sage' in
devel always points to the current branch. If you are running sage in
a certain branch, the objects hg_sage, hg_doc, hg_extcode and
hg_scripts correspond to Mercurial repositories for the main sage
library (including graph.py), the documentation, external files
(including our graph database ;) ), and scripts related to interfacing
etc, respectively. I usually only work with hg_sage, which is what you
want if you're editing graph.py.
Maybe the easiest way to explain it is to describe a development cycle
(the answer to your question #1 is at 4b):
1. Download and install sage ( you may want to read your favorite
Dickens novel while this is happening ;) )
2. (Optional) do sage -upgrade if it has been a while since you did
#1. This will download and install the latest packages, including the
package for the main sage library. In other words, this will bring you
up to date with the latest 'official' version. Sometimes this breaks,
but don't panic-- most likely, you will just need to force some
package to install again (mail the list at this point, probably).
3. (Also optional) if you want the latest, bleeding edge, super-
current code, you can also do hg_sage.pull() while you're running in
the 'main' branch. I always like to have my main branch as up to date
as possible, and do coding work on other branches, which brings us to:
4. Editing and testing code:
Suppose you have just done 1-3 in order. You are now ready to begin
hacking! To follow a concrete example, we'll start from the beginning:
4a. Create a branch you can safely hack in. If you simply run sage,
you will be in the current branch, which is by dafault sage-main. Do:
sage: hg_sage.clone('hackbranch')
This will copy the current branch to a branch called 'hackbranch', as
well as change the current branch to 'hackbranch'. Once the clone
command finishes, you will already be in the new branch. You can
verify this (or check what branch you are in whenever you like) by
typing hg_sage.status(). This will show you what you have modified, as
well as identify which branch you are in.
4b. Switching between branches: Anytime you do
$ sage -b branch,
you will build the branch 'branch'. If you aren't editing the files in
branch, you won't have access to the changes, since this also switches
the current branch to 'branch'. After doing 4a, you are in the branch
'hackbranch', so you shouldn't need to switch back and forth at all
while you are working: the command
$ sage -br
will build and run the current branch.
4c. Writing and testing code: now that you're this far, write some
functions, doing sage -br to test them out. Once you're happy with the
way the function works, write some doctests for the function and test
them, for example:
$ sage -t devel/sage-hackbranch/sage/graphs/graph.py
This tells sage to do all the doctests in graph.py and report if any
fail. Not specifying a file will test every file in sage! Note that
this is equivalent to
$ sage -t devel/sage/sage/graphs/graph.py,
since hackbranch is the current branch, and the symbolic link 'sage'
points to hackbranch.
5. Check in your changes, and submit a patch:
Once you have something that you definitely like, you should check in
your changes. This is done by
sage: hg_sage.ci()
When you do this, you will be shown the changes you have made, so
simply hit q when you're done looking at them. Then it will take you
to a vi screen, or something similar. Insert an insightful comment,
explaining what you have done, and save the file. Upon exit, Mercurial
will do the rest- it records the change in the repository, so that you
can share your changes with others, by:
sage: hg_sage.bundle('blah')
This creates a file called blah.hg, which contains the information of
what you changed. You can unbundle a bundle, which applies the changes
to a branch, via
sage: hg_sage.apply('blah.hg').
Note:
You must check in your changes before any transaction. If you haven't
checked in, and you try to do something else, Mercurial will
automatically put you into 'checking-in' mode first.
As far as the following, are you getting this error when you run the
main branch of sage, before modification?
2. Something seems wrong with my mercurial installation. I can't figure
out where something might be misconfigured, though. I get errors about
hgext/hct when using hg_sage inside of sage, but when running hg outside
of sage, everything seems fine. I can find hct.py in
/usr/local/lib/python2.5/site-packages/hgext/. Does anyone have any
idea where I can poke to find out what's wrong? I'm running Ubuntu.
Here's some relevant info:
$ sage
[sage-devel] Re: Burlington, VT on May 30-31, 2008
I'm interested! My first thought is I could speak on using sage in bioinformatics/ computational biology courses, although if the organizers had a particular focus some of my other interests might be more relevant (polytopes, teaching ODEs and calculus with sage, celestial mechanics). Marshall On Sep 20, 7:59 am, William Stein [EMAIL PROTECTED] wrote: Hello, If there is a Sage user/developer who is interested in representing Sage -- especially for purposes of teaching -- at an MAA, etc., meeting in ** Burlington, VT on May 30-31, 2008, ** please send me an email.Certainly people on the organizing committee for that meeting _may_ be interesting in putting together a Sage-related component, if there were a speaker or speakers available. -- 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: Burlington, VT on May 30-31, 2008
I'm interested. I am currently teaching a discrete math class where I am using Sage as an integral component of the course. The first project, which was due today, had the students finding primes in consecutive digits of e... like the Google competition, but with a catch: they had to prompt the user for a base, b, and a number of digits, N, and then search the base-b digits of e for N digit primes. --jason On 9/20/07, Hamptonio [EMAIL PROTECTED] wrote: I'm interested! My first thought is I could speak on using sage in bioinformatics/ computational biology courses, although if the organizers had a particular focus some of my other interests might be more relevant (polytopes, teaching ODEs and calculus with sage, celestial mechanics). Marshall On Sep 20, 7:59 am, William Stein [EMAIL PROTECTED] wrote: Hello, If there is a Sage user/developer who is interested in representing Sage -- especially for purposes of teaching -- at an MAA, etc., meeting in ** Burlington, VT on May 30-31, 2008, ** please send me an email.Certainly people on the organizing committee for that meeting _may_ be interesting in putting together a Sage-related component, if there were a speaker or speakers available. -- 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: newbie development questions
Thanks for the blueprint! I knew most of that but it was very helpful
to see it all spelled out in order.
-Marshall
On Sep 20, 2:52 pm, Robert Miller [EMAIL PROTECTED] wrote:
Maybe I can offer more words of advice. The source revision system
used by sage is Mercurial:http://www.genunix.org/wiki/index.php/Mercurial
The commands listed there have their equivalents in sage-land:
$ hg ci
becomes
$ sage -hg ci
The 'devel' directory contains all the different branches. When you
are running sage, you are running a single branch. The link 'sage' in
devel always points to the current branch. If you are running sage in
a certain branch, the objects hg_sage, hg_doc, hg_extcode and
hg_scripts correspond to Mercurial repositories for the main sage
library (including graph.py), the documentation, external files
(including our graph database ;) ), and scripts related to interfacing
etc, respectively. I usually only work with hg_sage, which is what you
want if you're editing graph.py.
Maybe the easiest way to explain it is to describe a development cycle
(the answer to your question #1 is at 4b):
1. Download and install sage ( you may want to read your favorite
Dickens novel while this is happening ;) )
2. (Optional) do sage -upgrade if it has been a while since you did
#1. This will download and install the latest packages, including the
package for the main sage library. In other words, this will bring you
up to date with the latest 'official' version. Sometimes this breaks,
but don't panic-- most likely, you will just need to force some
package to install again (mail the list at this point, probably).
3. (Also optional) if you want the latest, bleeding edge, super-
current code, you can also do hg_sage.pull() while you're running in
the 'main' branch. I always like to have my main branch as up to date
as possible, and do coding work on other branches, which brings us to:
4. Editing and testing code:
Suppose you have just done 1-3 in order. You are now ready to begin
hacking! To follow a concrete example, we'll start from the beginning:
4a. Create a branch you can safely hack in. If you simply run sage,
you will be in the current branch, which is by dafault sage-main. Do:
sage: hg_sage.clone('hackbranch')
This will copy the current branch to a branch called 'hackbranch', as
well as change the current branch to 'hackbranch'. Once the clone
command finishes, you will already be in the new branch. You can
verify this (or check what branch you are in whenever you like) by
typing hg_sage.status(). This will show you what you have modified, as
well as identify which branch you are in.
4b. Switching between branches: Anytime you do
$ sage -b branch,
you will build the branch 'branch'. If you aren't editing the files in
branch, you won't have access to the changes, since this also switches
the current branch to 'branch'. After doing 4a, you are in the branch
'hackbranch', so you shouldn't need to switch back and forth at all
while you are working: the command
$ sage -br
will build and run the current branch.
4c. Writing and testing code: now that you're this far, write some
functions, doing sage -br to test them out. Once you're happy with the
way the function works, write some doctests for the function and test
them, for example:
$ sage -t devel/sage-hackbranch/sage/graphs/graph.py
This tells sage to do all the doctests in graph.py and report if any
fail. Not specifying a file will test every file in sage! Note that
this is equivalent to
$ sage -t devel/sage/sage/graphs/graph.py,
since hackbranch is the current branch, and the symbolic link 'sage'
points to hackbranch.
5. Check in your changes, and submit a patch:
Once you have something that you definitely like, you should check in
your changes. This is done by
sage: hg_sage.ci()
When you do this, you will be shown the changes you have made, so
simply hit q when you're done looking at them. Then it will take you
to a vi screen, or something similar. Insert an insightful comment,
explaining what you have done, and save the file. Upon exit, Mercurial
will do the rest- it records the change in the repository, so that you
can share your changes with others, by:
sage: hg_sage.bundle('blah')
This creates a file called blah.hg, which contains the information of
what you changed. You can unbundle a bundle, which applies the changes
to a branch, via
sage: hg_sage.apply('blah.hg').
Note:
You must check in your changes before any transaction. If you haven't
checked in, and you try to do something else, Mercurial will
automatically put you into 'checking-in' mode first.
As far as the following, are you getting this error when you run the
main branch of sage, before modification?
2. Something seems wrong with my mercurial installation. I can't figure
out where something might be misconfigured, though. I get errors about
hgext/hct when using hg_sage inside of sage, but when running hg
[sage-devel] Re: Burlington, VT on May 30-31, 2008
Of course, I'm local! So let me know what I can do, I'm happy to help in any way. John Voight Assistant Professor of Mathematics University of Vermont [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cems.uvm.edu/~voight/ --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
