[sage-devel] Sage 3.4 sources released
Hello folks, after more delay than hoped for here goes the final 3.4. Sources are available from http://www.sagemath.org/src/ Upgrading Sage via the official channel also works already. There is also a sage.math only binary in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4/ Note that there is a difference between the 3.4 tarball posted over the last day and what is now on sagemath.org, but the difference is small, i.e. #5498. William and I are building binaries right now which should be mirroring out in the next half day or so just in time for the Arizona Winter School. Compared to rc0 there is now mainly ReST documentation polish as well as the rewritten Quaternion code. Cheers, Michael Merged in Sage 3.4: #5498: William Stein: fix weird weird bug in maxima.py and garbage collection [Reviewed by Michael Abshoff] Merged in Sage 3.4.final: #4640: Michael Abshoff: Do not dot out the number of pickles in the pickle jar doctest in sage/structure/sage_object.pyx, update pickle jar [Reviewed by William Stein] #5435: Carl Witty: sage-ptest Using cached timings. message could be better [Reviewed by Mike Hansen] #5409: William Stein, Jonathan Bober, John Voight: rewrite quaternion algebras -- the current implementation isn't sufficiently good [Reviewed by Gonzalo Tonaria, John Voight, Michael Abshoff] #5414: Mike Hansen: notebook help: the live documentation list are broken after the doc removal [Reviewed by Michael Abshoff] #5455: William Stein: gap-4.4.12 -- workspaces broken on iras (itanium Linux) [Reviewed by Michael Abshoff] #5461: Michael Abshoff: make -bdist build OSX app only on demand [Reviewed by William Stein] #5463: John Palmieri: new section for tutorial about functions vs. expressions, etc [Reviewed by William Stein] #5466: Mike Hansen: Make symbolic variables unpickle uniquely [Reviewed by Georg Weber] #5469: Mike Hansen: sage -clone ... should copy the sage/doc/output directory [Reviewed by Michael Abshoff] #5472: John Palmieri: typo in developer's guide [Reviewed by Michael Abshoff] #5474: John Palmieri: delimiters for LaTeX representation of matrices [Reviewed by William Stein] #5476: William Stein: dimension of jacobian of curves broken [Reviewed by Mike Hansen] Merged in Sage 3.4.rc1: #5099: Florent Hivert: rank for trivial mod n sparse matrices is broken [Reviewed by John Palmieri] #5220: Jason Grout: Weird or non-appearance of default in input_box in interact [Reviewed by William Stein] #5368: Bill Cauchois: plot3d is broken when variables not given [Reviewed by William Stein] #5408: Rob Breezer: Matrix kernel with PARI algorithm passes wrong type [Reviewed by John Cremona] #5416: Carl Witty: miscellaneous documentation fixes [Reviewed by Minh Van Nguyen] #5421: Robert Miller: Speedup is_isomorphic [Reviewed by Nick Alexander] #5428: Georg Weber: Doctest failure in devel/sage/doc/en/bordeaux_2008/ method_of_graphs.rst [Reviewed by Michael Abshoff] #5436: Minh Van Nguyen: more miscellaneous typos [Reviewed by Michael Abshoff] #5437: William Stein: pickle jar -- make it run through in order [Reviewed by Michael Abshoff] #5432: Nicolas Thiery: sage-combinat fixes: sage calls and qselect [Reviewed by Florent Hivert] #5434: Carl Witty: .shift() of a zero polynomial is broken [Reviewed by William Stein] #5443: Craig Citro: Segfault in congruence subgroup element code #5445: Carl Witty: coercion is very slow when new coercions are discovered [Reviewed by Robert Bradshaw] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4 sources released
mabshoff wrote: #5220: Jason Grout: Weird or non-appearance of default in input_box in interact [Reviewed by William Stein] William should get credit for this as well. I think it'd be best to list us both as authors and as reviewers. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4 sources released
On Mar 12, 12:35 am, Jason Grout jason-s...@creativetrax.com wrote: mabshoff wrote: #5220: Jason Grout: Weird or non-appearance of default in input_box in interact [Reviewed by William Stein] William should get credit for this as well. I think it'd be best to list us both as authors and as reviewers. Cool - done. Thanks, Jason Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: less than not transitive
On Thu, Mar 12, 2009 at 2:17 AM, Nils Bruin nbr...@sfu.ca wrote: Given the resolution of http://trac.sagemath.org/sage_trac/ticket/3936 it may be too hard to solve this one: A=GF(7)['h','k'] B=RealField()['x','y'] C=Integers() AB #true BC #true AC #false Perhaps someone with more understanding of sage internals could give it a thought how comparison could be made more consistent? The whole point of having a universal ordering is that comparison is transitive. One plus of having an ordering defined is that a wide range of outputs can be returned in the same order between runs of Sage. I think it is a good guiding principle that functions return output in the same order when possible. On a side note, in order to get an idea of the extent to which transitivity fails, I tried to sort the pickle jar: L=[] path=/usr/local/sage/default/tmp/pickle_jar-3.4 for n in os.listdir(path): if n.endswith(.sobj): L.append(load(path+/+n)) L.sort() This fails on a: AttributeError: 'TranspositionCryptosystem' object has no attribute '_ring' (triggered by a __cmp__ somewhere) That's definitely a bug. Please post it to trac. Thanks! -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] less than not transitive
Given the resolution of http://trac.sagemath.org/sage_trac/ticket/3936 it may be too hard to solve this one: A=GF(7)['h','k'] B=RealField()['x','y'] C=Integers() AB #true BC #true AC #false Perhaps someone with more understanding of sage internals could give it a thought how comparison could be made more consistent? The whole point of having a universal ordering is that comparison is transitive. On a side note, in order to get an idea of the extent to which transitivity fails, I tried to sort the pickle jar: L=[] path=/usr/local/sage/default/tmp/pickle_jar-3.4 for n in os.listdir(path): if n.endswith(.sobj): L.append(load(path+/+n)) L.sort() This fails on a: AttributeError: 'TranspositionCryptosystem' object has no attribute '_ring' (triggered by a __cmp__ somewhere) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fractions with factored denominators
Hi Nicolas, I have no time at the moment to look at this patch. I used it to do some computations which were completely undoable with the standard implementation of FractionField, and which became extremely fast using this implementation. So the lukewarm (to say the least) reaction by some very much discouraged me. Anyway here is a working link http://emis.uhasselt.be/~vdbergh/sage_patches/fraction_field_cache/ The beef is contained in a cython file factor_cache.pyx which acts as a wrapper around RingElement but which caches information about factorizations (to take mock gcd's and lcm's). FractionField_cache is an implementation of FractionField which uses factor_cache to cache factorizations of the denominator. You can turn this behaviour on and off using auto_reduce. It is quite likely that the files need to be adapted to work with the current version of Sage. Regards, Michel On Mar 9, 7:53 pm, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Dear Michel, On Mon, Mar 09, 2009 at 12:03:34AM -0700, Michel wrote: A long time ago I made a FractionFIeld implementation which would cache factorizations of denominators. instead of taking gcd's all the time http://markmail.org/message/7hxox5cbz5knxjse#query:new%20implementati... It is usually much faster than the naive implementation but it is possible to make examples where it is slower (see the above thread). That's why it was rejected. Cool, thanks so much for your pointer and your patch! In combinatorics, when playing with rational generating series, we have *lots* of fractions with denominators that factor well. So this gives quite a few applications to your code. Let me dream a bit. I very much like the idea of Factored(Ring), where elements are kept in factored form as long as possible, as is done in FriCas (thanks Martin for the pointer). I would like to have several variants to choose from: - PartiallyFactored(Ring) The factors are not guaranteed to be relatively prime - RelativelyPrimeFactored(Ring) The factors are guaranteed to be relatively prime, but not necessarily prime themselves - FullyFactored(Ring) The factors are all guaranteed to be prime In each case, the gcd function would do its best to exploit the structure (e.g. remember which factors are readily relatively prime). As readily pointed out, this is very modular, and leaves the user with the choice of the appropriate implementation of fraction field for his particular application (as the discussion pointed out there won't be one perfect implementation optimal in all cases). For example for my application, I ideally would use Ring / GcdFreePartiallyFactored(Ring). As a starter, I could do with FractionField(PartiallyFactored(Ring)). How much work would it be to adapt your patch in this direction? I definitely volunteer for testing and reviewing it! In fact, your patch would be very welcome on the Sage-combinat patch server so that we can easily start playing with it (even though it's not only about combinatorics). Best regards, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.nethttp://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Semantics of %
Here's a quick poll. In Python, if I write -1 % 5, I get 4. This is how we do it in Sage as well (and I think it's the right way--that's not what I'm trying to ask). However, in C if I write -1 % 5 I get -1. The question is, what should I get in Cython if I write (a % b) where a and b are cdef ints? Should I [ ] Get 4, because it should behave just like in Python, even though it will require extra logic and be a bit slower [ ] Get -1, because they're C ints, and besides we wouldn't be using Cython if we didn't care about performance [ ] Let the programmer decide (e.g. using http://wiki.cython.org/ enhancements/compilerdirectives ) recognizing that % will mean different things in different contexts. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On 03/12/2009 04:34 AM, Robert Bradshaw wrote: Wow, this thread has generated a lot of discussion! :) I am sorry for having started this. :-) On Mar 11, 2009, at 12:29 PM, Ralf Hemmecke wrote: Some more oil for the fire... sage: K=NumberField(x^2+1, 'a'); K Number Field in a with defining polynomial x^2 + 1 sage: a = K.0 sage: a a sage: a*a -1 sage: a1 False sage: a1 True sage: 1a False sage: 1a True sage: version() 'Sage Version 3.3, Release Date: 2009-02-21' Do I do something wrong or is autocoercion doing something strange here? In fact, I would have expected an error telling me that I cannot compare an element of K with any other thing. This is nothing to do with coercion. Really? sage: parent(1) Integer Ring sage: parent(a) Number Field in a with defining polynomial x^2 + 1 Are you saying that I can compare an integer with an element of K without coercion. Where can I find the code for this? Coercion is what allows on to write 1 3/2 2. On the other hand, Why is 'a' so different from 3/2? sage: K=NumberField(x^2+1, 'a'); K Number Field in a with defining polynomial x^2 + 1 sage: a = K.0 sage: one = K(1) sage: a*a -1 sage: one a False sage: one a True sage: one != a True The issue here is that comparison is useful outside of the purely mathematical context Aha... that means Sage just consideres K as an ordered set, but the order is not necessarily compatible with operations K. Of course K is not an ordered field. By the way... there is a bug already mentioned earlier in this thread. sage: aone True So is not even an order on the *set* K, because a is not the same as one. --for example if one wants to sort a list (for printing or searching) or use elements in sets or as keys in dictionaries OK. or simply throw an error on an illegal value like 0. That has to do with a zero-test not ordering. Ralf --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
Hmm. I have to think about it. For the moment, the only think I am sure of: coercions should *always* be safe. Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These currently work due to coercions that would be unsafe according to my definition. For R(3)*2 it seems reasonable not to fail, because every ring R can easily made into a Z-module where the above is just a shorthand for writing R(3) + R(3). Of course the result is in R. In general, if you have two rings R, S and a homomorphism h: R-S, then you can make S into a left-R-algebra by defining r*s := h(r)*s if the image of h lies in the center of S. (Note the possibility of non-commutativity.) If you also have an appropriate k: S-R then the question is whether r*s (maybe now defined as r*k(s)) is in R or in S. (I don't think that h(r)*s must be equal to r*k(s) even if you disregard being in R or S.) What happens in Sage in such a case? Or are cycles like (h,k) automatically detected in the coercion framework? Ralf --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Semantics of %
I have an ignorant question: what are the canonical reps of ZZZ/nZZZ in C? (-n/2,n/2]? Is the issue to decide between the interval [0,n-1] as reps of ZZ/nZZ (Python) vs (-n/2,n/2] (C)? The only C book I have in my office doesn't have this and my browser seems to have some problems (ASSERT: *** Search: _installLocation: engine has no file!) so I can't search for the answer. If the answer is yes then I also wonder if you can possibly leavie % the Python way and write a new operator to do it the C way? On Thu, Mar 12, 2009 at 5:14 AM, Robert Bradshaw rober...@math.washington.edu wrote: Here's a quick poll. In Python, if I write -1 % 5, I get 4. This is how we do it in Sage as well (and I think it's the right way--that's not what I'm trying to ask). However, in C if I write -1 % 5 I get -1. The question is, what should I get in Cython if I write (a % b) where a and b are cdef ints? Should I [ ] Get 4, because it should behave just like in Python, even though it will require extra logic and be a bit slower [ ] Get -1, because they're C ints, and besides we wouldn't be using Cython if we didn't care about performance [ ] Let the programmer decide (e.g. using http://wiki.cython.org/ enhancements/compilerdirectives ) recognizing that % will mean different things in different contexts. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Thu, Mar 12, 2009 at 12:35 AM, Robert Bradshaw wrote: OK, my last post on this tread for a while, I promise :). I hope no one is asking you to not post on this subject (priorities and time constraints notwithstanding)... :-( On Mar 11, 2009, at 7:19 PM, Bill Page wrote: On Wed, Mar 11, 2009 at 10:13 PM, David Roe wrote: On Wed, Mar 11, 2009 at 9:53 PM, Bill Page wrote: On Wed, Mar 11, 2009 at 9:08 PM, Carl Witty wrote: ... Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These currently work due to coercions that would be unsafe according to my definition. The __mul__ method exported by GF(5) could accept integers as well as elements of GF(5), i.e. rely on operator polymorphism rather than non-strict coercion in such cases. The reason we have coercion is so that we don't have to do this. +10. Otherwise every element has huge if-else lists in every __add__, __sub__, __mul__, etc. corresponding to the fixed list various possibilities that the programer original programmer thought of at the time, and then those who've added to it. I do not understand this claim. As Ralf pointed out, there are good (i.e. mathematical) reasons why it makes sense to multiply elements of GF(5) directly by integers. This has nothing to do with coercions or any other kind of type conversion per se. It makes sense to have this property of GF implemented locally. It would be inconvenient to have a symbol other than * to denote this operation. Because Python is dynamically typed, there is no alternative but to test some condition to determine what operation to perform. Using the coercion system to implement this kind of polymorphism moves some properties of GF into the coercion system instead of keeping it local. Much better to have a central system that one can reason with. Then the author of _mul_ only has to worry about how to actually multiply two elements of the same kind. I have nothing against the concept of a centralized system of coercions and I certainly would not advocate replacing it with exclusive use of operator polymorphism. And it makes it much messier to handle stuff like ZZ['x'] + 1/2. As others have pointed out here, coercions from ZZ['x'] - QQ['x'] should be considered safe. I presume that you do not mean to imply that this is the only reason to have coercion. Could it be said that this is the reason why you want non-strict (unsafe) coercions? I see this as one of the primary motivations to have coercion at all, safe (injective?) or not. BTW This does not make sense to me. Surely the main reason for coercions is for the convenience of the user. We want to make it easy to write in a notation that makes sense to the mathematician and which behaves in a simple and predictable (i.e. correct) manner. What Carl called safe coercions are guaranteed to satisfy this criterior. Non-safe coercions might only be necessary for more technical reasons, such as avoiding the use of operator polymorphism as discussed above. ... Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Thu, Mar 12, 2009 at 3:33 AM, Ralf Hemmecke r...@hemmecke.de wrote: Do I do something wrong or is autocoercion doing something strange here? In fact, I would have expected an error telling me that I cannot compare an element of K with any other thing. This is nothing to do with coercion. Really? sage: parent(1) Integer Ring sage: parent(a) Number Field in a with defining polynomial x^2 + 1 Are you saying that I can compare an integer with an element of K without coercion. Where can I find the code for this? No, we're saying that any oddities that arise due to having a (broken, nontransitive) ordering on K can also be seen in situations where coercion is not involved, so they are not in any way caused by coercion. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Thu, Mar 12, 2009 at 7:26 AM, Bill Page bill.p...@newsynthesis.org wrote: +10. Otherwise every element has huge if-else lists in every __add__, __sub__, __mul__, etc. corresponding to the fixed list various possibilities that the programer original programmer thought of at the time, and then those who've added to it. I do not understand this claim. As Ralf pointed out, there are good (i.e. mathematical) reasons why it makes sense to multiply elements of GF(5) directly by integers. This has nothing to do with coercions or any other kind of type conversion per se. It makes sense to have this property of GF implemented locally. It would be inconvenient to have a symbol other than * to denote this operation. Because Python is dynamically typed, there is no alternative but to test some condition to determine what operation to perform. Using the coercion system to implement this kind of polymorphism moves some properties of GF into the coercion system instead of keeping it local. It's still implemented locally... the coercion system doesn't know anything about GF(5) until GF(5) is created and tells the coercion system. (Actually, it looks like GF(5) hasn't been transitioned to the latest coercion API, so coercion doesn't know about GF(5) until somebody actually tries to do something like GF(5)(3)*2; at which point it will ask GF(5), can Integers be coerced to you?) The current system lets you also multiply elements of GF(5)['x']['y'], MatrixSpace(GF(5)['x'], 4, 4), ..., by Integers; this would be much harder to arrange if the information GF(5) can be multiplied by an Integer was locked inside the source code of __mul__ for GF(5). Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Semantics of %
Robert, Since I hit the problem I'm motivated to chime in. I also followed the email trail on the cython list. Quick summary: [X] Let the programmer decide, with [X'] Get 4 as the default There are obviously some cases where speed is paramount and others where Python compatibility is paramount, so it would be nice to choose. Echoing the cython list, I also prefer in-code directives over compiler options (though the two need not be mutually exclusive -- just a matter of development time). But given the ability to choose, you still need a default: which semantics are operative without any compiler options or pragmas. Even though I grew up writing C, I came to Cython gradually from Python code, making small changes to see what speed-ups I could get. So I assumed Python semantics were operative. Besides my use case and personal preference, I think it's more pleasant to add a pragma from a wiki page of optimizations than to get really frustrated debugging because you made one little change and now your code segfaults (my experience). Thanks for working on this! - Ryan Robert Bradshaw wrote: Here's a quick poll. In Python, if I write -1 % 5, I get 4. This is how we do it in Sage as well (and I think it's the right way--that's not what I'm trying to ask). However, in C if I write -1 % 5 I get -1. The question is, what should I get in Cython if I write (a % b) where a and b are cdef ints? Should I [ ] Get 4, because it should behave just like in Python, even though it will require extra logic and be a bit slower [ ] Get -1, because they're C ints, and besides we wouldn't be using Cython if we didn't care about performance [ ] Let the programmer decide (e.g. using http://wiki.cython.org/ enhancements/compilerdirectives ) recognizing that % will mean different things in different contexts. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] cohomology of finite groups and Steenrod operations -- some progress
Hi all, I had a conversation with John Palmieri and Simon King on sage-support about cohomology and Steenrod operations: http://groups.google.com/group/sage-support/browse_thread/thread/928840109cdadc6b/fd95901cea21288b?lnk=gstq=pierre+steenrod#fd95901cea21288b I have completed my plan of converting my own results into SAGE: http://www-irma.u-strasbg.fr/~guillot/research/cohomology_of_groups/index.html It will look silly compared to Simon's ambitious programme, but at least there is a first version of a class representing unstable algebras (I certainly need help with that). To give you an idea, if the Small Groups library is installed you can go: sage: load unstable_algebras.sage sage: G= DihedralGroup(8) sage: A= UnstableCohomologyRing(G) sage: A Unstable Algebra over GF(2) generated by z, y, x subject to z*y + y^2 = 0. sage: A.degrees [1, 1, 2] sage: z, y, x = A.gens() sage: Sq(1) z z^2 (I would have prefered Sq(1) * z but somehow it didn't work, so I went for ). For any group of order dividing 64 this will give you the mod 2 cohomology ring, from Carlson's computations; for about 90 groups among these, the Steenrod operations also work, as in the example above. If you want to avoid my UnstableAlgebra class, which isn't fully working yet, use CohomologyRing(G) instead. Any comments welcome. In fact there are a couple of questions in the .sage file, would be great if someone could help... Hope you enjoy this ! Pierre --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Error installing sage on Mac OSX 10.4.11 [cython]
Build is not working, here are some details: uname -a Darwin FatMac.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5370) Error line: python2.5 `which cython` --embed-positions --incref-local-binop -I/ Applications/sage/sage-3.2.1/devel/sage-main -o sage/calculus/var.c sage/calculus/var.pyx Error running command, failed with status 512. Running manually gives the output (same output whether or not i run sage -sh first): /Applications/sage/sage-3.2.1/local/bin/cython --embed-positions -- incref-local-binop -I/Applications/sage/sage-3.2.1/devel/sage-main -o sage/calculus/var.c sage/calculus/var.pyx 'import site' failed; use -v for traceback Traceback (most recent call last): File /Applications/sage/sage-3.2.1/local/bin/cython, line 7, in ? from Cython.Compiler.Main import main ImportError: No module named Cython.Compiler.Main my cython script contains only #!/usr/bin/env python # # Cython -- Main Program, Unix # from Cython.Compiler.Main import main main(command_line = 1) and i don't know any python so i can't go any further in this direction. However, there were plenty of .pyx files which were built before this failure, for example Building modified file sage/structure/wrapper_parent.pyx. Building modified file sage/symbolic/constants.pyx. Building modified file sage/symbolic/expression.pyx. Building modified file sage/symbolic/function.pyx. Building modified file sage/symbolic/pynac.pyx. Building modified file sage/symbolic/ring.pyx. Finally, python -V Python 2.3.5 Any ideas? Rohit --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Semantics of %
On Thu, Mar 12, 2009 at 4:16 AM, David Joyner wdjoy...@gmail.com wrote: I have an ignorant question: what are the canonical reps of ZZZ/nZZZ in C? (-n/2,n/2]? Is the issue to decide between the interval [0,n-1] as reps of ZZ/nZZ (Python) vs (-n/2,n/2] (C)? In C, ZZ/nZZ does not have canonical representatives. For example, the equivalent of [n%4 for n in [-7 .. 7]] would give: -3, -2, -1, 0, -3, -2, -1, 0, 1, 2, 3, 0, 1, 2, 3 This is annoying to a mathematician. The big reason in favor of this is to align with division: both C and Python give a==(a/b)*b+a%b, but Python uses floor division and C uses truncating division. So why does C use truncating division? I'm not sure what the choice point was, but at this point two very important reasons would be: because that's what the signed integer division instruction gives you on basically all processors, and because that's what the C standard has specified for years, so people have written code depending on that behavior. Given these facts, it's IMHO unlikely that C will ever change. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Semantics of %
[ ] Get 4, because it should behave just like in Python, even though it will require extra logic and be a bit slower [X] Get -1, because they're C ints, and besides we wouldn't be using Cython if we didn't care about performance [ ] Let the programmer decide (e.g. using http://wiki.cython.org/ enhancements/compilerdirectives ) recognizing that % will mean different things in different contexts. I've also been reading the Cython thread ... I agree that there's a good argument for Python semantics, but when it comes down to it, I think of Cython as being able to move my inner loops down to C -- if I type cdef int x, I'm generally expecting x to act like a C int, and be *as fast as humanly possible*. Plus, when we move things from Python down to Cython, we already have changes to make -- for instance, x**2 has to change, because C doesn't support exponentiation, so why would it be any different for %? That said, it would be really nice if there were an easy way to get Python semantics for % on C ints. I just don't think it should be the default. -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4 sources released
I am getting 1 error on sage -testall after an upgrade from 3.3 to 3.4 on Mac OS 10.5.6. sage -t devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py ** File /Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py, line 3023: sage: E.cremona_label() Expected: Traceback (most recent call last): ... RuntimeError: Cremona label not known for Elliptic Curve defined by y^2 + x*y + 3*y = x^3 + 2*x^2 + 4*x + 5 over Rational Field. Got: '10351a1' ** 1 items had failures: 1 of 7 in __main__.example_70 ***Test Failed*** 1 failures. Other than that everything seems okay. Thanks for all of the hard work. -- David Monarres dmmonar...@gmail.com Which is worse: ignorance or apathy? Who knows? Who cares? On Mar 12, 2009, at 1:09 AM, mabshoff wrote: On Mar 12, 12:35 am, Jason Grout jason-s...@creativetrax.com wrote: mabshoff wrote: #5220: Jason Grout: Weird or non-appearance of default in input_box in interact [Reviewed by William Stein] William should get credit for this as well. I think it'd be best to list us both as authors and as reviewers. Cool - done. Thanks, Jason Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fractions with factored denominators
Hi,
First, I think (at least last time I tried) there is a lot of room to
speed
up arithmetic in function fields, which would be my first priority.
Second, as a mathematical construction, I think that the
localizations
A_S where A is a ring (e.g. UFD or PID) and S = {p_1,...,p_n} is a
set
of primes/irreducibles, would be a useful class to have.
If one knows the primes inverted this would give the correct
structure
in which to carry out these calculations.
Regards,
David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Fractions with factored denominators
On Fri, Mar 13, 2009 at 4:03 AM, David Kohel drko...@gmail.com wrote:
Hi,
First, I think (at least last time I tried) there is a lot of room to
speed
up arithmetic in function fields, which would be my first priority.
Second, as a mathematical construction, I think that the
localizations
A_S where A is a ring (e.g. UFD or PID) and S = {p_1,...,p_n} is a
set
of primes/irreducibles, would be a useful class to have.
definite +1. In fact, this is (unsurprisingly) one of the features that the
audience at Sage Days 14 asked for in yesterday's what do you want from
Sage session.
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne --
Australia -- http://www.ms.unimelb.edu.au/~aghitza/
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
Dear Robert, The issue here is that comparison is useful outside of the purely mathematical context--for example if one wants to sort a list (for printing or searching) or use elements in sets or as keys in dictionaries or simply throw an error on an illegal value like 0. Sure. But if python allows for it, I'd rather not to mix mathematics and implementation detail. Is there a way to have a different order. In MuPAD we had a function sysorder. Let me quote the doc: 1 - A unique internal order exists for almost all objects that are created in a MuPAD session. sysorder compares two objects according to this in- ternal order. !! The exceptions are domains. (Note: ie: class in python language) 2 - One should not try and use the internal order to sort objects accord- ing to specific criteria. E.g., its does not necessarily reflect the natural ordering of numbers or strings. Further, the internal order may differ between different MuPAD versions. I like point 1) but implementing it relies on some feature of the memory management (unique rep + systematic computation of some hash value). As you can guess 2) was more a pain than anything else... Nevertheless I retain the idea of two orders one which is mathematically sound and the other one which is use for internal. Of course I'd rather keeping the usual = notation for the mathematical one. My dream is that the internal one is just an extension of the mathematical one when the later has no meaning, but this is too mush asking. Ideed, the mathematical sound can be very time consuming to compute. Whereas for most data structure applications you require that it is fast to compute. Is there any low level python data structures using search trees on something equivalent ? Operations like these would be much more of a pain if most objects in Sage threw errors on comparison. I agrees for sysorder. Not for ... Cheers, Florent --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Error installing sage on Mac OSX 10.4.11 [cython]
fat chat, member, , no email, allowed, 2006, 11, 1, 18, 24, 35 wrote: Hi, Build is not working, here are some details: SNIP What are you trying to do? Build from sources? Then something went very wrong since Cython not working is a serious failure earlier and you should have never gotten to this point. Please compress install.log and post a link so I can take a look since the content you gave is insufficient. You also might want to download Sage 3.4 which is available for download from the main website since late last night. Rohit Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: http://hg.sagemath.org/sage-main/
On Mar 12, 3:00 am, Martin Albrecht m...@informatik.uni-bremen.de wrote: Hi there, Hi Martin, it seems http://hg.sagemath.org/sage-main/ is out of date. Yeah, William and I started looking into fixing this last night, but we didn't get it done before having to take off. I am not sure we will get to it today, but due to various internal changes the old script will no longer work (we know what is wrong). Cheers, Martin Cheers, Michael -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www:http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Mar 12, 2009, at 7:26 AM, Bill Page wrote: On Thu, Mar 12, 2009 at 12:35 AM, Robert Bradshaw wrote: OK, my last post on this tread for a while, I promise :). I hope no one is asking you to not post on this subject (priorities and time constraints notwithstanding)... :-( No...it just always feels a bit odd when the last 4 replies to a thread are by the same person. On Mar 11, 2009, at 7:19 PM, Bill Page wrote: On Wed, Mar 11, 2009 at 10:13 PM, David Roe wrote: On Wed, Mar 11, 2009 at 9:53 PM, Bill Page wrote: On Wed, Mar 11, 2009 at 9:08 PM, Carl Witty wrote: ... Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These currently work due to coercions that would be unsafe according to my definition. The __mul__ method exported by GF(5) could accept integers as well as elements of GF(5), i.e. rely on operator polymorphism rather than non-strict coercion in such cases. The reason we have coercion is so that we don't have to do this. +10. Otherwise every element has huge if-else lists in every __add__, __sub__, __mul__, etc. corresponding to the fixed list various possibilities that the programer original programmer thought of at the time, and then those who've added to it. I do not understand this claim. As mentioned, everything can be seen as a Z-module. This would mean that every time I implement _mul_ I would have to handle this case. It's much simpler to let _mul_ only worry about the ring (or group, or field...) multiplication. One can define _rmul_, _lmul_, ... for actions. So, to rephrase the question, does this mean that GF(5)(3) + 1 and RR (pi) + 1 should fail? As Ralf pointed out, there are good (i.e. mathematical) reasons why it makes sense to multiply elements of GF(5) directly by integers. This has nothing to do with coercions or any other kind of type conversion per se. It makes sense to have this property of GF implemented locally. It would be inconvenient to have a symbol other than * to denote this operation. Because Python is dynamically typed, there is no alternative but to test some condition to determine what operation to perform. Using the coercion system to implement this kind of polymorphism moves some properties of GF into the coercion system instead of keeping it local. To clarify, the coercion system doesn't know anything about GF, it queries parents about their properties and then does reasoning based on that. Much better to have a central system that one can reason with. Then the author of _mul_ only has to worry about how to actually multiply two elements of the same kind. I have nothing against the concept of a centralized system of coercions and I certainly would not advocate replacing it with exclusive use of operator polymorphism. And it makes it much messier to handle stuff like ZZ['x'] + 1/2. As others have pointed out here, coercions from ZZ['x'] - QQ['x'] should be considered safe. Sorry, what I meant it would be messy to implement this in the _add_ operator. I presume that you do not mean to imply that this is the only reason to have coercion. Could it be said that this is the reason why you want non-strict (unsafe) coercions? I see this as one of the primary motivations to have coercion at all, safe (injective?) or not. BTW This does not make sense to me. Surely the main reason for coercions is for the convenience of the user. Yes, it's all about convenience. I was saying that arithmetic is one of the main conveniences coercion provides to the user and programer. We want to make it easy to write in a notation that makes sense to the mathematician and which behaves in a simple and predictable (i.e. correct) manner. What Carl called safe coercions are guaranteed to satisfy this criterior. Non-safe coercions might only be necessary for more technical reasons, such as avoiding the use of operator polymorphism as discussed above. I guess safe is a matter of personal taste. I find sage: GF(5)(0) == 0 True sage: GF(5)(1) == 1 True sage: GF(5)(-1) == -1 True to be safe, but it seems some people are really bothered by this idea and would rather have to write a == a.parent().coerce(1) - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Mar 11, 2009, at 10:23 PM, Carl Witty wrote: On Wed, Mar 11, 2009 at 9:35 PM, Robert Bradshaw rober...@math.washington.edu wrote: Here's some examples to hopefully clarify: RealField(20) - RealField(50) RealField(20) - RealIntervalField(20) I would call these dangerous, I should clarify, it'd be dangerous to use these for arithmetic. as the latter implicitly has more information than the former. No they don't: sage: pi20.exact_rational() 411775/131072 sage: RealField(50)(pi20).exact_rational() 411775/131072 See, exactly the same information :) I get your point, but to me if a function returns 1.00 that's more information than if a function returns 1.000, and 1.? is more information yet. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
I guess safe is a matter of personal taste. I find sage: GF(5)(0) == 0 True sage: GF(5)(1) == 1 True sage: GF(5)(-1) == -1 True to be safe, but it seems some people are really bothered by this idea and would rather have to write a == a.parent().coerce(1) I'd rather write a.parent().one or a.parent().one() or a.parent().unit() or... rather than to ask for coercion. IE if you are in a ring you are supposed to have unit which can be a complicated data structure (eg 1000x1000 sparse matrix or something even worse). If it's the case, the methods which compute it should have a cache if it's not an attribute whereas coerce clearly can't have reasonable cache for large base ring. I don't think having coerce do a particular thing for 0, 1 or -1 is reasonable... Cheers, Florent --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4 sources released
On 12 Mar, 18:20, mabshoff mabsh...@googlemail.com wrote: On Mar 12, 9:54 am, David M. Monarres dmmonar...@gmail.com wrote: Hi David, I am getting 1 error on sage -testall after an upgrade from 3.3 to 3.4 on Mac OS 10.5.6. sage -t devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py ** File /Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ ell_rational_field.py, line 3023: sage: E.cremona_label() Expected: Traceback (most recent call last): ... RuntimeError: Cremona label not known for Elliptic Curve defined by y^2 + x*y + 3*y = x^3 + 2*x^2 + 4*x + 5 over Rational Field. Got: '10351a1' ** 1 items had failures: 1 of 7 in __main__.example_70 ***Test Failed*** 1 failures. Other than that everything seems okay. Thanks for all of the hard work. This is a known issue - seehttp://trac.sagemath.org/sage_trac/ticket/5346 - and harmless IMHO since it only fails due to additional bits of John Cremona's elliptic curve database being installed. I thought there was a patch, but there isn't. I always thought that after an upgrade one had to reinstall optional packages, but this report makes that seem not true. That particular doctest is supposed to demonstrate that Sage does not know about labels for curves of conductor 1, so it fails to so that if you have the optional extra database installed. Perhaps we should change the doctest to one where the conductor is outside tha range of the large databse, i.e. over 13. John Cheers, Michael -- David Monarres dmmonar...@gmail.com --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Mar 12, 2009, at 11:23 AM, Carl Witty wrote: On Thu, Mar 12, 2009 at 12:57 AM, Florent Hivert florent.hiv...@univ-rouen.fr wrote: Dear Robert, The issue here is that comparison is useful outside of the purely mathematical context--for example if one wants to sort a list (for printing or searching) or use elements in sets or as keys in dictionaries or simply throw an error on an illegal value like 0. Sure. But if python allows for it, I'd rather not to mix mathematics and implementation detail. Is there a way to have a different order. In MuPAD we had a function sysorder. Let me quote the doc: ... Nevertheless I retain the idea of two orders one which is mathematically sound and the other one which is use for internal. Of course I'd rather keeping the usual = notation for the mathematical one. My dream is that the internal one is just an extension of the mathematical one when the later has no meaning, but this is too mush asking. Ideed, the mathematical sound can be very time consuming to compute. Whereas for most data structure applications you require that it is fast to compute. Is there any low level python data structures using search trees on something equivalent ? +1 for having refer to mathematical orderings (so it raises an exception where no standard mathematical ordering is defined), and for having a separate sysorder comparison for the somewhat-rare cases when you really want to sort. I could actually go for this as well. Python provides richcmp (used for and friends) and cmp, and I think the later could be the sysorder (which would hopefully be less arbitrary than a memory address, specifically respect the mathematical notions of equality at least) and the former the mathematical order. On the other hand, I would rather GF(5)(1) == pi return False than raise an error. I would also still advocate using coercions, so GF(5)(1) == 1 returns True (though the argument that RealField(20)(pi) == RealField(50)(pi) returns False is a good one.) I've think I've voted the other way in previous discussions of this topic. I changed my mind because: 1) I've seen a lot more mathematicians be confused/annoyed by having defined orderings between mathematically-unordered objects since then 2) I used to think that Python more-or-less required that all objects be ordered. I don't remember where I got that idea, but it's wrong; somebody pointed out that Python-native complex numbers are unordered. The standard low-level Python data structures are the list and the dictionary; neither depends on orderings. (Dictionaries are hash tables, so they use hashes and equality.) I don't know of any contexts where Python implicitly depends on orderings. This has been discussed before; for example, see http://groups.google.com/group/sage-devel/browse_thread/thread/ fa1c998160d41f62/bc550ad42bc08cc0?lnk=gst#bc550ad42bc08cc0 My suggestion in that thread of using cmp for sysorder is possible, but I doubt if it's a good idea... it makes it easy to make implementation mistakes, because by default cmp() and use the same code. This could be changed, and probably would be a good thing (though a lot of work--I don't know how much depends on the current semantics). The cmp code isn't the prettiest right now. But I think this is a distinct topic than whether or not to use coercions in comparison. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion and exception handling
On Mar 11, 2009, at 1:21 PM, Florent Hivert wrote: How many places is this used? In my (fairly fresh) Sage session, there are only 9 actions in the action cache (on matrices, number fields, and polynomials). I'd be willing to write the _get_action_ methods for these cases, if it would help kill off some of the excess error catching in coercion (I'm really not very fond of the idea try it to see if it will work, anyway). +1 to remove the try if it's work. Matrices are already implemented via the _get_action_ path. For polynomials and number fields, I think it's actually cleaner to just provide _rmul_ and _lmul_ than create an actions (especially in terms of subclassing). The very purpose of the category framework it to declare in a mathematical way, this that have a matematical meaning. In the case of a right action of A on B, on declare that B is a A-RightModule. It is much more informative by all respect than testing if a random element of A accept to be multiplied by a random element of B. _rmul_ and _lmul_ are only tried if B is an A-module. (We don't (yet) have the distinction between right and left modules, this is part of where the try it out comes into play). However, not all actions are module actions, e.g. a permutation acting on an ordered list, or a matrix acting on a quadratic form (to take two examples that I've been thinking about lately). - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: less than not transitive
It really bothers me that less than comparisons are allowed without transitivity. I understand the benefits of being able to sort output, and transitivity is essential for that. [a different school promotes to randomize the order of output whenever there is no inherent order to the answer. It discourages careless programming style. However, the automated testing in sage is such a benefit that it's probably worth it] Being able to sort the pickle jar is probably one of the most outlandish things one might try, so I was hoping that in more restricted domain, life might still be good. Unfortunately it already goes wrong for elements of number fields: P.x=Rationals()[] def h(): while true: while true: f=P.random_element() if f != 0: break f=f/f.leading_coefficient() if f.is_irreducible(): K.g=NumberField(f) return K.random_element() L=[h() for i in [1..100]] L.sort() #any pairs printed here are not in order and hence show failure of transitivity #there's usually a bunch of them. [[i,j] for j in [1..len(L)-1] for i in range(j) if L[i] L[j]] The notebook with auto-indent and block-indent is nearly ideal by now, by the way. A pleasure to work with. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Thu, Mar 12, 2009 at 12:47 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Mar 12, 2009, at 11:23 AM, Carl Witty wrote: My suggestion in that thread of using cmp for sysorder is possible, but I doubt if it's a good idea... it makes it easy to make implementation mistakes, because by default cmp() and use the same code. This could be changed, and probably would be a good thing (though a lot of work--I don't know how much depends on the current semantics). The cmp code isn't the prettiest right now. But I think this is a distinct topic than whether or not to use coercions in comparison. Note that cmp is gone in Python 3.1+, and it's illegal to compare values of incompatible types with (although == still works). This is interesting for two reasons: if we think we're going to switch to Python 3 eventually, then it might be a bad idea to start introducing more dependencies on cmp; and as a style issue, we might want to look really hard at whether sysorder should support comparing values of incompatible types. Here's some text quoted from What's new in Python 3.0 (http://docs.python.org/dev/3.0/whatsnew/3.0.html): Ordering Comparisons Python 3.0 has simplified the rules for ordering comparisons: * The ordering comparison operators (, =, =, ) raise a TypeError exception when the operands don’t have a meaningful natural ordering. Thus, expressions like 1 '', 0 None or len = len are no longer valid, and e.g. None None raises TypeError instead of returning False. A corollary is that sorting a heterogeneous list no longer makes sense – all the elements must be comparable to each other. Note that this does not apply to the == and != operators: objects of different incomparable types always compare unequal to each other. * builtin.sorted() and list.sort() no longer accept the cmp argument providing a comparison function. Use the key argument instead. N.B. the key and reverse arguments are now “keyword-only”. * The cmp() function should be treated as gone, and the __cmp__() special method is no longer supported. Use __lt__() for sorting, __eq__() with __hash__(), and other rich comparisons as needed. (If you really need the cmp() functionality, you could use the expression (a b) - (a b) as the equivalent for cmp(a, b).) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Thu, Mar 12, 2009 at 12:18 PM, Robert Bradshaw rober...@math.washington.edu wrote: So, to rephrase the question, does this mean that GF(5)(3) + 1 and RR (pi) + 1 should fail? And note that if the answer to the former question is yes, you lose this notational convenience: sage: K.x = GF(5)[] sage: 2*x^2 + 3*x + 4 2*x^2 + 3*x + 4 You would instead have to type 2*x^2 + 3*x + GF(5)(4). Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Coercion naming question
I'm glad the coercion model is starting to get discussed, implemented, and used by other people. Before it gets to popular, I would like to propose an api change. Currently, if A has an action on B (where B is not an A-module) one implements either a._l_action_ or b._r_action_. This is because sometimes it makes sense to put the method on the actor (e.g. Galois groups acting on field elements) and sometimes on the acted on (e.g. matrices acting on quadratic forms). However, the _x_action_ is hard to remember and doesn't always correspond to right/left actions. This may be why they're hardly used up to this point. The proposal is to make the methods a._act_on_(b, self_on_left) and b._acted_upon_(a, self_on_left). In other words, a*b would try a._act_on_(b, True) and b._acted_upon_(a, False). This wouldn't be a fundamental change on how things work, just mainly a naming change, but I though it would be a good idea to run it by here. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: less than not transitive
On Mar 12, 2:24 am, William Stein wst...@gmail.com wrote: L=[] path=/usr/local/sage/default/tmp/pickle_jar-3.4 for n in os.listdir(path): if n.endswith(.sobj): L.append(load(path+/+n)) L.sort() This fails on a: AttributeError: 'TranspositionCryptosystem' object has no attribute '_ring' (triggered by a __cmp__ somewhere) That's definitely a bug. Please post it to trac. Thanks! A more general version of this is now http://trac.sagemath.org/sage_trac/ticket/5503 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Thu, Mar 12, 2009 at 3:53 PM, Robert Bradshaw wrote: ... But what I'm saying is that sage: GF(5)(3) == 3 True Seems just as natural. The reason that this seems natural is that it is a rather special case involving a simple literal. Does the following sage: a = 11 sage: GF(5)(1) == a True seem just as natural? I think one might reasonably expect to write: sage: GF(5)(1) == GF(5)(11) True But why doesn't the following constitute a ValueError? sage: a=GF(2)(1); b=GF(5)(1); c==11 True sage: a==c True sage: b==c True sage: a==b False Equality isn't even transitive! This False result could easily mask a simple error in the coding of some algorithm. There is a reasonable solution but it involves some rather deep changes to Sage. Sage decides very early on (in the preparser stage?) that the symbol 3 is going to denote an element of Integer Ring. The reason that GF(5)(3) == 3 seems natural is because in this context a human reader normally reserves judgment about what the 3 stands for until the rest of the sub-expression is understood. 3 is just a literal. There could be several other forms of literals such as 'F12A', 0777, etc. For any parent, Sage needs a way to denote elements. Interpreting literals like 0 and 1 as GF(5).zero_element() and GF(5).one_element makes sense and this can be extended in a natural manner. Having made the mistake of interpreting 3 as an integer, there is little choice but to *convert* it to GF(5)(3) when necessary but this is not a safe coercion in general. Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Semantics of %
Craig Citro wrote: and be *as fast as humanly possible*. Plus, when we move things from Python down to Cython, we already have changes to make -- for instance, x**2 has to change, because C doesn't support exponentiation, so why would it be any different for %? Cython doesn't automatically translate x**2 into x*x or pow(x,2)? If not, why not? Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion and exception handling
The very purpose of the category framework it to declare in a mathematical way, this that have a matematical meaning. In the case of a right action of A on B, on declare that B is a A-RightModule. It is much more informative by all respect than testing if a random element of A accept to be multiplied by a random element of B. _rmul_ and _lmul_ are only tried if B is an A-module. (We don't (yet) have the distinction between right and left modules, this is part of where the try it out comes into play). Thanks for this explanation... Should I understand that once we had the correct framework, these are supposed to disappear ? However, not all actions are module actions, e.g. a permutation acting on an ordered list, or a matrix acting on a quadratic form (to take two examples that I've been thinking about lately). Permutations acting on lists is not a module structure but this may fits in a category of sets with a group acting on (G-set) no-linearity here. For acting on plain list, (i.e. data structure I would rather not use * do denote the operation). For matrix on quadratic form I don't see the problem. But maybe I'm not thinking about the same operation as you. Cheers, Florent --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion naming question
Robert Bradshaw wrote: I'm glad the coercion model is starting to get discussed, implemented, and used by other people. Before it gets to popular, I would like to propose an api change. Currently, if A has an action on B (where B is not an A-module) one implements either a._l_action_ or b._r_action_. This is because sometimes it makes sense to put the method on the actor (e.g. Galois groups acting on field elements) and sometimes on the acted on (e.g. matrices acting on quadratic forms). However, the _x_action_ is hard to remember and doesn't always correspond to right/left actions. This may be why they're hardly used up to this point. The proposal is to make the methods a._act_on_(b, self_on_left) and b._acted_upon_(a, self_on_left). In other words, a*b would try a._act_on_(b, True) and b._acted_upon_(a, False). This wouldn't be a fundamental change on how things work, just mainly a naming change, but I though it would be a good idea to run it by here. So if I'm being confusing (or wrong!) here, tell me. Right now, a vector*matrix is thought of as a matrix acting on the vector, right? (This might be where I'm confused because I'm too used to matrix*vector constructs.) But then the above would force that this would be contained in the vector._act_on_ or the matrix._acted_upon_ methods, right? This seems backwards... Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4 sources released
I'm running 64-bit Ubuntu 8.10 on a Core 2 processor, and Sage 3.4 has failed to build for me twice on the same error. It appears to occur on the compilation of PolyBoRi and I get the following error: polybori/src/BoolePolynomial.cc:915: instantiated from here polybori/include/CTermGenerator.h:172: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. scons: *** [polybori/src/BoolePolynomial.os] Error 1 scons: building terminated because of errors. Error building PolyBoRi. real2m58.526s user2m16.845s sys 0m13.881s sage: An error occurred while installing polybori-0.5rc.p6 and below are some of the last lines from install.log: polybori/include/CGenericIter.h:121: instantiated from 'polybori::CGenericIterOrderType, NavigatorType, MonomType::CGenericIter(NaviType, const MgrType) [with MgrType = boost::intrusive_ptrpolybori::CCuddCore, OrderType = polybori::LexOrder, NaviType = polybori::CCuddNavigator, RefType = unsigned int]' polybori/src/BoolePolynomial.cc:915: instantiated from here polybori/include/CTermGenerator.h:172: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. On Mar 12, 3:29 am, mabshoff mabsh...@googlemail.com wrote: Hello folks, after more delay than hoped for here goes the final 3.4. Sources are available from http://www.sagemath.org/src/ Upgrading Sage via the official channel also works already. There is also a sage.math only binary in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4/ Note that there is a difference between the 3.4 tarball posted over the last day and what is now on sagemath.org, but the difference is small, i.e. #5498. William and I are building binaries right now which should be mirroring out in the next half day or so just in time for the Arizona Winter School. Compared to rc0 there is now mainly ReST documentation polish as well as the rewritten Quaternion code. Cheers, Michael Merged in Sage 3.4: #5498: William Stein: fix weird weird bug in maxima.py and garbage collection [Reviewed by Michael Abshoff] Merged in Sage 3.4.final: #4640: Michael Abshoff: Do not dot out the number of pickles in the pickle jar doctest in sage/structure/sage_object.pyx, update pickle jar [Reviewed by William Stein] #5435: Carl Witty: sage-ptest Using cached timings. message could be better [Reviewed by Mike Hansen] #5409: William Stein, Jonathan Bober, John Voight: rewrite quaternion algebras -- the current implementation isn't sufficiently good [Reviewed by Gonzalo Tonaria, John Voight, Michael Abshoff] #5414: Mike Hansen: notebook help: the live documentation list are broken after the doc removal [Reviewed by Michael Abshoff] #5455: William Stein: gap-4.4.12 -- workspaces broken on iras (itanium Linux) [Reviewed by Michael Abshoff] #5461: Michael Abshoff: make -bdist build OSX app only on demand [Reviewed by William Stein] #5463: John Palmieri: new section for tutorial about functions vs. expressions, etc [Reviewed by William Stein] #5466: Mike Hansen: Make symbolic variables unpickle uniquely [Reviewed by Georg Weber] #5469: Mike Hansen: sage -clone ... should copy the sage/doc/output directory [Reviewed by Michael Abshoff] #5472: John Palmieri: typo in developer's guide [Reviewed by Michael Abshoff] #5474: John Palmieri: delimiters for LaTeX representation of matrices [Reviewed by William Stein] #5476: William Stein: dimension of jacobian of curves broken [Reviewed by Mike Hansen] Merged in Sage 3.4.rc1: #5099: Florent Hivert: rank for trivial mod n sparse matrices is broken [Reviewed by John Palmieri] #5220: Jason Grout: Weird or non-appearance of default in input_box in interact [Reviewed by William Stein] #5368: Bill Cauchois: plot3d is broken when variables not given [Reviewed by William Stein] #5408: Rob Breezer: Matrix kernel with PARI algorithm passes wrong type [Reviewed by John Cremona] #5416: Carl Witty: miscellaneous documentation fixes [Reviewed by Minh Van Nguyen] #5421: Robert Miller: Speedup is_isomorphic [Reviewed by Nick Alexander] #5428: Georg Weber: Doctest failure in devel/sage/doc/en/bordeaux_2008/ method_of_graphs.rst [Reviewed by Michael Abshoff] #5436: Minh Van Nguyen: more miscellaneous typos [Reviewed by Michael Abshoff] #5437: William Stein: pickle jar -- make it run through in order [Reviewed by Michael Abshoff] #5432: Nicolas Thiery: sage-combinat fixes: sage calls and qselect [Reviewed by Florent Hivert] #5434: Carl Witty: .shift() of a zero polynomial is broken [Reviewed by William Stein] #5443: Craig Citro: Segfault in congruence subgroup element code #5445: Carl Witty: coercion is very slow when new coercions are discovered [Reviewed by Robert Bradshaw] --~--~-~--~~~---~--~~ To post to this group, send
[sage-devel] Re: Coercion and exception handling
Dear Robert, The very purpose of the category framework it to declare in a mathematical way, this that have a matematical meaning. In the case of a right action of A on B, on declare that B is a A-RightModule. It is much more informative by all respect than testing if a random element of A accept to be multiplied by a random element of B. _rmul_ and _lmul_ are only tried if B is an A-module. (We don't (yet) have the distinction between right and left modules, this is part of where the try it out comes into play). Thanks for this explanation... Should I understand that once we had the correct framework, these are supposed to disappear ? They won't disappear--the coercion model will simply assume they're implemented and use them without trying them out first. I'm sorry I wasn't clear... In my mind, They was supposed to refer to try out an not _rmul_ and _lmul_. However, not all actions are module actions, e.g. a permutation acting on an ordered list, or a matrix acting on a quadratic form (to take two examples that I've been thinking about lately). Permutations acting on lists is not a module structure but this may fits in a category of sets with a group acting on (G-set) no-linearity here. For acting on plain list, (i.e. data structure I would rather not use * do denote the operation). BTW, We already have sage: [1,10,100] * 5 [1, 10, 100, 1, 10, 100, 1, 10, 100, 1, 10, 100, 1, 10, 100] I find this ugly !!! Just a little less uglier than Maple: [1,10,100] * 5 [5,50,500] (which is to be like Python) so there is some precedent. Perhaps a better example is an element of a galois group acting on a field. I'm sorry I don't get your point even with this new example. You have a group (finite or not) acting on a set (finite, discrete or not). And this is an actual action g1 . (g2 . x) = (g1 g2) . x So the field is a G-Set. And you probably need all the usual notion of orbit, fixed point, stabilizer, centralizer... Cheers, Florent --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion and exception handling
On Mar 12, 2009, at 2:42 PM, Florent Hivert wrote: Dear Robert, The very purpose of the category framework it to declare in a mathematical way, this that have a matematical meaning. In the case of a right action of A on B, on declare that B is a A-RightModule. It is much more informative by all respect than testing if a random element of A accept to be multiplied by a random element of B. _rmul_ and _lmul_ are only tried if B is an A-module. (We don't (yet) have the distinction between right and left modules, this is part of where the try it out comes into play). Thanks for this explanation... Should I understand that once we had the correct framework, these are supposed to disappear ? They won't disappear--the coercion model will simply assume they're implemented and use them without trying them out first. I'm sorry I wasn't clear... In my mind, They was supposed to refer to try out an not _rmul_ and _lmul_. No problem--I've certainly had my share of trying to re-explain myself :). Permutations acting on lists is not a module structure but this may fits in a category of sets with a group acting on (G-set) no-linearity here. For acting on plain list, (i.e. data structure I would rather not use * do denote the operation). BTW, We already have sage: [1,10,100] * 5 [1, 10, 100, 1, 10, 100, 1, 10, 100, 1, 10, 100, 1, 10, 100] I find this ugly !!! It's a natural extension of the fact that Python uses '+' for list concatenation. sage: [1, 2, 3] + [10, 20, 30] [1, 2, 3, 10, 20, 30] which is handy to be able to do (though you can complain about their choice of concatenation operator if you want). (which is to be like Python) so there is some precedent. Perhaps a better example is an element of a galois group acting on a field. I'm sorry I don't get your point even with this new example. You have a group (finite or not) acting on a set (finite, discrete or not). And this is an actual action g1 . (g2 . x) = (g1 g2) . x So the field is a G-Set. And you probably need all the usual notion of orbit, fixed point, stabilizer, centralizer... I was just coming up with an example that didn't involve lists. It certainly is a G-Set (with G hopefully lazily computed in practice). My point was that sometimes it make sense to implement the action on the actor's side, and sometimes on the acted-upon's side. Ideally, the coercion model just has the idea of an action, without having to specify where they can come from. In any case, it's clear there's some cleaning up to do, and I'll go in and do that (though not right now). - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Semantics of %
On Mar 12, 2009, at 2:17 PM, Jason Grout wrote: Craig Citro wrote: and be *as fast as humanly possible*. Plus, when we move things from Python down to Cython, we already have changes to make -- for instance, x**2 has to change, because C doesn't support exponentiation, so why would it be any different for %? Cython doesn't automatically translate x**2 into x*x or pow(x, 2)? If not, why not? There's actually a thread to re-implement this. Originally, Pyrex translated a**b to pow(a,b) for c ints, which was strange given the result was a floating point number, so we disabled it. Of course there's a narrow range of non-overflowing values. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sage -upgrade
Hi, As some of you know, I have a precious system wide install of sage. The latest sage -upgrade brought me to version 3.4: $ ls /usr/local/sage/spkg/installed/sage-* sage-1.5.1.2 sage-2.1 sage-2.2 sage-2.6 sage-2.8.3 sage-2.8.8.1 sage-3.1 sage-1.5.3sage-2.10 sage-2.3 sage-2.7 sage-2.8.3.3 sage-2.8.9sage-3.1.1 sage-1.6 sage-2.1.0.1 sage-2.4 sage-2.7.3sage-2.8.3.6 sage-2.9 sage-3.1.2 sage-1.6.1sage-2.10.1 sage-2.4.1sage-2.8 sage-2.8.4 sage-2.9.1.1 sage-3.1.4 sage-1.7 sage-2.10.2 sage-2.4.1.2 sage-2.8.10 sage-2.8.4.1 sage-2.9.2sage-3.2 sage-1.7.1sage-2.10.3 sage-2.4.2sage-2.8.11 sage-2.8.4.2 sage-3.0 sage-3.2.1 sage-1.8 sage-2.10.4 sage-2.5 sage-2.8.12 sage-2.8.5 sage-3.0.2sage-3.2.2 sage-1.8.1sage-2.11 sage-2.5.0.2 sage-2.8.13 sage-2.8.5.1 sage-3.0.3sage-3.2.3 sage-1.8.2.1 sage-2.1.3sage-2.5.1sage-2.8.14 sage-2.8.6 sage-3.0.4sage-3.3 sage-1.9 sage-2.1.3.1 sage-2.5.2sage-2.8.15 sage-2.8.7 sage-3.0.5sage-3.4 sage-2.0 sage-2.1.4sage-2.5.3sage-2.8.2sage-2.8.8sage-3.0.6 But somehow there are files that never get upgraded. For example sage, makefile, etcetera. So running make check fails. ./sage -testall gives a zillion of failures. Any help to save this install is welcome. Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade
On Thu, Mar 12, 2009 at 4:01 PM, Jaap Spies j.sp...@hccnet.nl wrote: Hi, As some of you know, I have a precious system wide install of sage. The latest sage -upgrade brought me to version 3.4: $ ls /usr/local/sage/spkg/installed/sage-* sage-1.5.1.2 sage-2.1 sage-2.2 sage-2.6 sage-2.8.3 sage-2.8.8.1 sage-3.1 sage-1.5.3 sage-2.10 sage-2.3 sage-2.7 sage-2.8.3.3 sage-2.8.9 sage-3.1.1 sage-1.6 sage-2.1.0.1 sage-2.4 sage-2.7.3 sage-2.8.3.6 sage-2.9 sage-3.1.2 sage-1.6.1 sage-2.10.1 sage-2.4.1 sage-2.8 sage-2.8.4 sage-2.9.1.1 sage-3.1.4 sage-1.7 sage-2.10.2 sage-2.4.1.2 sage-2.8.10 sage-2.8.4.1 sage-2.9.2 sage-3.2 sage-1.7.1 sage-2.10.3 sage-2.4.2 sage-2.8.11 sage-2.8.4.2 sage-3.0 sage-3.2.1 sage-1.8 sage-2.10.4 sage-2.5 sage-2.8.12 sage-2.8.5 sage-3.0.2 sage-3.2.2 sage-1.8.1 sage-2.11 sage-2.5.0.2 sage-2.8.13 sage-2.8.5.1 sage-3.0.3 sage-3.2.3 sage-1.8.2.1 sage-2.1.3 sage-2.5.1 sage-2.8.14 sage-2.8.6 sage-3.0.4 sage-3.3 sage-1.9 sage-2.1.3.1 sage-2.5.2 sage-2.8.15 sage-2.8.7 sage-3.0.5 sage-3.4 sage-2.0 sage-2.1.4 sage-2.5.3 sage-2.8.2 sage-2.8.8 sage-3.0.6 But somehow there are files that never get upgraded. For example sage, makefile, etcetera. So running make check fails. ./sage -testall gives a zillion of failures. Any help to save this install is welcome. You could copy the files SAGE_ROOT/sage and SAGE_ROOT/makefile over from the official sage-3.4.tar tarball. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4 sources released
On Mar 12, 2:25 pm, M. Yurko myu...@gmail.com wrote: Hi, I'm running 64-bit Ubuntu 8.10 on a Core 2 processor, and Sage 3.4 has failed to build for me twice on the same error. It appears to occur on the compilation of PolyBoRi and I get the following error: polybori/src/BoolePolynomial.cc:915: instantiated from here polybori/include/CTermGenerator.h:172: internal compiler error: Segmentation fault Your compiler is broken and fails with an internal error, you need to update it. There is nothing we can do on our end to fix this. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade
William Stein wrote: On Thu, Mar 12, 2009 at 4:01 PM, Jaap Spies j.sp...@hccnet.nl wrote: [...] But somehow there are files that never get upgraded. For example sage, makefile, etcetera. So running make check fails. ./sage -testall gives a zillion of failures. Any help to save this install is welcome. You could copy the files SAGE_ROOT/sage and SAGE_ROOT/makefile over from the official sage-3.4.tar tarball. Thanks! But there are problems: [j...@paix $ sage -- | Sage Version 3.4, Release Date: 2009-03-11 | | Type notebook() for the GUI, and license() for information.| -- sage: sage: x = crt(2, 1, 3, 5); x 11 But in the official sage-3.4: [j...@paix sage-3.4]$ ./sage -- | Sage Version 3.4, Release Date: 2009-03-10 | | Type notebook() for the GUI, and license() for information.| -- sage: sage: x = crt(2, 1, 3, 5); x -4 Moreover I see a lot of numerical noise. So there are more issues to be solved :( Jaap -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade
On Thu, Mar 12, 2009 at 4:37 PM, Jaap Spies j.sp...@hccnet.nl wrote: William Stein wrote: On Thu, Mar 12, 2009 at 4:01 PM, Jaap Spies j.sp...@hccnet.nl wrote: [...] But somehow there are files that never get upgraded. For example sage, makefile, etcetera. So running make check fails. ./sage -testall gives a zillion of failures. Any help to save this install is welcome. You could copy the files SAGE_ROOT/sage and SAGE_ROOT/makefile over from the official sage-3.4.tar tarball. Thanks! But there are problems: [j...@paix $ sage -- | Sage Version 3.4, Release Date: 2009-03-11 | | Type notebook() for the GUI, and license() for information. | -- sage: sage: x = crt(2, 1, 3, 5); x 11 But in the official sage-3.4: [j...@paix sage-3.4]$ ./sage -- | Sage Version 3.4, Release Date: 2009-03-10 | | Type notebook() for the GUI, and license() for information. | -- sage: sage: x = crt(2, 1, 3, 5); x -4 Moreover I see a lot of numerical noise. So there are more issues to be solved :( The above probably means that you didn't successfully install mpir. Try ./sage -f gmp-mpir-0.9.spkg William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade
William Stein wrote: On Thu, Mar 12, 2009 at 4:37 PM, Jaap Spies j.sp...@hccnet.nl wrote: William Stein wrote: On Thu, Mar 12, 2009 at 4:01 PM, Jaap Spies j.sp...@hccnet.nl wrote: [...] But somehow there are files that never get upgraded. For example sage, makefile, etcetera. So running make check fails. ./sage -testall gives a zillion of failures. Any help to save this install is welcome. You could copy the files SAGE_ROOT/sage and SAGE_ROOT/makefile over from the official sage-3.4.tar tarball. Thanks! But there are problems: [j...@paix $ sage -- | Sage Version 3.4, Release Date: 2009-03-11 | | Type notebook() for the GUI, and license() for information.| -- sage: sage: x = crt(2, 1, 3, 5); x 11 But in the official sage-3.4: [j...@paix sage-3.4]$ ./sage -- | Sage Version 3.4, Release Date: 2009-03-10 | | Type notebook() for the GUI, and license() for information.| -- sage: sage: x = crt(2, 1, 3, 5); x -4 Moreover I see a lot of numerical noise. So there are more issues to be solved :( The above probably means that you didn't successfully install mpir. Try ./sage -f gmp-mpir-0.9.spkg Sorry, but this does not solve the problems: sage: x = crt(2, 1, 3, 5); x 11 :(! Jaap William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] p-adic precision loss in charpoly
-- | Sage Version 3.4, Release Date: 2009-03-11 | | Type notebook() for the GUI, and license() for information.| -- sage: M = matrix([[8585 + O(101^2), 5612 + O(101^2), 5359 + O(101^2)], [1616 + O(101^2), 5283 + O(101^2), 2057 + O(101^2)], [8383 + O(101^2), 5843 + O(101^2), 7490 + O(101^2)]]) sage: M [ 85*101 + O(101^2) 57 + 55*101 + O(101^2) 6 + 53*101 + O(101^2)] [ 16*101 + O(101^2) 31 + 52*101 + O(101^2) 37 + 20*101 + O(101^2)] [ 83*101 + O(101^2) 86 + 57*101 + O(101^2) 16 + 74*101 + O(101^2)] sage: M.charpoly() (1 + O(101^2))*x^3 + (54 + O(101))*x^2 + (41 + O(101))*x + (95*101 + O (101^2)) Why does my charpoly have some coefficients only mod 101^1? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.4 sources released
On Mar 12, 2009, at 00:29 , mabshoff wrote: Hello folks, after more delay than hoped for here goes the final 3.4. Sources are available from http://www.sagemath.org/src/ Upgrading Sage via the official channel also works already. There is also a sage.math only binary in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4/ For the record: Sage 3.4 built w/o problems on Mac OS X, 10.5.6, on a Core Duo. Testing was successful (no failures)! Justin -- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's income --- -- They said it couldn't be done, but sometimes, it doesn't work out that way. - Casey Stengel -- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fractions with factored denominators
Hi David,
On Thu, Mar 12, 2009 at 10:03:53AM -0700, David Kohel wrote:
First, I think (at least last time I tried) there is a lot of room
to speed up arithmetic in function fields, which would be my first
priority.
Second, as a mathematical construction, I think that the
localizations A_S where A is a ring (e.g. UFD or PID) and S =
{p_1,...,p_n} is a set of primes/irreducibles, would be a useful
class to have.
In practice, it may occur that we don't really know in advance who are
the primes (because we are going to add later on news fraction with
some new primes in the denominator).
Well, that's just to point out a use case, in case someone gets some
clear idea how to handle this in a mathematically proper way, if at
all possible.
If one knows the primes inverted this would give the correct
structure in which to carry out these calculations.
Could you please post an appropriate ticket on the subject, with a
link to Michel's work? I am way too much of an amateur in this area
to give any good description of what should be done.
Thanks!
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Fractions with factored denominators
I have no time at the moment to look at this patch. I used it to do some computations which were completely undoable with the standard implementation of FractionField, and which became extremely fast using this implementation. So the lukewarm (to say the least) reaction by some very much discouraged me. Anyway here is a working link http://emis.uhasselt.be/~vdbergh/sage_patches/fraction_field_cache/ The beef is contained in a cython file factor_cache.pyx which acts as a wrapper around RingElement but which caches information about factorizations (to take mock gcd's and lcm's). FractionField_cache is an implementation of FractionField which uses factor_cache to cache factorizations of the denominator. You can turn this behaviour on and off using auto_reduce. It is quite likely that the files need to be adapted to work with the current version of Sage. Thanks for the pointer! Well, I am pretty much already overloaded myself, so I can will just vote +2 on this feature request for the moment. Best, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion and exception handling
Ideally, the coercion model just has the idea of an action, without having to specify where they can come from. In any case, it's clear there's some cleaning up to do, and I'll go in and do that (though not right now). Yup. That's why in MuPAD we were doing this declaratively; something like: declareSignature(operator.action, (QQ['x,y,z'], SymmetricGroup(3)), code_for_the_action) But the current model is way good enough for the moment. No need to refactor all at once :-) For the name change: +1 for me. Just please give a quick try of your patch with the ones of sage-combinat; I guess they should be compatible, but one never knows. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
Dear Robert, Hmmm. Quite an interesting discussion. Could anyone try to make some sort of synthesis of the different opinions expressed in this thread? On Thu, Mar 12, 2009 at 12:18:45PM -0700, Robert Bradshaw wrote: As mentioned, everything can be seen as a Z-module. This would mean that every time I implement _mul_ I would have to handle this case. It's much simpler to let _mul_ only worry about the ring (or group, or field...) multiplication. One can define _rmul_, _lmul_, ... for actions. +10 Just 2 cents: - I would reserve _lmul_, _rmul_ ... for actions which can be considered as some sort of multiplication by scalars, and using another name like the one you suggested for other actions - I see 10*bla as (potentially) involving two independent things: coercion and multiple dispatch For whatever it's worth, I had started writing a draft of paper on the coercion (= implicit conversion) and multiple dispatch mechanism I had implemented in MuPAD: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/Papers/2007-12-13-Overloading.tex?view=markup Strangely enough, I lost part of my motivation for working on this shortly after :-) Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: element of integermod is element of integer?
On Mar 12, 2009, at 8:47 PM, Nicolas M. Thiery wrote: Dear Robert, Hmmm. Quite an interesting discussion. Could anyone try to make some sort of synthesis of the different opinions expressed in this thread? On Thu, Mar 12, 2009 at 12:18:45PM -0700, Robert Bradshaw wrote: As mentioned, everything can be seen as a Z-module. This would mean that every time I implement _mul_ I would have to handle this case. It's much simpler to let _mul_ only worry about the ring (or group, or field...) multiplication. One can define _rmul_, _lmul_, ... for actions. +10 Just 2 cents: - I would reserve _lmul_, _rmul_ ... for actions which can be considered as some sort of multiplication by scalars, It is. The semantics for _rmul_ and _lmul_ are that the other element is guaranteed to be a scalar (i.e. a member of your basering). and using another name like the one you suggested for other actions - I see 10*bla as (potentially) involving two independent things: coercion and multiple dispatch Yep, though in my mind they're a bit more intertwined (e.g. for a \in Z, b \in QQ[x], one can do a*b by doing a coercion then an action, b._lmul_(QQ(a)). For whatever it's worth, I had started writing a draft of paper on the coercion (= implicit conversion) and multiple dispatch mechanism I had implemented in MuPAD: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/ trunk/MuPAD-Combinat/Papers/2007-12-13-Overloading.tex?view=markup Strangely enough, I lost part of my motivation for working on this shortly after :-) I'll take a look. I've been intending to write this up as a paper too, but haven't found the time yet. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
