Re: [sage-devel] Should RR coerce into RIF?
2014-03-18 19:16 GMT+01:00 Thierry sage-googlesu...@lma.metelu.net: Is Sage able to allow a coercion from A to B, but the coercion map is not the same as the conversion map there (i mean, could the coercion be a partial map of the conversion) ? In Sage/python, you can do whatever you want, but this will make people very unhappy. The rules for coercions are: if a coercion from A to B exists, then it has to be a map on all elements of A, and has to equal the conversion from A to B. http://www.sagemath.org/doc/thematic_tutorials/coercion_and_categories.html#the-four-axioms-requested-for-coercions -- 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] Should RR coerce into RIF?
Thanks for all the replies. It seems that everybody here agrees to disallow coercions from RR to RIF, which is all that ticket http://trac.sagemath.org/ticket/15114 is about, so that ticket can proceed. As for conversions or coercions RIF to RR, there doesn't seem to be anybody strongly in favour having them, and it is not clear how it should work, so I won't touch them. 2014-03-19 16:39 GMT+01:00 Robert Bradshaw rober...@math.washington.edu: +1 to all of this, specifically 1) allow 2) allow for point intervals (maybe) 3) dissallow On Tue, Mar 18, 2014 at 3:02 PM, David Roe roed.m...@gmail.com wrote: Marc Mezzarobba wrote: Marco Streng wrote: So the choices are: 1) explicit conversion RR -- RIF: allow / disallow 2) explicit conversion RIF -- RR: allow / disallow 3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR) [...] My vote is: 1) allow 2) allow 3) from RIF to RR Mine is: 1) allow 2) allow for point intervals, require the use of explicit method calls (e.g., center()) for general intervals 3) disallow (but see below) Regarding 3), and in response to Thomas Coffee's arguments, I would be in favor of also having non-rigorous intervals, living in a separate parent, with a coercion from RR. In fact, one also needs intervals with integer, rational or even symbolic endpoints from time to time. So unless I'm missing something, these non-rigorous interval could simply be the elements of Intervals(RR), where Intervals(C) would work for more or less arbitrary C. (And there could perhaps be a coercion from RIF to Intervals(RR), but certainly not in the other direction.) I agree with Marc, though I note that C needs at least a partial ordering, which most rings don't come with. On Tue, Mar 18, 2014 at 2:16 PM, Thierry sage-googlesu...@lma.metelu.net wrote: It seems there are more precise cases to consider: - How do you plan to coerce a RIF element with non-trivial diameter to a RR element ? I would say you don't even allow conversion in this case, let alone coercion. - How do you plan to convert - from RealIntervalField(2) to RealField(100) ? If you start with a point interval, there's no problem. Otherwise, disallowed. - from RealIntervalField(100) to RealField(2) ? Conversion should work as long as the upper and lower endpoints are the same in RealField(2). - from RealField(100) to RealIntervalField(2) ? Smallest interval containing the input. - from RealField(2) to RealIntervalField(100) ? Here you can use a point interval as the image. Of course, none of these should be coercions. - How do you mix both (do you plan to deal with possible compensations between number of bits of precision of the field and the diameter of the intervals) ? I would say yes: you can mix a change in precision with a change in precision type. For example, in which case do you allow (silent) coercion, and what should be the result of the (explicit) conversion: - RIF(-1,1) - RR Coercion and conversion should both fail. - RealIntervalField(100)(1.1,1.2)) - RealField(2) Coercion and conversion should both fail. - RealField(2)(pi) - RIF [which diameter, which endpoints ?] A point interval (3.0, 3.0) As for me, - it is clear that RIF(pi) should be coerced to RR(pi) I think that this actually isn't clear, since RIF(pi) is not a point interval. Of course, we could make a special case when the length of the interval is the minimum possible, and use the rounding mode of RR to determine which endpoint to pick (though I don't know what we should do in the default 'RNDN' - i agree with coercing from x in RealIntervalField(a) to RealField(b) when the endpoints of x are the same in RealField(b) Coercion needs to be defined on the whole domain. This rule works for conversion though. - i have no problem for explicit conversion from RIF(-1,1) to RR, but it should be well specified in the doc, since there is no canonical way. I think it should be disallowed, since there are already functions to get the lower, upper and center. - i am not sure wether RIF(-1,1) should coerce to RR Definitely not. Is Sage able to allow a coercion from A to B, but the coercion map is not the same as the conversion map there (i mean, could the coercion be a partial map of the conversion) ? No. If a coercion exists, it must be defined on all of A and must agree with the conversion map from A to B. As for me, i am against RR - RIF coercion because some Sage code (not user code) could convert from RIF to RR because of some internal multiplication, and then silently back to RIF (if the coercion RR-RIF were allowed), leading to a false sense of precision and even the experienced user will not noticing it (no none can be assumed to know all Sage source code), and will not be able to hand-check this as suggested in the comment, since not all computations are done by the user. +1
Re: [sage-devel] Should RR coerce into RIF?
It looks like this discussion just started again on trac, so maybe we should continue the discussion here and/or vote. To summarize: the consensus on this thread was that automatic coercions should to from RIF to RR, not from RR to RIF. The reason was that elements of RIF represent guaranteed intervals, while elements of RR represent approximations that are expected to have some rounding errors, so if you combine them, then a RIF result will be incorrect. Because of this, trac ticket 15114 was opened, which contains an example of a calculation with an incorrect answer. On that ticket, the user tcoffee mentions two applications that get broken by removing or inverting the coercion RR -- RIF: the use of exact power of 2 from RR and mixing them with RIF to get elements of RIF, and the use of RIF for representing ranges of inexact floating point numbers and mixing those with regular floating point numbers. For details, see the track ticket. So the choices are: 1) explicit conversion RR -- RIF: allow / disallow 2) explicit conversion RIF -- RR: allow / disallow 3) automatic coercisions: disallow / (RR--RIF) / (RIF--RR) The current situation afaik (Sage 6.0) is: 1) allow 2) disallow 3) from RR to RIF My vote is: 1) allow 2) allow 3) from RIF to RR Best, Marco Op woensdag 28 augustus 2013 12:00:28 UTC+2 schreef Marco Streng: It seems like everyone agrees that coercions from RR to RIF should be removed, so I created http://trac.sagemath.org/ticket/15114 -- 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: Best library for integer factorization (ecmfactor and the B1 parameter)
2014-01-30 Ondřej Čertík ondrej.cer...@gmail.com Hi Volker, I see. So is my understanding correct, that the proper usage of the ECM is as follows: 1. Determine if N is prime, using pari(N).ispseudoprime(). The standard conjecture is that there exist infinitely many counterexamples, even though no single one is known. Step 1+1/3: Determine if N is a perfect power (N.is_perfect_power()). Step 1+2/3: Do trial division to remove small prime factors, and maybe some other factorization algorithms that perform well on small ranges. This all depends on the kind of number you are trying to factor. 2. If N is not prime, lookup the proper B1 using the table I posted. 3. Keep calling ecmfactor() until it gives you a factor. It must give you a factor eventually. eventually can take a long time. So after a while, you may want to switch to the quadratic sieve or the number field sieve (say cado-nfs) if you still don't get your factors. ? Ondrej On Thu, Jan 30, 2014 at 12:04 PM, Volker Braun vbraun.n...@gmail.com wrote: Just calling ecmfactor from the innards of the ecm library is just trying one elliptic curve (see the docs). This is not going to be really useful by itself. sage: ecm.factor(121) [11, 11] Relevant discussion at http://trac.sagemath.org/ticket/15443 On Thursday, January 30, 2014 6:35:46 PM UTC, Ondřej Čertík wrote: Hi, What is the state of the art library for factoring integers? I was under the impression, that it is the GCM-ECM library (http://ecm.gforge.inria.fr/). I've been trying to use ECM and I noticed the following behavior: sage: from sage.libs.libecm import ecmfactor sage: N = 121 sage: factor(N) 11^2 sage: ecmfactor(N, 1) (True, 121) sage: ecmfactor(N, 100) (True, 121) sage: ecmfactor(N, 200) (True, 121) sage: ecmfactor(N, 0) (True, 121) sage: ecmfactor(N, 0.) (True, 11) In other words, it never finds the factor 11, unless you give it B1=0.0 Compared to N=122, where it always finds it: sage: N = 122 sage: factor(N) 2 * 61 sage: ecmfactor(N, 1) (True, 2) sage: ecmfactor(N, 100) (True, 2) sage: ecmfactor(N, 200) (True, 2) I have a few questions: * Does this mean that ECM only works sometimes? * Is there a parameter B1, that always works? In the README file of the ecm-6.4.4 package, I found: digits D optimal B1 default B2 expected curves N(B1,B2,D) -power 1 default poly 20 11e3 1.9e6 74 74 [x^1] 255e4 1.3e7221 214 [x^2] 30 25e4 1.3e8453 430 [D(3)] 351e6 1.0e9984 904 [D(6)] 403e6 5.7e9 2541 2350 [D(6)] 45 11e63.5e10 4949 4480 [D(12)] 50 43e62.4e11 8266 7553 [D(12)] 55 11e77.8e11 2015817769 [D(30)] 60 26e73.2e12 4717342017 [D(30)] 65 85e71.6e13 7766669408 [D(30)] Table 1: optimal B1 and expected number of curves to find a factor of D digits with GMP-ECM. The only documentation about ECM that I found in Sage is this: http://www.sagemath.org/doc/bordeaux_2008/integer_factorization.html http://www.sagemath.org/doc/reference/libs/sage/libs/libecm.html But it doesn't answer my questions above. If the answer is that ECM only works sometimes, but it's not a reliable way to factor integers, what is the fastest library that always works? Many thanks, Ondrej -- 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. -- 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
Re: [sage-devel] imag(CC(infinity)) is 0?
2013/10/8 John Cremona john.crem...@gmail.com Now a mathematician would argue that the last one should raise some kind of error since we are apparently asking for the equality of objects in incomparable domains. But Python requires (I believe) that == should always return True or False, so that is not an option. I can't find such a restriction here: http://docs.python.org/3/reference/datamodel.html#object.__eq__ Returning any value (explicitly including NotImplemented) is allowed, nothing is said about raising exceptions. -- 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] imag(CC(infinity)) is 0?
2013/10/8 Peter Bruin pjbr...@gmail.com The only two options that seem acceptable to me are - disallowing RR(oo) (if RR is taken to represent the field of real numbers as opposed to the extended real line); Sage's in is not a mathematical \in, Sage's RR is not the field of real numbers. Peter is arguing to make them behave more like they are. Others are arguing not to change these things for various reasons. (And I will not get myself tangled up in that, since I don't know enough about floating point standards, nor do I know the reasons behind Sage's definition of in.) But in any case, the current tutorial makes people think that in and RR mean exactly what they mean in mathematics. Their first occurrence in the tutorial is in http://www.sagemath.org/doc/tutorial/tour_rings.html and I quote: the real numbers, called RR in Sage ... Of course, this is not a rational number:: sage: i # square root of -1 I sage: i in QQ False So the tutorial says RR is the ring of real numbers, and in QQ tests whether something is a rational number. Extending this, the tutorial says oo in RR tests whether infinity is a real number! This tutorial would be a logical place to say that Sage's in and RR do not always mean what mathematicians think they do. The following examples / warnings would be in place when introducing in and RR to new users. sage: oo in RR True sage: Zmod(5)(3) in ZZ True Shall I open a ticket to add these caveats to the end of http://www.sagemath.org/doc/tutorial/tour_rings.html ? And is there a way to make one of the following work (and give some explanation as to how in is implemented and what it means): sage: in? Object `in` not found. sage: ?in Object `in` not found. - making the in keyword treat infinity as a special case. Either Sage's RR has an infinity element or it does not. And in this case the coercion framework correctly recognizes this and gives the output accordingly. If you are to introduce special cases, then some things are much worse: sage: Zmod(5)(3) in ZZ True -- 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] imag(CC(infinity)) is 0?
2013/10/8 Peter Bruin pjbr...@gmail.com sage: Mod(2,6)==Mod(4,8) True sage: Mod(1,3)==Mod(2,4) False Wow, that's because the first two are compared in the common quotient Zmod(2) of Zmod(6) and Zmod(8), but a special case was made to disallow using the common quotient Zmod(1) of Zmod(3) and Zmod(4): sage: (Mod(2,6)-Mod(4,8)).parent() # This is a mathematically reasonable answer, and explains the True above. Ring of integers modulo 2 sage: sage.categories.pushout.pushout(Zmod(8), Zmod(6)) Ring of integers modulo 2 sage: (Mod(1,3)-Mod(2,4)).parent() # And here is the reason for the False above. TypeError: unsupported operand parent(s) for '-': 'Ring of integers modulo 3' and 'Ring of integers modulo 4' sage: sage.categories.pushout.pushout(Zmod(4), Zmod(3)) # And here is the reason for the TypeError above: CoercionException: Trivial quotient intersection. So it seems that sage.categories.pushout.pushout(Zmod(m), Zmod(n)) is Zmod(gcd(m,n)) unless m and n are coprime, in which case it raises an error. This looks like a rather inconsistent choice to me. Unfortunately it is hard to think of a simple rule that gives the desired behaviour in all of the following cases: sage: Mod(1, 3) == ZZ(1) True # current behaviour; certainly OK sage: Mod(1, 3) == QQ(1) False # current behaviour; probably OK, but True wouldn't be completely wrong sage: Mod(1, 3) == Mod(1, 4) False # current behaviour; certainly OK sage: Mod(1,3) == Mod(1, 6) True # current behaviour; probably OK, but False wouldn't be completely wrong sage: Mod(2, 6)==Mod(4, 8) False # currently yields True sage: 2/1 in ZZ True sage: Mod(3, 5) in ZZ False # currently yields True sage: Mod(1,3) in Zmod(6) False # currently yields True sage: Mod(2,4) in Zmod(6) False # currently yields True 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. -- 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: Factorization of multivariate integer polynomial
2013/10/7 Jori Mantysalo jori.mantys...@uta.fi On Mon, 7 Oct 2013, John Cremona wrote: sage: R.x,y = ZZ[]; print (4*x^2-1).factor() --**--** --- NotImplementedError Traceback (most recent call last) But that is just what I would like to implement, i.e. make few lines of code that converts polynomial to QQ, factors it and then convert back to ZZ. Great, when you do, make sure to mention the ticket number on this thread. (But my first suggestion lacks .unit(), which need to be added.) It's not just a matter of units. In polynomial rings over QQ, all non-zero constants are units. In polynomial rings over ZZ, only +/- 1 are units, prime numbers are primes, and composite numbers are neither units nor primes (hence need to be factored). This is correctly implemented for ZZ[x], QQ[x] and QQ[x,y]: sage: P.x = ZZ[] sage: p = -15*(3*x+2)*(7*x-5) sage: f = p.factor() sage: f.unit() -1 sage: list(f) [(3, 1), (5, 1), (3*x + 2, 1), (7*x - 5, 1)] sage: P.x = QQ[] sage: p = -15*(3*x+2)*(7*x-5) sage: f = p.factor() sage: f.unit() -315 sage: list(f) [(x - 5/7, 1), (x + 2/3, 1)] sage: P.x,y = QQ[] sage: p = -15*(3*x+2)*(7*x-5) sage: f = p.factor() sage: f.unit() -15 sage: list(f) [(3*x + 2, 1), (7*x - 5, 1)] -- Jori Mäntysalo -- 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+unsubscribe@**googlegroups.comsage-devel%2bunsubscr...@googlegroups.com . To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/**group/sage-develhttp://groups.google.com/group/sage-devel . For more options, visit https://groups.google.com/**groups/opt_outhttps://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] imag(CC(infinity)) is 0?
2013/10/5 William Stein wst...@gmail.com
On Fri, Oct 4, 2013 at 1:56 PM, Greg Laun greg.l...@gmail.com wrote:
Thanks Peter. I agree that infinity in RR is a big problem. For those
following the discussion, Peter updated Trac ticket #11506 to reflect
this
concern and it is now marked as a critical bug.
I've added a long comment there
(http://trac.sagemath.org/ticket/11506#comment:8). The issue we're
discussing is a side-effect of the *bug* that RR(oo) == oo evaluates
to True, but it should evaluate to False. Somebody (me?) just messed
I read that comment, but it looks like the coercion framework does what it
should. RR(oo) == oo is evaluated by coercion to InfinityRing, where
positive infinity equals positive infinity:
sage: oo
+Infinity
sage: oo.parent() is InfinityRing
True
sage: InfinityRing.has_coerce_map_from(RR)
True
As far as I can see, to make RR(oo) == oo evaluate to False (or give an
error), while staying consistent with the coercion framework, one would
need to either
- disallow the explicit conversion RR(oo), or
- remove the automatic coercion from RR to InfinityRing, or
- make InfinityRing(RR(oo)) finite.
Are you arguing for one of these?
The following all make sense and look useful:
sage: UnsignedInfinityRing.has_coerce_map_from(RR) # natural map RR --
{finite, infinite}
True
sage: UnsignedInfinityRing.has_coerce_map_from(CC) # natural map CC --
{finite, infinite}
True
sage: InfinityRing.has_coerce_map_from(RR) # natural map RR -- { -oo,
negative, 0, positive, +oo}
True
sage: InfinityRing.has_coerce_map_from(CC) # no natural map CC -- { -oo,
negative, 0, positive, +oo}
False
that up when implementing RR long ago. Somebody else (me?) got the
same thing for CC right though.
The implementation of RR and CC in Sage are a very direct wrapping of
MPFR, which is the most well-thought out efficient implementation of
floating point real numbers I've ever seen. It is worth visiting
http://www.mpfr.org/mpfr-current/mpfr.html and searching for
infinity.
-- William
On Thursday, October 3, 2013 5:31:06 PM UTC-4, Peter Bruin wrote:
Hello,
from the perspective of the Riemann sphere it's a bit odd since
CC(infinity,0), CC(0, infinity) and CC(infinity, infinity) are all
distinct
in sage, giving us 3 different complex infinities.
Here is another case of unexpected behaviour:
sage: CC(I)+CC(Infinity)==CC(2*I)+CC(Infinity)
False
sage: CC(I+Infinity)==CC(2*I+Infinity)
True
See Trac tickets #14088, #11506 and #14857 for other reported problems
with various infinities.
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.
--
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: Factorization of multivariate integer polynomial
2013/10/4 Jori Mantysalo jori.mantys...@uta.fi On Fri, 4 Oct 2013, Volker Braun wrote: If the integral polynomial is not monic then the roots need not be integral: sage: R.x = QQ[] sage: (4*x^2-1).factor() (4) * (x - 1/2) * (x + 1/2) (4*x^2-1) = (2*x-1)*(2*x+1) ZZ[x] has unique factorization, and so does ZZ[x,y], and so does any multivariate polynomial ring over ZZ. Indeed, for any UFD R, the polynomial ring R[x] is again a UFD, hence by induction so are multivariate polynomial rings. So this would not be factorizable in ZZ[x] but is factorizable in QQ[x] Of course. Duh. Anyways, is this possible path to (non-optimal) solution? Factor in QQ, get parts that are not integral polynomials and multiply them to get integral parts? It would of course be quite slow if polynomial happens to have many factors that must be check to find integral-producing products. Just take the factorization over QQ, then for each factor, make it a primitive integral polynomial, i.e., multiply by the lcm of the denominators of the coefficients and divide by the gcd of the numerators of the coefficients. Then you have a factorization into irreducible integral polynomials times some integer, factor that integer and you have the complete factorization over ZZ. The only part that can be slow is the factorization of the integer in the end, the rest is very fast. It just requires a little bit more programming than what you wrote before. -- Jori Mäntysalo -- 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+unsubscribe@**googlegroups.comsage-devel%2bunsubscr...@googlegroups.com . To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/**group/sage-develhttp://groups.google.com/group/sage-devel . For more options, visit https://groups.google.com/**groups/opt_outhttps://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.
[sage-devel] intel compiler
Hi sage-devel, Has anyone recently try to build sage with Intel's compilers? And if so, does that result in a fully functional sage and is there a significant speed gain? Thanks! Marco -- 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] Should RR coerce into RIF?
It seems like everyone agrees that coercions from RR to RIF should be
removed, so I created
http://trac.sagemath.org/ticket/15114
2013/8/26 Vincent Delecroix 20100.delecr...@gmail.com
I am strongly against conversion from floating-point to interval
field. Floatting point arithmetic is approximate whereas interval
arithmetic is guaranteed. Moreover, the conversion between non exact
rings in Sage are always from more precision to less precision.
For these reasons the conversion should be from RIF to RR and from CIF
to CC and not the other way around.
I agree that there are trivial conversions from RR to RIF and CC to
CIF but I do not want them as coercions.
An example: if I is an interval and try {{{sage: I.cos()}}} you know
that the image of I by the (mathematical) function cos is contained in
the result. Now if you allow the coercion to the real numbers you
assume that {{{sage: RR(I).cos()}}} is a good answer for the same
computation which is not! It might even be out of the image of I by
the (mathematical) function cos.
A counter example: If x is a real number and I is an interval what do
we want for the result of I+x? I would prefer to obtain an interval,
but I think of this operation as a right action of RR on RIF by
translations of the intervals and **not** as an addition.
Best,
Vincent
2013/8/26 Marco Streng marco.str...@gmail.com:
2013/8/26 Marc Mezzarobba m...@mezzarobba.net
Hi,
Sage happily coerces floating-point numbers (e.g., elements of RR) into
intervals (e.g., elements of RIF), subject to some conditions on the
precision of the source and destination rings.
The relevant portion of the coercion graph looks like this:
( +--- RDF )
||
Exact v
real--- RLF --- RR
fields |
|v
+--- RIF
The coercions RLF -- RIF and RLF -- RR -- RIF violate the requirement
that coercions should form a commutative diagram. Right now, it is not
too much of an issue in practice, because coercions X -- RIF are
constructed based on the existing coercions X -- RR and direct
coercions like RLF -- RIF always(?) end up being preferred to variants
going through RR.
But this is of course pretty fragile to changes in the coercion system.
If a coercion path of the form X -- RR -- RIF is ever chosen for some
exact ring X (whose elements are not exactly representable by elements
of RR!), arithmetic operations between elements of X and intervals will
yield mathematically incorrect results. Besides, things like
sage: iv = 1 + 2^(-55) + 0. + RIF(1)
sage: iv.lower(), iv.upper()
(2.00, 2.00)
can already make for subtle bugs in the current situation.
The same issue exists for CC, CIF and friends.
I see little value in having mixed operations between floating-point
numbers and intervals work automatically, so I would be in favor of
removing the coercions from floating-point rings to interval rings
altogether. What do you think?
+1
When I use interval arithmetic, I do that because I want a proof that a
number is in an interval. But I also know that I can make a mistake of
the
form of your example above. We can allow explicit conversions both ways,
but
it makes more sense to me if automatic coercions don't go from RealField
to
RealIntervalField.
--
Marc
--
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.
--
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
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.
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] python triggers virus scanner
I scanned my mac with Bitdefender today, and it deleted sage-5.10.rc2/local/lib/python2.7/test/testbz2_bigmem.bz2 sage-5.10.rc2/spkg/standard/python-2.7.4.p0.spkg It also attempted to delete sage-5.10.rc2.tar The reason and fix are here: http://bugs.python.org/issue17843 quote: Apparently the file triggers a warning in several anti virus programs because it looks like a zip bomb. Can we update to python 2.7.5? That would fix this problem: http://www.python.org/download/releases/2.7.5/ -- 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: python triggers virus scanner
Thanks! 2013/6/21 leif not.rea...@online.de: Marco Streng wrote: I scanned my mac with Bitdefender today, and it deleted sage-5.10.rc2/local/lib/python2.7/test/testbz2_bigmem.bz2 sage-5.10.rc2/spkg/standard/python-2.7.4.p0.spkg It also attempted to delete sage-5.10.rc2.tar The reason and fix are here: http://bugs.python.org/issue17843 quote: Apparently the file triggers a warning in several anti virus programs because it looks like a zip bomb. Can we update to python 2.7.5? That would fix this problem: http://www.python.org/download/releases/2.7.5/ That's #14600, merged into Sage 5.11.beta1. ;-) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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] Sage does not respond to Control C when computing orders in number fields
This is now http://trac.sagemath.org/sage_trac/ticket/14740 2013/5/28 Jeroen Demeyer jdeme...@cage.ugent.be: On 05/28/2013 11:37 AM, Volker Braun wrote: It might depend on when you are pressing ctrl-c; It didn't work when I tried it. I don't know what I can say, for me it always works. But sometimes the traceback can be very long, so perhaps the interrupt works but it simply takes a long time to display the traceback. -- 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. -- 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] Sage does not respond to Control C when computing orders in number fields
I don't understand what is going on. It seems like trac_14523_improve_attach.patch triggers the problem on my 5.10.beta2 (Mac), but sometimes it also happens on unpatched 5.10.beta5 (Mac) or 5.9.beta5 (Linux). The last time it happened on an unpatched Sage, it was after I waited a couple of minutes before pressing Ctrl+C. And closing the Terminal window on my Mac did not always kill the process when this happened. 2013/5/27 Jeroen Demeyer jdeme...@cage.ugent.be On 05/27/2013 09:57 PM, Marco Streng wrote: 5.10.beta2, Mac 10.6 and also 5.9.beta5, Linux I'm building beta5 now I doubt that something changed between beta2 and beta5, are you really sure that it doesn't work in beta2? Obviously something is wrong with the code since it uses very large amounts of memory (I suspect an infinite loop), but at least CTRL-C works for me. -- 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+unsubscribe@**googlegroups.comsage-devel%2bunsubscr...@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=enhttp://groups.google.com/group/sage-devel?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Sage does not respond to Control C when computing orders in number fields
2013/5/27 Jeroen Demeyer jdeme...@cage.ugent.be On 05/27/2013 12:23 AM, Marco Streng wrote: sage: Qa12.kappa12 = NumberField(x^14 - 26*x^13 + 325*x^12 - 2548*x^11 + 13832*x^10 - 54340*x^9 + 157118*x^8 - 333580*x^7 + 509366*x^6 - 534820*x^5 + 354536*x^4 - 124852*x^3 + 15145*x^2 - 33514*x + 13) sage: y = polygen(Qa12) sage: L.c = Qa12.extension(y^2-kappa12) sage: L.alpha = L.absolute_field() sage: OO = Qa12.maximal_order() sage: bas = [L.structure()[1](b) for b in OO.basis()] sage: subOrderK = L.order(bas + [b*alpha for b in bas]) Which version is that? 5.10.beta2, Mac 10.6 and also 5.9.beta5, Linux I'm building beta5 now CTRL-C works for me on sage-5.10.beta5, Linux x86_64. -- 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+unsubscribe@**googlegroups.comsage-devel%2bunsubscr...@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=enhttp://groups.google.com/group/sage-devel?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Sage does not respond to Control C when computing orders in number fields
2013/5/27 Marco Streng marco.str...@gmail.com 2013/5/27 Jeroen Demeyer jdeme...@cage.ugent.be On 05/27/2013 12:23 AM, Marco Streng wrote: sage: Qa12.kappa12 = NumberField(x^14 - 26*x^13 + 325*x^12 - 2548*x^11 + 13832*x^10 - 54340*x^9 + 157118*x^8 - 333580*x^7 + 509366*x^6 - 534820*x^5 + 354536*x^4 - 124852*x^3 + 15145*x^2 - 33514*x + 13) sage: y = polygen(Qa12) sage: L.c = Qa12.extension(y^2-kappa12) sage: L.alpha = L.absolute_field() sage: OO = Qa12.maximal_order() sage: bas = [L.structure()[1](b) for b in OO.basis()] sage: subOrderK = L.order(bas + [b*alpha for b in bas]) Which version is that? 5.10.beta2, Mac 10.6 and also 5.9.beta5, Linux I'm building beta5 now (building 5.10.beta5, that is) CTRL-C works for me on sage-5.10.beta5, Linux x86_64. -- 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+unsubscribe@**googlegroups.comsage-devel%2bunsubscr...@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=enhttp://groups.google.com/group/sage-devel?hl=en . For more options, visit https://groups.google.com/**groups/opt_outhttps://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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Sage does not respond to Control C when computing orders in number fields
On Fri, May 24, 2013 at 10:38 AM, Karl-Dieter Crisman kcris...@gmail.com wrote: Just pass this on to anyone who might know the answer (you? sage-nt?) - the same person asked this twice: http://stackoverflow.com/questions/11850418/computing-maximal-orders-in-large-number-fields-with-sage http://ask.sagemath.org/question/1652/computing-maximal-orders-in-relative-extensions I tried to answer the question, but ran into trouble. And the worst part is that Ctrl+C does not help me. Is a KeyboardInterrupt caught accidentally? Or is a keyboard interrupt not properly passed on to another program? I'm having trouble debugging this one. Perhaps I'm not knowledgeable or patient enough to work with the trace command. Any ideas? sage: Qa12.kappa12 = NumberField(x^14 - 26*x^13 + 325*x^12 - 2548*x^11 + 13832*x^10 - 54340*x^9 + 157118*x^8 - 333580*x^7 + 509366*x^6 - 534820*x^5 + 354536*x^4 - 124852*x^3 + 15145*x^2 - 33514*x + 13) sage: y = polygen(Qa12) sage: L.c = Qa12.extension(y^2-kappa12) sage: L.alpha = L.absolute_field() sage: OO = Qa12.maximal_order() sage: bas = [L.structure()[1](b) for b in OO.basis()] sage: subOrderK = L.order(bas + [b*alpha for b in bas]) ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C And once we get Ctrl+C to work, there is more work to do: In this case, Sage is having trouble with just one order, supplied by an actual basis. All Sage needs to do is verify that the input spans a ring. And the example is not too large. Indeed, Magma has no trouble even in finding the maximal order: sage: Om = magma(L).MaximalOrder() (a functional answer in a few seconds) -- 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.
Re: [sage-devel] SQRT of negative number is negative? Or positive? Or what?
As for the question html( In which kind of school do they teach
$\\sqrt{-2.4995} = - i 1.58$ ??? );, I think any good school that teaches
about complex numbers should teach that both - i 1.58 and i 1.58
are equally valid (approximate) square roots of -2.4995. One choice is as
good as another. Any choice one makes on the whole complex plane involves
(at least) a branch cut, cutting up the complex plane from the origin
outwards. At the branch cut, the square root function is non-continuous, so
any floating point implementation will be erratic near the branch cut (like
Sage and C are around the negative real axis). If you want to make a choice
that is different from your computer programme (such as mapping all numbers
to numbers with non-negative imaginary part), you will have to add a few
lines to the square root code that check the imaginary part of the output
and change the sign of the number if necessary.
2013/5/13 man...@gmx.net
Could anyone shed a bit of light on this?
The more I try, the more SAGE's types get in my way. It turns out to be
an unpredictable element. Unless I make sure *every* involved function
really returns one specific type, calculations are becoming practically
impossible, because the results are completely random (malfunctions).
Here is just the last and most annoying of my encounters I can't make
heads or tails of, enjoy:
http://alpha.sagenb.org/home/pub/701/
--
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.
--
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.
Re: [sage-devel] Re: can't escape sage after error in attached file (IPython experts?)
This is now http://trac.sagemath.org/sage_trac/ticket/14523
There are indeed choices to be made first, all options sound sensible.
2013/5/2 Nils Bruin nbr...@sfu.ca
On May 1, 9:45 am, Marco Streng marco.str...@gmail.com wrote:
And how to fix this? I have three ideas that all have a downside:
* Catching the error will destroy a valuable traceback (which I removed
above). Or is there a way to preserve that traceback and have it printed
somehow?
Apparently the traceback is there. One should be able to retrieve the
most recent one:
exc_type, exc_value, exc_traceback = sys.exc_info()
(just google for it -- there's some info in stack exchange about it)
So we could do something along the lines:
try:
reload_modified_attached_files()
except:
INFO = sys.exc_info()
print Warning. An exception occurred during reloading of ...
print_traceback(INFO)
print continuing with command you entered. Funny things can
happen
execute_command()
The problem with this is that usually the right thing to do IS to
abort if an error occurs on reloading an attached file. People will
probably get used to just entering an empty command to trigger reload
after they've edited though, so the extraneous execution of an empty
command will probably not affect much.
Not really important, but completely empty commands actually don't trigger
reloading.
sage: %attach myfile.sage
loading file
sage:
sage: file('myfile.sage','a').write('\nprint this line was added later')
sage:
sage:
sage:
sage:
sage:
sage: 1+1
loading file
this line was added later
2
sage: file('myfile.sage','a').write('\nprint this line was added later')
sage:
sage:
sage: ;
loading file
this line was added later
this line was added later
''
* How about attempting to reload only once (move the line
attached[fpath]
= os.path.getmtime(fpath) to just before execfile in
sage.misc.preparser.load)? This may hide the problem: there will be only
one error message when attach fails, which the user may mistake for an
error related to the last input, and then think the latest version of the
file is safely attached, while actually an old version is still being
used.
If that is accompanied by an explicit message
detaching file ... due to exception.
Execute 'attach(file)' to reattach.
I think that's the cleanest (and we actually do detach the file)
The other option is indeed
suspending reloading file ... due to exception
Reload will be reattempted if file modification is detected
(and then just update the reference timestamp as you suggest)
* Is it possible to separate the reloading from the evaluation of the
input
line? This may be the best option. Any idea how to implement that? Looks
like this is handled in IPython/core/interactiveshell.py , so it would
mean
patching IPython?
I think the option above, catch exception but print the traceback
anyway, would accomplish this in essence. Of course now we have to
answer questions such as: should we catch exceptions for each reloaded
file separately? Do we just print all tracebacks if multiple fail? Or
do we abort after first reload?
For reference, Magma does:
Attach(a.m);
Attach(b.m);
intrinsic_defined_in_a();
True
[invalidate a.m and b.m]
1;
[PC]
[PC] User error: syntax error at end of input
[PC]
[PC] User error: syntax error at end of input
intrinsic_defined_in_a();
User error: Identifier 'intrinsic_defined_in_a' has not been declared
or assigned
So:
- it reloads all attachments separately
- it still executes the command
- definitions in a failed reload really disappear
- reloads are only reattempted when another change is detected.
Due to python semantics, we cannot let previous attachments really
disappear, but we can do the rest.
--
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.
--
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] can't escape sage after error in attached file (IPython experts?)
Dear sage-devel,
Here's a minimal version of something that happened to me a few times
recently:
{{{
17:57:03:~$ touch myfile.sage
17:57:05:~$ sage
--
| Sage Version 5.8, Release Date: 2013-03-15 |
| Type notebook() for the browser-based notebook interface.|
| Type help() for help.|
--
sage: %attach myfile.sage
sage: file('myfile.sage', 'w').write('1/0')
sage: 1+1
...
ZeroDivisionError: Rational division by zero
sage: exit
...
ZeroDivisionError: Rational division by zero
sage: detach('myfile.sage')
...
ZeroDivisionError: Rational division by zero
}}}
It seems like the only way to continue using this Sage session is to fix
the error first. But suppose you have some reason not to (e.g. are in a
hurry, and the error is hard to fix). I think it would be much better if
Sage was to evaluate 1+1 and especially exit and detach even when
unable to reload one of the attached files. Shall I open a ticket for this?
And how to fix this? I have three ideas that all have a downside:
* Catching the error will destroy a valuable traceback (which I removed
above). Or is there a way to preserve that traceback and have it printed
somehow?
* How about attempting to reload only once (move the line attached[fpath]
= os.path.getmtime(fpath) to just before execfile in
sage.misc.preparser.load)? This may hide the problem: there will be only
one error message when attach fails, which the user may mistake for an
error related to the last input, and then think the latest version of the
file is safely attached, while actually an old version is still being used.
* Is it possible to separate the reloading from the evaluation of the input
line? This may be the best option. Any idea how to implement that? Looks
like this is handled in IPython/core/interactiveshell.py , so it would mean
patching IPython?
* Any other ideas?
Marco
--
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.
Re: [sage-devel] Who wants to review #3416: Weierstrass form lattice polytope stuff?
I can review the ticket you link to, if you can find a reviewer for the dependencies first. Most notably: http://trac.sagemath.org/sage_trac/ticket/12553 Add interface for PALP polytope databases 2013/4/14 Volker Braun vbraun.n...@gmail.com There is a somewhat interdisciplinary ticket for Weierstrass forms, in addition to undergraduate algebraic geometry there are dependencies for fast lattice polygons to review. Most of the code has been languishing on trac for year(s): http://trac.sagemath.org/3416 -- 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. -- 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.
Re: [sage-devel] Strange bug (or feature) in relative number fields
2013/2/19 Jeroen Demeyer jdeme...@cage.ugent.be: On 2013-02-19 20:54, David Roe wrote: I'm fairly sure the problem is that the defining polynomial for the relative extension is not monic. One solution would be to use an equivalent monic polynomial and keep track of a simple transformation allowing one to translate between the internal representation of elements on the one hand and print representations and conversions from polynomials on the other. This is http://trac.sagemath.org/sage_trac/ticket/252 Indeed, and since that isn't being fixed, maybe we should warn the user, as suggested here: http://trac.sagemath.org/sage_trac/ticket/252#comment:7 How about printing a warning when a non-monic or non-integral polynomial is fed to the number field constructor? That saves many people the time needed for debugging PariError. -- 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.
Re: [sage-devel] CDF[X] pretty-printing
I don't think it is a bug, rather it is a question about what polynomials are. CDF['x'](0) is the zero polynomial, with no coefficients, which really is equal to 0, not just a numerical 0.0. Polynomials in Sage have a well-defined degree, and that means that the leading coefficient cannot be (numerically) zero, the degree of 0.0 is ambiguous unless we decide that 0.0 is just 0, in which case we may as well print it as such. sage: P(0) 0 sage: P(0).list() [] sage: P(0).degree() -1 sage: P(1) 1.0 sage: P(1).list() [1.0] sage: P(1).degree() 0 sage: P.gen() # note that no + 0.0 is printed here either x sage: P.gen().list() [0.0, 1.0] sage: P.gen().degree() 1 2013/1/12 Charles Bouillaguet charles.bouillag...@gmail.com: Hi all, I just stumbled upon this: sage: CDF(0) 0.0 sage: CDF['x'](0) 0 I would have liked these two to pretty-print identically. OK, I agree that this is an ultra-minor nitpick, but it made doctest fail in the french sage book (http://trac.sagemath.org/sage_trac/ticket/11672). Should we somehow try to make CDF(y) and CDF['x'](y) print identically ? --- Charles Bouillaguet http://www.lifl.fr/~bouillaguet/ -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Changing the default behaviour of Poset
2012/11/12 Nicolas M. Thiery nicolas.thi...@u-psud.fr First thing: for those who want to know more on what a facade is: sage: S = Sets() sage: S.Facade? Object `S.Facade` not found. It should be: sage: S.Facades? -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Bits and pieces about Quotient Rings
2012/10/28 Charles Bouillaguet charles.bouillag...@gmail.com: Hi all, While playing with the quotient of a polynomial ring with an ideal, I encountered several glitches. *) Trying to compute the inverse of something which is not invertible. I know it is kind of weird to try this. However, it raises a NotImplementedError exception, instead of something more informative such as NonInvertible or whatever. I am willing to patch this, but could someone tell me what is the correct exception to raise? Based on http://docs.python.org/2/library/exceptions.html, it should be ValueError (unless Sage has a more precise error for this situation, but I don't think so). But in order to be able to raise a ValueError, you need to first decide whether your element is invertible or not. If such a decision mechanism is not implemented, then NotImplementedError is the only possibility. And I guess that is the current situation here. *) Non-deterministic output of some (presumably deterministic) functions Here is an example : sage: R.x1,x2 = QQ[] sage: I = R.ideal(x2**2 + x1 - 2, x1**2 - 1) sage: test = I.gen(0) + x2*I.gen(1) sage: (test).lift( I ) [1, x2] # this is correct sage: R.x1,x2 = QQ[] sage: I = R.ideal(x2**2 + x1 - 2, x1**2 - 1) sage: test = I.gen(0) + x2*I.gen(1) sage: (test + 1).lift( I ) [0, 0] # this is correct No it isn't, the correct output would be ValueError, as (test+1) is not in I. So this is a bug in the lift method. sage: R.x1,x2 = QQ[] sage: I = R.ideal(x2**2 + x1 - 2, x1**2 - 1) sage: test = I.gen(0) + x2*I.gen(1) sage: (test).lift( I ) [0, 0] # this is WRONG !!! should be [1, x2] It looks like this could be a caching issue, so I am not sure whether I need to open a new ticket for this, or if it is already catch by an already-opened ticket. It is some kind of corruption triggered by the abovementioned bug, so it may vanish when that bug is fixed. Here is a shortened version of your input: sage: R.x1,x2 = QQ[] sage: I = R.ideal(x2**2 + x1 - 2, x1**2 - 1) sage: test = I.gen(0) + x2*I.gen(1) sage: test.lift(I) # correct [1, x2] sage: (test+1).lift(I) # invalid input, should give error [0, 0] sage: test.lift(I) # incorrect [0, 0] *) Segfault The same kind of problem allows a small piece of code to cause segfaults in SAGE (apparently in singular-related stuff) : sage: R.x1,x2 = QQ[] sage: S = R.quotient_ring( R.ideal(x2**2 + x1 - 2, x1**2 - 1) ) sage: 1 / S(x1 + x2)# should raise NotImplementedError sage: sage: R.x1,x2 = QQ[] sage: S = R.quotient_ring( R.ideal(x2**2 + x1 - 2, x1**2 - 1) ) sage: S.is_integral_domain() --- BOOM *) bizarre output of p.lift(….) When R is a Polynomial Ring, I is an ideal of R, and p is a polynomial of I, then p.lift( I ) returns a polynomial combination of a (groebner) basis of I which is equal to p. However, when p is not in I, then p.lift( I ) returns [0,0,…,0]. I find this a bit strange. Should p.lift(…) raise an exception instead? This would be a change of specification, so I guess it should be discussed first… --- Charles Bouillaguet http://www.lifl.fr/~bouillaguet/ -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-devel group. 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. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Sage whitespace policy
2012/8/14 Robert Bradshaw rober...@math.washington.edu: TestsPassed PluginFailed, so it will only ever be blue if all tests I assume this is an implication arrow to the left. So ok, forget about my suggestion and thanks for the explanation! passed but one or more plugins failed -- -- 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
Re: [sage-devel] Re: Sage whitespace policy
2012/8/14 Robert Bradshaw rober...@math.washington.edu: Volkers point is right on: the patchbot is purely advisory. Then I suggest a small change to the patchbot. iirc, the patchbot (and its blob on trac) shows a huge plugin failed when there are trailing whitespaces on changed/added lines, without saying anything about whether the Sage doctests pass. You have to open the log file to see the result of the doctests. Can we make the doctest results more prominent again (like they were before the introduction of this plugin)? -- -- 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
Re: [sage-devel] Units in Orders
On 13/08/2012 06:50, David Roe wrote: Thanks for the pointer to that ticket, which explains the change in the the is_unit() behavior. Why should the inverse of four succeed when the result is not in K? sage: four^-1 in K False The order K is analogous to the ring of integers inside QQ. So even though the inverse of four exists in the number field, it's not in the order and thus four is not a unit. See http://en.wikipedia.org/wiki/Order_%28ring_theory%29 Exactly. This is completely analogous to the following: sage: 4.parent() is ZZ True sage: 4.is_unit() False sage: 4^-1 1/4 sage: 4^-1 in ZZ False sage: (4^-1).parent() is QQ True In your example, ZZ is replaced with the order K, and QQ is replaced by the field of fractions of K, which is the number field QQ(sqrt(-3)). On #12242 (a follow-on to the ticket above), David Loeffler argues that the following is the wrong behavior, and that the last command should raise an error. sage: K.a = NumberField(x^2 - x - 1); OK = K.ring_of_integers() sage: OK(12).divides(OK(13)) True Here again OK is a generalization of ZZ. In K, 12 does divide 13 and the quotient is 13/12, but since 13/12 is not in OK, the answer should be False as David says. sage: OK(12) // OK(13) 12/13 Since OK is a generalization of ZZ, we look at what // does for ZZ. From the reference manual, http://www.sagemath.org/doc/tutorial/tour_assignment.html : sage:10//4# for integer arguments, // returns the integer quotient 2 So // gives the integral part of the quotient, forgetting the remainder. Just like / does for python ints. Therefore, sage: 12//13 0 sage: (12//13).parent() is ZZ True So whatever OK(12) // OK(13) returns, it has to be an element of OK, hence (as David L. says: not 12/13). Moreover, we must always have b * (a // b) + (a % b) == a for this quotient and remainder. The easiest fix is have it raise an Error, which is better than anything that is not in OK. Again, it's a question of where the arithmetic is taking place. The issue is that 12/13, while an element of K, is not in OK. 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
Re: [sage-devel] Units in Orders
These outputs look fine to me. See also http://trac.sagemath.org/sage_trac/ticket/11673 2012/8/11 Rob Beezer goo...@beezer.cotse.net: Is this a bug? First example is from Judson's abstract algebra text. Note that .is_unit() returned True in sage 4.8. sage: sage: K.x,y = ZZ[sqrt(-3)]; K Order in Number Field in a with defining polynomial x^2 + 3 sage: four = K(4) sage: four.is_unit() False sage: four^-1 1/4 Second example: all but the last input is basically from the documentation of .is_unit(). sage: K.a = NumberField(x^2 - x - 1) sage: OK = K.ring_of_integers() sage: u = OK(13) sage: u.is_unit() False sage: u^-1 1/13 Thanks, 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 -- -- 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
Re: [sage-devel] the default behaviour of reduce() for ideals
I'm just letting the list know that there is a patch at http://trac.sagemath.org/sage_trac/ticket/13345 deprecating the default implementation of Ideal_generic.reduce in favour of NotImplementedError. Op maandag 30 juli 2012 11:36:06 UTC+2 schreef Marco Streng het volgende: 2012/7/30 Thomas Feulner: Hi, in the definition of a QuotientRing there is the following assumption ASSUMPTION: ``I`` has a method ``I.reduce(x)`` returning the normal form of elements `x\in R`. In other words, it is required that ``I.reduce(x)==I.reduce(y)`` `\iff x-y \in I`, and ``x-I.reduce(x) in I``, for all `x,y\in R`. On the other hand, the default definition of reduce in sage/rings/ideal.py says def reduce(self, f): return f # default Wouldn't it be better to raise a NotImplementedError? It would be safer, but it sounds like it would break a lot of code. Right now, reduce does exactly what it says: Return the reduction of the element of `f` modulo the ideal `I` (=self). This is an element of `R` that is equivalent modulo `I` to `f`. If you don't get any objections, you could change this documentation and add a deprecation warning to this default implementation. Then later it can be changed to NotImplementedError. These are the consequences: sage: Z16x.x = Integers(16)[] sage: GR.y = Z16x.quotient(x**2 + x+1 ) sage: I = GR.ideal(4) sage: I.reduce(GR(6)) 6 # should be reduced mod 4 another example is sage: J = Z16x.ideal([x+1, x+1]) # just to avoid that the ideal is identified as a principal ideal sage: R.z = Z16x.quotient(J) sage: R(x) # should be 15 I'm fine with all the outputs above, though they can be improved. However, I think the following is a bug: sage: R(x+1) == 0 False The only correct answer is True. This goes wrong because the ASSUMPTION that you quotes above is not satisfied. However, I would trust R to be correct, because I never get to see the assumption, even when I type Z16x.quotient?? R?? Suggested fixes: - add the assumption to the documentation of the quotient method of Z16x, or - add some checks to the equality tests of QuotientRing, or - kill the default implementation of reduce as you suggest (but do deprecation first). (or some combination of the above) Best, Marco -- -- 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
Re: [sage-devel] the default behaviour of reduce() for ideals
2012/7/30 Thomas Feulner thomas.feul...@uni-bayreuth.de: Hi, in the definition of a QuotientRing there is the following assumption ASSUMPTION: ``I`` has a method ``I.reduce(x)`` returning the normal form of elements `x\in R`. In other words, it is required that ``I.reduce(x)==I.reduce(y)`` `\iff x-y \in I`, and ``x-I.reduce(x) in I``, for all `x,y\in R`. On the other hand, the default definition of reduce in sage/rings/ideal.py says def reduce(self, f): return f # default Wouldn't it be better to raise a NotImplementedError? It would be safer, but it sounds like it would break a lot of code. Right now, reduce does exactly what it says: Return the reduction of the element of `f` modulo the ideal `I` (=self). This is an element of `R` that is equivalent modulo `I` to `f`. If you don't get any objections, you could change this documentation and add a deprecation warning to this default implementation. Then later it can be changed to NotImplementedError. These are the consequences: sage: Z16x.x = Integers(16)[] sage: GR.y = Z16x.quotient(x**2 + x+1 ) sage: I = GR.ideal(4) sage: I.reduce(GR(6)) 6 # should be reduced mod 4 another example is sage: J = Z16x.ideal([x+1, x+1]) # just to avoid that the ideal is identified as a principal ideal sage: R.z = Z16x.quotient(J) sage: R(x) # should be 15 I'm fine with all the outputs above, though they can be improved. However, I think the following is a bug: sage: R(x+1) == 0 False The only correct answer is True. This goes wrong because the ASSUMPTION that you quotes above is not satisfied. However, I would trust R to be correct, because I never get to see the assumption, even when I type Z16x.quotient?? R?? Suggested fixes: - add the assumption to the documentation of the quotient method of Z16x, or - add some checks to the equality tests of QuotientRing, or - kill the default implementation of reduce as you suggest (but do deprecation first). (or some combination of the above) Best, Marco -- -- 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
Re: [sage-devel] Re: weighted projective spaces
2012/5/24 David Eklund sven.david.ekl...@gmail.com: Hi, I guess Volker meant Riemann surface when saying smooth elliptic surface in P^2 (that is, an elliptic curve). But as Marco says, this is about hyperelliptic curves. Volkers comment that toric varieties in Sage are often assumed to be defined over a field is important and has implications for the issues regarding hyperelliptic curves discussed above. Developing toric varieties over general rings sounds like an intriguing (and elaborate) project. I think I will start small by adding explicit construction of weighted projective spaces to the toric variety library. We'll see what happens after that. Yes, it would be good to have weighted projective spaces over general rings. But don't worry too much about that for hyperelliptic curves. First of all, as far as I know, hyperelliptic curves are currently not really implemented over general rings, such rings are just not rejected on input. Second, points on elliptic curves over general rings work in Sage, even though they don't work in the ambient projective space, so the ambient space apparently does not have to support everything: sage: E = EllipticCurve(QQ, [0,0,0,-1,0]) sage: E([1,0]) # point sage: P = E.ambient_space() sage: P([1,0]) # point sage: E = EllipticCurve(Zmod(6), [0,0,0,-1,0]) sage: E([1,0]) # point sage: P = E.ambient_space() sage: P([1,0]) # error sage: Q.x = QQ[] sage: C = HyperellipticCurve(x^6-1) sage: C([1,0]) # point sage: Q.x = Zmod(6)[] sage: C = HyperellipticCurve(x^6-1) sage: C([1,0]) # error Marco's standard solution number 1) with two glued A^2 also sounds useful. Maybe this is similar to what we would actually be doing with the weighted projective plane P(1,g+1,1) where g is the genus of the curve. The resulting smooth projective hyperelliptic curves are of course isomorphic, but the two ambient spaces make a difference in implementation, so there is indeed a choice to be made. I don't know whether glueing is done anywhere in Sage so far, but neither are weighted spaces, so I don't know how much work each option would be. For more on the theory behind (1) and (2), see pages 86 and 87 of Hindry-Silverman, Diophantine Geometry, An Introduction. Method (1) of glueing smooth affine curves in two copies of A^2 is A.4.2(a) -- (c). Method (2) of a higher-dimensional projective space is A.4.2(d), but is probably not suitable for fast computations due to the high dimension. best /David On Tuesday, May 22, 2012 3:39:34 PM UTC-6, Marco Streng wrote: Op 22-05-2012 15:26, Volker Braun schreef: On Tuesday, May 22, 2012 4:16:08 AM UTC-4, Marco Streng wrote: Definitely! That would make it possible to have a smooth projective model, with the correct points at infinity. I don't understand that sentence - a smooth elliptic surface can already be embedded in P^2, right? That sentence refers to the sentence by David Eklund right above it. So it has nothing to do with elliptic surfaces, but is about hyperelliptic curves. Hyperelliptic curves can be mapped birationally onto a curve in P^2, just by going via the standard model in A^2 of the form y^2 + h(x)*y = f(x). But the image is not smooth at infinity for any hyperelliptic curve (of genus =2). To make the image smooth, the standard solutions are to 1) glue two copies of A^2, 2) use a higherdimensional P^n, or 3) use a weighted projective 2-dimensional space. I think David was aiming at (3), and I was simply welcoming that. Note that the toric variety code assumes that the base ring is a field at various places. So for number theory purposes it might be good to split things into ToricVariety_ring vs. ToricVariety_field. Its mostly my ignorance about toric varieties over general rings that prevented me from doing so... -- 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 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 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
Re: [sage-devel] Re: weighted projective spaces
Op 22-05-2012 4:09, David Eklund schreef: Hi Volker, thanks for the advice! I think basing the implementation on the Cox ring is what I wanted anyway. If any number theory people are reading this I think it is worth thinking about making hyperelliptic curves subvarieties of weighted projective planes Definitely! That would make it possible to have a smooth projective model, with the correct points at infinity. (whether using the toric variety version I will work on or some other implementation of weighted projective spaces). /David Eklund On Sunday, May 20, 2012 7:03:04 PM UTC-6, Volker Braun wrote: Hi David, I think it would be best to construct them as toric varieties. This'll give you lots of functionality. For starters you should probably add a weighted projective space constructor to the toric_varieties library. There is already a toric_varieties.P(int), how about toric_varieties.WP(list of ints). If you want to provide specialized implementations for toric algorithms you can derive from the ToricVarieties class. Volker On Sunday, May 20, 2012 3:06:16 PM UTC-4, David Eklund wrote: Hi, I'm considering opening a ticket for the implementation of weighted projective spaces (in a class of its own). I think it could be quite useful in general but there are also algebraic varieties already in Sage for which weighted projective space is a natural habitat (like hyperelliptic curves). Does this sound like a good idea? Or is it superfluous? Are there tickets on this already? Any ideas of how it can be done? For example, does anyone know how it is done in Magma? Some technical remarks: it might be that the work is essentially already done in connection with toric varieties. I'm not sure exactly which functionalities I would like, but at least I want to construct them by simply giving the weights and also define subschemes by giving a bunch of weighted homogenous polynomials. Perhaps test smoothness of such subschemes etc. Maybe weighted projective spaces should be constructed as toric varieties. Or perhaps it is better to make an independent implementation of them. Any thoughts? thanks! /David Eklund -- 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 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
Re: [sage-devel] Re: weighted projective spaces
Op 22-05-2012 15:26, Volker Braun schreef: On Tuesday, May 22, 2012 4:16:08 AM UTC-4, Marco Streng wrote: Definitely! That would make it possible to have a smooth projective model, with the correct points at infinity. I don't understand that sentence - a smooth elliptic surface can already be embedded in P^2, right? That sentence refers to the sentence by David Eklund right above it. So it has nothing to do with elliptic surfaces, but is about hyperelliptic curves. Hyperelliptic curves can be mapped birationally onto a curve in P^2, just by going via the standard model in A^2 of the form y^2 + h(x)*y = f(x). But the image is not smooth at infinity for any hyperelliptic curve (of genus =2). To make the image smooth, the standard solutions are to 1) glue two copies of A^2, 2) use a higherdimensional P^n, or 3) use a weighted projective 2-dimensional space. I think David was aiming at (3), and I was simply welcoming that. Note that the toric variety code assumes that the base ring is a field at various places. So for number theory purposes it might be good to split things into ToricVariety_ring vs. ToricVariety_field. Its mostly my ignorance about toric varieties over general rings that prevented me from doing so... -- 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 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
Re: [sage-devel] Where is double-and-add algorithm for scalar multiplication implemented
I think it is sage.structure.coerce_actions.fast_mul in
sage/structure/coerce_actions.pyx
That function is called when I do
sage: 100*P
And it is a double-and-add.
2012/4/18 Daniel Krenn kr...@aon.at:
If I perform a scalar multiplication e.g. of an integer with a module
element, it seems that a double-and-add algorithm is used. Where (in
which file/class) is that algorithm exactly implemented?
It is called, for example by
sage: E = EllipticCurve('37a')
sage: P = E(0,0)
sage: 5*P
(1/4 : -5/8 : 1)
I searched in element.pyx, coerce.pyx, coerce_action.pyx, action.pyx,
but couldn't find it. Maybe I overlooked it or maybe it is defined in
Python somewhere.
Daniel
--
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 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
Re: [sage-devel] Re: Dealing with different signs in doctest output?
On 07/02/2012 15:43, Jason Grout wrote: On 2/7/12 9:34 AM, John H Palmieri wrote: Or as part of the doctest normalize G.round(6): multiply by -1 if the real part of the (0,0) entry is positive. If it gets too complicated, maybe it should be moved to a TESTS block instead of an EXAMPLES block. I wonder what part of the algorithm leads to a difference choice of sign on this one platform. so something like: sage: G.round(6)*sgn(G[0,0].real()) Thanks, Jason These are quite ugly solutions. How do people feel about having a solution analogous to #10952? http://trac.sagemath.org/sage_trac/ticket/10952 For example, let # sign variation ignore every +, -, and space in the output string. Marco -- 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
Re: [sage-devel] Re: Dealing with different signs in doctest output?
On 07/02/2012 16:06, Jason Grout wrote: On 2/7/12 9:55 AM, Marco Streng wrote: On 07/02/2012 15:43, Jason Grout wrote: On 2/7/12 9:34 AM, John H Palmieri wrote: Or as part of the doctest normalize G.round(6): multiply by -1 if the real part of the (0,0) entry is positive. If it gets too complicated, maybe it should be moved to a TESTS block instead of an EXAMPLES block. I wonder what part of the algorithm leads to a difference choice of sign on this one platform. so something like: sage: G.round(6)*sgn(G[0,0].real()) Thanks, Jason These are quite ugly solutions. How do people feel about having a solution analogous to #10952? http://trac.sagemath.org/sage_trac/ticket/10952 For example, let # sign variation ignore every +, -, and space in the output string. But then it would consider the two vectors (-1,2) and (-1,-2) to be the same, which is not what we want. Jason True, that is the biggest downside of this solution. But examples should be illustrative. It would be a shame to have a documentation of a function without any printed examples of the output of the function. Users may want to see what the output is supposed to look like, as a way of understanding what a function does. We can always add another test like M*M.transpose() below it if we really are afraid of getting (-1,-2) instead of (-1, 2). -- 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
Re: [sage-devel] Literal matrix syntax
Op 26-01-2012 8:22, Robert Bradshaw schreef: I would like to propose the addition of a matrix literal syntax, namely sage: [1, 2; 3, 4] [1 2] [3 4] +1 even gp has this A second question, what of the basering? Consistency with [Mm]atrix([[1,2],[3,4]]) would be most clear. So would you argue to change basering of that too? -- 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
Re: [sage-devel] Re: Literal matrix syntax
2012/1/26 Dima Pasechnik dimp...@gmail.com: No, that's not good. Cause this syntax forbids 1-row matrices to be entered in this format (as it won't be possible to distinguish it from a list!) How about [1,2,3;] for matrix([[1,2,3]])? This problem and solution are similar to (1,) for a 1-tuple in Python. Dima -- 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 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
Re: [sage-devel] Re: Literal matrix syntax
What would Matlab users think of having to learn the habit of putting . behind their integers in Sage, e.g.? sage: matrix([[1.,2],[3,4]]).base_ring() Real Field with 53 bits of precision sage: matrix([[1/1,2],[3,4]]).base_ring() Rational Field This would be a possible warning to engineers: Make sure numbers contain . even if they are integers, e.g., type 2. instead of 2 when you want the number 2. The reason: Sage is used by many kinds of users. For example, if you type an integer, then Sage may assume that you are interested only in integers and that you want (slow) exact arithmetic. Sage will even reply False to [1,2;3,4].is_invertible(). Typing a . behind your integers makes them into nice fast floating point numbers, so that [1.,2;3,4].is_invertible() does return True as expected. Do we have good introduction to Sage for Matlab users, introduction to Sage for Maple users, etc.? Those would be a good place for warnings of this form and good habits. It would be hard to explain in the documentation when to use [[1,2;3,4]] versus matrix([[1,2],[3,4]]). And if we want a default for [1,2;3,4], would it be QQ or RDF? QQ may become inefficient as numbers become large, but how do we know whether users want exact arithmetic or not? Also, maybe the docstring of is_invertible could have a big warning so that people use is_singular instead if they are not interested in ZZ, but only in fields. -- 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
Re: [sage-devel] Re: Literal matrix syntax
2012/1/26 Jason Grout jason-s...@creativetrax.com: That's part of the problem pointed out in an earlier message---our RR matrices really are pretty bad for numerical things, but RDF matrices are the way to go (the RDF matrices use standard numerical algorithms for the most part, whereas RR matrices use naive algorithms that can be really bad and slow). This should be fixed, but for right now, RR matrices don't seem to be all that useful compared to RDF matrices. Is RDF always better than 53-bit RR in this way? If so, perhaps RealNumber or the preparser could be changed to use RDF if the precision is sufficiently small. Most users typing 12.345 will want the fastest implementation and not something generic. -- 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
Re: [sage-devel] Re: Literal matrix syntax
Should [a, b; c, d] be a valid syntax for matrix construction in Sage? [ X ] Yes, I love this syntax! It would be make life better for me and my students. [ ] I wouldn't oppose, but may require some convincing. [ ] No, that's a horrible idea. Why? Short, intuitive, clear, coincides with gp notation. Should the default basering be more linear-algebra friendly? E.g. R - Frac(R), RR - RDF. [ ] Yes, that would take away a lot of pain/be what I'd have to specify manually anyway. [ X ] Could be handy, but the drawbacks are significant. [ ] No, matrices over QQ are for sissies, real mathematicians work over ZZ unless otherwise specified. Why? I think strongly that there should be no difference between [a,b; c,d] and matrix([[a,b],[c,d]]). Otherwise the difference will have to be explained over and over again. I don't personally know enough to say anything about RR - RDF for matrices, so no opinion on that. ZZ - QQ for matrix will likely break some people's existing code. It also means extra pain for me personally. What does R - Frac(R) mean when it is hard to decide whether R is a domain? -- 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
Re: [sage-devel] Re: Should matrix spaces keep violating the basic assumption on hash functions, or should they be unique parents?
On 11/01/2012 11:46, Simon King wrote:
2) A more general consideration: The coercion model prefers to have
unique parents. But many people think that A == B should mean A
and B are canonically isomorphic, and not just A is B. That could
be solved by making the coercion model consequently use containers
that compare by is and not by ==.
I'm not sure what you mean by ``making the coercion model use containers
that compare by is and not by =='', but I'll just chime in as I
think it could be related to something that I found.
Currently, if two parents A and B are equal according to == and no
good coercion map is found, then A.coerce_map_from(B) returns
A._generic_convert_map(B). In case of number fields, this means that if
two number fields have same generator name and same defining polynomial,
then the generators are identified by coercion. There is a NumberField
example where this is incompatible with maps that I would consider
natural. So in the NumberField case, I would prefer not to have a
coercion in this case, but only a conversion.
Marco
PS. More specifically, the example is
sage: K.a = NumberField(x^2-2, embedding=-1)
sage: L.b = NumberField(x^2-2, embedding=1)
sage: xK = K['x'].gen()
sage: xL = L['x'].gen()
sage: M.c = NumberField(xK^2-3)
sage: N.d = NumberField(xL^2-3)
sage: O = M.absolute_field('e')
sage: P = N.absolute_field('e')
sage: b_in_a = K(0)+b
sage: map1 = O.structure()[1]
sage: map2 = P.structure()[1]
sage: b_in_a in map1.domain()
# True
sage: b in map2.domain()
# True
sage: map1(b_in_a) - map2(b)
# e^3 - 9*e, which is non-zero, so the maps don't commute!
The maps O -- M -- K -- L -- N -- P are natural (structure
morphisms and coercions).
The fields O and P have same generator name and same defining
polynomials, hence O==P is True. However, O.structure() and
P.structure() are distinct, which makes O._generic_convert_map(P)
incompatible with the natural maps O -- M -- K -- L -- N -- P
So I would prefer there not to be a coercion from O to P. I'm fine with
conversion.
--
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
Re: [sage-devel] Rational Extension Representation for function fields
On 20/12/2011 08:59, syd.lavas...@gmail.com wrote: I think it is essential (speaking priority) to have a parallel to Magam RationalExtensionRepresentation(F) : FldFunG - FldFun The function field F represented as an extension of a rational function field. This function gives the representation of function fields F/k as finite extensions. This basically collapses the extension tower to one extension. It significantly speeds up any computation which happens at the top of the tower. If sage has such a method for number fields, it should be fairly straight forward to recycle for the function field class. Does anybody knows if we have such a method for number fields? absolute_field -- 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
Re: [sage-devel] gcd with integers mod n
2011/12/11 William Stein wst...@gmail.com: sage: parent(gcd(Mod(5,7), 7)) Integer Ring which... sucks! I consider this a bug. We should definitely have that the gcd is in parent(Mod(5,7)). This bug seems to be as old as http://trac.sagemath.org/sage_trac/ticket/4443 If a in gcd(a,b) has no attribute gcd, then both are coerced to ZZ before taking a gcd. -- 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
Re: [sage-devel] gcd with integers mod n
2011/12/11 Jeroen Demeyer jdeme...@cage.ugent.be: On 2011-12-11 21:44, Marco Streng wrote: 2011/12/11 William Stein wst...@gmail.com: sage: parent(gcd(Mod(5,7), 7)) Integer Ring which... sucks! I consider this a bug. We should definitely have that the gcd is in parent(Mod(5,7)). This bug seems to be as old as http://trac.sagemath.org/sage_trac/ticket/4443 If a in gcd(a,b) has no attribute gcd, then both are coerced to ZZ before taking a gcd. It can't be that simple, otherwise gcd(Mod(5,7), 7) would be the integer 1, not 5. It seems that #4443 introduces a gcd by coercing to ZZ, but does not coerce back. Recently, #10771 changed the answer from 1 to 5 (both correct), but did correct the type from Integer to IntegerMod. -- 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
Re: [sage-devel] gcd with integers mod n
2011/12/11 Marco Streng marco.str...@gmail.com: did correct the type from Integer to IntegerMod. (sorry, that should have been did not) -- 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
Re: [sage-devel] gcd with integers mod n
2011/12/11 Marco Streng marco.str...@gmail.com: Recently, #10771 changed the answer from 1 to 5 (both correct), but (this change was caused by the fact that 7 is now coerced to ZZ/7ZZ first, before being coerced back to ZZ, where it is 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] numbers on Sage usage outside academic maths
Hi Sage-devel and Sage-edu, I was wondering if we have any numbers on how much Sage is used outside university mathematics, i.e, - education outside universities (e.g. secondary schools) - education outside mathematics (e.g. physics, engineering, ...) - academic research outside mathematics - private companies Such numbers could help Sage developers motivate their involvement with Sage to grant committees and employers. Sorry if this has been asked before. On the web page and mailing lists, I could only find numbers of downloads and numbers of web page visits, and a few individual examples. Does this mean we have no such numbers? Thanks, Marco -- 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: nondescript tracebacks with load and attach of .sage files
New and easier patch is ready for review! http://trac.sagemath.org/sage_trac/ticket/11812 The patch gives sage.misc.preparser.load an option preparse_to_file, which defaults to True for attach and False for load. Preparsing to a file gives good tracebacks, preparsing to memory gives keeps the speed high. The patch contains no complicated doctests, as the content of tracebacks is too hard to test. So the patch is very short. Marco -- 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: nondescript tracebacks with load and attach of .sage files
There is a problem with my patch (#11812). Can anyone help me?
I wanted to have a doctest in there that really tests whether the
traceback contains certain substrings. Python doctesting ignores the
content of a traceback. So to test the content of the traceback, I
tried starting a nested Sage session. Sage or sage0 doesn't just
print the errors, but really throws them forward into the main Sage
session, so they don't help. With import pexpect;
pexpect.spawn(full_path_to_sage_executable), I get an error message.
The only thing that seemed to do exactly what I wanted was import
pexpect; pexpect.spawn('sage'), but it doesn't, as the patchbot shows
at #11812.
For an example of what I was trying, see the patch at that ticket.
--
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: Can I input n variables in python?
On Thu, Sep 22, 2011 at 1:37 PM, Anna Haensch annahaen...@gmail.com wrote: Is there any way in sage, or rather python, to define a function which takes as its input n variables, rather than assigning a fixed number? I've just written a piece of code for the Quadratic Forms module, which takes as input a Quadratic Lattice, Q, and three vectors, so (Q,v_1,v_2,v_3), and it generates the lattice L which is on the same underlying quadratic space as Q but with basis v_1,v_2,v_3. Why not simply use a list v with elements v_1,v_2,...,v_n? So input (Q, [v_1,v_2,v_3]) into a function sage: def(Q, v): : # start by unpacking the elements of v : Mike's example would become sage: def f(v): : return sum(v) : sage: f([1,2,3]) 6 sage: f([2,3,5,8]) 18 -- 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: nondescript tracebacks with load and attach of .sage files
On 18 sep, 17:49, Simon King simon.k...@uni-jena.de wrote: Sorry, I thought your suggestion was that there should be a cleartraceback(hence, a temporary file) when youattachsomething, and when you load something then it should be as efficient as possible, hence, accepting less descriptive tracebacks. Done. #11812 needs review. -- 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: nondescript tracebacks with load and attach of .sage files
Thanks Conrado, that works perfectly. It is now ticket #11812. http://trac.sagemath.org/sage_trac/ticket/11812 As for the efficiency: how big was the improvement here in efficiency? Is this significant for load or for attach or both? Can/should we make a distinction between load and attach? If I do attach, then that's because I am writing the code and trying it out. That means I want to have good tracebacks always. If I do load, then code is loaded only once. That means that the efficiency improvement becomes less important. -- 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: nondescript tracebacks with load and attach of .sage files
On Sep 18, 12:18 pm, Simon King simon.k...@uni-jena.de wrote: Same here. So, I am +1 to your suggestion. Thanks, but what was my suggestion? I didn't write it very explicitly in that message, but I guess I argued for going back to the old behaviour completely. If people object to that, then an alternative suggestion is to go back to the old behaviour for attach and to keep the high performance for load. -- 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: nondescript tracebacks with load and attach of .sage files
On Sep 18, 4:27 pm, William Stein wst...@gmail.com wrote: There was some good reason for making the change (it fixed a bug?), so somebody should look into that, right? I'm pretty sure *I* made the change, but I can't remember why at this moment. Hi William, You wrote the current version of that line here: http://trac.sagemath.org/sage_trac/attachment/ticket/7514/sagelib-7514_combined.3.patch (up to a very minor change made later by Willem Jan) It is part of a major rewrite of load and attach and replaces an ugly triplicate version. Could that have been the only reason? Marco ps 1 (offtopic). I found this out by trying a few cusom trac queries and trac searches and reading quite a few of the search results. Is there a more automated way of finding out in which ticket a piece of code was changed? ps 2. Conrado's fix does not break sage -t of sage/misc -- 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: nondescript tracebacks with load and attach of .sage files
On Sep 18, 5:41 pm, Conrado P. L. Gouvêa conrado...@gmail.com wrote: Sage 4.3 used to get the full path of the .sage file, replace '/' by '_' and write it to a temp file. It should be easier just to port the older code but I couldn't find where this is handled... The function sage.misc.interpreter.preparse_file_named preparses a file to a termporary .py file and returns the name of the temporary file -- 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: GiNaC and Python disagree on arithmetic
I'd say we should stick with Python's convention 0^0 = 1. Some additional information: on sage-nt http://groups.google.com/group/sage-nt/browse_thread/thread/67e53f8e5d5061d2/ we chose to follow Python's convention 0^0 = 1 through a bit further. As for Maarten's examples, there are some more in Example 1 of: http://trac.sagemath.org/sage_trac/ticket/10772 At that ticket, only the ArithmeticError was fixed, the infinite recursions and NaNs are still there. -- 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] magma interface broken for number fields?
Hi all,
Is it just me, or is magma(K) broken for number fields K?
The following example is in number_field.py (Sage 4.6.2):
===
sage: R.t = QQ[]
sage: K.a = NumberField(t^2 + 1)
sage: K._magma_init_(magma)# optional - magma
'SageCreateWithNames(NumberField(_sage_[...]),[a])'
sage: L = magma(K)# optional - magma
sage: L # optional - magma
Number Field with defining polynomial t^2 + 1 over the Rational Field
===
If I try that on a machine with Magma V2.16-7, I get:
===
sage: R.t = QQ[]
sage: K.a = NumberField(t^2 + 1)
sage: K._magma_init_(magma)# optional - magma
'SageCreateWithNames(NumberField(_sage_[6]),[a])'
sage: L = magma(K)# optional - magma
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (29, 0))
---
TypeError Traceback (most recent call last)
[...]
TypeError: Error evaluating Magma code.
IN:_sage_[6]:=SageCreateWithNames(NumberField(_sage_[6]),[a]);
OUT:
_sage_[6]:=SageCreateWithNames(NumberField(_sage_[6]),[a]);
^
Runtime error in 'NumberField': Bad argument types
Argument types given: RngIntElt
===
Am I the only one with this problem?
Is this Magma-version dependent?
How often are optional tests done before releasing a new Sage version?
Thanks,
Marco
ps. most of the Magma interface seems to work fine
sage: R.t = QQ[]
sage: magma(t^2 + 1).NumberField()
Number Field with defining polynomial t^2 + 1 over the Rational Field
but there are some problems outside of NumberField as well.
Examples:
File
/usr/local/sage/sage-4.6.2/devel/sage-main/sage/symbolic/expression.pyx,
line 512:
sage: magma(f) # optional - magma
Expected:
sin(cos(x^2) + log(x))
Got:
sin(log(x) + cos(x^2))
File
/usr/local/sage/sage-4.6.2/devel/sage-main/sage/crypto/mq/mpolynomialsystem.py,
line 579:
sage: magma(R1) # implicit doctest;
optional - magma
Expected:
Graded Reverse Lexicographical Order
Got:
Order: Graded Reverse Lexicographical
A complete list:
sage -t -only-optional=magma
devel/sage/sage/structure/sage_object.pyx # 2 doctests failed
sage -t -only-optional=magma
devel/sage/sage/symbolic/expression.pyx # 1 doctests failed
sage -t -only-optional=magma
devel/sage/sage/crypto/mq/mpolynomialsystem.py # 2 doctests failed
sage -t -only-optional=magma
devel/sage/sage/schemes/hyperelliptic_curves/hyperelliptic_g2_generic.py
# 4 doctests failed
sage -t -only-optional=magma
devel/sage/sage/interfaces/magma.py # 6 doctests failed
sage -t -only-optional=magma
devel/sage/sage/algebras/quatalg/quaternion_algebra.py # 2 doctests failed
sage -t -only-optional=magma
devel/sage/sage/rings/polynomial/term_order.py # 1 doctests failed
sage -t -only-optional=magma
devel/sage/sage/rings/polynomial/pbori.pyx # 1 doctests failed
sage -t -only-optional=magma
devel/sage/sage/rings/polynomial/multi_polynomial_ring_generic.pyx # 5
doctests failed
sage -t -only-optional=magma
devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests
failed
sage -t -only-optional=magma
devel/sage/sage/rings/number_field/order.py # 2 doctests failed
sage -t -only-optional=magma
devel/sage/sage/rings/number_field/number_field_element.pyx # 2 doctests
failed
sage -t -only-optional=magma
devel/sage/sage/rings/number_field/number_field.py # 4 doctests failed
sage -t -only-optional=magma
devel/sage/doc/en/bordeaux_2008/birds_other.rst # 2 doctests failed
--
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] nondescript tracebacks with load and attach
Hi sage-devel, When debuggin code that is loaded into or attached to a Sage session, the tracebacks are not very informative: they refer to string instead of to the file name, and give no line numbers or code snippets. This makes it hard to find out where the error is. Can this be changed or improved in any way? Thanks, Marco Example: Suppose I have some files loaded with load or attach, and one of them is class Bar(): def function_with_common_name(self): # lots of lines of code 1/0 # lots of lines of code # other classes that also have functions named function_with_common_name def foo(): # lots of lines of code a = Bar() a.function_with_common_name() # lots of lines of code Now I do sage: foo() --- ZeroDivisionError Traceback (most recent call last) /home/marco/ipython console in module() /home/marco/string in foo() /home/marco/string in function_with_common_name(self) /usr/local/sage/sage-4.6.2/local/lib/python2.6/site-packages/sage/structure/element.so in sage.structure.element.RingElement.__div__ (sage/structure/element.c:11981)() /usr/local/sage/sage-4.6.2/local/lib/python2.6/site-packages/sage/rings/integer.so in sage.rings.integer.Integer._div_ (sage/rings/integer.c:11944)() /usr/local/sage/sage-4.6.2/local/lib/python2.6/site-packages/sage/rings/integer_ring.so in sage.rings.integer_ring.IntegerRing_class._div (sage/rings/integer_ring.c:5142)() ZeroDivisionError: Rational division by zero Then to find the bug using this traceback, I would need to search my files to find all functions named function_with_common_name that are called from functions named foo for a line that could cause a division by zero... Functions that are imported do give useful information, including line numbers a few lines of code. I'd like to see information like this for functions that come from loading a file. -- 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: magma interface broken for number fields?
On Apr 19, 2:47 pm, John Cremona john.crem...@gmail.com wrote: There's a ticket fixing this at #7870, merged in 4.7.alpha4. Thanks, that ticket looks good. Which version were you using? Sage 4.6.2, Magma V2.16-7 -- 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: Indented code in terminal
On Apr 19, 3:18 pm, pipedream jan.groenew...@gmail.com wrote: sage: %cpaste Pasting code; enter '--' alone on the line to stop. :def f(x): : if x == 1: : return 2 : return 1 :-- sage: f(1) 2 Thanks! -- 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
Re: [sage-devel] Re: patchbot+nagbot
Op 30-12-2010 22:16, Robert Bradshaw schreef: On Thu, Dec 30, 2010 at 2:04 PM, daveloefflerdave.loeff...@gmail.com wrote: On Dec 30, 1:41 pm, Robert Bradshawrober...@math.washington.edu wrote: And otherwise it does a best guess kind of approach, which is decent (especially if there is only one patch :). In any case, I don't think people would mind getting a nag that the patchbot got confused, indicating that it might be worth your while to give it a hint. - Robert Agreed. Are there docs for the patchbot extant somewhere? It would be handy to have some brief guidelines (perhaps on the Trac wiki?) Could someone add http://wiki.sagemath.org/buildbot to http://www.sagemath.org/doc/developer/trac.html#patching-bugs-working-on-tickets ? -- 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: pari bugfixes
In this particular case it were pari bugs 1143 (fixed in 12769) and 1144 (fixed an hour earlier it seems). On 3 dec, 18:50, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2010-12-03 16:15, Marco Streng wrote: I encountered a bug in pari 2.4.3 (alpha) while working on a sage ticket. I reported it to pari, and they fixed it the same day. But then it takes some time for this fix to reach sage, or we could update sage with bug fixes immediately. I you tell me which bug it is and in which PARI version it was fixed, I wouldn't mind making a new PARI spkg. There is another PARI patch anyway which I wanted to include in Sage. Jeroen. -- 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] pari bugfixes
How often will / should pari be updated within sage? I encountered a bug in pari 2.4.3 (alpha) while working on a sage ticket. I reported it to pari, and they fixed it the same day. But then it takes some time for this fix to reach sage, or we could update sage with bug fixes immediately. I don't know how the process of updating pari within sage works, but I've been told that it should be a lot quicker now that pari 2.4.3 is in. Hence the question. Marco -- 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: linbox build failure of 4.1.2.alpha0 (gmp version problem)
Hi John, How did you solve this problem in the end? I seem to have the same problem on the same machine trying to build sage-4.5.3 and sage-4.6.1.alpha0. Marco On 4 sep 2009, 15:31, John Cremona john.crem...@gmail.com wrote: On this machine, which built 4.1.1 fine: Linuxversion2.6.28-13-generic (bui...@yellow) (gccversion4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 using thisversionof gcc: j...@selmer%gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /usr/local/gcc-4.4.1-source/configure --disable-multilib Thread model: posix gccversion4.4.1 (GCC) I tried to build 4.1.2.alpha0, but it failed at this point during linbox configuration: checking forGMP= 3.1.1... problem Sorry, yourGMPversionis too old. Disabling. *** ERROR:GMPnot found! GMPversion3.1.1 or greater with --enable-cxx is required for this library to compile. Please make sureGMPis installed and specify its location with the option --with-gmp=prefix when running configure. *** Error configuring linbox real 0m11.695s user 0m5.568s sys 0m5.780ssage: An error occurred while installing linbox-1.1.6.p0 Now, (1) the installedversionofgmpis 4.2.1: j...@selmer%grep GMP_VERSION /usr/include/gmp.h #define GMP_VERSION 4.2.1 and (2) doesn'tsageinstall its owngmp(actually mpir) which is alsoversion4.1.2? So why is linbox getting this wrong now? John -- 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
Re: [sage-devel] Re: How does real_lazy work?
Robert Bradshaw schreef: What should be done is either fixing LazyNamedUnop to preserve documentation, or populating these methods at class creation time (rather than attribute lookup time, perhaps dynamically creating a docstring for them). I don't think it's a good idea to hard code every one of these methods, and the set of methods on RealNumbers will grow/change over time, and that's a lot of redundant code. If you need to do one or two (like sqrt) than that makes sense, but probably not a good idea to do all of them. Verbose code takes resources (both human and computer) to keep around. At least that's my $0.02. Hi Robert, Interesting solutions, but I see some problems with them. Possibly because of my own lack of experience, so maybe you can explain. I don't understand how fixing LazyNamedUnop to preserve documentation helps. If sqrt gets defined in RingElement, then __getattr__ of LazyWrapper doesn't get called. Where does LazyNamedUnops appear in this story? Populating sqrt of LazyWrapper at class creation time is interesting. I assume you do that via its __init__ method. But how do you get around the following problems? * If a class HypotheticalObject extends LazyWrapper and has its own actual sqrt attribute, then that sqrt attribute gets overwritten at creation time as well, doesn't it? Preventing stuff like this from happening and (even worse) debugging whenever this happens is also a lot of work, isn't it? Is there a way to do what you suggest in a stable and not-too-complicated way? * The methods created at class creation time must have documentation including examples. This documentation doesn't appear in the reference manual and these examples aren't doctested. How do you get this documentation in the reference manual and how to doctest these examples? Here I don't mean by copying them, because copies can be changed without changing the original. Marco -- 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: arithmetic with True and False
An earlier topic on the same problem is http://groups.google.com/group/sage-devel/browse_thread/thread/2821c770f3c62efd Apparently True*2 was fixed (now returns 2), but True*SR(2) wasn't (still returns 1). I think Robert Bradshaw made the patch back then, so he knows how to fix this (something to do with coercion). It was also discussed whether implicit coercion from booleans to integers (or other numbers) was to be allowed at all. There were votes for following python convention, which is what was done back then. I like the TypeError here to avoid bugs, but don't mind following python convention either. Marco On 25 jul, 00:44, Robert Bradshaw rober...@math.washington.edu wrote: On Sat, Jul 24, 2010 at 2:29 PM, Burcin Erocal bur...@erocal.org wrote: Hi, At Sage Days 24, I learned that Python allows the user to do arithmetic with bools: In [1]: 5+True Out[1]: 6 In [2]: True + False Out[2]: 1 In [3]: 5+False Out[3]: 5 Sage seems to follow this convention as well: sage: 5 + True 6 sage: 5. - True 4.00 I can't see any use cases for this convention. I believe all these examples should just raise a TypeError. IMHO, code relying on this feature is very likely to be buggy. Apparently the symbolic ring doesn't handle things so well [1], but I'm not decided what the fix should be. :) [1]http://trac.sagemath.org/sage_trac/ticket/9560 Any comments? For whatever reason, bools subclass int, sage: isinstance(True, int) True so to accept ints and reject bools, we'd have to do a lot of special casing. This is useful, for example sage: sum(is_prime(p) for p in range(100)) 25 - 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] finding out if something is a valid keyword argument
Hi, I have a question that I thought was a simple python question, but I was unable to find the answer on the internet. Suppose I want to find out if root is a valid keyword argument for the is_square function of an object a. Is there a good way to do this? I tried the following for Integer, but it didn't work. sage: from inspect import getargspec sage: getargspec(Integer.is_square) TypeError: arg is not a Python function sage: getargspec(5.is_square) TypeError: arg is not a Python function See also http://trac.sagemath.org/sage_trac/ticket/9094 Thanks, Marco -- 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] Scheme extends Parent
Hi all,
I'm getting a bit confused about Parent objects and why
sage.schemes.generic.scheme.Scheme extends Parent.
Schemes are not really containers of anything, right? Calling
S.an_element() currently gives a NotImplementedError for most schemes,
and TestSuite(S).run() will give lots of failures for almost every
kind of scheme.
ProjectiveSpace does implement an_element, but that gives elements of
the coordinate ring instead of elements of the projective space
itself.
To make things even more confusing, the documentation for
sage.structure.parent.Parent.an_element() says Parent structures that
are should override _an_element_() instead. What does Parent
structures that are mean? When is a parent structure?
Thanks,
Marco
{{{
sage: Q.X,Y,Z = QQ[]
sage: P = ProjectiveSpace(Q)
sage: e = P.an_element(); e
X
sage: e.parent()
Multivariate Polynomial Ring in X, Y, Z over Rational Field
sage: S = Curve(X^2-Y^2+Z^2)
sage: S.an_element()
NotImplementedError: please implement _an_element_ for Projective
Curve over Rational Field defined by X^2 - Y^2 + Z^2
}}}
--
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: Scheme extends Parent
On 12 jul, 18:54, William Stein wst...@gmail.com wrote: On Monday, July 12, 2010, Marco Streng marco.str...@gmail.com wrote: Hi all, I'm getting a bit confused about Parent objects and why sage.schemes.generic.scheme.Scheme extends Parent. Schemes are not really containers of anything, right? A scheme is by definition a locally ring topological space. Thus a scheme is: - a set of points (prime ideals in case of an affine scheme) - a topology (locally the zariski topology) - a sheaf if rings Calling S.an_element() currently gives a NotImplementedError for most schemes, and TestSuite(S).run() will give lots of failures for almost every kind of scheme. ProjectiveSpace does implement an_element, but that gives elements of the coordinate ring instead of elements of the projective space itself. Why elements in quotes? Coordinate ring elements is a bug. In quotes because I don't call them elements but points (or elements) of the underlying topological space. Variety extends Scheme, but for me an element of a variety sound like a rational point or a geometric point, but not a scheme-theoretic point. Anyway, I'm fine with elements of a Sage Scheme meaning points of the topological space. I'm still confused about the following though: To make things even more confusing, the documentation for sage.structure.parent.Parent.an_element() says Parent structures that are should override _an_element_() instead. What does Parent structures that are mean? When is a parent structure? Thanks, Marco -- 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] possible sage bug: True*2=1
I found that in Sage 3.4, True * Integer(2)returnsint(1) I think it would be better if the output were either 2 or a type error. This seems to be a problem with Sage integers, python integers work just fine. Some more details: -- | Sage Version 3.4, Release Date: 2009-03-11 | | Type notebook() for the GUI, and license() for information.| -- sage: True*1341234874 1 sage: True*int(1341234874) 1341234874 sage: type(True*1341234874) type 'int' --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
