[sage-devel] Epydoc API Documentation for Sage
Hello all, I played around a bit with Epydoc this morning and was able to get it to produce semi-decent output for Sage (by explicitly importing sage.all at the top of the epydoc script). You can find the documentation at http://sage.math.washington.edu/home/mhansen/sage-epydoc . --Mike (Note that this was generated from a Sage tree that had a few of the sage-combinat patches already applied. Needless to say, the documentation for sage.combinat isn't quite what's in 3.0.5) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: does zn_poly normally take a long time to build?
On Jul 16, 2008, at 11:54 PM, tkeller wrote: I may have been imprecise. To clarify, zn_poly built, then displayed this message: Calibrating cycle counter... ok (3.84e+18) Okay, this means that zn_poly thinks your clock speed is around 3.84 billion GHz. (Yes, 3.84 * 10^18 cycles per second.) This means zn_poly thinks it's allowed to spend a bit longer (!) on the tuning process. I assume your machine is not really that fast. It's possible that either my cycle counting code is not working on your machine, or that something like getrusage is not working as I expect on your machine, or maybe some other weird timing fluke. Could you try building again, to see if it's easily reproducible? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] [Sage Bug Report] Invalid polynomials generated in formal group law calculation
Dear sage-devel, I have recently come across a bug which is perhaps best summarised in the following code (I've removed a big chunk of the backtrace to make it easier to read; the full backtrace is available at the end of this message): --- BEGIN --- sage: k.a = GF(5^2, 'a') sage: EllipticCurve(k, [1,1]).formal_group().group_law(prec = 7) --- TypeError Traceback (most recent call last) /Users/hlaw/src/ipython console in module() /Users/hlaw/sage/local/lib/python2.5/site-packages/sage/schemes/ elliptic_curves/formal_group.py in group_law(self, prec) 440 lam3 = lam2*lam 441 t3 = -t1 - t2 - \ -- 442 (a1*lam + a3*lam2 + a2*nu + 2*a4*lam*nu + 3*a6*lam2*nu)/ \ 443 (1 + a2*lam + a4*lam2 + a6*lam3) 444 inv = self.inverse(prec) [snip] /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial.valuation (sage/ rings/polynomial/polynomial_element.c:22641)() TypeError: The polynomial, p, must have the same parent as self. --- END --- (Note that the polynomial referred to in the TypeError is a red herring: it's an optional parameter to the valuation() method that is not being used in this case.) So the bug is being triggered in the Polynomial.valuation() method, but from what I've determined so far, it occurs because the polynomial whose valuation is being calculated is corrupted in the following sense. If p is the polynomial triggering the error, then: p.coeffs() is [0, 0, 0, 0, 0, 0, 0] p.degree() is 6 p.is_zero() is False Moreover, the error only occurs at certain precisions. For example: sage: def run_test(field, prec_bound=20): E = EllipticCurve(field, [1,1]) FG = E.formal_group() error_precisions = [] for precision in range(2, prec_bound): try: gl = FG.group_law(precision) except TypeError: error_precisions.append(precision) return error_precisions sage: run_test(GF(5^2, 'a'), 30) [5, 6, 7, 9, 11, 13, 14, 15, 17, 19, 21, 23, 25, 26, 27, 29] I have tried randomly changing the elliptic curve and the field degree, but run_test() returned exactly the same list each time. Changing the base field modifies the list a bit: sage: run_test(GF(7^2, 'a'), 30) [5, 6, 7, 9, 11, 13, 15, 17, 18, 19, 20, 21, 23, 25, 27, 29] So 14 and 26 are now gone, but 18 and 20 have been introduced. And finally, no errors occur at all if we use a prime finite field instead of a non-prime one: sage: run_test(GF(5), 30); run_test(GF(7), 30) [] [] The same basic bug occurs on the following machines: Sage 3.0.3 (upgraded from 2.11), Ubuntu Linux 8.04, x86 Sage 2.11, Ubuntu Linux 8.04, x86 Sage 3.04, Mac OS X 10.5.3, x86 The examples in this message were all calculated on the MacOSX machine. Also, I'd like to be put on the CC list of the ticket, if/when a ticket is created for this bug. Thanks in advance, Hamish. Full backtrace: sage: k.a = GF(5^2, 'a') sage: EllipticCurve(k, [1,1]).formal_group().group_law(prec = 7) --- TypeError Traceback (most recent call last) /Users/hlaw/src/ipython console in module() /Users/hlaw/sage/local/lib/python2.5/site-packages/sage/schemes/ elliptic_curves/formal_group.py in group_law(self, prec) 440 lam3 = lam2*lam 441 t3 = -t1 - t2 - \ -- 442 (a1*lam + a3*lam2 + a2*nu + 2*a4*lam*nu + 3*a6*lam2*nu)/ \ 443 (1 + a2*lam + a4*lam2 + a6*lam3) 444 inv = self.inverse(prec) /Users/hlaw/src/element.pyx in sage.structure.element.RingElement.__mul__ (sage/structure/element.c: 8797)() /Users/hlaw/src/coerce.pxi in sage.structure.element._mul_c (sage/ structure/element.c:16614)() /Users/hlaw/src/power_series_poly.pyx in sage.rings.power_series_poly.PowerSeries_poly._mul_c_impl (sage/rings/ power_series_poly.c:3161)() /Users/hlaw/src/element.pyx in sage.structure.element.RingElement.__mul__ (sage/structure/element.c: 8797)() /Users/hlaw/src/coerce.pxi in sage.structure.element._mul_c (sage/ structure/element.c:16614)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial._mul_c_impl (sage/ rings/polynomial/polynomial_element.c:7260)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial._mul_karatsuba (sage/rings/polynomial/polynomial_element.c:10735)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.do_karatsuba (sage/rings/ polynomial/polynomial_element.c:25040)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.do_karatsuba (sage/rings/ polynomial/polynomial_element.c:24742)() /Users/hlaw/src/element.pyx in
[sage-devel] Re: [Sage Bug Report] Invalid polynomials generated in formal group law calculation
Hi, I don't have time to debug this now, but I want to mention that it sounds suspiciously similar to this ticket: http://sagetrac.org/sage_trac/ticket/2943 Maybe there are some clues there, but I never quite got to the bottom of it. david On Jul 17, 2008, at 8:50 AM, Hamish wrote: Dear sage-devel, I have recently come across a bug which is perhaps best summarised in the following code (I've removed a big chunk of the backtrace to make it easier to read; the full backtrace is available at the end of this message): --- BEGIN --- sage: k.a = GF(5^2, 'a') sage: EllipticCurve(k, [1,1]).formal_group().group_law(prec = 7) -- - TypeError Traceback (most recent call last) /Users/hlaw/src/ipython console in module() /Users/hlaw/sage/local/lib/python2.5/site-packages/sage/schemes/ elliptic_curves/formal_group.py in group_law(self, prec) 440 lam3 = lam2*lam 441 t3 = -t1 - t2 - \ -- 442 (a1*lam + a3*lam2 + a2*nu + 2*a4*lam*nu + 3*a6*lam2*nu)/ \ 443 (1 + a2*lam + a4*lam2 + a6*lam3) 444 inv = self.inverse(prec) [snip] /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial.valuation (sage/ rings/polynomial/polynomial_element.c:22641)() TypeError: The polynomial, p, must have the same parent as self. --- END --- (Note that the polynomial referred to in the TypeError is a red herring: it's an optional parameter to the valuation() method that is not being used in this case.) So the bug is being triggered in the Polynomial.valuation() method, but from what I've determined so far, it occurs because the polynomial whose valuation is being calculated is corrupted in the following sense. If p is the polynomial triggering the error, then: p.coeffs() is [0, 0, 0, 0, 0, 0, 0] p.degree() is 6 p.is_zero() is False Moreover, the error only occurs at certain precisions. For example: sage: def run_test(field, prec_bound=20): E = EllipticCurve(field, [1,1]) FG = E.formal_group() error_precisions = [] for precision in range(2, prec_bound): try: gl = FG.group_law(precision) except TypeError: error_precisions.append(precision) return error_precisions sage: run_test(GF(5^2, 'a'), 30) [5, 6, 7, 9, 11, 13, 14, 15, 17, 19, 21, 23, 25, 26, 27, 29] I have tried randomly changing the elliptic curve and the field degree, but run_test() returned exactly the same list each time. Changing the base field modifies the list a bit: sage: run_test(GF(7^2, 'a'), 30) [5, 6, 7, 9, 11, 13, 15, 17, 18, 19, 20, 21, 23, 25, 27, 29] So 14 and 26 are now gone, but 18 and 20 have been introduced. And finally, no errors occur at all if we use a prime finite field instead of a non-prime one: sage: run_test(GF(5), 30); run_test(GF(7), 30) [] [] The same basic bug occurs on the following machines: Sage 3.0.3 (upgraded from 2.11), Ubuntu Linux 8.04, x86 Sage 2.11, Ubuntu Linux 8.04, x86 Sage 3.04, Mac OS X 10.5.3, x86 The examples in this message were all calculated on the MacOSX machine. Also, I'd like to be put on the CC list of the ticket, if/when a ticket is created for this bug. Thanks in advance, Hamish. Full backtrace: sage: k.a = GF(5^2, 'a') sage: EllipticCurve(k, [1,1]).formal_group().group_law(prec = 7) -- - TypeError Traceback (most recent call last) /Users/hlaw/src/ipython console in module() /Users/hlaw/sage/local/lib/python2.5/site-packages/sage/schemes/ elliptic_curves/formal_group.py in group_law(self, prec) 440 lam3 = lam2*lam 441 t3 = -t1 - t2 - \ -- 442 (a1*lam + a3*lam2 + a2*nu + 2*a4*lam*nu + 3*a6*lam2*nu)/ \ 443 (1 + a2*lam + a4*lam2 + a6*lam3) 444 inv = self.inverse(prec) /Users/hlaw/src/element.pyx in sage.structure.element.RingElement.__mul__ (sage/structure/element.c: 8797)() /Users/hlaw/src/coerce.pxi in sage.structure.element._mul_c (sage/ structure/element.c:16614)() /Users/hlaw/src/power_series_poly.pyx in sage.rings.power_series_poly.PowerSeries_poly._mul_c_impl (sage/rings/ power_series_poly.c:3161)() /Users/hlaw/src/element.pyx in sage.structure.element.RingElement.__mul__ (sage/structure/element.c: 8797)() /Users/hlaw/src/coerce.pxi in sage.structure.element._mul_c (sage/ structure/element.c:16614)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial._mul_c_impl (sage/ rings/polynomial/polynomial_element.c:7260)() /Users/hlaw/src/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial._mul_karatsuba
[sage-devel] Re: [Sage Bug Report] Invalid polynomials generated in formal group law calculation
On Jul 17, 2:58 pm, David Harvey [EMAIL PROTECTED] wrote: I don't have time to debug this now, but I want to mention that it sounds suspiciously similar to this ticket: http://sagetrac.org/sage_trac/ticket/2943 It certainly does. (I probably should have filtered the tickets with power series instead of just polynomial when I was looking through them.) The main difference seems to be that in the the present case, the base ring of the polynomial ring is exact, though the polynomial ring in question is derived from the inexact power series ring used in the calculation of the formal group law. Anyway, I get something that works if I remove the bit in the patch in ticket 2943 that uses the old way of determining __nonzero__-ness for exact base rings (i.e. now the code says a polynomial is __nonzero__ if all its coefficients are nonzero, instead of checking if the list of coefficients is non-empty). Cheers, Hamish. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.6.alpha0 released
Installed fine and all tests passed on amd64 hardy heron.
On Wed, Jul 16, 2008 at 11:48 PM, mabshoff [EMAIL PROTECTED] wrote:
Hello folks,
this is 3.0.6.alpha0. This release is a mix of bug fixes and new
features. Nothing crazy has been merged so far and it is unclear at
the moment how things will develop until ISSAC. I have a bunch of
Solaris build fixes sitting on my box that have not been merged due to
lack of time (I am leaving for ECM in about an hour), but expect
steady progress on that front in 3.0.6. As usual please review patches
and spkgs since we have a boatload of them sitting in trac.
Sources and a binary for sage.math are in the usual place:
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.alpha0.tar
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.alpha0-sage.math-only-x86_64-Linux.tar.gz
As usual please report problems and testing results.
Cheers,
Michael
#3232: Martin Albrecht: wrap NTL's BKZ [Reviewed by Ralph-Philipp
Weinmann]
#3531: Gary Furnish: create optional boehm_gc.spkg [Reviewed by
Michael Abshoff]
#3532: Gary Furnish: create optional gdbm.spkg [Reviewed by Michael
Abshoff]
#3554: Mike Hansen: improve M2 pexpect interface [Reviewed by Gary
Furnish]
#3564: William Stein: optimize sage startup: don't import sympy by
default [Reviewed by Michael Abshoff]
#3579: Emily Kirkman: bug in RandonGNP graph constructor [Reviewed by
Robert Miller]
#3592: Ondrej Certik: update sympy to the 0.6.0 release [Reviewed by
Michael Abshoff]
#3601: Anne Schilling: Reimplementation of tensor products [Reviewed
by Mike Hansen]
#3614: Gary Furnish: pbuild broken by finance [Reviewed by Michael
Abshoff]
#3626: Tom Boothby: Graph.set_boundary only takes lists [Reviewed by
Robert Miller]
#3629: Clement Pernet: givaro-3.2.11 installs its own libgmpxx.{so,a}
[Reviewed by Michael Abshoff]
#3650: Gary Furnish: Infinite recursion in pbuild by recursive pxd
imports [Reviewed by Michael Abshoff]
#3651: John Cremona: elliptic curves -- bug in L_ratio() [Reviewed by
Chris Wuthrich]
#3657: Carlo Hamalainen: Documentation for latin squares, DLXCPP;
minor fixes [Reviewed by Mike Hansen]
#3632: Chris Wuthrich, David Harvey: small bug in p-adic heights
[Reviewed by David Harvey, Chris Wuthrich]
#3647: Michael Abshoff: remove - static-libgcc from lcalc's CFLAGS)
[Reviewed by Mike Hansen]
#3648: Carl Witty, David Harvey: complex(pari(...)) fails [Reviewed by
David Harvey, Carl Witty]
#3660: Anne Schilling, Mike Hansen: add documentation to the reference
manual for crystals and root systems [Reviewed by Mike Hansen]
#3661: Nicolas Thiery, Mike Hansen: move sage/combinat/family.py into
the main tree [Reviewed by Mike Hansen]
#3667: William Stein: notebook -- if user history can't be loaded from
disk make it blank (much better than making entire notebook not work
at all) [Reviewed by Michael Abshoff]
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: does zn_poly normally take a long time to build?
Rebuilt 3.0.5 and didn't have any issues this time. Cycle counter gave (1.68e+09) this time around and zn_poly built in about 2 minutes or so. I also rebuilt 3.0.3 and likewise didn't have any problems. Sorry for the phantom bug report. Thomas On Jul 17, 6:36 am, David Harvey [EMAIL PROTECTED] wrote: On Jul 16, 2008, at 11:54 PM, tkeller wrote: I may have been imprecise. To clarify, zn_poly built, then displayed this message: Calibrating cycle counter... ok (3.84e+18) Okay, this means that zn_poly thinks your clock speed is around 3.84 billion GHz. (Yes, 3.84 * 10^18 cycles per second.) This means zn_poly thinks it's allowed to spend a bit longer (!) on the tuning process. I assume your machine is not really that fast. It's possible that either my cycle counting code is not working on your machine, or that something like getrusage is not working as I expect on your machine, or maybe some other weird timing fluke. Could you try building again, to see if it's easily reproducible? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: does zn_poly normally take a long time to build?
On Jul 17, 2008, at 10:31 AM, tkeller wrote: Rebuilt 3.0.5 and didn't have any issues this time. Cycle counter gave (1.68e+09) this time around and zn_poly built in about 2 minutes or so. I also rebuilt 3.0.3 and likewise didn't have any problems. Sorry for the phantom bug report. I've been looking at the calibration code and I can see one spot where (in extremely rare circumstances) the behaviour you observed could occur. Thanks for the bug report, and let us know if it happens again! david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Invalid polynomials generated in formal group law calculation
On Jul 17, 2008, at 9:51 AM, Hamish wrote: I don't have time to debug this now, but I want to mention that it sounds suspiciously similar to this ticket: http://sagetrac.org/sage_trac/ticket/2943 It certainly does. (I probably should have filtered the tickets with power series instead of just polynomial when I was looking through them.) The main difference seems to be that in the the present case, the base ring of the polynomial ring is exact, though the polynomial ring in question is derived from the inexact power series ring used in the calculation of the formal group law. Anyway, I get something that works if I remove the bit in the patch in ticket 2943 that uses the old way of determining __nonzero__-ness for exact base rings (i.e. now the code says a polynomial is __nonzero__ if all its coefficients are nonzero, instead of checking if the list of coefficients is non-empty). I have added a link back to this thread from the ticket. If you find out any more, please add comments to that ticket. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
I took a quick look at that link and it looks brilliant to me. Just this afternoon Francis Clarke and I were saying how nice it would be to have something just like this, and I observed that there was probably someone in the Sage community clever enough to do it. Were you reading my mind? John 2008/7/17 Mike Hansen [EMAIL PROTECTED]: Hello all, I played around a bit with Epydoc this morning and was able to get it to produce semi-decent output for Sage (by explicitly importing sage.all at the top of the epydoc script). You can find the documentation at http://sage.math.washington.edu/home/mhansen/sage-epydoc . --Mike (Note that this was generated from a Sage tree that had a few of the sage-combinat patches already applied. Needless to say, the documentation for sage.combinat isn't quite what's in 3.0.5) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
Wow. This is amazing and great that you did this! Thanks very much Mike. On Thu, Jul 17, 2008 at 6:06 AM, Mike Hansen [EMAIL PROTECTED] wrote: Hello all, I played around a bit with Epydoc this morning and was able to get it to produce semi-decent output for Sage (by explicitly importing sage.all at the top of the epydoc script). You can find the documentation at http://sage.math.washington.edu/home/mhansen/sage-epydoc . --Mike (Note that this was generated from a Sage tree that had a few of the sage-combinat patches already applied. Needless to say, the documentation for sage.combinat isn't quite what's in 3.0.5) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
On Jul 17, 2008, at 6:06 AM, Mike Hansen wrote: Hello all, I played around a bit with Epydoc this morning and was able to get it to produce semi-decent output for Sage (by explicitly importing sage.all at the top of the epydoc script). You can find the documentation at http://sage.math.washington.edu/home/mhansen/sage-epydoc . Hmmm looks really nice, but there's some strangeness, e.g. the documentation for next_prime() in sage.rings.arith has some weird stuff in the proof flag. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
The weirdness seems to appear when the default for a parameter is None. What extra magic would cause the latex parts of the docstrings to be jsmath'ed ? John 2008/7/17 David Harvey [EMAIL PROTECTED]: On Jul 17, 2008, at 6:06 AM, Mike Hansen wrote: Hello all, I played around a bit with Epydoc this morning and was able to get it to produce semi-decent output for Sage (by explicitly importing sage.all at the top of the epydoc script). You can find the documentation at http://sage.math.washington.edu/home/mhansen/sage-epydoc . Hmmm looks really nice, but there's some strangeness, e.g. the documentation for next_prime() in sage.rings.arith has some weird stuff in the proof flag. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
On Thu, Jul 17, 2008 at 12:06 PM, Mike Hansen [EMAIL PROTECTED] wrote: Hello all, I played around a bit with Epydoc this morning and was able to get it to produce semi-decent output for Sage (by explicitly importing sage.all at the top of the epydoc script). You can find the documentation at http://sage.math.washington.edu/home/mhansen/sage-epydoc . --Mike Mike: AWESOME!!! I used to use epydoc for sage long ago, but stopped because it kept crashing more and more when the sage library got larger. Mike: Can you explain precisely how to generate this? Harald: Could you add documentation like this to the sagemath.org website? It's not perfect but I think we should make it nicely available soon. In the meantime, we could just link to http://sage.math.washington.edu/home/mhansen/sage-epydoc Also, http://sagemath.org/doc/html/ needs to be updated. I don't know how to do that anymore now that you have the new website setup. That directory should equal the contents of /home2/sage/build/sage-3.0.5/devel/doc/html Harald -- could you either update this or just tell me what to change and how? Obviously, I could just start poking at files in home2/sage/www-files, but it would be better to have some direction. Thanks! William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
On Thu, Jul 17, 2008 at 11:53 AM, John Cremona [EMAIL PROTECTED] wrote: The weirdness seems to appear when the default for a parameter is None. Yeah, I'm not exactly sure why it's doing that. What extra magic would cause the latex parts of the docstrings to be jsmath'ed ? There are two options. First, you could write a markup module for epydoc ( http://epydoc.sourceforge.net/api/epydoc.markup-module.html ) that processes the docstring and produces the appropriate output. The second option would be to covert Sage's docstrings to a reST format which would be a fair amount of work, but would have lots of advantages. I'll write more about this later. On Thu, Jul 17, 2008 at 1:31 PM, William Stein [EMAIL PROTECTED] wrote: Mike: AWESOME!!! I used to use epydoc for sage long ago, but stopped because it kept crashing more and more when the sage library got larger. Mike: Can you explain precisely how to generate this? Sure. These were the following steps that I took: 1) Download the latest epydoc from http://epydoc.sourceforge.net/ 2) Run sage -sh and run python setup.py install 3) Edited $SAGE_ROOT/local/bin/epydoc by adding import sage.all right before the cli() line. 4) Ran the following command epydoc --html -o sage-epydoc sage It runs surprisingly quickly, but used about 450mb of memory . Also, I didn't turn on any of the options to make the graphs, etc. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.6.alpha0 released
Installed fine and all tests passed, with these flags set:
SAGE_BUILD_THREADS=2
SAGE_PBUILD=yes
on here:
Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version
4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Tue Apr 17 08:42:35
UTC 2007
John
2008/7/17 David Joyner [EMAIL PROTECTED]:
Installed fine and all tests passed on amd64 hardy heron.
On Wed, Jul 16, 2008 at 11:48 PM, mabshoff [EMAIL PROTECTED] wrote:
Hello folks,
this is 3.0.6.alpha0. This release is a mix of bug fixes and new
features. Nothing crazy has been merged so far and it is unclear at
the moment how things will develop until ISSAC. I have a bunch of
Solaris build fixes sitting on my box that have not been merged due to
lack of time (I am leaving for ECM in about an hour), but expect
steady progress on that front in 3.0.6. As usual please review patches
and spkgs since we have a boatload of them sitting in trac.
Sources and a binary for sage.math are in the usual place:
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.alpha0.tar
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.alpha0-sage.math-only-x86_64-Linux.tar.gz
As usual please report problems and testing results.
Cheers,
Michael
#3232: Martin Albrecht: wrap NTL's BKZ [Reviewed by Ralph-Philipp
Weinmann]
#3531: Gary Furnish: create optional boehm_gc.spkg [Reviewed by
Michael Abshoff]
#3532: Gary Furnish: create optional gdbm.spkg [Reviewed by Michael
Abshoff]
#3554: Mike Hansen: improve M2 pexpect interface [Reviewed by Gary
Furnish]
#3564: William Stein: optimize sage startup: don't import sympy by
default [Reviewed by Michael Abshoff]
#3579: Emily Kirkman: bug in RandonGNP graph constructor [Reviewed by
Robert Miller]
#3592: Ondrej Certik: update sympy to the 0.6.0 release [Reviewed by
Michael Abshoff]
#3601: Anne Schilling: Reimplementation of tensor products [Reviewed
by Mike Hansen]
#3614: Gary Furnish: pbuild broken by finance [Reviewed by Michael
Abshoff]
#3626: Tom Boothby: Graph.set_boundary only takes lists [Reviewed by
Robert Miller]
#3629: Clement Pernet: givaro-3.2.11 installs its own libgmpxx.{so,a}
[Reviewed by Michael Abshoff]
#3650: Gary Furnish: Infinite recursion in pbuild by recursive pxd
imports [Reviewed by Michael Abshoff]
#3651: John Cremona: elliptic curves -- bug in L_ratio() [Reviewed by
Chris Wuthrich]
#3657: Carlo Hamalainen: Documentation for latin squares, DLXCPP;
minor fixes [Reviewed by Mike Hansen]
#3632: Chris Wuthrich, David Harvey: small bug in p-adic heights
[Reviewed by David Harvey, Chris Wuthrich]
#3647: Michael Abshoff: remove - static-libgcc from lcalc's CFLAGS)
[Reviewed by Mike Hansen]
#3648: Carl Witty, David Harvey: complex(pari(...)) fails [Reviewed by
David Harvey, Carl Witty]
#3660: Anne Schilling, Mike Hansen: add documentation to the reference
manual for crystals and root systems [Reviewed by Mike Hansen]
#3661: Nicolas Thiery, Mike Hansen: move sage/combinat/family.py into
the main tree [Reviewed by Mike Hansen]
#3667: William Stein: notebook -- if user history can't be loaded from
disk make it blank (much better than making entire notebook not work
at all) [Reviewed by Michael Abshoff]
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Epydoc API Documentation for Sage
On Thu, Jul 17, 2008 at 2:44 PM, Mike Hansen [EMAIL PROTECTED] wrote: 4) Ran the following command epydoc --html -o sage-epydoc sage Sorry about the double post, but you'll want to add a --docformat=plaintext option in there as well. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] remove or hide a method?
This is probably a stupid question: Is there a way to hide or delete a method for a class? If I do this: class SteenrodAlgebra(Algebra): blah blah then do A = SteenrodAlgebra() then A has inherited all of the methods from the Algebra class, many of which are useful, but some of which are completely irrelevant (e.g., the 'variable_name' method). It might be nice if I could define the class SteenrodAlgebra so as to hide (or remove) those methods, so that 'A.tab' doesn't display them as possibilities. (I'm trying to think of this from the point of view of beginning users who might be overwhelmed by the long list of options when they try to tab- complete.) So, is there any way to do this, or am I stuck with these methods once I define SteenrodAlgebra in terms of the Algebra class? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: remove or hide a method?
On Thu, Jul 17, 2008 at 2:52 PM, John H Palmieri [EMAIL PROTECTED] wrote: This is probably a stupid question: Is there a way to hide or delete a method for a class? If I do this: class SteenrodAlgebra(Algebra): blah blah then do A = SteenrodAlgebra() then A has inherited all of the methods from the Algebra class, many of which are useful, but some of which are completely irrelevant (e.g., the 'variable_name' method). It might be nice if I could define the class SteenrodAlgebra so as to hide (or remove) those methods, so that 'A.tab' doesn't display them as possibilities. (I'm trying to think of this from the point of view of beginning users who might be overwhelmed by the long list of options when they try to tab- complete.) So, is there any way to do this, or am I stuck with these methods once I define SteenrodAlgebra in terms of the Algebra class? I don't know of an easy way to hide a particular method, but you can control what things get tab completed by defining a trait_names method: sage: class Foo(object): : def trait_names(self): : return ['a','b','c','d'] : sage: a = Foo() sage: a. a.aa.ba.ca.da.trait_names As a user, I don't know whether or not I would prefer a customized tab completion. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: remove or hide a method?
On Thu, Jul 17, 2008 at 9:57 PM, Mike Hansen [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 2:52 PM, John H Palmieri [EMAIL PROTECTED] wrote: This is probably a stupid question: Is there a way to hide or delete a method for a class? If I do this: class SteenrodAlgebra(Algebra): blah blah then do A = SteenrodAlgebra() then A has inherited all of the methods from the Algebra class, many of which are useful, but some of which are completely irrelevant (e.g., the 'variable_name' method). It might be nice if I could define the class SteenrodAlgebra so as to hide (or remove) those methods, so that 'A.tab' doesn't display them as possibilities. (I'm trying to think of this from the point of view of beginning users who might be overwhelmed by the long list of options when they try to tab- complete.) So, is there any way to do this, or am I stuck with these methods once I define SteenrodAlgebra in terms of the Algebra class? I don't know of an easy way to hide a particular method, but you can control what things get tab completed by defining a trait_names method: sage: class Foo(object): : def trait_names(self): : return ['a','b','c','d'] : sage: a = Foo() sage: a. a.aa.ba.ca.da.trait_names As a user, I don't know whether or not I would prefer a customized tab completion. trait_names doesn't currently allow one to cover up existing names from appearing in the tab completion list. However, I'm certain Fernando Perez could make it so IPython could call some function like trait_names that would allow one to cover up certain attributes. Fernando -- what do you think? -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Minor documentation error
This page: http://www.sagemath.org/doc/html/prog/node72.html claims: You can browse the official repositories for Sage with your web browser here: http://sagemath.org/sage/hg This appears to not be valid at present. It returns a 404. Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fwd: [sage-devel] Minor documentation error
Hi Harald, What happened to the hg repos? Before you modified the web page, http://sagemath.org/hg pointed to all the hg repos for sage. Now it doesn't anymore. We need to have a www2/hg directory, I think. -- Forwarded message -- From: Bill Hart [EMAIL PROTECTED] Date: Thu, Jul 17, 2008 at 11:23 PM Subject: [sage-devel] Minor documentation error To: sage-devel sage-devel@googlegroups.com This page: http://www.sagemath.org/doc/html/prog/node72.html claims: You can browse the official repositories for Sage with your web browser here: http://sagemath.org/sage/hg This appears to not be valid at present. It returns a 404. Bill. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.6.alpha0 released
Hi, small report - compiled fine, all tests passed (but that's what was reported by make test)... looking into test.log there's still segfault with tachyon test: sage -t devel/sage/sage/plot/tachyon.pysh: line 1: 2 Naruszenie ochrony pamięci tachyon /root/.sage//temp/ginland/23251//tmp_12.dat -format PNG -o /root/.sage//temp/ginland/23251//test.png /dev/null about ssmod, there's something strange in it. I run it about 20 times (as there were 2 failures / 150 tests it seems I made not enough tests to hit it), passed all the time, but look at speed difference, 19 times it was around 8 seconds, once more than 220 seconds! to make it clear, in both cases I had enough free memory (but long case took 50mb more), and I didn't had other apps running than test and top to make sure... no cron jobs for hour etc... I don't know if there should be such huge difference in same test run in same environment [EMAIL PROTECTED] sage]# sage -t devel/sage/sage/modular/ssmod/ssmod.py sage -t devel/sage/sage/modular/ssmod/ssmod.py [8.8 s] -- All tests passed! Total time for all tests: 8.8 seconds [EMAIL PROTECTED] sage]# sage -t devel/sage/sage/modular/ssmod/ssmod.py sage -t devel/sage/sage/modular/ssmod/ssmod.py [221.5 s] -- All tests passed! Total time for all tests: 221.5 seconds cheers, Andrzej. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Minor documentation error
On Jul 17, 11:23 pm, Bill Hart [EMAIL PROTECTED] wrote: browser here:http://sagemath.org/sage/hg Seems to be a bug in the documentation, the correct link is http://www.sagemath.org/hg/ or http://hg.sagemath.org/ Harald PS: don't forget the trailing / ... directory vs. file problem --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] another coercion question
I have several different vector space bases for an algebra A, and I have implemented this by having a class MyAlgebra, instances of which have an attribute _basis_name which is a string naming the basis. I have __cmp__ defined so that the basis is ignored: any two instances are canonically isomorphic, and there is good coercion between them. Now, the attribute _basis_name just affects the _repr_ and _latex_ methods for elements of the algebra; it has no other effect. My question is this: when I multiply elements from algebras with two different bases, I can't figure out how the parent of the result is determined. Some documentation suggests that the parent should be determined by the left factor, but that is not consistently what's happening. I think I would like to force the result to have the same parent as the left-hand factor, but by the time elements get to the _mul_ method, their parents have been changed (via coercion), so I can't find out what that parent is. (Perhaps something is getting cached in the coercion process, so things are getting coerced to the cached algebra, not the left-hand parent?) What should I do? Does it sound like I'm doing something wrong, and if so, what should I investigate? I can try to post some sample code somewhere, but that will take a bit of work. Or I can post short snippets here, of course. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: book that uses sage
In section 1.1.3 of your book you state: The smallest currently open challenge is RSA-704, worth $30.000: ... In 2007 RSA withdrew all unsolved factoring challenges: http://www.rsa.com/rsalabs/node.asp?id=2094 RSA-704 remains unsolved, but solving it today will only earn you a mention in wikipedia. -Daryl On Jul 9, 3:47 am, William Stein [EMAIL PROTECTED] wrote: Hi, This number theory book that I wrote uses Sage throughout: http://sage.math.washington.edu/papers/ent/ent-stein/ent.pdf It will be published by Springer-Verlag as a UTM book sometime in the next 6 months. Comments welcome before it's too late :-) -- William -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: another coercion question
On Jul 17, 3:30 pm, John H Palmieri [EMAIL PROTECTED] wrote: I have several different vector space bases for an algebra A, and I have implemented this by having a class MyAlgebra, instances of which have an attribute _basis_name which is a string naming the basis. I have __cmp__ defined so that the basis is ignored: any two instances are canonically isomorphic, and there is good coercion between them. Now, the attribute _basis_name just affects the _repr_ and _latex_ methods for elements of the algebra; it has no other effect. My question is this: when I multiply elements from algebras with two different bases, I can't figure out how the parent of the result is determined. Some documentation suggests that the parent should be determined by the left factor, but that is not consistently what's happening. I think I would like to force the result to have the same parent as the left-hand factor, but by the time elements get to the _mul_ method, their parents have been changed (via coercion), so I can't find out what that parent is. (Perhaps something is getting cached in the coercion process, so things are getting coerced to the cached algebra, not the left-hand parent?) What should I do? Does it sound like I'm doing something wrong, and if so, what should I investigate? Currently it's built-in to coercion that if two parents are equal, then it doesn't matter which parent it picks. (And the decision is baked into various caches, etc., so the decision can depend on the previous history of commands in this session.) I've raised this issue as a problem a few weeks ago (see http://groups.google.com/group/sage-devel/browse_thread/thread/4520ed454e705ce1#), but nothing came of it yet. Even if this gets fixed, I don't think you can fix it so that coercion uses the parent of the left-hand value by changing your code; this would require changes inside the base coercion code. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: another coercion question
On Jul 17, 4:51 pm, Carl Witty [EMAIL PROTECTED] wrote: On Jul 17, 3:30 pm, John H Palmieri [EMAIL PROTECTED] wrote: I have several different vector space bases for an algebra A, and I have implemented this by having a class MyAlgebra, instances of which have an attribute _basis_name which is a string naming the basis. I have __cmp__ defined so that the basis is ignored: any two instances are canonically isomorphic, and there is good coercion between them. Now, the attribute _basis_name just affects the _repr_ and _latex_ methods for elements of the algebra; it has no other effect. My question is this: when I multiply elements from algebras with two different bases, I can't figure out how the parent of the result is determined. Some documentation suggests that the parent should be determined by the left factor, but that is not consistently what's happening. I think I would like to force the result to have the same parent as the left-hand factor, but by the time elements get to the _mul_ method, their parents have been changed (via coercion), so I can't find out what that parent is. (Perhaps something is getting cached in the coercion process, so things are getting coerced to the cached algebra, not the left-hand parent?) What should I do? Does it sound like I'm doing something wrong, and if so, what should I investigate? Currently it's built-in to coercion that if two parents are equal, then it doesn't matter which parent it picks. (And the decision is baked into various caches, etc., so the decision can depend on the previous history of commands in this session.) I've raised this issue as a problem a few weeks ago (seehttp://groups.google.com/group/sage-devel/browse_thread/thread/4520ed...), but nothing came of it yet. Even if this gets fixed, I don't think you can fix it so that coercion uses the parent of the left-hand value by changing your code; this would require changes inside the base coercion code. Okay, thanks. Here's something from Section 2.8 of the Sage Programming Guide: ARITHMETIC __add__, __mul__, ...:: When doing a binary operation, if the parents are not identical (in the sense of is ), determine if precisely one _coerce_ map is defined; if so, apply it and do the arithmetic operation. If both are defined, the parents are canonically isomorphic, so use the left one. If neither are defined, raise a TypeError. (Whether or not there is a coerce map between objects should be cached for efficiency.) I guess you're saying that this is wrong (the part that says so use the left one). Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Identification with ldap.
I am in the processes of implementing ldap authentication as well... although it is not going so smoothly. I was trying to override the classes in user_db.py with some custom classes. Fine. That seems ok. The UserDatabase is used throughout twist.py which seemed to be the server software. avatars.py and guard.py rely heavily on this. Unfortunately there seems to be a somewhat independed db of users in notebook. This is really 'twisting' my head around. I have code using python-ldap for doing the queries (happy to share though it is not pretty) but the user management is very hard to follow. Is there some cruft here? Do notebooks keep their own subsets of users for the purposes of limited collaborations? Any leg up would be nice! On Jul 7, 12:38 am, Philippe Saade [EMAIL PROTECTED] wrote: Hi, i know it would be specific to Linux boxes but i think there is a python_PAM module that would help Sage rely on native Linux PAM mechanism.. Maybe an option.. Philippe On Sun, Jul 6, 2008 at 8:38 PM, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, 2008/7/6 Thierry Dumont [EMAIL PROTECTED]: Great! --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Parent and Element support for non numeric data
On Jul 16, 2:39 pm, Mike Hansen [EMAIL PROTECTED] wrote: I have a class which represents the set of words over an alphabet (but is not a Monoïd since it also contains infinite words) and another class which represents a word. These classes have a natural Parent/Element relationship and I tried to use these classes from Sage as superclasses. But I am encountering various problems due to the implicit assumption that the Elements are always sort of numeric. As an example Element.__nonzero__() tries to call the parent with 0 to compare against the 0 element. But in my case it does not makes sense to create a word from that. So I am stuck. We already have a working parent/element relationship, but since it is not the Sage one it does not participate in coercions and we can't use Sage morphisms. The Element.__nonzero__ is just a sensible default that should be overridden if needed by subclasses of Element. The __nonzero__ method gets called if you have an object a and you do if a:. See the example below: sage: class Foo(object): : def __nonzero__(self): : return True : sage: a = Foo() sage: if a: : print a is 'nonzero' : a is 'nonzero' So, you should decide how you want your words to behave with respect to this. Just to throw in my two cents, the fact that the class has a member function __nonzero__() suggests that the class is intended for objects supporting some sort of binary operation. Certainly one is not forced to use such a class in this way, but that is the intention. And given that we want to be able to construct things like combinatorial algebras from other combinatorial objects, it makes sense that a class of combinatorial objects support designating a zero (identity) element for some binary operation and a way of testing whether a given instance of the class is this zero element. Words are certainly one such class of combinatorial object. And while there are many kinds of binary operations one might define on words, for a great many of such operations that occur naturally, the empty word turns out to be the identity element. So I think a more reasonable default for the word class would be that the integer zero is coerced to the empty word, and __nonzero_(w) would return True iff w is the empty word, even if the entire set of words does not form a monoid. But I think this discussion does bring up the question of how such structures are factored within the overall combinatorics module. It is reasonable to expect to be able to design a class X for some kind of combinatorial object (words, trees, graphs, matroids, etc) without necessarily declaring any sort of binary operation, and without regard to higher future uses, such as forming the basis of an algebra. One would like subsequently to be able to form an algebra or coalgebra or other type of higher structure from the elements of type X, making use of the X code, but without burdening the class definition of X by adding these other notions necessary for the higher structure. It is at the point that one forms the higher structure that one needs to worry about what the binary operations are and what is are the identity elements, if any, of these operations. I have not examined the existing Sage class structure enough to know how cleanly these concerns are separated, but it sounds like the kind of concern that Arnaud is driving at. There are also costs as well as benefits of separating these concerns in the implementation, so it is the sort of think that deserves a hard look (sober evaluation) before dashing off in any particular direction. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] python warning module and computation warnings
In working on the eigenspaces command, if an inexact ring uses the generic algorithm, we want to warn the user that the answer may not make sense because of numerical issues. Currently this is done by refusing to compute the eigenspaces unless a special option is set to true. Instead, I propose we use the standard Python warning features in the warnings module (see http://docs.python.org/lib/module-warnings.html ) As I understand it, warnings in Python are just exceptions that are treated in special ways. Using the warnings module, the user can decide to have warnings trigger different actions, from nothing to printing out error messages to throwing exceptions. I propose we add some warning classes to Sage that can be used as a general framework for warnings, much as the current exception framework is used. Python has several builtin warning categories, including a DeprecationWarning class, etc. I propose we add the following warning classes SageWarning - NumericalPrecisionWarning - ??? Okay, so I'm not very creative. What other warnings would be nice for Sage to have? Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Minor documentation error
On Thu, Jul 17, 2008 at 11:45 PM, Harald Schilly [EMAIL PROTECTED] wrote: On Jul 17, 11:23 pm, Bill Hart [EMAIL PROTECTED] wrote: browser here:http://sagemath.org/sage/hg Seems to be a bug in the documentation, the correct link is http://www.sagemath.org/hg/ or http://hg.sagemath.org/ Harald Can you make a trac ticket listing this documentation error, so it gets fixed? PS: don't forget the trailing / ... directory vs. file problem -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Identification with ldap.
On Fri, Jul 18, 2008 at 2:17 AM, Michael_D_G [EMAIL PROTECTED] wrote:
I am in the processes of implementing ldap authentication as well...
although it is not going so smoothly.
I was trying to override the classes in user_db.py with some custom
classes.
Fine. That seems ok. The UserDatabase
is used throughout twist.py which seemed to be the server software.
avatars.py and guard.py
rely heavily on this. Unfortunately there seems to be a somewhat
independed db of users in
notebook. This is really 'twisting' my head around. I have code using
python-ldap for doing
the queries (happy to share though it is not pretty) but the user
Why is it not pretty?
management is very hard to follow.
Is there some cruft here?
Of course.
Do notebooks keep their own subsets of users
for the purposes of limited collaborations?
By notebooks do you mean worksheets?
If so, then yes each worksheet has a list of users that
are allowed to collaborate on that worksheet. It's
just a plain text list of usernames.
Each complete notebook has a list of users. This is
completely independent of twisted, avatar.py, guard.py,
etc. except that those files will query this list to decide
whether login credentials are valid.
Here is an example of using the users() method to get a list
of them:
EXAMPLES:
sage: n = sage.server.notebook.notebook.Notebook(tmp_dir())
sage: n.create_default_users('password')
Creating default users.
sage: list(sorted(n.users().iteritems()))
[('_sage_', _sage_), ('admin', admin), ('guest', guest),
('pub', pub)]
sage: n.delete()
The list of users for a notebook is a very very simple data
structure. A user is just an instance of the class User that
is defined in user.py. The list of users (the attribute
__users of the notebook instance) is just pickled as part
of the notebook object. That's all there is to
users in the Sage notebook.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: another coercion question
On Fri, Jul 18, 2008 at 2:11 AM, John H Palmieri [EMAIL PROTECTED] wrote: On Jul 17, 4:51 pm, Carl Witty [EMAIL PROTECTED] wrote: On Jul 17, 3:30 pm, John H Palmieri [EMAIL PROTECTED] wrote: I have several different vector space bases for an algebra A, and I have implemented this by having a class MyAlgebra, instances of which have an attribute _basis_name which is a string naming the basis. I have __cmp__ defined so that the basis is ignored: any two instances are canonically isomorphic, and there is good coercion between them. Now, the attribute _basis_name just affects the _repr_ and _latex_ methods for elements of the algebra; it has no other effect. My question is this: when I multiply elements from algebras with two different bases, I can't figure out how the parent of the result is determined. Some documentation suggests that the parent should be determined by the left factor, but that is not consistently what's happening. I think I would like to force the result to have the same parent as the left-hand factor, but by the time elements get to the _mul_ method, their parents have been changed (via coercion), so I can't find out what that parent is. (Perhaps something is getting cached in the coercion process, so things are getting coerced to the cached algebra, not the left-hand parent?) What should I do? Does it sound like I'm doing something wrong, and if so, what should I investigate? Currently it's built-in to coercion that if two parents are equal, then it doesn't matter which parent it picks. (And the decision is baked into various caches, etc., so the decision can depend on the previous history of commands in this session.) I've raised this issue as a problem a few weeks ago (seehttp://groups.google.com/group/sage-devel/browse_thread/thread/4520ed...), but nothing came of it yet. Even if this gets fixed, I don't think you can fix it so that coercion uses the parent of the left-hand value by changing your code; this would require changes inside the base coercion code. Okay, thanks. Here's something from Section 2.8 of the Sage Programming Guide: ARITHMETIC __add__, __mul__, ...:: When doing a binary operation, if the parents are not identical (in the sense of is ), determine if precisely one _coerce_ map is defined; if so, apply it and do the arithmetic operation. If both are defined, the parents are canonically isomorphic, so use the left one. If neither are defined, raise a TypeError. (Whether or not there is a coerce map between objects should be cached for efficiency.) I guess you're saying that this is wrong (the part that says so use the left one). Argh. It was right when I wrote that documentation and implemented the second version of the coercion model. :-) Whoever implemented the third/fourth version(s) of the coercion model will I hope also update the programming guide with correct statements (hint, hint Robertwb). -- william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.5/3.0.6.alpha0: doctest failure in ssmod.py
Ok, here is what I found out last night: * 3.0.3 runs the test 200 times without failing it once * 3.0.4 with the new FLINT 1.0.13 fails 8 ought of 500 tests. So we are given a couple possibilities: * There is an algorithmic issue in ssmod somewhere or some algorithmic issue got exposed somehow in 3.0.4+ * There is an undiscovered bug in LinBox * There is an undiscovered bug in FLINT * none of the above * all of the above Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
