[sage-devel] Re: absolute value in a p-adic quotient field
I would argue that P.root_field() should return a p-adic field here, not a polynomial quotient ring. This would be consistent with the behaviour of root_field for polynomials over QQ and number fields; generally, when we have a choice of several different Sage representations of the same mathematical object, it probably makes sense to return the one with the most functionality, doesn't it? I've opened a ticket for this change to root_field (#14893). David On Wednesday, July 10, 2013 10:49:54 PM UTC+1, Paul Mercat wrote: If I define 'a' like this: R.x=PolynomialRing(Qp(2)); P=2*x^2+1; K.a=P.root_field(); why 'a' has no attribute abs ? It's not a big problem, because it's easy to compute the absolute value from the norm, but it don't work : a.norm() gives TypeError: cannot construct an element of Full MatrixSpace of 2 by 2 dense matrices over 2-adic Field with capped relative precision 20 from [0, 1 + O(2^20), 2^-1 + 1 + 2 + 2^2 + 2^3 + 2^4 + 2^5 + 2^6 + 2^7 + 2^8 + 2^9 + 2^10 + 2^11 + 2^12 + 2^13 + 2^14 + 2^15 + 2^16 + 2^17 + 2^18 + O(2^19), 0, O(2^20)]! Somebody knows why this don't work ? -- 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.
Re: [sage-devel] Re: Products of permutations use nonstandard order of operation
2013/7/13 Volker Braun vbraun.n...@gmail.com: But the question is, how is this right action that you speak of implemented in Sage? +1 to this comment of Volker. And the notation should be ^ (hat) I had Darij's problem as well, and many others probably did as well. In a right action, I would prefer p(1) to give a warning. In a right action, I would want some notation where p is on the right, preferably 1^p (1 hat p). The notation * has the wrong distributive laws in case of actions on rings or groups. Of course this is irrelevant for permutations acting on sets, but since Galois groups can be interpreted as permutation groups too and they act on rings, the hat is much better. +1 also to a parent option for all groups with natural actions (Galois groups, permutation groups, ...?) saying left or right. I don't care too much what the default value is in each case, as long as there are warnings. -- 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] Re: Sage graphics in javascript ?
On 07/14/2013 12:17 AM, Nathann Cohen wrote: Hello everybody !!! Have you ever seen this thing ? https://github.com/mbostock/d3/wiki/Gallery It's a javascript library which seems to handle quite a range of things, and I am thinking of writing a patch that would let us draw Sage graphs using it instead of Matplotlib. Perhaps we could also use it to obtain a small interface to visually edit graphs too. Perhaps we could also use it to draw more complicated graphs, like the ones that the combinat guys like to print, with a lot of information on edges and vertices. What happened to the graph editor that was written by Rado? I forget how it was supposed to be called. Is there anybody else around here who would like to replace matplotlib with something easier to work with ? Or at least to provide another output to our objects for a while, and see how it goes ? The library seems to be GPL-compatible. See youuu ! Nathann -- 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. -- 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.
Re: [sage-devel] Re: New Trac Server
On Mon, Jul 15, 2013 at 1:29 AM, R. Andrew Ohana andrew.oh...@gmail.com wrote: I've created a daemon on the trac server that will do one direction of the sync, but it shouldn't be too hard to make it a two way sync. one way is good enough, i just didn't hear back when I asked about this earlier. thank's for upgrading all this! and yes, disabling this in the wiki desired, but so far i never heard any reports about that (the only reports are that resetting the password on the current trac doesn't work, but that will certainly be fixed now ;-) h -- 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.
Re: [sage-devel] Re: Sage graphics in javascript ?
What happened to the graph editor that was written by Rado? I forget how it was supposed to be called. I actually remembered its existence yesterday, hence after sending my message. Here it is : sage: graph_editor? The problem with this is that one needs to run the notebook to give it a try. On the other hand, you can actually edit the file while I was only thinking of a new way to display it. You can actually give d3.js a try with the .py file I join to this post. sage: %runfile js.py sage: showg(graphs.CubeGraph(4)) Nathann -- 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. js.py Description: Binary data
[sage-devel] cloud.sagemath.org, Sage Notebook, command line, etc
Hello, what sequence of instructions could tell what Sage 5.10 user-interface is currently being used ? Possible answers are: - cloud.sagemath.org - Sage Notebook - linux command line - windows command line (?) - cygwin command line (?) - new others... Long ago I used to check if variable sage.plot.plot.EMBEDDED_MODE is defined to see if notebook is being used. Thank you, Pedro -- 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] Re: cloud.sagemath.org, Sage Notebook, command line, etc
Ideally there would not be a user-visible way to find out how Sage is being run. Otherwise we'll just end up with code that only works with the interface that the developer prefers (like the OSI disaster in ACPI tables). The differences should be abstracted away by the Sage api, so to show graphics you use graphics.show() independently of the interface. Maybe you can tell us what you want to achieve, not how? On Monday, July 15, 2013 9:58:55 AM UTC-4, Pedro Cruz wrote: Hello, what sequence of instructions could tell what Sage 5.10 user-interface is currently being used ? Possible answers are: - cloud.sagemath.org - Sage Notebook - linux command line - windows command line (?) - cygwin command line (?) - new others... Long ago I used to check if variable sage.plot.plot.EMBEDDED_MODE is defined to see if notebook is being used. Thank you, Pedro -- 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] Custom derivative output from pynac
Dear all,
I was wondering about a way to get a custom derivative output,
that is more readable for an end-user. For example, in pynac.pyx,
py_print_fderivative() returns the operator as
ostr = ''.join(['D[', ', '.join([repr(int(x)) for x in params]), ']'])
whereas it would be nice to have
ostr = ''.join(['D_{', ', '.join([repr(args[int(x)]) for x in params]),
'}'])
What is a recommended way to get such a custom output from
a level of an external package?
Best regards,
Michal
--
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.
Re: [sage-devel] Re: Products of permutations use nonstandard order of operation
Hi Marco and all, I had Darij's problem as well, and many others probably did as well. In a right action, I would prefer p(1) to give a warning. In a right action, I would want some notation where p is on the right, preferably 1^p (1 hat p). That would make sense (except that I don't really see why ^ is better than *, see below). In principle one can even allow completely symmetric notation: - left action of g on x: g(x) or g^x; think of [left exponent g]x in two-dimensional notation - right action of g on x: (x)g or x^g Of course g^x and (x)g look a bit funny and maybe too confusing, but this is just because we are used to thinking that g^x means that x is in the exponent (as opposed to g, on the left), and we are not used to (x)g at all. I guess existing parsers could be enhanced to accept all these notations if somebody is crazy enough to want them. 8-) The notation * has the wrong distributive laws in case of actions on rings or groups. Of course this is irrelevant for permutations acting on sets, but since Galois groups can be interpreted as permutation groups too and they act on rings, the hat is much better. For both left and right actions, whether multiplicative (*, similar binary symbols or the empty notation) or exponential notation (^, left or right exponents) looks more natural depends on whether you are looking at the behaviour of the group action with respect to addition or with respect to multiplication. The following (and their equivalents for right actions) look OK: g*(x + y) = g*x + g*y [left exponent g](x*y) = [left exponent g]x * [left exponent g]y g^(x*y) = (g^x)*(g^y) (as long as you think of g as the exponent, not x and y) But the following look somewhat less appropriate: g*(x*y) = (g*x)*(g*y) [left exponent g](x + y) = [left exponent g]x + [left exponent g]y (especially strange for right actions) g^(x + y) = g^x + g^y 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 https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Products of permutations use nonstandard order of operation
On Mon, Jul 15, 2013 at 10:34 AM, Peter Bruin pjbr...@gmail.com wrote: Hi Marco and all, I had Darij's problem as well, and many others probably did as well. In a right action, I would prefer p(1) to give a warning. In a right action, I would want some notation where p is on the right, preferably 1^p (1 hat p). That would make sense (except that I don't really see why ^ is better than *, see below). In principle one can even allow completely symmetric notation: - left action of g on x: g(x) or g^x; think of [left exponent g]x in two-dimensional notation Trivial remark: I don't think anybody is suggesting that we use exponentiation to denote a *left* action. Above, he wrote In a right action, I would want - right action of g on x: (x)g or x^g Of course g^x and (x)g look a bit funny and maybe too confusing, but this is just because we are used to thinking that g^x means that x is in the exponent (as opposed to g, on the left), and we are not used to (x)g at all. I guess existing parsers could be enhanced to accept all these notations if somebody is crazy enough to want them. 8-) The notation * has the wrong distributive laws in case of actions on rings or groups. Of course this is irrelevant for permutations acting on sets, but since Galois groups can be interpreted as permutation groups too and they act on rings, the hat is much better. For both left and right actions, whether multiplicative (*, similar binary symbols or the empty notation) or exponential notation (^, left or right exponents) looks more natural depends on whether you are looking at the behaviour of the group action with respect to addition or with respect to multiplication. The following (and their equivalents for right actions) look OK: g*(x + y) = g*x + g*y [left exponent g](x*y) = [left exponent g]x * [left exponent g]y g^(x*y) = (g^x)*(g^y) (as long as you think of g as the exponent, not x and y) But the following look somewhat less appropriate: g*(x*y) = (g*x)*(g*y) [left exponent g](x + y) = [left exponent g]x + [left exponent g]y (especially strange for right actions) g^(x + y) = g^x + g^y 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 https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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.
Re: [sage-devel] Re: Products of permutations use nonstandard order of operation
2013/7/15 Peter Bruin pjbr...@gmail.com:
Hi Marco and all,
I had Darij's problem as well, and many others probably did as well.
In a right action, I would prefer p(1) to give a warning. In a right
action, I would want some notation where p is on the right, preferably
1^p (1 hat p).
That would make sense (except that I don't really see why ^ is better than
Hi Peter,
I was just saying that I prefer ^ personally (reasons below if you
really want to know), but never for left actions, and actually not
even for all right actions. This must be true for more people. So why
not allow multiple notations:
g(x) (but give a warning if it is a right action)
g*x (but give a warning if it is a right action)
x*g (but give a warning if it is a left action)
x^g (but give a warning if it is a right action)
We can even have three types of actions: left, right, and commutative
(for commutative groups acting, where one could let g(x), g*x, x*g,
x^g all give the same result with no warnings).
*, see below). In principle one can even allow completely symmetric
notation:
Yes, but I would discourage writing left actions as right actions or
vice versa. The associative laws become a great source of confusion
and mistakes. For example, x^(g*h) = (x^g)^h makes sense where the
current notation suggests the (in current Sage incorrect) (g*h)(x) =
g(h(x)).
- left action of g on x: g(x) or g^x; think of [left exponent g]x in
two-dimensional notation
- right action of g on x: (x)g or x^g
Of course g^x and (x)g look a bit funny and maybe too confusing, but this is
just because we are used to thinking that g^x means that x is in the
To people who use hats for exponentiation and/or latex superscripts,
g^x can only mean that x is in the exponent. The only notation I can
think of where g is in the superscript is the ugly ${}^g x$ (which is
sometimes really used in the literature), but I don't see how to do
that in Python and I don't expect to be very popular in Sage.
For both left and right actions, whether multiplicative (*, similar binary
symbols or the empty notation) or exponential notation (^, left or right
exponents) looks more natural depends on whether you are looking at the
behaviour of the group action with respect to addition or with respect to
multiplication.
True, but (and this debate about * versus ^ is not really
important, so this is the place to stop reading this post if you still
are, it also is not really about permutation groups acting on sets of
integers.)
I'll take Peter's examples, but only for right actions of course,
there is no discussion about notations for left actions.
For actions on rings and additive groups:
(x+y)^g = x^g + y^g violates no rules of arithmetic in itself,
just looks funny
(x+y)*g = x*g + y*g is a very nice distributive law
For actions on commutative rings and multiplicative groups:
(x*y)^g = (x^g) * (y^g) is a very nice distributive law
(x*y)*g violates the associative rule for multiplication, since
(x*y)*g = x*(y*g) is only true if g acts trivially on x.
So in some situations * is very bad, while in all situations ^ is ok.
Also, I sometimes choose a right action *because* I want to use
exponential notation, as in e.g. x^(1-g) = x / (x^g).
--
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] change_ring and affine patches for toric varieties
When you change the ring for a toric variety, that ring change does not propagate to the affine patches on the toric variety. Here's an example: o = lattice_polytope.octahedron(3) cube = o.polar() VRes = CPRFanoToricVariety(Delta_polar=cube, coordinate_points=all) q =5^2 field = GF(q, 'a') VRes.change_ring(field) patch = VRes.affine_patch(0) em = patch.embedding_morphism() emDomain = em.domain() emDomain.base_ring() This returns Rational Field. VRes is a 3-dimensional toric variety, so emDomain should be field^3. If you try to map an element of field^3 into VRes using the patch embedding morphism, you get a type error due to a failed coercion. For example, em(emDomain(field(1), field(1), field(1))) returns TypeError: Unable to coerce 1 (type 'sage.rings.finite_rings.element_givaro.FiniteField_givaroElement') to Rational --Ursula. -- 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] Re: change_ring and affine patches for toric varieties
That is correct. The change_ring() methods in Sage return a new object and do _not_ modify the original object: sage: x = toric_varieties.P2() sage: x.base_ring() Rational Field sage: x.change_ring(GF(3)).base_ring() Finite Field of size 3 sage: x.base_ring() Rational Field Similar: sage: R = PolynomialRing(QQ, 'x') sage: R.base_ring() Rational Field sage: R.change_ring(GF(3)) Univariate Polynomial Ring in x over Finite Field of size 3 sage: R.base_ring() Rational Field On Monday, July 15, 2013 5:57:21 PM UTC-4, Ursula wrote: When you change the ring for a toric variety, that ring change does not propagate to the affine patches on the toric variety. Here's an example: o = lattice_polytope.octahedron(3) cube = o.polar() VRes = CPRFanoToricVariety(Delta_polar=cube, coordinate_points=all) q =5^2 field = GF(q, 'a') VRes.change_ring(field) patch = VRes.affine_patch(0) em = patch.embedding_morphism() emDomain = em.domain() emDomain.base_ring() This returns Rational Field. VRes is a 3-dimensional toric variety, so emDomain should be field^3. If you try to map an element of field^3 into VRes using the patch embedding morphism, you get a type error due to a failed coercion. For example, em(emDomain(field(1), field(1), field(1))) returns TypeError: Unable to coerce 1 (type 'sage.rings.finite_rings.element_givaro.FiniteField_givaroElement') to Rational --Ursula. -- 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] Re: change_ring and affine patches for toric varieties
On Monday, July 15, 2013 3:09:29 PM UTC-7, Volker Braun wrote: That is correct. The change_ring() methods in Sage return a new object and do _not_ modify the original object: Fair enough. I think we have found a true coercion problem involving finite fields toric varieties, though. This one arises when constructing anticanonical hypersurfaces in a Fano toric variety with coefficients in a finite field. Let's make a smooth Fano toric variety over a finite field of non-prime order: o = lattice_polytope.octahedron(3) cube = o.polar() VRes = CPRFanoToricVariety(Delta_polar=cube, coordinate_points=all) field = GF(5^2, 'a') X=VRes.change_ring(field) Then let's define a hypersurface with coefficients specified by a list of elements in our field: hyp = X.anticanonical_hypersurface(monomial_points=vertices+origin, coefficients=[field(1),field(1),field(1),field(1),field(1),field(1),field(3)]) This raises a type error: Error in lines 6-6 Traceback (most recent call last): File /mnt/home/7tQIE6sJ/.sagemathcloud/sage_server.py, line 494, in execute exec compile(block+'\n', '', 'single') in namespace, locals File , line 1, in module File /mnt/home/7tQIE6sJ/sage-5.10-linux-64bit-ubuntu_12.04.2_lts-x86_64-Linux/local/lib/python2.7/site-packages/sage/schemes/toric/fano_variety.py, line 905, in anticanonical_hypersurface return AnticanonicalHypersurface(self, **kwds) File /mnt/home/7tQIE6sJ/sage-5.10-linux-64bit-ubuntu_12.04.2_lts-x86_64-Linux/local/lib/python2.7/site-packages/sage/schemes/toric/fano_variety.py, line 1438, in __init__ for m, coef in zip(monomial_points, coefficients)) File /mnt/home/7tQIE6sJ/sage-5.10-linux-64bit-ubuntu_12.04.2_lts-x86_64-Linux/local/lib/python2.7/site-packages/sage/schemes/toric/fano_variety.py, line 1432, in genexpr coefficients = (F(SR(coef)) for coef in coefficients) File parent.pyx, line 961, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:8136) File coerce_maps.pyx, line 82, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3856) File coerce_maps.pyx, line 77, in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/structure/coerce_maps.c:3757) File /mnt/home/7tQIE6sJ/sage-5.10-linux-64bit-ubuntu_12.04.2_lts-x86_64-Linux/local/lib/python2.7/site-packages/sage/rings/finite_rings/finite_field_givaro.py, line 362, in _element_constructor_ return self._cache.element_from_data(e) File element_givaro.pyx, line 377, in sage.rings.finite_rings.element_givaro.Cache_givaro.element_from_data (sage/rings/finite_rings/element_givaro.cpp:6428) File element_givaro.pyx, line 490, in sage.rings.finite_rings.element_givaro.Cache_givaro.element_from_data (sage/rings/finite_rings/element_givaro.cpp:6126) TypeError: unable to coerce We suspect the problematic coercion comes from this line in the AnticanonicalHypersurface class: # Direct conversion a/b to F does not work in Sage-4.6.alpha3, # so we go through SR, even though it is quite slow. coefficients = (F(SR(coef)) for coef in coefficients) --Ursula. -- 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] Re: change_ring and affine patches for toric varieties
Yes that line looks suspicious... On Monday, July 15, 2013 7:40:36 PM UTC-4, Ursula wrote: # Direct conversion a/b to F does not work in Sage-4.6.alpha3, # so we go through SR, even though it is quite slow. coefficients = (F(SR(coef)) for coef in coefficients) -- 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 on Ubuntu 13.04
Hi Pablo, At the moment the PPA is 64bit only. I might do 32bit in a few months. There is a binary for 13.04 here: http://boxen.math.washington.edu/home/sagemath/sage-mirror/linux/32bit/sage-5.10-linux-32bit-ubuntu_13.04-i686-Linux.tar.lzma Regards, Jan -- Forwarded message -- From: Pablo Fernando Zubieta Rico pablof...@yahoo.com.mx Date: 15 July 2013 23:15 Subject: Sage on Ubuntu 13.04 To: j...@aims.ac.za j...@aims.ac.za Hi again I wrote you before to explain that I wasn't able to install de sagemath-upstream-binary adding the Sage PPA, but looking into the packages details, I found they were 64-bit packages. I have a 32-bit installation. Is there any plan on uploading 32-bit versions? Thank you, Pablo Zubieta -- .~. /V\ Jan Groenewald /( )\www.aims.ac.za ^^-^^ -- 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.
