[sage-devel] Sage compilation
I'm been unable to compile Sage on my MacOS laptop (Monterrey, x86 intel) I've tried installing all homebrew packages requested, but it tends to still not find them (path problem?). I switched to using conda, following the directions here: https://doc.sagemath.org/html/en/installation/conda.html but it fails with the error message below (another path problem?). The config log file is attached. Any suggestions would be appreciated. --David Kohel Checking whether SageMath should install SPKG gmp... checking gmp.h usability... yes checking gmp.h presence... no configure: WARNING: gmp.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: gmp.h: proceeding with the compiler's result checking for gmp.h... yes checking gmpxx.h usability... yes checking gmpxx.h presence... no configure: WARNING: gmpxx.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: gmpxx.h: proceeding with the compiler's result checking for gmpxx.h... yes checking for library containing __gmpq_cmp_z... -lgmp configure: will use system package and not install SPKG gmp checking absolute name of ... checking for gmp.h... (cached) yes configure: error: failed to find absolute path to gmp.h despite it being reported found -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/86561d45-63e9-69fb-9361-4142fa731a9d%40univ-amu.fr. This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Sage configure 9.7.beta1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --prefix=/Applications/anaconda3/envs/sage-build ## - ## ## Platform. ## ## - ## hostname = bunyip.home uname -m = x86_64 uname -r = 21.5.0 uname -s = Darwin uname -v = Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 /usr/bin/uname -p = i386 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = Mach kernel version: Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 Kernel configured for up to 4 processors. 2 processors are physically available. 4 processors are logically available. Processor type: x86_64h (Intel x86-64h Haswell) Processors active: 0 1 2 3 Primary memory available: 16.00 gigabytes Default processor set: 511 tasks, 2100 threads, 4 processors Load average: 13.69, Mach factor: 0.29 /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /Applications/anaconda3/envs/sage-build/bin PATH: /Applications/anaconda3/condabin PATH: /usr/local/opt/texinfo/bin PATH: /Library/Frameworks/Python.framework/Versions/3.9/bin PATH: /Users/kohel/.nvm/versions/node/v8.17.0/bin PATH: /usr/local/opt PATH: /Library/Frameworks/Python.framework/Versions/2.7/bin PATH: /usr/local/texlive/2019/bin/x86_64-darwin PATH: /usr/local/bin PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/sbin PATH: /sbin PATH: /Library/TeX/texbin PATH: /usr/local/go/bin PATH: /Library/Apple/usr/bin PATH: /Applications/Magma PATH: /Users/kohel/bin PATH: /usr/local/go/bin ## --- ## ## Core tests. ## ## --- ## configure:4334: checking for a BSD-compatible install configure:4402: result: /usr/bin/install -c configure:4413: checking whether build environment is sane configure:4468: result: yes configure:4614: checking for a thread-safe mkdir -p configure:4653: result: config/install-sh -c -d configure:4660: checking for gawk configure:4690: result: no configure:4660: checking for mawk configure:4690: result: no configure:4660: checking for nawk configure:4690: result: no configure:4660: checking for awk configure:4676: found /usr/bin/awk configure:4687: result: awk configure:4698: checking whether make sets $(MAKE) configure:4720: result: yes configure:4749: checking whether make supports nested variables configure:4766: result: yes configure:4909: checking whether to enable maintainer-specific portions of Makefiles configure:4918: result: yes configure:4938: checking whether make supports the include directive configure:4953: make -f confmf.GNU && cat confinc.out this is the am__doit target configure:4956: $? = 0 configure:4975: result: yes (GNU style) configure:5005: checking for x86_64-apple-darwin13.4.0-gcc configure:5032: result: x86_64-apple-darwin13.4.0-clang configure:5301: checking for C compiler version configure:5310: x86_64-apple-darwin13.4.0-clang --version >&5 clang version 13.0.1 Target: x86_64-apple-darwin13.4.0 Thread model: posix InstalledDir: /Applica
[sage-devel] Re: Weber polynomials
Hi, To extend beyond a pre-computed database, I suggest linking the cm library of Andreas Enge: http://www.multiprecision.org/index.php?prog=cm Pari has implementation of the weber function, but I think this (cm) should be the reference implementation, in the framework of standard mpc/mpfr libraries. In the same direction, it would be desirable to interface the library cmh for the genus 2 analogs: http://cmh.gforge.inria.fr/ Best, David On Saturday, March 5, 2016 at 1:22:09 PM UTC+1, Ибкс Спбпу wrote: > > Greetings! > > We are the students of Peter the Great St. Petersburg Polytechnic > University, Information Security department (Russia, St. Petersburg). > During the stuyding of Algebraic Geometry we use free mathematics software > system SAGE. For completing our lab "Elliptic curve generation" we had to > use Weber Polynomial. We couldn't find a built-in function of Weber > Polynomial. So we realized one and we suggest it to be included in SAGE. > > Is it possible? > Thank you in advance for your answer. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Catalog of algebras: the definition of an algebra
Hi All, I think it would be a good idea to have a subcategory of associative algebras (and inheritance of classes from an associative class). Morphisms need to know to check associativity. On the other hand, I was convinced years ago (by an argument of Bergman at Berkeley) that algebras should be unital. A non-unital algebra can be embedded in a universal unital algebra, such that the non-unital object is a two-sided ideal. In Magma, I find it awkward that the algebras include the ideals, and there is no class (type in Magma) to know whether an algebra admits a morphism from its base ring or is just a module. Consequently Ideals as objects of study is essentially absent in Magma. E.g. ideals over a number ring are hacked as elements of a (fractional) ideal group or ideal monoid, but do not support elements. Peter argues that certain Hecke algebras are non-unital, but should these not be viewed as ideals? I would be tempted to have associative algebras inherit from unital algebras, and to view non-unital algebras as ideals. The (important) case of Lie algebras is worth considering, whether it is too restrictive to assume that a general Lie algebra is an ideal over a universal algebra. This would conflict with the usual definition (a Lie algebra over R has no embedding of R). Moreover, should the * operation be the Lie bracket, or be reserved for its envelopping algebra? (Using [x,y] would be nice but would conflict with lists.) With * as the algebra operation, do the special properties of Lie algebras (e.g. the set-theoretic inclusion in an envelopping algebra is not a homomorphism) suggst they should be implemented outside the class and categorical hierarchy of algebras. To me, the main question is whether one needs morphisms between Lie algebras and associative or non-associative algebras, and (in practice) what code can be shared between the associated classes. It seems clear that Lie algebras need to inherit from general (non-unital non-associative) algebras, but the relation with other algebras needs some consideration. The unital condition is important because it determines whether it is reasonable to coerce an element of the base ring, or dismiss such a request without solving a potentially hard question whether there exists a canonical embedding. For a unital algebra, we want to require an efficient canonical coercion from the base ring, whereas for ideals, either a not implemented error or a potentially expensive but correct algorithm would be acceptable and expected. In short, to the extent possible I would impose the unital condition as widely as possible, and develop the ideal theory of algebras in its own right. Cheers, David On Wednesday, May 6, 2015 at 10:21:58 PM UTC+2, Peter Bruin wrote: Hello, Travis Scrimshaw wrote: On #15635, we are trying to decide whether we want non-associative algebras to be included in the catalog of algebras. For a general mathematical software system such as Sage, I think it is overly restrictive to impose the rule that algebras are associative. There are too many interesting non-associative algebras (such as Lie algebras), or non-unital algebras (such as certain Hecke algebras) to make associativity part of the definition of an algebra. Moreover, it is in my opinion an unfortunate choice of terminology if non-associative algebras are not in general algebras. The argument against including them is most people think of algebras as being associative (and maybe even unital), and as such, might surprise people when they come across the non-associativity in their computations. Anyone has the right to think of algebras as being associative, just like many people think of vector spaces as being finite-dimensional, say. This is a bit like books or papers using the convention that all the algebras that one considers are assumed to be associative (or that vector spaces are assumed to be finite-dimensional, etc.) However, it feels wrong to elevate such conventions to definitions. However, the community was at one point considering renaming magmatic algebras into algebras and having to specify the associative axiom explicitly. I would be in favour of this. When finite-dimensional algebras over a field were implemented in #12141, we explicitly included non-associative algebras. In case the user already knows that his algebra is associative, he can pass a flag assume_associative (default: False) to avoid a lengthy computation to check this. Peter -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit
[sage-devel] Re: [sage-algebra] Re: Lattice, RealLattice, ComplexLattice, VectorSpaceLattice: a bikeshed question
Dear all, First of all, in the context of modules there should be no confusion about the terminology lattice (as opposed to a lattice poset in combinatorics). There is little doubt that modules with bilinear pairings are ubiquitous in mathematics, but precisely that poses problems with differing conventions for the differing domains of mathematics. Before someone goes too far in reinventing the wheel, I should point out that a datastructure for lattices already exists since 2007-2008. Around this time (at a Sage days), I think I also looked into linking in some lattice reduction algorithms (LLL BKZ), but they never migrated upstream to Sage. The concept of a quadratic module (or bilinear module), encompasses definite, indefinite, isotropic and non-isotropic lattices, whereas the terminology lattice depends on the interests of the author and is often restricted to positive definite quadratic modules, possibily with a fixed embedding in RR^n. A = MatrixSpace(ZZ,2)([[1,0],[0,-1]]) M = FreeModule(ZZ,2,inner_product_matrix=A) M.ambient_vector_space() B = M.basis() M.gram_matrix() M0 = M.submodule([ M.0 ]) M1 = M.submodule([ M.1 ]) M0.inner_product_matrix() M0.gram_matrix() The definitions of inner product matrix and Gram matrix are that the inner product matrix A is the Gram matrix of the ambient module (supposing that a module M is embedded in and ambient free module R^n), and the Gram matrix is the V A V^t with respect to the basis of M. Assuming R is an integral domain with field of fractions K, then the ambient vector space is the tensor product with K (with canonical embedding), which is a quadratic space. Inside this space one can carry out intersections and sums of (sub)lattices. The FreeModule constructor gives the default Euclidean inner product matrix (the identity): sage: M = FreeModule(ZZ,3) sage: M.inner_product_matrix() [1 0 0] [0 1 0] [0 0 1] sage: L = M.submodule_with_basis([ M([1,1,1]), M([1,-1,0]), M([1,0,-1]) ]) sage: L.gram_matrix() [3 0 0] [0 2 1] [0 1 2] So there will be no surprises if a user creates a FreeModule without specifying an inner product. It comes with the default dot product as inner product. There is a convention problem of where to divide by 2 (when 2 is not a zero divisor) in this construction. If q: V - V is a quadratic form, then one can define u,v = q(u+v) - q(u) - q(v) in which case one recovers q(u) = 1/2 u,u. Other authors prefer to put the 1/2 in the definition of u,v so that q(u) = u,v. If one works only with the bilinear form u,v determined by v A v^t, then then we avoid addressing this choice of convention. (However, if one defines a norm or length, this is usually defined as ||u|| = sqrt(q(u)), and the normalization convention changes this value by a sqrt(2).) At present, I personally don't think there is a need to introduce new datatypes to represent the various quadratic modules (over PID's) or quadratic spaces (over fields). Someone could just write a Lattice function which makes a call to FreeModule with the correct syntax, so that users find the existing constructor. The question of categories arises, however, since the usual choice of morphisms of quadratic modules (and quadratic spaces) are the isometries (morphisms preserving the inner product). There should be a category of quadratic modules in which it is checked that the morphisms preserve this additional structure. In my view, the functionality that is missing is determining if a given ZZ-module (extend to your favorite subrings of RR if you like) is (positive) definite, isotropic, etc., L.is_definite() L.is_positive_definite() L.is_isotropic() then the application of LLL, BKZ, or other reduction algorithms (the output should be a module with basis having the new reduced basis, as a submodule of the input module). There are also indefinite versions of LLL which could apply to indefinite lattices. Note that the pari LLL function doesn't return the LLL reduced basis, but the transformation matrix U determining the isometry with the LLL reduced object. This is linked in somewhere in Sage, and the output is not what one expects. Regarding the various combinations of rings, one might define concepts of exact and integral lattices. Here being exact is an implementation-side question, and there are two: 1. Is the specification of the basis elements exact (e.g. the basis elements of M might be given in RR^n to some approximation with precision). An example is the Minkowski lattice of an order or ideal in a number field. The coordinates do not have exact representations, but the inner product [matrix] is exact [= the identity]. 2. Is the specification of the pairing (e.g. in a real field) exact? An example is the height pairing on an elliptic curve E/K (= a number field); on E(K)/E(K)_tors, the height is known only to some fixed precision. The two examples given above allow the precision to be extended at will (for some cost), but in both, testing for zero in the codomain
Re: [sage-devel] Re: [sage-algebra] Re: Lattice, RealLattice, ComplexLattice, VectorSpaceLattice: a bikeshed question
Hi Martin, I asked about it because it seems no one seems to have touched those data structures in years and because I failed to interact with it the way I wanted. In my world I think of a lattice as given by a basis and my bases are over the integers. I failed to construct that. However, revisiting that, it seems I was an idiot and I merely need: sage: ZZn = FreeModule(ZZ, 10) sage: B = random_matrix(ZZ, 10, 10) # - my basis sage: L = ZZn.submodule(B) I guess I could move my new class (specialising to ZZ) at http://trac.sagemath.org/ticket/15976 to fit into there and add a short-hand constructor? Probably the constructor you want (to preserve the data of B) is: sage: L = ZZn.submodule_with_basis(B) and the LLL or BKZ reductions should use this constructor to return a submodule (equal to the original) with the preferred reduced basis. I had hoped that someone would pick up the quadratic module class and add functionality. In Magma the lattice class was (in my view) too rigid in not admitting lattices which were anything but positive definite, and -- even over the integers -- in order to implement local invariants (over ZZ_p) using the general free modules class. This would be fine if lattices were a special subtype of the general class, but they don't (or didn't) behave the same as other free modules. --David -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [sage-algebra] Re: Lattice, RealLattice, ComplexLattice, VectorSpaceLattice: a bikeshed question
On Friday, April 4, 2014 12:36:02 PM UTC+2, Volker Braun wrote: On Friday, April 4, 2014 11:19:11 AM UTC+1, Martin Albrecht wrote: existing one. However, in my case it would seem natural to improve the basis during the lifetime of an object. IMHO that is always going to cause tears later on as the end-user isn't going to be aware that this modified all references to the lattice. The only downside of returning new objects is memory, and I'm pretty sure your problem runs of CPU before RAM. If you don't like that your lattice has a built-in basis then you could return new BasisOfLattice (say) objects. Indeed, I think changing the basis of a lattice in place will break the expected interface of users or programs for that lattice. One could have a function such as LLL_basis() if you want a light function which avoids creating a new object, or possibly cache a reduced basis, which could be accessed later (but then there is the issue of the different parameters input to LLL or other algorithms Minkowski, BKZ, etc. which could produce different concepts or levels of reduction). But the basis which is used for the interface to the module should not change. --David basis -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Products of permutations use nonstandard order of operation
Hi, I also strongly support both left and right actions, with the syntax Left action: s1(s2(x)) == (s1*s2)(x) Right action: (x^s1)^s2 == x^(s1*s2) Currently the left (functional) notation is implemented in Sage with the right order of application: s1(s2(x)) == (s2*s1)(x) is True. This needs to be either accepted or deprecated in preference to a new right operator. Magma implements only the right action with ^ notation, and GAP also (only?) implements the same. Attention: Unless I'm mistaken, Magma does something bad with operator precedence in order to have x^s1^s2 evaluate to (x^s1)^s2 rather than x^(s1^s2) -- the latter is defined but not equal. The significant change is that a left acting symmetric group will have its multiplication reversed. Implementing the right action involves some thought, since it must be a method on the domain class. Either the domain must be a designated class of G-sets, which knows about its acting group G, or for each object with a natural permutation action, one needs to implement or overload ^ on a case-by-case basis (e.g. integers, free modules, polynomial rings and other free objects [action on the generators], etc.). Please correct me if there is another way to drop through and pick up an action operation on the right-hand argument. Defining the (left or right) action by * would probably be a nightmare with the coercion model, since it is handled as a symmetric operator. Some thought needs to be given to the extension from a group action to a group algebra action. The ZZ-module structure of an abelian group with left G-action would give an argument to admitting * as a possible (left) notation for this operation, despite the obvious headaches. The ^ notation would give a compatible extension of the natural ZZ-module structure acting on the right on a multiplicatively represented abelian group. As an example, in number theory, when G is a Galois group Gal(L/K), it is typical to left K[G] act on the left on L by *, and ZZ[G] act on the right on multiplicative group L^*. Although G is not a permutation group in this example, we want to set up the framework for G-sets to admit these natural actions. The left action is problematic, since the coercion model is susceptible to building L[G] and carry out * with the trivial G-action on L. To avoid this, L needs to be identified as an object in the category of K-modules (with G-action) rather than a K-algebra. Until someone comes up with a well-developed and coherent model for treating the operator * in general G-actions, I would avoid any implementations using this operator with permutation actions. --David -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Fwd: [sage-algebra] Boundary cases
In a ring of characteristic 0, it seems that 0^0 (= 1) is well-defined. In my view this is correct. It makes it much simpler to define the matrix (e.g. FF a finite field): G = matrix([ [ a^i for a in FF ] for i in range(k) ]) However, in finite fields or any of the the following rings, 0^0 gives an error: FF.w = FiniteField(32) FF = FiniteField(31) PF.x = PolynomialRing(FF) The correct behaviour can be faked in an isomorphic ring which is a quotient of something in characteristic zero: PZ.x = PolynomialRing(ZZ) R = PZ.quotient_ring([x-1,31]) Here R(0)^0 (= 1) is fine. Is there any objection to reporting this as a bug and fixing it? --David -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Broken interators
1. For free abelian groups, the iterator doesn't enumerate any elements. sage: A = AbelianGroup(3) sage: A Multiplicative Abelian Group isomorphic to Z x Z x Z sage: for a in A: : print a : The bug is in A.__iter__: invs = self.invariants() for t in mrange(invs): yield AbelianGroupElement(self, t) since invs is [0,0,0] the mrange is empty. 2. For free ZZ-modules the iterator doesn't enumerate all elements. sage: M = ZZ^3 sage: for v in M: print v if sum([ abs(v[i]) for i in range(3) ]) 8: break : (0, 0, 0) (1, 0, 0) (-1, 0, 0) (2, 0, 0) (-2, 0, 0) (3, 0, 0) (-3, 0, 0) (4, 0, 0) (-4, 0, 0) (5, 0, 0) (-5, 0, 0) (6, 0, 0) (-6, 0, 0) (7, 0, 0) (-7, 0, 0) (8, 0, 0) (-8, 0, 0) (9, 0, 0) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Numbers of bounded height
This would be interesting also to have an iterator for [all] elements of unbounded height, in number rings and fields. See my post regarding the broken iterator on ZZ^n (and the independently broken iterator on isomorphic free abelian groups). --David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Poll: Making sage-mode a standard package
[X ] Make it standard at some point in the near future. Argument: Sage includes many interfaces to standard software. This includes software that the majority users will never use in their lifetimes, e.g. the big M's (unless at a mathematics department or institute where there exists a license) and numerous open source software libraries and systems. Emacs is a standard open source tool, and an interface (albeit from emacs to sage) seems reasonable. I also thought that this was standard in the sense that it was one file which one could find (like sagetex.sty) in the sage distribution. I would like to find it there if I need to update my system. --David On May 30, 7:44 am, Ivan Andrus darthand...@gmail.com wrote: On May 25, 2012, at 11:24 PM, Ivan Andrus wrote: Dear all sage and emacs (or not) users, Since I've been working on sage-mode a bit recently I thought I would look at trac and try to fix any sage-mode related bugs there. I found #2666 which wants to make sage-mode a standard package. If people want this then I'd like to get it done. But if not then I'd like to close the ticket. Personally, I'm not sure it should be standard since people who wish to use it still have to add something to their .emacs, and hence they still need to know about it and take some action. However, I'm open to being persuaded. The spkg is 272K. [ ] Make it standard at some point in the near future. [ ] Don't make it standard and close the ticket. [ ] Don't make it standard now, but don't close the ticket. The results are fairly close (I guess everyone has responded who wants to). We have 3.5 votes for making it standard, 3.5 for not, and 1 for thought it was standard, which I assume means make it standard. So I guess I'll keep the ticket open and work towards making it standard unless anyone else would like to weigh in. -Ivan [X] Don't make it standard and close the ticket. Justin C. Walker David Roe Dima Pasechnik Benjamin Jones -- initially, see below [X] Make it standard at some point in the near future. Nicolas M. Thiéry Keshav Kini Volker Braun Benjamin Jones -- if it would improve maintenance, see above [X] I thought it was already standard, and am surprised to hear that it isn't. William Stein -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Deleting depreciated is_functions
Hi, 1. (On Sage syntax): For the record, there are some reasons why ZZ in Fields doesn't (and perhaps shouldn't) make sense: Fields is a function not the category it returns: sage: Fields class 'sage.categories.fields.Fields' sage: Fields() Category of fields I think a student learning Sage should have a first session in which they learn that every function takes parentheses, and that there are some pre-defined objects at their disposal. The ring ZZ and field QQ are pre-defined for the ease of the user, and are not the same beasts. Is is true that ZZ(n) is valid, but is meant to create an integer, e.g. ZZ(1). For empty argument it defaults to ZZ(0), which allows '5/1 in ZZ()' to give an error in a confusing place. This should not be confused with the category constructors VectorSpaces, Fields, etc. In the same vane as pre-defining ZZ and QQ, one could pre-define some defaults Flds = Fields() and Vect = VectorSpaces() globally, but unlike ZZ, QQ, RR, and CC, I think the naive or first-time user does not usually need to have these categories at hand or need to know anything about categories to use Sage. Doing some magic to make 'QQ^2 in VectorSpaces' work might just do injustice to first-time users, since it defers the realization that they just made a typo -- unless VectorSpaces is no longer a Python class: sage: VectorSpaces class 'sage.categories.vector_spaces.VectorSpaces' rather an instance of the category of vector spaces. 2. (On is_Name): Regarding is_PrimeField(F) and ilk -- remove them: instead the syntax F.is_prime_field() is (or should be) implemented: sage: F = FiniteField(2) sage: F.is_prime_field() True sage: F.a = FiniteField(8) sage: F.is_prime_field() False for all fields. Where is is not, or incorrect (!): sage: K.a = NumberField(x-2/3) sage: K.is_prime_field() False this should be fixed. And someone should certainly create a trac item to for this bug. --David On Mar 28, 11:00 am, Keshav Kini keshav.k...@gmail.com wrote: Florent Hivert florent.hiv...@lri.fr writes: sage: ZZ in Fields False sage: ZZ in Fields() False sage: QQ in Fields True sage: QQ in Fields() True I don't pretend to understand why this is the case :) But maybe it's better if we tell new users to use `ZZ in Fields` instead of `ZZ in Fields()`, to minimize confusion...? Or maybe doing so would be misleading in ways I haven't realized? It works because Nicolas did the work (Ticket #9469 Category membership, without arguments, Merged in: sage-5.0.beta6). Awesome! :D Thanks, Nicolas! I think you are right saying that we should teach QQ in Fields to beginner rather than QQ in Fields(), except that if I remember correctly, there is a performance issue for the short notation. Also they don't have the exact same meaning. The difference is apparent in sage: QQ^2 in VectorSpaces(QQ) True sage: QQ^2 in VectorSpaces True sage: QQ^2 in VectorSpaces(CC) False Note that they are still some mathematically surprising answers: sage: QQ in VectorSpaces(QQ) # bootstrap problem False sage: QQbar in VectorSpaces(QQ) False Interesting... So the answer is: thinks are going better in each new Sage release. That is all one can hope for :) -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: categories and element classes
Hi Alex, This is a historical legacy of a heavy-handed attempt by William and me to implement schemes from the book (aka Hartshorne): sage: A = AffineSpace(2, ZZ) sage: p = A(0, 0) sage: p.parent().category().element_class class 'sage.categories.category.Schemes_abstract.HomCategory. element_class' sage: type(p) class 'sage.schemes.generic.morphism.SchemeMorphism_point_affine' It is mathematically correct to say that a point is a section from the base scheme (often a field), whose coordinates are the values of the coordinate functions. However, in most working settings, you just want a list of coordinates over a ring or field. This is more efficient, more intuitive, and easier to work with. In the worst case you need multiple lists of coordinates which glue together where the base ring is not a PID or is a more general scheme. This is the standard parent-element standard used by Sage (elsewhere) and Magma. (This is a subjective point which I will argue:) Such elements are not described by a category framework (which deals with objects, morphisms, and functors). Elements are practical things which we often demand of objects in order to evaluate maps between objects. They often do have a categorical interpretation by their identification with morphisms from a free object (if such exists), but in retrospect equating the set of elements X(S) with Hom(S,X) was a bad idea. We don't implement set, module or ring elements this way, and shouldn't for schemes either. Instead, ditch this, create an elements class in the standard parent-element dichotomy and have constructors to turn elements of X(k) into morphisms in Hom(Spec(k),X). This was already done, I believe, for elliptic curves precisely because the beautiful Grothendieck theory of points as morphisms was too slow to be of any use; coordinate access by evaluation of the composition of a morphism S - X with a coordinate function just doesn't cut it. The general theory is needed for X(S) but the line between efficient elements and their interpretation as morphisms can be made by the choice of users: X(k) or X(R) for a field k or ring R will be implemented differently from X(Spec(k)) and X(Spec(R)). --David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: All known bugs in Sage silently producing wrong answers
Hi,
Here's one:
sage: K.a = NumberField(x-2/3)
sage: K.is_prime_field()
False
The code is just a bit too naive:
Source:
def is_prime_field(self):
r
Return True if this ring is one of the prime fields `\QQ` or `
\GF{p}`.
...
return False
i.e. is probably just isn't implemented for number fields.
Once one realises that the default function returns False if it is
not
defined in a subclass, it is possible to find other examples:
sage: P.x = QQ[x]
sage: R.a = P.quo(x-1)
sage: R.is_field()
True
sage: R.is_prime_field()
False
--David
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Coefficients of univariate polynomials
On Tue, May 10, 2011 at 10:37 PM, Mike Hansen mhan...@gmail.com wrote: On Tue, May 10, 2011 at 6:52 PM, Rob Beezer goo...@beezer.cotse.net wrote: OK, thanks for the explanation, Tom. p.exponents() was the missing piece I did not have. It would probably make sense to have p.monomials() method to be consistent with the multivariate case: sage: R.t,s = QQ[] sage: p = t^4 + 8 sage: p.coefficients() [1, 8] sage: p.monomials() [t^4, 1] sage: sum(c*m for c,m in zip(p.coefficients(), p.monomials())) t^4 + 8 +1 +1 (with documentation with benchmarching -- p.monomials() might be more expensive than the analogous loop over p.exponents()). p.coeffs() might be better off renamed to something like all_coefficients or dense_coefficients or I suggest deprecation and reference in p.coefficients to p.list. I use p.coeffs() pretty often. Perhaps p.coefficients should take an additional argument: p.coeffs could be an alias to p.coefficients(dense=True), and get deprecated. +1 to deprecation I'm opposed to different behaviour for p.coeffs and p.coefficients, which can only be a source of confusion. As long as p.list() is documented in p.coefficients() then I'm neutral on adding the dense keyword -- like p.coeffs() [see docstring] it is likely to be slower, and people are likely to use it. I was at first surprised by p.coefficients but it seems useful, efficient, and compatible with sparse and dense representations; p.list() is completely standard Python syntax. --David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: questions about sage/databases/*
Hi, 1. It seems to me that kohel.py is broken and has not been used in the past 5 years or so. Then I suppose we should remove it, unless David Kohel has objections. Go ahead and remove it. Cheers, David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: mathematically correct eigen* methods of matrices.
Hi, Backwards compatibility or not, I consider this either a bad design or a bug: sage: M = Matrix([[1,-1],[1,0]]) sage: f = M.minimal_polynomial() sage: f.roots() [] sage: M.eigenvalues() [0.5? - 0.866025403784439?*I, 0.5? + 0.866025403784439?*I] First of all, why return roots in some arbitrary field? I don't agree that this is the most natural result for first year calculus or linear algebra. Many will only consider real solutions to be valid. Certainly an algebraist will expect solutions over the given base ring. There is also the lack of consistency with sqrt(3), which returns a symbolic ring element - why not the same for eigenvalues? Over a finite field, one should ask if Sage is consistent: sage: FF = FiniteField(Integer(5)) sage: M = Matrix(FF,[1,-1],[1,0]]) sage: M.eigenvalues() I get a 'Not implemented error' -- but this should be implemented and should give something consistent. In a general system, I can't see anything reasonable that one can do in general other than returning the roots of the characteristic polynomial in the base ring. I find the syntax: M.eigenvalues(ring=None, extend=False) perfectly well-defined. Since extend=True will fail for most rings, since a natural algebraically closed field containing the base ring is unlikely to exist or be implemented in Sage, so I don't think that default can be extend=True. So I must vote -1 to default extend=True. On the other hand, I think M.eigenvalues(CC) gives a simple syntax for linear algebra students, and also lets them do M.eigenvalues(RR) in order to distinguish between real vector spaces, complex ones, or different behaviors of these spaces. I'm not sure all teachers and students would prefer CC over RR -- in my experience in Sydney complex numbers only existed for advanced first year students, and for students in the ordinary track the real numbers were enough (one could argue that such relative mathematics should not exist but there are still different teaching needs). When studying or teaching real solutions for a problem, one needs a simple syntax for equation solving over RR or CC. I would hope that Sage could keep a generic syntax for linear algebra which doesn't require knowing that one behavior will result for matrices over the integers, rationals, or reals, a different one for linear operators, and a completely different set of behaviors when the base ring is a finite field, number field, power series ring, or function field. I would argue that one should always ask first whether a given function makes sense in a general context, and not implement something which conflicts with the function in the general context. --David On Jun 14, 7:14 pm, Rob Beezer goo...@beezer.cotse.net wrote: Miguel, Having read #8974 carefully, I could see the default for endomorphisms going either way. My main concern is that matrices follow practice and default to providing eigenvalues (and eigenvectors) outside the base field. Endomorphisms could default to behave identically to matrices, or they could respect the notion of being functions and only return proper elements of the domain and range, as you have argued in regards to your own teaching. But with options available for matrices and endomorphisms, individual opinions/tastes can be accomodated. Thanks for bringing the discussion to sage-devel. Rob -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Latest Magma fails to load
Hi, I solved this problem by changing the Magma script to not search in the DYLD_LIBRARY_PATH (in $ROOT/magma): #DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$ROOT # original line DYLD_LIBRARY_PATH=$ROOT # hard code to use libgmp.3.dylib in $ROOT Similarly, if you want to use another libgmp3 (version 9.0.0 or later according to Magma' error message), then change this line or make a symbolic link here. I was of mixed opinion whether this was a bug in Sage or Magma, and decided that it was better to solve it in Magma. --David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org To unsubscribe from this group, send email to sage-devel+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[sage-devel] Re: SAGE in abstract algebra class
Hi Nicolas, The list sage-nt was set up to have a lower volume and lower noise forum for sage-devel issues with mathematical (number theoretic) interest. I also don't track sage-combinat for similar reasons as John, and miss most of what passes on sage-devel due to the high volume. Maybe there should be a sage-algebra list (as John suggested) for discussions of algebraic and categorical topics of mathematical interest. I'm likely to miss discussions on sage-devel in between discussions of compiler and architecture problems. Cheers, David On Mar 10, 5:31 pm, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Wed, Mar 10, 2010 at 09:59:41AM +, John Cremona wrote: To me combinat is short for combinatorics, which is different from what I do (number theory, and more generally algebra). I certainly did not realise when the combinat people joined Sage how useful they and what they do would be for people like me! (This is supposed to be a compliment). I appreciate the compliment :-) But I get the impression that quite a lot of discussion about design in this area is happening in sage-combinat, which it never occurred to me to join (since I don't do cominatorics). Would it be better to have another discussion group for (say) sage-algebra? Or is it impossible to separate what I think of as algebra with the rest of what goes in in sage-combinat? You are perfectly right. It is some sort of deviance that, since we so much need the category stuff for (algebraic) combinatorics, I tend to discuss anything related on sage-combinat. The line is fine, but in that case, I shall instead run the discussion on sage-devel, and just crosspost a notice on sage-combinat. Cheers, Nicolas -- Nicolas M. Thi ry Isil nthi...@users.sf.nethttp://Nicolas.Thiery.name/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: InfinitePolynomialRing is -- very -- slow
Rather I would say that sparse should be the default: P.x = InfinitePolynomialRing(QQ, implementation=sparse) Moreover, this syntax (and for gens, etc.) is inconsistent with PolynomialRing. The syntax: PolynomialRing(ring, integer, sparse=True) would be a more coherent, where integer=Set(ZZ) would give an infinite polynomial ring. --David On Nov 26, 9:43 am, Robert Bradshaw rober...@math.washington.edu wrote: On Nov 26, 2009, at 12:35 AM, Florent Hivert wrote: Hi Nathann, For Linear Programming, I need to create plenty of symbolic variables which I use to represent linear functions To do it, I use the class InfinitePolynomialRing which lets me create them easily ( and it is really needed, as my colleagues often have to create Linear Programs using 1000~2000 variables. This is not a problem for the solvers, but Sage does not like it : To understand my problem, just try this code : X.x = InfinitePolynomialRing(RR) sum([x[i] for i in range(200)]) Don't you think it is a bit long just to generate a sum ? I have to admit I do not know how this class is coded, and the slowness may be required for applications different from mine.. But wouldn't there be a way to speed this up ? If not, do you know of any way to generate many symbolic variables ( they do not need to be polynomial, just linear in my case ) ? This is indeed a problem. I think I know the cause... Each time a new variable is created, the ring itself is somehow changed. Therefore for each new variable in your sum, there is a big computation which convert the former sum to the new ring. Though this could be improved by using a similar trick than doubling the size of a list when appending element, I'm not sure that's what we want. I think this makes perfect sense...I'm actually surprised it's not implemented that way already. In the mean time. I have the following workaround: Just start by declaring your last variable: If one knows how many variables one needs ahead of time, than what's the advantage of using the InfinitePolynomialRing over a finite one of the right size? - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage-4.2
I've verified that I can build sage-4.2 on my laptop running 10.6, but that singular fails (with similar errors reported in the above logfile) on two recent Mac desktop machines with the latest XCode. A pending software update to 10.6.1 (requires a reboot) could explain the difference, but the specific documentation for the update doesn't suggest it. --David --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.2
Hi, I just verified that my home Mac desktop is 10.6.1 (and current for all Mac updates). I need to kill all of my jobs to update my office machine, so I deferred this step at work. However this is not the source of the problem. Instead it seems that the problem is due to running MacOSX in 64-bit mode. According to the application 32- or 64-bit Kernel Startup Mode Selector, 64-bit mode is not supported by my laptop, whereas I set the two desktops to 64-bit mode. In the singular configure file, I find: liki10:/usr/local/sage-4.2/spkg/build/singular-3-1-0-4-20090818.p1/src $ ./configure loading cache ./config.cache checking uname for singular... unknown configure: error: Unknown architecture: Check singuname.sh Running singuname.sh I find: liki10:/usr/local/sage-4.2/spkg/build/singular-3-1-0-4-20090818.p1/src $ ./singuname.sh x86_64-Unknown On my 32-bit mode laptop it reports ix86Mac-darwin. So it seems that the singuname.sh file is not able to correctly parse the output of `uname - a` in 64-bit mode: Darwin liki10 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 Compare this to the 32-bit output: Darwin iml26 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386 So I think it should be easy to patch singuname.sh to get past the configure error. --David --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.2
Hi, What is the current status of MacOS 10.6 compatibility? I just downloaded sage-4.2.tar to my desktop machine and compilation fails in the singular package (see below). I don't seem to have succeeded in compiling sage-4.1.2 on any MacOS 10.6 desktop although it seems to have compiled on my 10.6 laptop. All are running the same version of XCode. In particular, gcc -v gives gcc version 4.2.1 (Apple Inc. build 5646) I will try sage-4.2 on my laptop, but the README.txt only cites OS X 10.5 as officially supported: x86 Apple Mac OS X 10.5.x Nevertheless, I thought one of the goals was 10.6 support, so hoped this would work. Cheers, David sage-spkg singular-3-1-0-4-20090818.p1 21 Warning: Attempted to overwrite SAGE_ROOT environment variable singular-3-1-0-4-20090818.p1 Machine: Darwin liki10 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 Deleting directories from past builds of previous/current versions of singular-3-1-0-4-20090818.p1 Extracting package /usr/local/sage-4.2/spkg/standard/ singular-3-1-0-4-20090818.p1.spkg ... -rw-r--r--@ 1 root wheel 7645724 Sep 30 14:07 /usr/local/sage-4.2/ spkg/standard/singular-3-1-0-4-20090818.p1.spkg Finished extraction Host system uname -a: Darwin liki10 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:46:25 PDT 2009; root:xnu-1456.1.25~1/RELEASE_X86_64 x86_64 CC Version gcc -v Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable- checking --enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx- include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- -- host=x86_64-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) make[2]: *** No rule to make target `distclean'. Stop. rm: /usr/local/sage-4.2/local/bin/Singular*: No such file or directory creating cache ./config.cache checking uname for singular... unknown configure: error: Unknown architecture: Check singuname.sh Unable to configure Singular. real0m0.299s user0m0.112s sys 0m0.165s sage: An error occurred while installing singular-3-1-0-4-20090818.p1 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /usr/local/sage-4.2/install.log. --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Categories review: the last ones?
Hi, Glad to hear that Javier took up the last category files. I don't have a strong opinion whether OrderedSets (or Monoids) should have total or partial ordering. However, since there is a possible ambiguity, my preference is to not use OrderedX as an alias for either PartiallyOrderedX or TotallyOrderedX. Specifically for PartiallyOrderedSet, Poset is standard. Regarding a FreeModules category: in general the subset (or subcollection) of free objects in a category does not form a nice or natural category. The category should determine what structures the morphisms should preserve such as binary or unary operations like +, *, -, not, xor, . The morphisms should be implemented to respect this structure and ensure integrity of the category. Free objects play an important role in a category, but they are not preserved by taking kernels, quotients, or other standard constructions. They are the first (Sage/Python classes of) objects in the category on which morphisms (to any object in the category) can and should be implemented. The full category should contain all of the natural and interesting objects that one wants to study. Some objects X and Y may not have good computational models or we may not be able to created their elements, and similarly we may not be able to construct effective elements of Hom(X,Y) for all objects in the category. The various classes of objects should implement the free objects by special constructors (= functors from sets), but they don't fill out a nice category in themselves. For this reason, I don't think CategoryWithBasis (or more generally CategoryWith[Free]Generators) is a natural category -- unless the generators are structures intended to be preserved, as is the case with a category of pointed sets. Rather than having unnatural subcategories, one should have functions like Cat.is_free(X) or X.is_free(), then, if True, X.generators() or X.basis(), for identifying such objects and easily constructing their morphisms. Cheers, David --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Categories review: algebra_modules.py, monoid_algebras.py and groupoids.py
Hi Nicolas, If I understand what existed and what is proposed, then I vote for the category Groupoids() and no arguments. A standard definition of a groupoid in category theory is a category in which every morphism is an isomorphism. Thus it is possible that this was intended as a constructor for any such category (whose underlying objects are in some given set), but a multigraph would probably be a more precise input (and efficient representation). But there are many categories which might turn out to be groupoids, and it is unlikely that one constructor would suffice for their study. One still needs functors between categories to represent their morphisms (in the category Groupoids() of all groupoids). Those groupoids which do have a concrete representation (e.g. as a multigraph) and morphisms between them provide sufficient motivation to create the category Groupoids. The fact that each of its objects can be viewed as a category is an approach that can be explored later (if someone wants to build an effective framework for functors, natural transformations, etc.). The original code was set up to give a framework for category theory to organize mathematical constructs. The new category framework should be modular and flexible enough to delete unnecessary categories, or add a new one and experiment with its morphisms of functors from certain core categories. At present a constructor of a specific category, which happens to be a groupoid, is more of a motivating example for what one should be able to do rather than a core part of the categories framework. Cheers, David --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Category review: what's the category of a category?
What about the category of categories (with functors as morphisms)? --David --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: EllipticCurveIsogeny: problems with entering a kernel polynomial to E.isogeny(kernel)
Hi Jenny,
Since the base ring of E is QQ, what do you expect to get for an
input polynomial over Qt? A feature of Sage over, say, Magma,
is that the the tracebacks are long (allowing debugging).
Perhaps your entirely valid criticism is that the error in + is too
late: some checking that the base ring of the polynomial equals
the base ring of the curve (or that maps canonically to it) would
pick up the error at the correct point and returns a more
meaningful error message.
Another problem is that if I base extend to Qt, then isogeny is
no longer defined:
sage: Et = E.base_extend(Qt)
sage: Et.isogeny?
This seems to be a problem with the EllipticCurve constructor,
not isogeny:
sage: type(Et)
class
'sage.schemes.elliptic_curves.ell_generic.EllipticCurve_generic'
In particular, a line for rings.is_Field(x) needs to be added in here
to returns
an EllipticCurve_field:
if rings.is_Ring(x):
if rings.is_RationalField(x):
return ell_rational_field.EllipticCurve_rational_field(x,
y)
elif rings.is_FiniteField(x) or (rings.is_IntegerModRing(x)
and x.characteristic().is_prime()):
return ell_finite_field.EllipticCurve_finite_field(x, y)
elif rings.is_pAdicField(x):
return ell_padic_field.EllipticCurve_padic_field(x, y)
elif rings.is_NumberField(x):
return ell_number_field.EllipticCurve_number_field(x, y)
return ell_generic.EllipticCurve_generic(x, y)
Cheers,
David
On Sep 9, 10:51 am, J. Cooley j.a.coo...@warwick.ac.uk wrote:
Hi,
Here is an example:
sage: Qt = Frac(PolynomialRing(QQ,'t'))
sage: t = Qt.gen()
sage: R = PolynomialRing(Qt,'X')
sage: X = R.gen()
sage: k2 = X^2 -732*X + 94752
sage: E = EllipticCurve('11a1')
sage: E.isogeny(kernel=k2, model = minimal)
Result: horrible, horrible error!
Thanks,
Jenny
--~--~-~--~~~---~--~~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an 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: verifying visual look of ReST in docstrings
Hi William, Thanks (to John Palmieri et al), such a feature was requested at Sage Days 16. Is there an interface in the command-line version or a command-line call on a file that doesn't request require starting up Sage? Cheers, David --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an 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: verifying visual look of ReST in docstrings
I would prefer to generate a html or pdf file that I could view with standard tools or just read as plain text. Or maybe break the task into steps: extract the doc strings to a ReST file, and browse the ReST file with some standard tools (say rst2html file | lynx). The first step is important since I'd like to look at and compare valid ReST extracted from the source files, e.g. identified from good examples in the manual. If I want to learn ReST, then I would like to have some standard tool (as simple as pdflatex file.tex + my_favorite_pdf_viewer) so that I could view and validate a ReST file that I attempt to write. So I find the second step important. --David --~--~-~--~~~---~--~~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an 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: accessors for FreeAlgebraElement
Hi Florent, I think the polynomial ring model should translate well to the non-commutative free algebras. In addition to access, specifying a (non-commutative) monomial ordering would be desirable. Generalizing these orderings is the only challenge in the generalization from free commutative algebras. For performance, one might want to use the same idea of a dictionary directly and have both free mononoids and free algebras use this. I think I strongly tied these two classes together, but this could be weakened while preserving the sharing of code. On the subject of orders, Sage, like Magma, allow one to specify the monomial ordering, but use the reverse ordering for printing: magma: Px,y := PolynomialRing(QQ,2); magma: B := [ 1, x, x^2, y, x*y ]; magma: Sort(B); [ 1, y, x, x*y, x^2 ] magma: +B; x^2 + x*y + x + y + 1 sage: P.x,y = PolynomialRing(QQ,2) sage: B = [ 1, x, x^2, y, x*y ] sage: B.sort() sage: B [1, y, x, x*y, x^2] sage: sum(B) x^2 + x*y + x + y + 1 It would be desirable to be able to specify the printing order (whether 'reverse' or not). In the context of completions, a left-to-right printing is preferable: sage: P.x = PolynomialRing(QQ) sage: S.t = PowerSeriesRing(QQ) sage: f = x^7 + x + 1 sage: f x^7 + x + 1 sage: S(f) 1 + t + t^7 This could be controlled by a simple flag. Cheers, 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: p-adic precision loss in charpoly
William, Thanks for pointing out that I was wrong about the lifting problem and original of this slow behavior. Rather than just putting in place the solution by lifting to ZZ, which you show to be much faster for reasonable size, I hope someone can profile arithmetic or linear algebra for ZZ/nZZ and figure out why this determinant is so dog slow. Are there too many GCD's or what is going on? I hope the original p-adic problem also gets a track rather than being lost by my side comment, since there the problem was that a wrong answer was being returned -- a much more serious issue! Cheers, 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: p-adic precision loss in charpoly
Hi, The algorithm used doesn't need to be specific to the p-adics, but shouldn't apply an algorithm for fields or integral domains. Rather than the matrix code, it looks like this is the source of the problem: sage: M.parent().base_ring() 101-adic Ring with capped relative precision 2 sage: R.is_integral_domain() True With such a result, the wrong linear algebra is applied. One could possibly identify which algorithms to apply for real complex fields, p-adics, and power series rings from this: sage: R.is_exact() False Inexact rings are only approximations to mathematical objects. However, in this case the intended ring is the quotient ring Z/p^nZ (= Z_p/p^n Z_p), which is 'exact' (i.e. a well-defined ring) but is not an integral domain. I would hope that the matrix code would then pick up a valid algorithm to apply, even if not the most efficient. --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: p-adic precision loss in charpoly
Hi, One can always work around a problem, but it would be better to discuss the best approach and put this in place. A related problem I had recently was in finding a random element of GL_n(ZZ/26ZZ) where n was 20-30. It was failing to terminate in the determinant computation. My guess is that a determinant over ZZ was being computed and reduced but that the resulting determinant was too big. I didn't verify this, but invite someone to check. Instead I worked around this by computing the determinants mod 2 and mod 13 and using CRT (if the determinants were both units). The time was then almost trivial. Suppose I replace this problem over ZZ/25ZZ or ZZ/256ZZ. I would still hope that the problem would NOT be lifted to ZZ for computation, since this would certainly not terminate in reasonable time for a dense matrix. Taking the approach of lifting to ZZ for charpolys of matrices of non-trivial size will undoubtably lead to exactly the same coefficient explosion which is the presumed source of the problem with determinants over ZZ/26ZZ. --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: Algebras with several bases, aka abstract parents with several concrete representations
Hi Nicolas, I would suggest that the choice of basis (or generators) should be an intrinsic part of the algebra's representation and interface. Different representations imply different (but possibly equal, even canonically equal) algebras. Compare free modules and polynomial rings: sage: V = FreeModule(QQ,2) sage: B = V.basis() sage: B[0] (1, 0) sage: U = V.submodule_with_basis([ V([1,2]), V([0,1]) ]) sage: U == V True sage: U.basis() == V.basis() False and sage: sage: P = PolynomialRing(QQ,2,'t') sage: P.gen(0) t0 The module basis is also a set of ring generators, hence there is some ambiguity which of these two roles the basis elements are playing. sage: H = HeckeAlgebra(R, W, q1, q2, basis='hecke') sage: T = H.basis() sage: T[(1,2,1)] == H.gen((1,2,1)) True I think also the parent of T[(1,2,1)] should be H and not the set T; at least in the way sets are handled in Magma, a set (or sequence) has a universe which is the parent of its elements and intersections and unions are then well-defined for all sets which are subsets of that universe. sage: A = HeckeAlgebra(R, W, q1, q2, basis='yang-baxter') sage: YB = A.basis() sage: a = YB[(3,2,3,1)] sage: x = H(a) Or one can create a class of homomorphisms and set up an isomorphism between a Hecke algebras in one basis to one in the other. Note: I wrote B[i] for indexing of a basis B (for i in I), but A.gen (i). I write i as tuples (1,2,1) or (3,2,3,1) since they are immutable, hence can be hashed, and give a fixed number of arguments, 1. This should be easier to code and be more robust. Possible drawbacks: if H and A are expensive to create, and cache important information, this information will not be simultaneously available to both rings and may have to be recalculated (or some sophisticated global caching would be required). Advantages: The basis and/or generators are well-defined for each ring. It is clear when one passes from one representation to another. One representation of an object does not try to pretend to be the other. It is probable that one wants a different print function for each different representation and access to implementation data such as the support (= basis elements with non-zero coefficients) and coefficients are well-defined. Mathematically one might consider A and H to be canonically equal (the object being independent of the definition). This can be acknowledged by defining A == H to be True, and supporting canonical coercions from one to the other. On the other hand, representing both by a single instance of a class in my view would lead to too many ambiguities. Each instance of a module or algebra should have a restricted indexing set and use standard access functions like X.basis()[i] and X.gen(i) which refer to the module or algebra structure. (Maybe X.basis_element(i) should be added for all modules.) Recognizing, for the particular class of algebras, that the generators are denoted T_n would suggest the short-hand H.T(n): def T(self,n): return self.gen(n) But the proliferation of the possible short-hands, H.YB, H.KL, H.C, depending on the particular presentation of the algebra, leads me to believe that this is not the way to go. Other comments: - Syntactically distinguishing different operations to prevent any ambiguity. Namely: what should T(2) mean: - The integer 2 in ZZ, embedded via the canonical morphism into T? - The 2nd generator of the Hecke algebra? (such ambiguities have lead to maintenance and debugging nightmares) Indeed, for a unital algebra A and integer n, the value A(n) must be the integer n as an element of A. Practical code calls for strong support to the easy definition of standard shorthands, as close as possible to mathematical notations, and particularly (but not only) for interactive use: - T = H.? - T[i] - T[reduced word] - T[w] - T(some algebra element) In the following I will assume that A is Hecke algebra in the T basis, while B is the T basis itself. There should also be limitations to maintain a uniform syntax for algebras, modules, etc. What's readily clear / decided: - If there is a coercion (natural morphism) from some set X to A, then, for x in X, A(x) calls this coercion. - If B is the basis of the Hecke algebra (which is indexed by the elements of the group W), then B[w] is the basis element indexed by w. - A(2) is *not* the 2nd generator T_2 of the Hecke algebra. This obviously rules out A(2,1,2). +1 The syntax A((2,1,2)) is not ruled out, but I would suggest A.gen ((2,1,2)). Decisions to be taken: (I) Syntax to access the Hecke algebra in the T basis: Choices: (1) H.T (2) H.T() (3) ??? In MuPAD, we were using (1), which is nice and short. I would even ask, what homomorphisms (of sets, monoids, etc.) apply to T? If it is not typically needed as a structure with morphisms, and one usually just creates one element at a time, then (2) H.T a function,
[sage-devel] Power series rings
Hi,
I am finding problems, holes, or missing features in power series
rings
and Laurent series rings.
sage: K.u = LaurentSeriesRing(QQ)
sage: R.t = PowerSeriesRing(QQ)
1. exp(t) is defined but exp(u) is not.
2. log(1 - t) and log(1-u) -- I started filling in this gap (below)
for
Laurent series but ran into more problems.
3. coercion to R does not work (R(u) fails trying to coerce to QQ).
The style of implementations of source code look completely
independent.
I would like to have R == K.ring_of_integers() be defined and True
(maybe
if I call the variables the same). But the lack of coercion suggests
that
these where not designed together, as do the functions for creating
error
terms O(t^n).
The names of the files hint at a design break:
sage: type(t)
type 'sage.rings.power_series_poly.PowerSeries_poly'
sage: type(u)
type 'sage.rings.laurent_series_ring_element.LaurentSeries'
Now there also exists a power_series_ring_element file, but it
implements
a class PowerSeries inheritted from PowerSeries_poly (in a separate
file).
There is also a power_series_mpoly, which must either be an attempt
at
multivariate power series or a sparse power series.
Is there a reason for this split, and if so, why do Laurent series not
follow
the same dichotomy?
I think I need to understand what is intended before hacking around
all
of these classes.
Cheers,
David
P.S. A first start with log -- is there a more efficient algorithm
already
implemented somewhere or does someone want to put in place a more
efficient algorithm?
{{{
def log
(self):
The logarithm of the power series t, which must be in a
neighborhood of 1.
TODO: verify that the base ring is a QQ-algebra.
u =
self-1
if u.valuation() =
0:
raise AttributeError, Argument t must satisfy val(t-1)
0.
N = self.prec
()
if isinstance(N,
sage.rings.infinity.PlusInfinity):
N = self.parent().default_prec
()
u.add_bigoh
(N)
err = LaurentSeries(self.parent(), 0, 0).add_bigoh
(N)
return sum([ u**k/k + err for k in range
(1,N) ])
}}}
--~--~-~--~~~---~--~~
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: Riemann-Roch spaces in Magma
Can I suggest moving this discussion to sage-nt? Cheers, 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.rc0
Build falled in clisp on MacOSX Leopard: cp -p cfgunix.lisp config.lisp chmod +w config.lisp echo '(setq *clhs-root-default* http://www.lisp.org/HyperSpec/;)' config.lisp To continue building CLISP, the following commands are recommended (cf. unix/INSTALL step 4 ff): cd src emacs -nw config.lisp make make check Working around nohup problem and the infamous UNIX error 45 bug in OSX by sending make output to /usr/local/sage-3.4.rc0/spkg/build/ clisp-2.46.p7/build.log. Error building clisp real 2m5.338s user 0m40.245s sys 0m28.565s sage: An error occurred while installing clisp-2.46.p7 --~--~-~--~~~---~--~~ 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.rc0
Compilation got past clisp once I installed XCode 3.1.2. The lines before the above this reported that readline was too old, but I don't know if this was the source of the compile failure. --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] A magma evaluation and a parser bug
Hi, 1. Here is a bug in evaluation of Magma code sage: m = Magma() sage: s = for i in [1..7] do print i^2+i+1; end for; sage: m(s) ... TypeError: Error evaluating Magma code. IN:_sage_[5]:=for i in [1..7] do print i^2+i+1; end for; OUT: _sage_[5]:=for i in [1..7] do print i^2+i+1; end for; ^ User error: bad syntax 2. And here is a bug in the pre-parser: sage: s = for i in [1..7] do print i^2+i+1; end for; sage: s '\nfor i in (ellipsis_range(1,Ellipsis,7)) do\nprint i^2+i +1;\nend for;\n' Similarly: sage: s = \ for i in [1..7] do\ print i^2+i+1;\ end for; sage: s 'for i in (ellipsis_range(1,Ellipsis,7)) doprint i^2+i+1;end for;' 3. Although this is not the sage-support list, I'll ask some questions: a. Is it possible to pass user_config=True to the %magma shell as for Magma()? b. Where do I find the source code for %magma? c. In the notebook, I don't have the same preprocessing of the input. In both, the sage shell and notebook I would like to be able to preprocess (=,==) - (:=,=) and keep the 4. In the notebook, is it desirable to require a %magma at the top of every cell in order to interpret a sequence of Magma code as such? Ex. %magma x := 1; for i in [1..7] do x +:= i^2+i+1; end for; Next cell: %magma print x I expected to remain in %magma mode until executing quit; as in the Sage command-line shell. 5. Instead %magma quit then %magma 1 + 1; Gives an error; I think it fails to restart a Magma session. If any Magma users want to suggest or comment on good ways to merge Sage and Magma code and port code this would be helpful. I have some 10 years worth of integrated code: http://echidna.maths.usyd.edu.au/~kohel/alg/index.html and directories of worked examples. It is not a simple matter of porting a handful of functions. Instead I need an means of working with Magma within Sage, and verifying results in the two systems as individual functions do get ported or rewritten in Sage. --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: Naming convention again...
Hi Florent, I would also like to see a class which is generally useful throughout Sage, as the default return type for many different finite or enumerable structures. I'm sorry but I don't understand what you mean by this sentence. Can you give an example, please ? Jason Bandlow's reply essentially answers your question, but I think it is worth making my comment more precise and having a general discussion, so I will start a new post. --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] Enumerative structures in Sage
Hi, In Python (hence Sage) there exist simple aggregate or enumerative structures: dictionaries, lists (and tuples), and sets. Beyond these types, there are Sage Sequences and Sets, and (name under discussion) EnumeratedSets coming from the combinatorial community. For comparison, in Magma one has classes for sequences, sets, and indexed sets (which combine the indexing of sequences with hashed set structure). Since Magma invents its own language (generally a negative), it makes its own choices about what datastructures to provide. This largely dictates the conventions for their use. In Sage, as these structures multiply, we need to decide what are the best datastructures to implement (beyond Python types) and which to use. Ex. 1: This is a Sage sequence class: sage: F0 = FreeModule(QQ, 3) sage: B0 = F0.basis () sage: type (B0) class 'sage.structure.sequence.Sequence' and tuple for the same basis given by gens () sage: type(F0.gens ()) type 'tuple' Ex. 2: This is the EnumeratedSet class: sage: F1 = CombinatorialFreeModule(QQ, list (abc)) sage: B1 = F1.basis () sage: type (B1) class 'sage.combinat.family.FiniteFamily' Currently gens() is not implemented. Ex. 3: Should we return an tuple, EnumeratedSet, or Sequence?: sage: P0 = PolynomialRing(QQ,list (abc)) sage: type(P0.gens ()) type 'tuple' Ex. 4: This is of a slightly different flavour, but we could instead return a Sequence (which knows that all points belong to the same parent), or an EnumeratedSet (giving hashed lookup and indexing): sage: FF = FiniteField (7) sage: E = EllipticCurve([FF(1),FF (3)]) sage: type(E.rational_points ()) type 'list' The first two examples are different implementations of the same object (with different representations but they could converge into one FreeModule class with sparse and dense subclasses). The third example is similar, in the sense that a polynomial ring is a free object on the underlying set of generators, which we could define to be a basis. The last example is just another instance of a naturally occurring, finite enumerable structure, where we might want to preserve the knowledge of the common parent (e.g. Magma would return a sequence or indexed set which stores this data). The important feature of a free object F(X) on a set X (in a category C) is that: Hom_Set(X,U(G)) = Hom_C(F (X),G), where U(G) is the underlying set of object G. This is just the definition of a free function F as left adjoint to the forgetful functor U. In practice, this means we would like to be able to pass a morphism of sets f in Hom_Set(X,U(G)) to the homset Hom_C(F(X),G) as defining data of a morphism F(X) - G. In order to do so, it would be desirable, in the first three examples, to define F(X).basis() which return a Sage object X for which we can construct its morphisms (of sets). It would also be desirable for this basis to be efficient -- for finite X it should not involve too much overhead (compared with a Python tuple or list, or Sage Sequence). I see that a hierarchy of EnumeratedSet classes would give a common category for returning all sort of enumerable and iterable objects which can extend to infinite (enumerable) sets. As a start, I would suggest that for free objects F, one define F.basis() : EnumeratedSet X such that F = F (X) F.gens() : Python tuple when X is finite, or else an error (or should this be an immutable Sequence?) Here F could be a: FreeGroup FreeAbelianGroup FreeMonoid FreeAbelianMonoid FreeModule PolynomialRing (= Free[Unital] CommutativeRing) FreeAlgebra (= FreeUnitalAssociativeAlgebra) etc. This supposes that the EnumeratedSet class is as efficient, intuitive, and useful for finite sets (with indexing) as a list, tuple, or Sequence. I assume that this class belongs to the category of sets, not ordered sets, and so that the indexing is not respected by morphisms. However, one could have the possibility of using the indexing to define a set morphism via a morphism of the index sets. This leaves open the question what roles Sequence and Set play, and whether the class Set can be superceded by EnumeratedSet, or where in the system they should be used. In short, I think we should decide what are the primary aggregate structures to support, optimise, and use, then set these down as conventions in the developers guide. Comments? --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: A magma evaluation and a parser bug
Hi William, Is all the code you have above GPL-licensed now? Yes, see: http://echidna.maths.usyd.edu.au/kohel/alg/index.html I need to update the code, but I propose that this could be an optional Sage package, for Magma users. This would ensure more users, and enforce testing against rot, and maybe get more people behind porting. --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: Idea solicitation for semester-long algebra project
Implementing Florian Hess' article in Sage would be vey welcome, and I'm sure that Florian (or I for that matter) would be happy to given input. --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: Naming convention again...
Hi,
I know nothing of combinatorics, but shouldn't accessing a set's n-th
element be more understandable using S[n] ?
I agree.
I would think S.index(x) would be more intuitive to a non-
combinatorist
like me. Do I understand correctly that these are sets enumerated by
an indexing set (e.g. of natural numbers)? I vote for EnumeratedSets,
or IndexedSets.
(Countable|Enumerable)Sets would be descriptive for a datastructure
without indexing function.
IterableSets does not capture the fact that there is a indexing
structure,
and CombinatorialSets doesn't convey anything to me, except that I
probably should never use it (not belonging to the club of
combinatorists
who immediately understand what auxilliary properties of a class
[class
in the Python/object-oriented sense] of sets are defined and used by
combinatorists).
For comparison, in Magma one has enumerated sets:
SetEnum:
finite sets with hashing in which the elements are expanded
or enumerated in memory (as opposed to defined by some
membership test function)
and indexed sets (SetIndx):
SetIndx:
a SetEnum X with an indexing function {1,...,n} - X.
I don't like the former name (for the Magma structure), since the
sets are in fact only finite, and the sense in which they are
enumerated is vague. I would be happy if an EnumeratedSets
class in Sage reclaimed the term enumerated to mean that
the sets are actually enumerated by an indexing function, and
which are enumerable but not necessarily finite.
I would also like to see a class which is generally useful
throughout Sage, as the default return type for many different
finite or enumerable structures.
--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: Cardinality of a set...
Hi,
Despite the length, I prefer cardinality() since card() is vague and
obscure
(and len(), size(), and count() ambiguous).
I would argue that cardinality(), as distinct from len(), should
consistently
return a Sage Integer (or some concept of cardinal number) rather than
a
Python int.
sage: X = Set([1,2,4])
sage: type(len(X))
type 'int'
sage: type(X.cardinality()) # change to Integer
type 'int'
Similarly one could distinguish len(x) and x.length() by their return
values
Python int's and Sage Integer's.
Natural numbers are missing, but it is not clear that one
implementation
will suit all intended uses:
1) as a poset with i = i+j (extended by other cardinalities);
2) as a poset with i = i*j;
3) as an additive abelian monoid;
4) as a multiplicative abelian monoid;
5) etc.
Until one considers N in the context of its possible structures and
morphisms,
one might as well restricting to the subset of integers.
--David
On Feb 26, 11:02 am, Florent Hivert florent.hiv...@univ-rouen.fr
wrote:
Hi Vincent Delecroix,
There is a difference at the interpreter level, look at :
sage: timeit('len(l)')
625 loops, best of 3: 229 ns per loop
sage: timeit('l.__len__()')
625 loops, best of 3: 442 ns per loop
I don't know exactly why. Perhaps the len() do not have to parse the
list of methods of the object ?
I'd guess : some python internal optimization for basic datatype. I.e. if l is
a list the python interpreter looks directly into to data structure without
calling .__len__() but it's special to lists.
I really agree that the case of words is really special. A word has a
length but no cardinality. Perhaps it's the same for other
combinatorial object (but no combinatorial classes). And I think that
a word is more a combinatorial object.
For combinatorial objects, in the real life (ie talk/course) as well as in
MuPAD, we use to call this the size of the object. Eg: the size of a
the permutations [3,1,2,5,4] is 5, the size of the partitions (3,2,1,1,1)
is 8, the size of a tree is its number of node...
If we choose something for combinatorial classes the count is not so
bad, because a combinatorial class is not a list (there is no
repetition).
It is not clear for me and in some case wrong... Some combinatorial class are
multisets.
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: Double transpose on right_kernel()
Hi, As I have been creditted by William with the free modules as row vectors and default left kernel for matrices (under the influence of Magma), let me propose a coherent way to relax this design decision. It should be easy to add an argument to free modules to create them as column spaces and give a nice latex and (not so nice) ascii art printing. Thus right_kernel should return such a module or vector space. Arbitrary matrices will then have both left and right kernels, and the composition will be well-defined. There has been a huge amount of effort going into calculus to make Sage suitable (and a natural choice) for undergraduate calculus teaching. A much smaller amount of effort would make it suitable to map any undergraduate linear algebra textbook exercise in terms of row OR column vectors to a Sage exercise without convoluted applications of transposes. Except for details like passing the column/row orientation to subspaces and caching issues, the main changes are largely restricted to __repr__ and __mul__ (for compatibility with matrix multiplication). If someone has two days to spare (one for implementation and one for documentation and bug tracking), then I would highly recommend this complementary project to the right_kernel cleanup. There would be numerous advantages also to research, e.g. in the theory of theta functions or Siegel modular forms it would be a huge pain to correctly transpose the standard column vector notation into reliable code. --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: Expected value of probability space
Hi Paul, Thanks for explaining that, I see how that causes problems when S is not a set of numbers. Even so, would it make sense for the random variable ps to be the identity function X(x) = x on the probability space ps? Currently the random variable ps is the function X(x) = P(x). Is this a useful random variable that I'm just not aware of? Well, ps is a probability space (you did create it as DiscreteProbabilitySpace, rather than DiscreteRandomVariable, which I had missed in my first reply), hence its values are necessarily probabilities. There is no other valid choice. To create a DiscreteRandomVariable, you currently must first create a probability space, then the function on that space. One could have shorter constructors which assume a finite uniform probability space, if not given. The order of the arguments is probability space, then function or values, but if a probability space is no longer required, this order should change. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Categories for the working programmer
Hi, I should point out that the class hierarchy should not be confused with the categories. The latter are intended to model the mathematics. In particular a homomorphism in the category of rings should satisfy f(x*y) = f(x)*f(y). Each class is assigned a default category, but the idea is that one should be able to create a morphism of sets between objects which happen to be rings. The domain and codomain would presumably remain objects in the category of rings and inherit from set objects, although one could imagine modifying the category field to reflect that these rings are intended uniquely to be used as set objects. How to manage the metastructure of categories on top of the class hierarchy was never completely fleshed out. In particular, it should be possibly to create new categories from old, such as pointed objects (X,x) whose maps send X_1 to X_2 and x_1 to x_2. The separation of categories from the class hierarchy was just the first step. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why Sage needs var(...) commands unlike Mathematica?
Hi John, To give a bit more weight to the counterargument against the alphabetti solution: I agree, and I did not really mean my alphabetti suggestion to be taken too seriously. In some version, there was an invasive declaration of single character symbols to be symbolic elements. This caused me all sorts of grief when I forgot to declare some variable, I would get an error message far down the line at some completely irrelevant place. I complained and this feature was removed (so blame me Chris). For the same reason I voted to leave QQ, RR, and CC, and remove predefinition of Q, R, and C (originally Q == QQ, etc.). If I forget to declare a variable, I want to see it as soon as I try to use it. Since you declare x to be in Qx in your startup file, you don't see the problem, but symbolic variables are viral: if another generator interacts with one it gets the symbolic virus. The current symbolics package supports a lot of features (which wasn't always the case) so maybe the typical user won't notice a problem, however this is one instance where one can easily pass over to the symbolics world: sage: P.X = PolynomialRing(QQ); sage: X + x X + x sage: f = X^2 - x^2 sage: f.factor() (X - x)*(X + x) sage: f.parent() Symbolic Ring sage: X = f.parent()(X) sage: type(X) class 'sage.calculus.calculus.SymbolicPolynomial' sage: type(f.factor()) class 'sage.calculus.calculus.SymbolicArithmetic' sage: fac = (1/f).factor() sage: fac == 1/f 1/((X - x)*(X + x)) == 1/(X^2 - x^2) sage: f.is_unit() ... Not implemented error The sorts of questions and functionality one asks the symbolics variables are not the same questions one asks an element of a polynomial ring or of a function field element. Stumbling into this world by mistake because someone predefined a bunch of variables for me was a real headache. SAGE is doing remarkably well at keeping a balance between ease-of- use for beginners and high-end users. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.3.alpha3 released
Hi, I'm just trying to update my sage for SAGE Days 10, but find that the compilation hangs here: checking for paperconf... false checking for java... /usr/bin/java checking for javac... /usr/bin/javac checking for javah... /usr/bin/javah checking for jar... /usr/bin/jar checking whether Java compiler works... This is on Mac OSX Leopard, after moving /opt/local/ to /opt/ local.back by hand. I actually have had a javac process running for 3 hours... Any suggestions? --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.3.alpha3 released
P.S. I get the same behavior for 3.1.2. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: SD10 Accomodation Again
Hi, Cc: Paul for comment on local information. This (http://www.hotel-eclipse.fr) looks inexpensive but (unless I'm mistaken), not accessible to LORIA or the center except by car. The center is reasonably accessible by tram; those working late at LORIA (if this is compatible with building security -- Paul???) will just have to pay attention to the tram schedule. I've booked a room in the Hotel Americain: http://www.americain-hotel.com/ which is walking distance to the train station. Another inexpensive option is Hotel Akena: http://www.hotel-akenanancy.com/ also close to the train station (on the other side). I would suggest some local input before booking hotels independently. If the hostel next to LORIA is full, then a group booking in the center would be the next best solution, would have the advantage of being close to restaurants, and we could regroup at a ciber cafe, or hotel lounge with WiFi. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sagemath.org relaunch
Hi Harald, Note that all of the mirrors, mine included in Sydney, rynchronize sage.math.washington.edu, so this site needs to be current. At present the line: Sage Devel Days 1 (aka Sage Days 8.5) will be in Seattle June 13-20, 2008 is out of date (and it lagged behind sagemath.org in announcing releases). I would like a faster way to get to the Download complete source link, without scrolling down the page to find it: http://www.sagemath.org/download.html Maybe the text for each platform could be moved to a download page. Is there any chance of adding some color? --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: parent of component of CartesianProduct
Note that the intent of these SAGE constructors is not (just) to replicate the design (and errors) of Magma or other languages. There are natural product and coproduct constructions in various mathematical categories (e.g. a coproduct in Sets _is_ the union). The constructor CartesianProduct should be the product in the category of Sets (although you give an example which the sets are also rings). However this identification does not conflict with its role in enumeration in loops (over enumerable sets). A categorical perspective should aid in the design of efficient and useful structures for mathematics and computation, many of which could map to natural constructions in various languages. The Coproduct in Sets equals the Union, as you indicate. Similarly there should also be a product and coproduct constructor, for example, in the category of commutative rings, which are different objects. Should be means when someone finds the need and time to implement such structures. Record appears not to fit in a (mathematical) category framework, but an equivalent functionality may be provided by some existing Python structure. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Adding functions to Sage
Hi David, Nick, et al., I will also be arriving for SAGE Devel Days, on the 12th (with jetlag). I am interested on focusing on p-adic arithmetic and related constructions. A GaloisRing class is essentially an finite quotient of an unramified p-adic local ring; if a separate class is created, it should inherit from the p-adic quotients and have a common code base. The interest of users of a GR interface is likely to be low precision, normal bases, etc. For my use, I want high precision, and fast Frobenius application balanced with fast multiplication. At a more general level, I'd be interested in finding individuals interested in higher algebraic (and geometric) constructions and possibly forming an additional working group at SAGE Devel Days. Cheers, David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Tensor products
Hi,
Given algebras A and B, I would return C and the two maps m1: A - C
and m2: B - C:
(C, m1, m2) = A.tensor_product(B,ring=R)
I might prefer to have something like
C = A.tensor_product(B, ring=R)
and then one can do
C.coerce_map_from(A)
C.coerce_map_from(B)
This would require a new tensor product class in order to represent C.
I think it might be desirable when taking the tensor product of two
matrix algebras to return a matrix algebra, or when taking a tensor
product of two polynomial rings to return a polynomial ring.
The other option is to have a genuine class which wraps these
rings as you indicate.
The suggested syntax above, and here:
One would rarely need the maps themselves, as one
could do C(a) and C(b), or even c + a, and the coercion model would
handle it all well (here a, b, and c live in A, B, and C resp. of
course).
assumes that A is distinct from B (or that there are no canonical
coercions from A to B or vice versa). However a common
construction is precisely to form a self tensor product or power
C = \otimes_{i=1}^n A, in which case the choice of the 2 or n
maps A - C can not be decided by without specification of
the map.
C would probably be implemented one of David Roe's wrapper
classes, so Q tensor Z[x] would be Q[x], but would still know its
factors.
A good design is very important.
In fact this is a vey generic categorical construction of (a sum or
coproduct in the category of rings). We should first consider how
general products and coproducts should be constructed, and set
up a common infrastructure and syntax. It needs to be (1) easy
and natural to use, (2) mathematically correct and complete.
The homomorphisms for products and coproducts are essential
parts of the construction so they should be an accessible part
of the design. The homomorphisms themselves should be fast
to apply, and their design should take into account canonical
homomorphisms.
--David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: Tensor products
Hi, Tensor products (of commutative rings) are necessary for representing the coordinate rings of a product of [affine] schemes. For commutative rings, a new tensor product class imay not be needed or desirable, rather what is missing currently is the homomorphisms. Given algebras A and B, I would return C and the two maps m1: A - C and m2: B - C: (C, m1, m2) = A.tensor_product(B,ring=R) The algebra C would be an algebra which represents the tensor product and whose class could depend on A and B. If the ring is not specified, then A and B should have the same base_ring. Tensor products of polynomial rings and their quotients would be the first natural cases to implement. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: A Sage Enhancement Proposal: Lattice Modules
I support John's view that real-valued lattice need also to be taken into account. Minkowski lattices of number fields and Mordell-Weil groups are prime examples. Some people also like to embed lattices in R^n equipped with the standard Euclidean inner product. As such the coordinates are non-rational even though the module L is (isomorphic to) Z^n (or Z^m for m n). These could be handled better than Magma, in which the problem of recognizing a vector from R^n in L is not handled well. There need to be good constructors for elements of L both from approximations in R^n and in terms of an integer coordinates relative to the basis of L. I think the proposed definition of is_euclidean is not obviously the natural one. I would expect this to return True iff the inner product was symmetric and positive definite, i.e. is embeddable in Euclidean space R^n (with the standard inner product). The syntax is_symmetric should return True if the inner product is symmetric. I also support the extension (relative to Magma) to (symmetric) lattices with isotropic elements and arbitrary signature. The treatment of skew-symmetric or general non-symmetric inner products might be handled by a different class. The need for a separate LatticeModule class is not completely obvious. Shouldn't the dual of a free module ever return anything but the dual with respect to the inner product, embedded in L \otimes_Z R? Probably the lattice label should apply only to symmetric inner products, and there should be subclasses for positive definite lattices. Note that even this dual constructor, for non real-valued inner products, requires that we have Z-modules embedded in an ambient space with respect to non-rational coordinates. There was also the previously raised issue of Hermitian modules, but these are yet another beast, which need to be defined with respect to a ring with fixed involution. Again there should be exact versions (e.g. over the Gaussian or Eisenstein integers, a cyclotomic ring/field, or a number ring/field) and inexact versions over the complex numbers. For real-valued lattices or non-exact Hermitian lattices, it becomes clear that the ambient vector space places an important role and should be a fixed attribute. I don't think that there should be a sublattice class. I think there should be an ambient vector space, and if two lattices lie in the same ambient space they can be added or intersected to get new lattices, and tested for inclusion. Note that the terminology QuadraticModule (for LatticeModule) and QuadraticSpace (for the ambient space) are also possible. These classes should interact well with Jon Hanke's classes for quadratic forms. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Cell splitting/merging in notebook
Hi,
On the subject of notebook features:
One feature that would be really nice is to have distinct text cells,
in html or
even better latex mode. A text cell could created by a hot key (say
cntrl-t)
in edit mode which displays the source latex or html, then toggled out
of edit
mode to display the formatted text. This could be nicer for
preparing
worksheets for teaching which combine latex formatted exercises with
sage
cells for code, rather than using
# Exercise 1. Let p = 75361. Evaluate x^(p-1) mod p for x = 2, 5, 7,
and 11.
# What do you observe? Is p a prime?
Create text cell in edit mode:
%latex
{\bf Exercise 1.} Let $p = 75361$. Evaluate $x^{p-1} \bmod p$ for $x
= 2, 3,
5, 7$ and $11$ with the commands
\begin{verbatim}
p = 75361
for x in (2,3,5,7,11):
powermod(x,p-1,p)
\end{verbatim}
What do you observe? Is $p$ a prime?
toggle edit mode
This would look much more professional than just using comments as in
the first
example.
Even better, I could imagine exporting the worksheet as a latex file
and conversely
reading a marked up latex file as a workshop.
Is this feasible?
--David
On Apr 2, 11:08 pm, [EMAIL PROTECTED] wrote:
I'm sick at home today, and this actually has a braindead solution that I
might be able to implement in my current (braindead) state. What hotkeys do
you want?
On Wed, 2 Apr 2008, Andrey Novoseltsev wrote:
Is it possible to realize some convenient and fast (in the sense of
keyboard use) cell splitting/merging? It seems to me that now it
involves manual copying of a part of code and creating/removing a
cell, or editing the text representation. I really liked the ability
to do it in Maple (back when I was using it ;-) by pressing some hot
keys since it allows you to group cells for executing in one step and
nicer visual presentation or break them back when you want to interact
with intermediate values.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: zero-dimensional schemes and multivariate polynomials in zero variables
Hi Martin et al., Magma doesn't support rank zero polynomial rings and this is a real pain when we were trying to implement schemes. I could give you examples which break the schemes code, but I made no progress in convincing Allan Steel to support this boundary case. On the other hand if the polynomial rings are designed correctly from the outset, and the documentation and test code checks the design, then the support problem will be minimized. It is better to get the design right from the outset rather than trying to hack around it. A similar problem we had in Magma was support for degree one number fields, which have been supported for a number of years now. Two obvious problems arise when trying to write generic code and these rings are not supported (e.g. returning the base ring for polynomials or the rationals for a degree one extension of the rationals): 1) the depth of recursion for calls to base ring drops, and 2) the type of the returned object is different (or wrong). Boundary cases do often break code and require support, but if the boundary cases are not supported then a lot of other code will break. For a robust generic system the boundary cases need to be well-supported even if they seem trivial. William's example of matrices with zero rows or columns is another good example; their importance should not be underestimated in a generic system. To give a trivial example, take Proj(K[x]), an zero dimensional scheme with one rational point (1) over K (or any field extension). An affine patch has coordinate ring isomorphic to K, but we need a rank zero polynomial ring to be able to represent it as a polynomial ring. Otherwise schemes code will have to test everywhere for this and similar boundary cases. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: discrete logs
Hi John, I'm not sure I understand the end of your message. Nowhere does the code I have in mind assume that anything is cyclic, let alone of prime order: the bsgs and dlog functions will terminate if there is no solution, with a ValueError. Since baby-step, giant-step is deterministic, you can do so. A Pollard-rho algorithm is probabilistic with similar expected runtime, but often faster, and uses less memory. However, it can fail to terminate if the discrete logarithm is not satisfied. For generic abelian groups one should have both BSGS and Pollard rho algorithms available, and it should be possible to use exponent or group order bounds, exact group exponents and orders, and factored group orders, when this information is available. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Permutation vs PermutationGroupElement
Hi Mike, Thanks for the explanation. Indeed a Permutation could be represented by an element of a symmetric group, but we would want to make sure that until a group-theoretic question is asked, no call to GAP should interfere with the calculations. Your: sage: G = Permutations(3) would be analogous to sage: G = Set(SymmetricGroup(3)) i.e. you are not concerned with the group structure. I have thought that permutation groups should be generalised to act on arbitrary sets -- that is one feature which you implement. Similarly, from a glance at your code, you appear to allow right or left actions on a set. Again, a useful construction to have G-sets with right and/or left actions. The multiset actions require more thought to put in a general context. I think it would be useful to model PermutationGroup's on all of the features that you want or need, then see if they can be made as light as the implementation you have, but as efficient as the cython coded permutations for the arithmetic of the group law and group actions. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why is the Groebner basis not an ideal
OK, as a conscious decision it is certainly justified. Of course, mathematically you are right that an object and a particular basis of that object are two different things. Only i was surprised, because i grew up with Singular and not with Magma... FYI, magma has both commands GroebnerBasis, which returns a sequence, and Groebner, which is actually a procedure that modifies the ideal basis in place so that Basis(Groebner(I)) eq GroebnerBasis(I); returns true. Interestingly, the syntax is not Groebner(~I), which is what one would expect for a call-by-reference, modifying the object in place. But that seems to be a design decision that the user-defined ideal generators are not an immutable attribute of the ideal, so GroebnerBasis also changes the ideal generators in place. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: generator inconsistencies in finite fields
Hi All, Just a few comments: there are three possible concepts for generator[s]: 1) As a field over its prime field or base field (function gen(), category Field or Algebra); 2) As a vector space over its base field (function additive_generators(), category Module) 3) As a group, restricted to the set of nonzero elements, which is the original source of confusion (function primitive_element() or group_generator(), category Group). It has been noted that 3) can be difficult to compute for large fields. Finite fields should be first and foremorst Fields, hence gen() should remain as it is, and functions like additive_generators() and primitive_element() or group_generator() could be added. The term primitive_element() is very standard terminology for a group_element() when talking specifically of finite fields, but unfortunately this can be confusing with a primitive element of an arbitrary finite algebraic extension field, where it is defined to be a generator of the field extension. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: generator inconsistencies in finite fields
Hi, It is probably a bias of the choice of (additive) generators for finite field extensions which results in the primitive field element also being a generator for the multiplicative group (confusingly called a primitive element of the finite field). It is not possible to set GF(q).gen() to always be a generator for the multiplicative group, since it is not always computationally feasible to determine it. In particular requires a factorization of q-1. The finite field constructor for non-prime fields would then also have to be changed to ONLY use primitive elements (since GF(q).gen() must certainly return the generator with respect the the defining polynomial). This would conflict with the desire to allow user-chosen polynomials or polynomials of SAGE's choice which are selected for sparseness (hence speed) rather than as generator of the multiplicative group. Moreover, any such definition for convenience of the user would have to be turned off for q [some arbitrary bound] and could not be reliable. Thus I don't see how it would be possible to make the definition that GF(q).gen() is a generator for the multiplicative group. For small finite fields, one could set GF(q).gen() to be such a generator. This could either be convenient, or confuse users into thinking that this is more generally True. --David P.S. On the other hand, I find (additive) order confusing and there should be some checking of the index for FF.i below (i.e. give an error if i ! = 0). sage: FF.x = GF(7^100); sage: x.order() 7 sage: x x sage: x.multiplicative_order() 323447650962475799134464776910021681085720319890462540093389533139169145963692806000 sage: FF.0 x sage: FF.1 x sage: FF.2 x sage: FF.100 x sage: FF.101 x --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
I will try to take all the above on board as I am implementing it, and look forward to having you people make constructive criticisms But David K's suggestion about the set of all iso/automorphisms might wait until the next round. I (or someone else) can implement the structures of Iso's at a later date and any existing, relevant member functions moved or copied to these structures later. I hope that people other than elliptic curve afficionados have been following this thread, since the whole discussion is relevant in many other contexts and (as has been said) we definitely want a consistent interface. +1 -- the subject (multiple return values) was intentionally broad to address the wider audience. Cheers, David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Multiple return values
There was a thread on multiple return values coming from Magma, since renamed to Integer points on conics William pointed out that one can access the multiple return values using nvals: x = magma.XGCD(15, 10) x,y,z = magma.XGCD(15, 10, nvals = 3) The first returns an integer, while the second returns a tuple. Q1: Is this an acceptable general construction for Python and/or SAGE, namely to return a different type depending on the values passed into it? Is it acceptable when it is controlled by nvals in exactly this way? As William pointed out, very different algorithms can be called depending on the number of arguments requested in Magma. The following is an example: sage: E = magma.EllipticCurve([1,3]) sage: magma.IsIsomorphic(E,E) true sage: bool, phi = magma.IsIsomorphic(E,E,nvals=2) sage: phi Elliptic curve isomorphism from: Elliptic Curve defined by y^2 = x^3 + x + 3 over Rational Field to Elliptic Curve defined by y^2 = x^3 + x + 3 over Rational Field Taking (x : y : 1) to (x : y : 1) Currently in SAGE we have: sage: E = EllipticCurve([1,3]) sage: E.is_isomorphic(E) True Q2: Would the following be acceptable way of implementing equivalent functionality in SAGE?: sage: bool, phi = E.is_isomorphic(E, nvals=2) Note that often (in many concexts) it more expensive to return an isomorphism, but only slightly more so compared with recomputing the isomorphism test. If the answer to my question is no, it not acceptable SAGE/Python syntax, then how should we implement this functionality? One possibility is: sage: phi = E1.isomorphism(E2) and to trap an error if is_isomorphic returns false. Is this a better? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Sollya
Here is another open source CAS, which is being advertised here. Someone might want to evaluate it to see how much is being reinvented and what is new. Note that it uses a particular French open source licence designed in response to the GPL and which supposedly addressed legal problems with the GPL in France. --David - Forwarded message from Sylvain Chevillard [EMAIL PROTECTED] - Date: Tue, 15 Jan 2008 13:01:15 +0100 From: Sylvain Chevillard [EMAIL PROTECTED] lyon.fr User-Agent: Icedove 1.5.0.10 (X11/20070329) To: [EMAIL PROTECTED] im.fr, [EMAIL PROTECTED] [EMAIL PROTECTED] lyon.fr Subject: [gdr-im] Sollya 1.0 Bonjour, depuis un an environ, nous développons un logiciel libre appelé Sollya : http://sollya.gforge.inria.fr Ce logiciel se présente sous forme d'un shell interactif avec un langage de script étendu. Actuellement, Sollya se veut un outil général d'aide à la synthèse de codes numériques mais comporte plusieurs fonctions utiles en elles-mêmes. Entre autres choses, Sollya permet de calculer (en précision arbitraire) la norme infinie d'une fonction, d'en calculer le meilleur approximant polynomial de degré fixé, et il est capable de produire du code C certifié pour évaluer avec une précision donnée un tel polynôme d'approximation. À notre connaissance, certaines fonctionnalités de calcul numérique n'étaient disponibles que dans des logiciels propriétaires de type Maple ou Matlab. Sollya a vu le jour dans le but de s'affranchir de cette dépendance ainsi que d'obtenir des résultats plus rapides et plus précis. Nous invitons ceux d'entre vous qui pourraient avoir des besoins similaires à essayer Sollya, à nous faire part de leurs remarques et besoins supplémentaires, ou même à participer au développement. Sylvain Chevillard et Christoph Lauter Équipe Arénaire - ENS Lyon - End forwarded message - --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: inner product of complex vectors
Dear John (et
al.),
I think the inner product should be the same irrespective of the
field.
The inner product as dot product is relevant to the study of
quadratic
forms, conics, and orthogonal groups. For instance finding a
rational
point on the conic x^2 + y^2 + z^2 = 0 over CC is equivalent to
a
representation of zero of the quadratic form, but not if the form
is
replaced by x\bar{x} + y\bar{y} + z\bar{z}, and I don't think we
want
to break this correspondence between points on conics and
isotropic
vectors.
What is missing is a class for Hermitian modules, which would
have
a ring with involution as base ring. Such a class would be useful
for
studying Riemannian lattices such as the period lattice of an
abelian
variety, and unimodular groups. This class would allow one to
define
the Hermitian inner product x\bar{x} + y\bar{y} + z\bar{z} on a
ring
with inner product x |-
\bar{x}.
One choice of inner product is not sufficient to represent all such
forms,
and defining the default inner product to be the Hermitian product
for
complex fields would require making similar definition for
imaginary
quadratic fields, cyclotomic fields, and other CM fields for
consistency.
Even recognition of a CM field is nontrivial and this would lead
to
arbitrary choices. Worse, for other number fields, a Hermitian
product
would depend on a particular choice of
embedding.
So if this is entered into a trac, I think it should be for creation
of a class
of Hermitian forms together with a class of rings with involution
(from
which CC, quadratic rings, cyclotomic rings, and a class of CM
fields
would
inherit).
--
David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: non-commutative polynomial rings
Hi, I didn't implement subs for these types, but it seems to be inheriting from some generic code. The description of output says that self is returned if the substitution fails, which is the behavior you observe. This could be fixed by defining subs for a FreeAlgebraElement, but the logic of the generic function should be reported as a bug. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Proposed minor enhancement: elliptic curve transformations
Hi John, Group -- WierstrassIsomorphismGroup GroupElement -- WeierstrassIsomorphism OK I'll try that. On this subject, I had the idea that an Iso(X,Y) subset of Hom(X,Y) should be defined for every category. Note that the subset Aut(X) of an End(X) is a group, but in general the WeierstrassIsomorphism class are (two- sided) G-sets (over Aut(X) and Aut(Y)) but not groups. Thus I think they should have some inheritance like Morphism - EllipticCurveIsogeny - EllipticCurveIsomorphism, The middle class could be skipped for the moment. Within the category of abelian varieties, we can assume 0 goes to 0. In the future it might be of interest to have special classes of genus 1 curves which might admit more general isomorphisms, but they will no longer be given by linear transformations, which reduce to coefficients [u,r,s,t] of an (upper triangular) matrix. You could cc me in relevant messages to make sure that I response -- we have a one-week teaching break, but need to pack up my office this week. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: calculus in SAGE/SymPy
Hi,
Just to add my 2 bits, I think we should aim for something like the
following:
sage: x = var('x')
sage: X = x.domain()
sage: X
Affine line over the Real Field
sage: X.identity()
x
sage: f = sin(x)
sage: X == f.domain()
True
sage: f = sin(domain=X,codomain=X)
sage: y = var('y')
sage: g = sin(y)
sage: f.domain() == g.domain()
False
sage: f == g
False
sage: h = sin(domain=X,codomain=Y)
sage: f == h
False
Note that the default domain could be a Complex Field rather than a
Real Field.
In order to allow domains which are, say, the positive real numbers, I
don't see
how to get around the need for a class for such domains (i.e.
RealField() does
not do the job).
Note also that this provides a means of resolving sqrt(x)^2 and
similar expressions.
However it also introduces some headaches, like when (or on what
domain) is the
composition sqrt(x) defined, and how to specify the domain of an
inverse function:
sage: sin_inv = sin.inverse() # well-defined on some default subspace
of the codomain?
sage: sin_inv.domain()
???
With this approach, one has to make a design decision whether a
function must be
defined everywhere on a domain, whether it can have isolated poles,
and if the
domain and codomain contains a +oo and/or -oo. Personally, I think
isolated poles
(or codimension = 1 poles) should be allowed, but sqrt(x) should
require x.domain()
to be contained in the positive reals (or a complex domain and some
choice of branch).
Thus sqrt(exp(x)) would be valid but not x = var('x'); sqrt(x). This
would provide some
mathematical rigor without killing usability.
--David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: ticket #59 (optimize elliptic curve arithmetic)
I think the problem needs to be profiled. The problem is likely NOT in elliptic curves, but some horrendous chain of calls to module operations before getting to the (same) actual algorithms. Note that P*2 is slightly faster since it calls directly the member function of P rather than a function on integers. sage: E = EllipticCurve([GF(101)(1),3]) sage: P = E([-1,1,1]) sage: timeit 2*P 1000 loops, best of 3: 309 µs per loop sage: timeit P+P 1 loops, best of 3: 89.8 µs per loop sage: timeit P*2 1000 loops, best of 3: 204 µs per loop Yes, reopen it: these sorts of problems need to be looked at and optimized. The same problem applies to points on Jacobians (compare 2*P, P*2, and P+P). --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Crypto package additions?
Hi Everyone, The main crypto functionality that I implemented concerns classical cryptography, for the purposes of teaching: http://echidna.maths.usyd.edu.au/~kohel/tch/Crypto/ Hence most of the systems are breakable (using suitable classical cryptanalytic attacks). The cryptosystem class can be extended by adding subclasses for more serious RSA, ElGamal, and symmetric key systems. Modes of operation (for block ciphers) are yet to be implemented, but intended. Classes of hash functions would also be natural additions -- I'm happy to discuss the higher level structure for classes of ciphers and hashes. Many of the latter algorithms, and fast algorithms for RSA, ElGamal, and ECC have implementations in standard libraries, but as noted, scaled down weak versions would be useful for testing or demonstrating attacks. --David On May 29, 10:08 am, David Harvey [EMAIL PROTECTED] wrote: On May 28, 2007, at 7:38 PM, Nick Alexander wrote: William Stein [EMAIL PROTECTED] writes: SUMMARY: There is a huge amount of crypto-related functionality in SAGE already, but it is all over, and there are some exciting and unique cryptographic algorithms that could be implemented in SAGE that aren't implemented now. In addition, SAGE could really use arithmetic in Jacobians of hyperelliptic curves. If you are interested in computational algebraic geometry and cryptography, this would be a valuable contribution. I second this. Would be great to have a fast implementation. In particular there are supposed to be very fast algorithms for genus 2, and perhaps 3 too. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Discrete log problem
To David Kohel: index calculus for discrete logs uses linear algebra mod p-1 (not 2). Yes, I overstated the similarities between factorization and dlogs. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Discrete log problem
(Partial) factorization (by trial division) of p-1 is in other to make use of CRT of discrete logarithms mod m where m | p-1. The index calculus algorithm requires a relations collection phase, and a linear algebra phase. The linear algebra phase just requires sparse linear algebra over F_2 to discover squares. Beyond the quadratic field sieve, the number field sieve and function field sieves require more mathematics than most computer scientists, cryptographers, or programmers possess. Understanding of prime ideals, class groups, unit groups, and treatment of maximal orders not given by a power basis requires a background not typically found in programmers. (And those will such a background are likely to work in industry or government, where their code is proprietary.) Also optimization of NFS seems to be more art than science, even if one has a working implementation. It is NOT usually called by a one-line call to factorization or discrete log. Generally the algorithm is (only?) suitable for distributed computation. A good QFS (after Pollard rho [and ECM for factorization problems]) should suffice for any stand-alone system. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: integer.valuation and polynomial.valuation
Hi William, In agreement with Nils, f.valuation() should agree with -f.degree(). This should be a valid sage session: sage: f = x^3 + x^5 # = t^-3 + t^-5 = t^-5 (t^2 + 1) where t = 1/x sage: f.valuation() # should be the valuation at infinity with uniformizing parameter t -5 sage: f.factor() (x^2 + 1) * x^3 sage: (x^2+1).degree()*f.valuation(x^2+1) + x.degree()*f.valuation(x) + f.valuation() == 0 True The last line is the product formula (logarithmic version for valuations). In agreement with William, ord and valuation should be synonyms for both integers and polynomials. Note that polynomial code got re-arranged some in sage-1.8.1.2, so upgrade to that before working on this. Should read sage-1.8.2.1? But trying this on sage.math gives a TypeError rather than NotImplementedError for f.valuation(x). So maybe sage-1.8.2.2 when it is available? type 'exceptions.TypeError': function takes exactly 0 arguments (1 given) --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: p-adics
Hi, The mploc might require further development to be stable in odd characteristics, but at least aims to be a standard p-adic C library. I am very interested in seeing p-adics developed, so please CC me: David R. Kohel [EMAIL PROTECTED] and my student: Hamish Law [EMAIL PROTECTED] with developments. As William mentioned before, it would not be bad to have two implementations for testing, comparison, and improvement of both. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Dlogs
I'm really glad I'm not writing everything in SAGE from scratch! Definitely. I can put this in this weekend, but if someone doesn't get to it sooner. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Euclidean div
For x, m != 0 in a Euclidean domain, one should have: x == m*(x.div(m)) + x.mod(m) Although one can get the result of x.div(m) as x.quo_rem(m)[0], but I would suggest having this as a separate function. I know that it is more efficient, if one wants both, to use quo_rem, and essentially no worse, but students see will div and mod operators in class, and the syntax for quo_rem is more obscure to find and to use. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Dirty random
Any ideas how to get a random number from 1 to n in SAGE? Here's a bad way to do it: sage: n = 10^2 sage: G = SymmetricGroup(n) sage: G.random()(1) which will blow up as n goes to infinity. Here's a slightly better one: sage: x = random() sage: int(n*x) At least it gives a float's worth of precision. Should there be random_integer in addition to random_prime? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Permutation groups
Hi William,
Oops, I forgot to post my reply to my own message. This is the
solution I found,
using the same GAP manual entry for PermList.
def gap_format_cycles(x):
Put a permutation in Gap format, as a string.
x = str(x).replace(' ','')
return x.replace('),(',')(').replace('[','').replace(']','')
def gap_format_images(x):
Put a permutation in Gap format, as a string.
return PermList( + str(x) + )
I hadn't yet sorted out how to preserve the correct cycle printing,
as the __gap is used
also for printing.
This will be useful for creating transposition ciphers.
--David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Strings in SAGE
I'd like to get opinions on the following from the experts -- I am in
the process
of preparing for a cryptography course, for which I've previously used
a Magma
package that I wrote and would like to use SAGE.
Python has some special octal ('\ooo') and hexadecimal ('\xhh') string
constructors, e.g. one can see hexadecimals in action here in SAGE:
import Crypto
for i in range(256):
x = Crypto.Util.number.long_to_bytes(i)
print %s: %s %s [%s] % (i, repr(x), x, len(x))
Note that repr(x) uses hexadecimal printing for strings in some, but
not all,
ranges of the ASCII alphabet.
Thus Python strings represent the monoid \union_n {0,..,255}^n, with
special
constructors for the subsets of octals in \union_n {0,..7} and
hexadecimals in
\union_n {0,..,15}^n.
What would you think of having SAGE classes for binary, octal,
hexadecimal,
radix64 (used by GPG) and other string monoids, which are not Python
strings?
Advantages: differentiated printing, clear morphisms, efficient
embeddings
(i.e. length n binary strings can use n + O(log(n)) rather than 256n
bits),
and more general string monoids (like with alphabets {AA,..,ZZ}).
Disadvantages: performance and introduction of non-standard Python
classes.
The alternative is to always embedd cryptographic strings in Python
strings.
In Magma I did create a Hackobj cryptographic string type (CryptTxt)
for
exclusive use with my cryptography package.
V := VigenereCryptosystem(8);
M := Encoding(V,ABCDEFGH);
ABCDEFGH
Type(M);
CryptTxt
This was meant to overcome certain disadvantages with Magma strings,
give verifiable type-checking, etc.
What do you think of such classes in SAGE would be merited?
Is there possibly any existing string library which provides similar
features?
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
