[sage-devel] canonicalize or evaluate
Hi, yesterday on IRC I realized I don't understand these terms. :) x + x - 2*x is this evaluation? x +y, vs. y+x ... is this canonicalization? Is this how everyone understands these terms? If so, we need to fix SymPy all over. :) Also I was mistaking canonize and canonicalize: http://en.wikipedia.org/wiki/Canonization http://en.wikipedia.org/wiki/Canonicalization It'd be good if all of us use the same terms for the same thing. Also, Garry, how are you going to call the method/function, that does x+x- 2*x, -- eval? We used to call it eval, now we call it canonize (which is completely wrong, see above), so I think we should switch back to eval. Ondrej --~--~-~--~~~---~--~~ 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: notebook failure with sage-3.0.alpha4
Looks like this was due to a bad merge of #2883. My guess is, adding another 'id,' to sage/server/notebook/cell.py, line 659 will do the trick -- unless something tricky is going on. I'll check it around 1:30 Monday. On Mon, 14 Apr 2008, Jaap Spies wrote: On Fedora 7, 32 bits all tests passed, but on opening a new worksheet (and alson on opening an existing ws) got an internal server error. See below, Jaap sage: notebook() The notebook files are stored in: /home/jaap/.sage//sage_notebook Port 8000 is already in use. Trying next port... * * * Open your web browser to https://localhost:8001 * * * There is an admin account. If you do not remember the password, quit the notebook and type notebook(reset=True). Removing stale pidfile /home/jaap/.sage/sage_notebook/twistd.pd 2008-04-14 11:49:14+0200 [-] Log opened. 2008-04-14 11:49:14+0200 [-] twistd 8.0.1 (/home/jaap/downloads/sage-3.0.alpha4/local/bin/python 2.5.1) starting up 2008-04-14 11:49:14+0200 [-] reactor class: class 'twisted.internet.selectreactor.SelectReactor' 2008-04-14 11:49:14+0200 [-] twisted.web2.channel.http.HTTPFactory starting on 8001 2008-04-14 11:49:14+0200 [-] Starting factory twisted.web2.channel.http.HTTPFactory instance at 0xa76b76c 2008-04-14 11:49:23+0200 [HTTPChannel,0,127.0.0.1] Exception rendering: 2008-04-14 11:49:23+0200 [HTTPChannel,0,127.0.0.1] Unhandled Error Traceback (most recent call last): File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 185, in addCallbacks self._runCallbacks() File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 323, in _runCallbacks self.result = callback(self.result, *args, **kw) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 284, in _continue self.unpause() File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 280, in unpause self._runCallbacks() --- exception caught here --- File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 323, in _runCallbacks self.result = callback(self.result, *args, **kw) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/server.py, line 296, in lambda d.addCallback(lambda res, req: res.renderHTTP(req), self) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 85, in renderHTTP return method(request) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 202, in http_GET return super(Resource, self).http_GET(request) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 128, in http_GET return self.render(request) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/twist.py, line 1148, in render s = notebook.html(worksheet_filename = self.name, username=self.username) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/notebook.py, line 1936, in html body = self._html_body(worksheet_filename=worksheet_filename, username=username, show_debug=show_debug) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/notebook.py, line 1609, in _html_body worksheet_html = worksheet.html() File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/worksheet.py, line 828, in html s += self.html_worksheet_body(do_print=do_print) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/worksheet.py, line 984, in html_worksheet_body s += cell.html(ncols, do_print=do_print) + '\n' File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/cell.py, line 609, in html html_in = self.html_in(do_print=do_print) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/cell.py, line 659, in html_in %(cls, r, ncols, id, id, id, id, id, 'readonly=1' if do_print else '', t) exceptions.TypeError: not enough arguments for
[sage-devel] notebook failure with sage-3.0.alpha4
On Fedora 7, 32 bits all tests passed, but on opening a new worksheet (and alson on opening an existing ws) got an internal server error. See below, Jaap sage: notebook() The notebook files are stored in: /home/jaap/.sage//sage_notebook Port 8000 is already in use. Trying next port... * * * Open your web browser to https://localhost:8001 * * * There is an admin account. If you do not remember the password, quit the notebook and type notebook(reset=True). Removing stale pidfile /home/jaap/.sage/sage_notebook/twistd.pd 2008-04-14 11:49:14+0200 [-] Log opened. 2008-04-14 11:49:14+0200 [-] twistd 8.0.1 (/home/jaap/downloads/sage-3.0.alpha4/local/bin/python 2.5.1) starting up 2008-04-14 11:49:14+0200 [-] reactor class: class 'twisted.internet.selectreactor.SelectReactor' 2008-04-14 11:49:14+0200 [-] twisted.web2.channel.http.HTTPFactory starting on 8001 2008-04-14 11:49:14+0200 [-] Starting factory twisted.web2.channel.http.HTTPFactory instance at 0xa76b76c 2008-04-14 11:49:23+0200 [HTTPChannel,0,127.0.0.1] Exception rendering: 2008-04-14 11:49:23+0200 [HTTPChannel,0,127.0.0.1] Unhandled Error Traceback (most recent call last): File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 185, in addCallbacks self._runCallbacks() File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 323, in _runCallbacks self.result = callback(self.result, *args, **kw) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 284, in _continue self.unpause() File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 280, in unpause self._runCallbacks() --- exception caught here --- File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 323, in _runCallbacks self.result = callback(self.result, *args, **kw) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/server.py, line 296, in lambda d.addCallback(lambda res, req: res.renderHTTP(req), self) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 85, in renderHTTP return method(request) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 202, in http_GET return super(Resource, self).http_GET(request) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 128, in http_GET return self.render(request) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/twist.py, line 1148, in render s = notebook.html(worksheet_filename = self.name, username=self.username) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/notebook.py, line 1936, in html body = self._html_body(worksheet_filename=worksheet_filename, username=username, show_debug=show_debug) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/notebook.py, line 1609, in _html_body worksheet_html = worksheet.html() File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/worksheet.py, line 828, in html s += self.html_worksheet_body(do_print=do_print) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/worksheet.py, line 984, in html_worksheet_body s += cell.html(ncols, do_print=do_print) + '\n' File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/cell.py, line 609, in html html_in = self.html_in(do_print=do_print) File /home/jaap/downloads/sage-3.0.alpha4/local/lib/python2.5/site-packages/sage/server/notebook/cell.py, line 659, in html_in %(cls, r, ncols, id, id, id, id, id, 'readonly=1' if do_print else '', t) exceptions.TypeError: not enough arguments for format string 2008-04-14 11:50:56+0200 [-] (Notebook cleanly saved. Press control-C again to exit.) --~--~-~--~~~---~--~~ 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
[sage-devel] Re: Giac/Xcas? (was Re: multivariate factoring - use maxima ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, parisse wrote: | (c) Create some sort of C/C++ library interface. This is very | very difficult. | | | I had some hope that swig could help do the bridge between the C++ | giac library and python, but I never tried. If your code is heavy on templates, I suggest to try out Boost.Python[1]. You just need a decent C++ compiler to use it (no external tools), I use it for my project and it is really a blessing. As far as I can tell, performance is indistinguishable from C++. Best regards, ~ Francesco. [1] http://www.boost.org/doc/libs/release/libs/python/doc/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgDLs0ACgkQFCtI0YdDCEs0kACgv2MtXfUOCNG+Eme0K6fscozk l10AnRvyCut47zTvS+YLebw/j6C3xQkp =1uWd -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: Noncanonical coercion (finite fields)
On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. Interesting that's not what happens in my install of sage 2.11. I get: sage: F9.a = GF(9) sage: F81.b = GF(81) sage: F81(a) [.] type 'exceptions.IndexError': n=17606600 must be self.order() 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: Noncanonical coercion (finite fields)
THere's a ticket somewhere asking for the implementation of sensible coercion between finite fields. Obviously only F_q - F_q' where q' ia a power of q. But I have no idea how to do this in a way which is canonical -- so at the very least is transitive so that q - q' - q is the same as q-q. If anyone out there has an idea here it would be good to hear it. Is the following a sensible strategy: For each prime p maintain a list of fields of p-power order which have been created so far, with maps between them, always normalised to that if n is the largest degree of a field in the list (i.e. p^n is the largest power of p) then all the others are divisors of n. Now, on the creation of a new field of size p^m, if n|m then (do something fairly simple), or if gcd(n,m)=1 then (do something else fairly simple, else (do something more complicated). Does anyone know how Magma handles this? John 2008/4/14 David Harvey [EMAIL PROTECTED]: On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. Interesting that's not what happens in my install of sage 2.11. I get: sage: F9.a = GF(9) sage: F81.b = GF(81) sage: F81(a) [.] type 'exceptions.IndexError': n=17606600 must be self.order() 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: Giac/Xcas? (was Re: multivariate factoring - use maxima ?)
I'm interested in his spreadsheet from a browser project, since we plan to do something similar with Sage at some point, probably. Does he intend to embed giac like functionality as formulas in the cells? Does from a browser mean an AJAX application? giac has already cell evaluation functionnality, something you can test from inside xcas (Edit-Add spreadsheet). It must reevaluate the whole table. I'm on vacation this week, I don't have the URL where you can test it, if my recollection is correct it is indeed an ajax application. I think some people in CA research will come around eventually, though if they don't it won't stop us. I agree. You could make this vastly easier for us if you (1) installed Sage on a computer from source (2) installed giac into that Sage install by typing ./sage -sh # to set some environ variables and paths then in your giac source directory ./configure --prefix=$SAGE_LOCAL make make install and *fix* all the problems that come up. Then tell us what steps are needed to build giac into your Sage install. With that info, we could easily make a giac spkg. I have done the experience on my local sage install (2.8.15), I had indeed to fix the file Xcas1.cc where a #ifdef HAVE_LIBFLTK #endif was missing. I have updated the source tarball on my ftp site. I can not garantee that it will work everywhere since giac configure does check for libraries outside the sage local tree, hence your config.h might differ from mine, but that should be easy to fix (I mean perhaps add a couple of #fidef). You might have an error doing make install if latex2html is not installed. If you don't want to install latex2html, an easy fix is to comment the recursion in Makefile.am from the doc subdirectory, the first two lines should look like doc/Makefile.am #SUBDIRS #DIST_SUBDIRS then run automake in the giac directory and then ./configure --prefix=$SAGE_LOCAL --disable-gui Another way to fix this is to run make install from the src subdirectory only. Or maybe add a fake latex2html command somewhere in your path. I don't know what the sage build process can handle best. Any suggestion? After reading your answers, here is what I hope will happen: (1) you will spend some time building Sage from source and figure out how to install giac into the Sage build directory. This is by far easier for you than for us, probably, since you know the giac build system and code base more than anybody. I hope it should work for you now. (4) I hope you will continue watching sage-devel and post whenever you have any thoughts or experiences about things we're discussing. Given your goals and background developing giac, it is inevitable that you'll have a lot to offer in regard to experience, etc. Even if there turns out to be no real code sharing between the giac and Sage projects, there are certainly a lot of common problems and solutions (patterns) which can be shared. At the Enthought/Sage Days in Austin Texas in February, there were a surprisingly large number of discussions about common problems the Enthought/Scipy project faces and the Sage project faces, where no code would or could be shared, but where we benefited a lot from discussing our solutions together. (5) I hope you'll come to a Sage Days workshop sometime. You can see a list of upcoming workshops here: http://wiki.sagemath.org/ Notice that one is in Nancy, France in October. Coming to a Sage Days is by far the best way to find out who the Sage developers really are, which is just a bunch of people all over who just want to create awesome free open source mathematical software. Excellent, I'll probably be able to come to Nancy at least one day next October. Bernard --~--~-~--~~~---~--~~ 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: notebook failure with sage-3.0.alpha4
[EMAIL PROTECTED] wrote: Looks like this was due to a bad merge of #2883. My guess is, adding another 'id,' to sage/server/notebook/cell.py, line 659 will do the trick -- unless something tricky is going on. I'll check it around 1:30 Monday. Opened trac ticket: http://trac.sagemath.org/sage_trac/ticket/2917 Jaap --~--~-~--~~~---~--~~ 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: Noncanonical coercion (finite fields)
On Sun, Apr 13, 2008 at 09:50:44AM -0700, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. I've made this ticket #2916. The patch I attached there catches a missing case in FiniteField_givaro.__call__ and throws a TypeError, which appears to be the intent of the function according to the existing docstring. -Willem Jan --~--~-~--~~~---~--~~ 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: Giac/Xcas? (was Re: multivariate factoring - use maxima ?)
On Mon, Apr 14, 2008 at 6:58 AM, parisse [EMAIL PROTECTED] wrote: I'm interested in his spreadsheet from a browser project, since we plan to do something similar with Sage at some point, probably. Does he intend to embed giac like functionality as formulas in the cells? Does from a browser mean an AJAX application? giac has already cell evaluation functionnality, something you can test from inside xcas (Edit-Add spreadsheet). It must reevaluate the whole table. I'm on vacation this week, I don't have the URL where you can test it, if my recollection is correct it is indeed an ajax application. I think some people in CA research will come around eventually, though if they don't it won't stop us. I agree. You could make this vastly easier for us if you (1) installed Sage on a computer from source (2) installed giac into that Sage install by typing ./sage -sh # to set some environ variables and paths then in your giac source directory ./configure --prefix=$SAGE_LOCAL make make install and *fix* all the problems that come up. Then tell us what steps are needed to build giac into your Sage install. With that info, we could easily make a giac spkg. I have done the experience on my local sage install (2.8.15), I had indeed to fix the file Xcas1.cc where a #ifdef HAVE_LIBFLTK #endif was missing. I have updated the source tarball on my ftp site. I can not garantee that it will work everywhere since giac configure does check for libraries outside the sage local tree, hence your config.h might differ from mine, but that should be easy to fix (I mean perhaps add a couple of #fidef). Which libraries does it check for that a standard system won't have? I guess I'll find out. On OS X my build fails with: In file included from gen.h:39, from sym2poly.h:25, from sym2poly.cc:32: vecteur.h:25:28: error: gsl/gsl_vector.h: No such file or directory vecteur.h:26:28: error: gsl/gsl_matrix.h: No such file or directory vecteur.h:27:33: error: gsl/gsl_permutation.h: No such file or directory In file included from sym2poly.cc:36: In file included from sym2poly.cc:36: modpoly.h:27:30: error: NTL/ZZXFactoring.h: No such file or directory modpoly.h:28:20: error: NTL/ZZ.h: No such file or directory modpoly.h:29:22: error: NTL/GF2X.h: No such file or directory modpoly.h:30:32: error: NTL/pair_GF2X_long.h: No such file or directory modpoly.h:31:31: error: NTL/GF2XFactoring.h: No such file or directory I guess this is Giac not finding GSL, NT, etc.Your autoconf seems to have options to enable/disable GSL, NTL, etc., but I can't tell wout to specify exactly *where* those libraries are installed on the system (for Sage, they are in $SAGE_LOCAL). On one Linux machine that I tried the buld *does* work, perhaps because so much is installed system-wide on that machine. The spkg I made is here: http://sage.math.washington.edu/home/was/tmp/giac-0.7.4.spkg this is really a tar bz2 file, so you can extract it with tar jxvf giac-0.7.4.spkg It took 31 minutes to build giac/xcas, and the build appears to work: sage: !giac Help file aide_cas not found // Unable to find keyword file doc/en/keywords Added 0 synonyms Welcome to giac readline interface (c) 2001,2007 B. Parisse others Homepage http://www-fourier.ujf-grenoble.fr/~parisse/giac.html Released under the GPL license 2.0 or above See http://www.gnu.org for license details - Press CTRL and D simultaneously to finish session Type ?commandname for help 0 2+3 5 // Time 0 You might have an error doing make install if latex2html is not installed. If you don't want to install latex2html, an easy fix is to You're right, we definitely can't assume that latex2html is installed. (Note: latex2html has a non-GPL-compatible license; we also use it for the sage docs, since Python did, but I regret this dependency.) comment the recursion in Makefile.am from the doc subdirectory, the first two lines should look like doc/Makefile.am #SUBDIRS #DIST_SUBDIRS then run automake in the giac directory and then ./configure --prefix=$SAGE_LOCAL --disable-gui Another way to fix this is to run make install from the src subdirectory only. Or maybe add a fake latex2html command somewhere in your path. I don't know what the sage build process can handle best. Any suggestion? Best is probably only running make install from the src subdirectory. That's what I've done in the above spkg. After reading your answers, here is what I hope will happen: (1) you will spend some time building Sage from source and figure out how to install giac into the Sage build directory. This is by far easier for you than for us, probably, since you know the giac build system and
[sage-devel] Re: Noncanonical coercion (finite fields)
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial, in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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: Noncanonical coercion (finite fields)
This has been discussed at length; the relevant words are Conway
polynomials and the relevant paper is Lattices of compatibly
embedded finite fields (http://portal.acm.org/citation.cfm?id=268929).
If you implement this I will be forever in your debt.
Nick
On 14-Apr-08, at 8:38 AM, Willem Jan Palenstijn wrote:
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields
of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial,
in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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: Noncanonical coercion (finite fields)
2008/4/14 Nick Alexander [EMAIL PROTECTED]:
This has been discussed at length; the relevant words are Conway
polynomials and the relevant paper is Lattices of compatibly
embedded finite fields (http://portal.acm.org/citation.cfm?id=268929).
If you implement this I will be forever in your debt.
Very tempting!
Perhaps you should mention that the authors of that paper are the
Magma trio Bosma, Cannon and Steele. I have just printed it and will
take a look.
John
Nick
On 14-Apr-08, at 8:38 AM, Willem Jan Palenstijn wrote:
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields
of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial,
in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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: Noncanonical coercion (finite fields)
I implemented this while converting finite fields over to the new
coercion model, but it only works when we Conway polynomials are used
to define the extension (the default if the database goes that high).
Conway polynomials can be expensive to compute, so if one is not
available we don't want to do that on the fly, but if one keeps track
of all fields created one can dynamically create a set of compatible
embedding (which is described in the paper referenced below).
- Robert
On Apr 14, 2008, at 8:53 AM, Nick Alexander wrote:
This has been discussed at length; the relevant words are Conway
polynomials and the relevant paper is Lattices of compatibly
embedded finite fields (http://portal.acm.org/citation.cfm?
id=268929).
If you implement this I will be forever in your debt.
Nick
On 14-Apr-08, at 8:38 AM, Willem Jan Palenstijn wrote:
On Mon, Apr 14, 2008 at 02:40:14PM +0100, John Cremona wrote:
Does anyone know how Magma handles this?
From what I can tell, magma seems to choose 'default' finite fields
of a
given size at run-time, and presumably also injections between them.
Which fields become default can depend on the order in which they are
created. For example,
K := FiniteField(3^100);
L := FiniteField(3^500);
gives a different field ('measured' by MinimalPolynomial(K.1) ) than
L := FiniteField(3^500);
K := FiniteField(3^100);
while IsDefault(K); returns true in both cases.
In the first case, MinimalPolynomial(K.1) is a sparse polynomial,
in the
second case we have L.1^( (3^500-1) div (3^100-1) ) eq L!K.1 .
In the first case, L!K.1 can change between two magma runs, so the
chosen injection appears to be chosen randomly at run-time.
Note that this behaviour may of course be different for smaller or
larger finite fields.
-Willem Jan
--~--~-~--~~~---~--~~
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: Noncanonical coercion (finite fields)
Actually, Conway polynomials don't cut it in general, in the sense that one can't actually generate them for sufficiently large finite fields. Even Magma doesn't know them in the sizes that Willem is talking about: ConwayPolynomial(3,100); ^ Runtime error in 'ConwayPolynomial': A conway polynomial for GF(3^100) is not known David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:21:46 on sage [Seed = 391961513] Type ? for help. Type Ctrl-D to quit. time F := FiniteField(3^100); Time: 0.050 time K := FiniteField(3^200); Time: 3.470 Total time: 4.190 seconds, Total memory usage: 8.39MB [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:22:08 on sage [Seed = 508940938] Type ? for help. Type Ctrl-D to quit. time K := FiniteField(3^200); Time: 0.420 time F := FiniteField(3^100); Time: 0.050 That paper is particularly frustrating -- if you're trying to figure out exactly this, you end up getting referred around the paper a few times, only to discover a paragraph where they say and in the case that the Conway polynomial can't be found, we make another default choice. Wow, thanks. :) -cc --~--~-~--~~~---~--~~ 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: canonicalize or evaluate
On Apr 13, 11:07 pm, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, yesterday on IRC I realized I don't understand these terms. :) x + x - 2*x is this evaluation? x +y, vs. y+x ... is this canonicalization? Is this how everyone understands these terms? If so, we need to fix SymPy all over. :) I would call x+x - 2*x simplification, and x+y - y+x canonicalization. evaluation would mean the process: x + y evaluated at x=2, y=3 is 5. 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: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 9:23 AM, Craig Citro wrote: Actually, Conway polynomials don't cut it in general, in the sense that one can't actually generate them for sufficiently large finite fields. Even Magma doesn't know them in the sizes that Willem is talking about: ConwayPolynomial(3,100); ^ Runtime error in 'ConwayPolynomial': A conway polynomial for GF (3^100) is not known David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:21:46 on sage [Seed = 391961513] Type ? for help. Type Ctrl-D to quit. time F := FiniteField(3^100); Time: 0.050 time K := FiniteField(3^200); Time: 3.470 Total time: 4.190 seconds, Total memory usage: 8.39MB [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:22:08 on sage [Seed = 508940938] Type ? for help. Type Ctrl-D to quit. time K := FiniteField(3^200); Time: 0.420 time F := FiniteField(3^100); Time: 0.050 That paper is particularly frustrating -- if you're trying to figure out exactly this, you end up getting referred around the paper a few times, only to discover a paragraph where they say and in the case that the Conway polynomial can't be found, we make another default choice. Wow, thanks. :) I looked at the paper a bit too, and had the same feeling. However, I think the key insight is (and I'm not sure if this is stated in their paper) that the choice of polynomial isn't important, it's the choice of morphism that one has to be clever with. Specifically, suppose one has F_p^n and one wants to create F_p^n. One can choose any (irreducible) polynomial of degree n, and then (by looking at how the defining polynomials factor over higher fields, which isn't too hard) chooses embeddings F_p^gcd(m,n) - F_p^n - F_p^lcm(m,n) compatible with F_p^gcd(m,n) - F_p^m - F_p^lcm(m,n). Though I haven't worked out all the details I am pretty sure this is the basic idea, and I'm sure there's lots of additional optimizations one can make. - Robert --~--~-~--~~~---~--~~ 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: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 9:28 AM, Nick Alexander wrote: On 14-Apr-08, at 9:21 AM, Robert Bradshaw wrote: I implemented this while converting finite fields over to the new coercion model, but it only works when we Conway polynomials are used to define the extension (the default if the database goes that high). Can you say a few words on the new coercion model and when it might be available? I'm sure a lot of people have the same question. In terms of status, we have just about finished converting all the parents to the new style (all that's left is a couple of groups and scheme files) and are doing regression testing to make sure the entire codebase still passes all doctests. The next step will be to merge in the 2.10.2 - 3.0 changes and fix anything that's happened since then. The timeline is as follows: Sage 3.0 released (very soon?) [merge 3.0 and coercion branch (after everything working in the coercion branch) Sage 3.1 released quickly merge coercion branch with 3.1 (should be easy, assuming 3.0 - 3.1 isn't too long) Sage 3.2 release with new coercion (hopefully within a day or two of 3.1) The 3.1 - 3.2 release will be a coercion release only. - Robert --~--~-~--~~~---~--~~ 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: Is this a bug?
On Apr 13, 2008, at 9:46 PM, William Stein wrote: On Sun, Apr 13, 2008 at 9:37 PM, [EMAIL PROTECTED] wrote: sage: Q.x,y = QQ['x,y'] sage: R.X,Y = Q.quo(Q.ideal(x^2 + y^2 -1)) sage: X/2 - -- type 'exceptions.NotImplementedError' Traceback (most recent call last) /home/boothby/.sage/ipython console in module() /home/boothby/.sage/element.pyx in sage.structure.element.RingElement.__div__ (sage/structure/ element.c:9080)() /home/boothby/.sage/coerce.pyx in sage.structure.coerce.CoercionModel_cache_maps.bin_op_c (sage/ structure/coerce.c:5055)() /home/boothby/.sage/element.pyx in sage.structure.element.RingElement.__div__ (sage/structure/ element.c:9063)() /home/boothby/.sage/coerce.pxi in sage.structure.element._div_c (sage/structure/element.c:16174)() /home/boothby/sage/local/lib/python2.5/site-packages/sage/rings/ quotient_ring_element.py in _div_(self, right) 114 if not right.is_unit(): 115 raise ZeroDivisionError -- 116 raise NotImplementedError 117 118 def __int__(self): type 'exceptions.NotImplementedError': I'd understand if I were trying to divide by a non-unit, or even a unit polynomial. But I'm trying to divide by a unit in the base ring -- shouldn't that work? Is this a problem in the coercion model, or is it validly not implemented? It's simply not implemented. Implement it and post a patch :-) I would add that it needs to be implemented carefully--it will be easy to create infinite loops as division creates fraction-field elements, so you can't just invert and cast. The source code for the function _div_ that is called is sage: X._div_?? Source: def _div_(self, right): if not right.is_unit(): raise ZeroDivisionError raise NotImplementedError which does *not* presently try to invert right if it does happen to be a unit in the base ring. Why? Because it's not implemented yet. Your best bet is to either implement better functionality for computing in quotient rings or to type sage: X * (1/2) 1/2*X By the way, looking at the file quotient_ring_element.py, I would bring the doctest coverage to 100% before adding or subtracting any code from that file. Right now coverage is a terrible 24%. -- 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: Noncanonical coercion (finite fields)
On Apr 14, 6:57 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Apr 14, 2008, at 9:28 AM, Nick Alexander wrote: SNIP Can you say a few words on the new coercion model and when it might be available? I'm sure a lot of people have the same question. In terms of status, we have just about finished converting all the parents to the new style (all that's left is a couple of groups and scheme files) and are doing regression testing to make sure the entire codebase still passes all doctests. The next step will be to merge in the 2.10.2 - 3.0 changes and fix anything that's happened since then. The timeline is as follows: Sage 3.0 released (very soon?) The plan is to get 3.0 out in the next two, three days and we are certainly getting close to that goal. On the list of things to be done most real blockers have been fixed from my point of view, now it is merging back a bunch of build fixes and getting components like the pexpect R interface and the benchmarking framework in. [merge 3.0 and coercion branch (after everything working in the coercion branch) Sage 3.1 released quickly merge coercion branch with 3.1 (should be easy, assuming 3.0 - 3.1 isn't too long) Sage 3.2 release with new coercion (hopefully within a day or two of 3.1) I have update the roadmap to reflect how I would anticipate things going down: 3.0: soon [past experience has told us that things can be late, but now we are at the end of the normal two week release window] 3.0.1: three, four days after 3.0 - a bug fix only release. This should provide ample time for the coercion people to make their code work with 3.0 while minimizing any disturbing conflicts relative to the 3.0 code base while we fix the inevitable issues that happened in the 2.11-3.0 transition 3.1: three, four days after 3.0.1 - merge the updated coercion code right at the start, add the usual set of small fixes and get a release out as soon as possible. Details http://trac.sagemath.org/sage_trac/roadmap [dates can and probably will move around] The 3.1 - 3.2 release will be a coercion release only. - Robert Thought? 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 -~--~~~~--~~--~--~---
[sage-devel] Bad example with NICE graph isomorphism
Attached is an example where NICE does not correctly determine the isomorphism between two graphs. I tested this with Sage 2.11. I have not had an opportunity to examine the NICE code, so I'm not sure where the problem is. I do not currently have a Trac account, so I am sending the example here. Best wishes, Stephen --~--~-~--~~~---~--~~ 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_nice_bad_example.sage Description: Binary data
[sage-devel] Re: Bad example with NICE graph isomorphism
Perhaps this has been fixed already?
sage: version()
'SAGE Version 3.0.alpha2, Release Date: 2008-04-06'
sage: import sage.graphs
sage: import sage.graphs.graph_isom
sage:
sage: G=Graph([EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@[EMAIL PROTECTED]@KN~_^}?~{)
, 17, 18, 0, 5, 4, 2, 6, 1, 3, 9, 7, 8, 20, 25, 24, 22, 26, 21, 23,
29, 27, 28, 31, 30, 32]
sage: H=G.relabel(perm,inplace=False)
sage:
sage: _,Gcan=sage.graphs.graph_isom.search_tree(G,[range(G.order())])
sage: _,Hcan=sage.graphs.graph_isom.search_tree(H,[range(H.order())])
sage: if Gcan==Hcan:
: print NICE says the graphs are isomorphic
: else:
: print NICE says the graphs are NOT isomorphic
:
NICE says the graphs are isomorphic
Since bugs are usually reported to sage-support (not sage-devel), I am
cross-posting.
On Mon, Apr 14, 2008 at 2:03 PM, Stephen Hartke [EMAIL PROTECTED] wrote:
Attached is an example where NICE does not correctly determine the
isomorphism between two graphs. I tested this with Sage 2.11. I have not
had an opportunity to examine the NICE code, so I'm not sure where the
problem is.
I do not currently have a Trac account, so I am sending the example here.
Best wishes,
Stephen
--~--~-~--~~~---~--~~
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: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 10:28 AM, mabshoff wrote: On Apr 14, 6:57 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Apr 14, 2008, at 9:28 AM, Nick Alexander wrote: SNIP Can you say a few words on the new coercion model and when it might be available? I'm sure a lot of people have the same question. In terms of status, we have just about finished converting all the parents to the new style (all that's left is a couple of groups and scheme files) and are doing regression testing to make sure the entire codebase still passes all doctests. The next step will be to merge in the 2.10.2 - 3.0 changes and fix anything that's happened since then. The timeline is as follows: Sage 3.0 released (very soon?) The plan is to get 3.0 out in the next two, three days and we are certainly getting close to that goal. On the list of things to be done most real blockers have been fixed from my point of view, now it is merging back a bunch of build fixes and getting components like the pexpect R interface and the benchmarking framework in. [merge 3.0 and coercion branch (after everything working in the coercion branch) Sage 3.1 released quickly merge coercion branch with 3.1 (should be easy, assuming 3.0 - 3.1 isn't too long) Sage 3.2 release with new coercion (hopefully within a day or two of 3.1) I have update the roadmap to reflect how I would anticipate things going down: 3.0: soon [past experience has told us that things can be late, but now we are at the end of the normal two week release window] 3.0.1: three, four days after 3.0 - a bug fix only release. This should provide ample time for the coercion people to make their code work with 3.0 while minimizing any disturbing conflicts relative to the 3.0 code base while we fix the inevitable issues that happened in the 2.11-3.0 transition 3.1: three, four days after 3.0.1 - merge the updated coercion code right at the start, add the usual set of small fixes and get a release out as soon as possible. Details http://trac.sagemath.org/sage_trac/roadmap [dates can and probably will move around] The 3.1 - 3.2 release will be a coercion release only. - Robert Thought? One week is almost certainly over-optimistic for having all the coercion stuff ready to go in, and so I am thinking that there would almost certainly be enough development between now and then to warrant a normal (non-bugfix-only) release first. I do really want to isolate the coercion model going in from all other changes (though if there is a critical bugfix I understand). - Robert --~--~-~--~~~---~--~~ 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: Bad example with NICE graph isomorphism
On Apr 14, 8:08 pm, David Joyner [EMAIL PROTECTED] wrote:
Perhaps this has been fixed already?
sage: version()
'SAGE Version 3.0.alpha2, Release Date: 2008-04-06'
sage: import sage.graphs
sage: import sage.graphs.graph_isom
sage:
sage: G=Graph([EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@[EMAIL PROTECTED]@KN~_^}?~{)
, 17, 18, 0, 5, 4, 2, 6, 1, 3, 9, 7, 8, 20, 25, 24, 22, 26, 21, 23,
29, 27, 28, 31, 30, 32]
sage: H=G.relabel(perm,inplace=False)
sage:
sage: _,Gcan=sage.graphs.graph_isom.search_tree(G,[range(G.order())])
sage: _,Hcan=sage.graphs.graph_isom.search_tree(H,[range(H.order())])
sage: if Gcan==Hcan:
: print NICE says the graphs are isomorphic
: else:
: print NICE says the graphs are NOT isomorphic
:
NICE says the graphs are isomorphic
Hi Stephan,
Thanks for the bug report.
Since bugs are usually reported to sage-support (not sage-devel), I am
cross-posting.
Nah, if is is something focused like this posting here is alright in
my book. Especially since not every dev reads sage-support
On Mon, Apr 14, 2008 at 2:03 PM, Stephen Hartke [EMAIL PROTECTED] wrote:
Attached is an example where NICE does not correctly determine the
isomorphism between two graphs. I tested this with Sage 2.11. I have not
had an opportunity to examine the NICE code, so I'm not sure where the
problem is.
I do not currently have a Trac account, so I am sending the example here.
Best wishes,
Stephen
I get:
sage: version()
'SAGE Version 3.0.alpha4, Release Date: 2008-04-12'
sage: import sage.graphs
sage: import sage.graphs.graph_isom
sage: G=Graph([EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@?
[EMAIL PROTECTED]@KN~_^}?~{)
sage: perm=[10, 15, 14, 12, 16, 11, 13, 19, 17, 18, 0, 5, 4, 2, 6, 1,
3, 9, 7, 8, 20, 25, 24, 22, 26, 21, 23, 29, 27, 28, 31, 30, 32]
sage: H=G.relabel(perm,inplace=False)
sage: _,Gcan=sage.graphs.graph_isom.search_tree(G,[range(G.order())])
sage: _,Hcan=sage.graphs.graph_isom.search_tree(H,[range(H.order())])
sage:
sage: Gcan==Hcan
True
3.0.alpha1 contained the following fix:
#2765: Robert Miller: bug in graph_isom, Hoffman-Singleton
constructor
which sounds like it fixed your problem.
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
-~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Apr 14, 2008, at 06:16 , David Harvey wrote: On Apr 13, 2008, at 12:50 PM, Kiran Kedlaya wrote: Any opinions about what sage: F9.a = GF(9); F81.b = GF(81); F81(a) should return? There is no canonical answer, so it may be better to throw an exception rather than pick one of the two correct answers. But any of these would be better than the current behavior, which is to return 0. Interesting that's not what happens in my install of sage 2.11. I get: sage: F9.a = GF(9) sage: F81.b = GF(81) sage: F81(a) [.] type 'exceptions.IndexError': n=17606600 must be self.order() Even more interesting is what I get (Sage 2.11, Mac OS X, 10.5.2): sage: F9.a=GF(9) sage: F81.b=GF(81) sage: F81(a) 0 sage: trace(F81(a)) string(1)module() (Pdb) s ...[more 's' ] [SNIP] /Volumes/Zeppo/SandBox/Justin/sb/sage-2.11/finite_field_givaro.pyx in sage.rings.finite_field_givaro.FiniteField_givaro.log_to_int() type 'exceptions.IndexError': n=110973296 must be self.order() sage: More interesting still is that, when I retry the 'trace', I get the exception right away, no (Pdb) prompt. Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- I'm beginning to like the cut of his jibberish. --- --~--~-~--~~~---~--~~ 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: Noncanonical coercion (finite fields)
On Apr 14, 8:16 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Apr 14, 2008, at 10:28 AM, mabshoff wrote: SNIP Thought? One week is almost certainly over-optimistic for having all the coercion stuff ready to go in, and so I am thinking that there would almost certainly be enough development between now and then to warrant a normal (non-bugfix-only) release first. I do really want to isolate the coercion model going in from all other changes (though if there is a critical bugfix I understand). Ok, that certainly sounds reasonable and I don't see a problem to make either a slightly longer 3.0.1 bug fix release [i.e. a week] or even throw in a second 3.0.2 bug fix release [maybe even with small features]. Either way, let us know about the status changes about the coercion rewrite as you guys go along so we can adjust the release plans accordingly. - Robert 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 -~--~~~~--~~--~--~---
[sage-devel] Status of Sage 3.0.a5 with gcc 4.3/Arch Linux
Hi. I am currently in the finishing stage on getting gcc 4.3 build support into Sage 3.0.alpha5. I am doing so on an 64 bit Arch Linux VMWare image and am down to the following bug (which is not gcc 4.3 related): File /home/mabshoff/sage-3.0.alpha3/tmp/real_double.py, line 546: sage: a = -RDF(1)/RDF(0); a.str() Expected: '-inf' Got: 'inf' ** File /home/mabshoff/sage-3.0.alpha3/tmp/real_double.py, line 981: sage: a.is_positive_infinity() Expected: False Got: True ** File /home/mabshoff/sage-3.0.alpha3/tmp/real_double.py, line 993: sage: a.is_negative_infinity() Expected: True Got: False ** 3 items had failures: 1 of 6 in __main__.example_35 1 of 5 in __main__.example_67 1 of 5 in __main__.example_68 ***Test Failed*** 3 failures. For whitespace errors, see the file /home/mabshoff/sage-3.0.alpha3/ tmp/.doctest_real_double.py [17.1 s] exit code: 1024 It is an issue in GSL which I have already fixed with OSX 10.5, so it will be easy to fix on Arch Linux, too. I am wondering what the exact Posix behavior dictates here since the fallback GSL isinf function also returns -inf instead of inf. On another note: Is the packager of Sage on Arch around here? I.e. a/ the person who is involved with http://aur.archlinux.org/packages.php?ID=14429 I got a couple notes for Sage 3.0 on Arch Linux and I would prefer to have the packagers be aware of the issues before they run into it. Probably the most important is that on Arch with gcc 4.3 you *must* set SAGE_FORTAN and SAGE_FORTRAN_LIB to use gfortran from gcc 4.3 instead of using the g95 binary we provide since that seems horribly broken on Arch. 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Noncanonical coercion (finite fields)
On Mon, Apr 14, 2008 at 12:23 PM, Craig Citro [EMAIL PROTECTED] wrote: Actually, Conway polynomials don't cut it in general, in the sense that one can't actually generate them for sufficiently large finite fields. Even Magma doesn't know them in the sizes that Willem is talking about: ConwayPolynomial(3,100); ^ Runtime error in 'ConwayPolynomial': A conway polynomial for GF(3^100) is not known David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:21:46 on sage [Seed = 391961513] Type ? for help. Type Ctrl-D to quit. time F := FiniteField(3^100); Time: 0.050 time K := FiniteField(3^200); Time: 3.470 Total time: 4.190 seconds, Total memory usage: 8.39MB [EMAIL PROTECTED] ~] $ magma Magma V2.13-5 Mon Apr 14 2008 09:22:08 on sage [Seed = 508940938] Type ? for help. Type Ctrl-D to quit. time K := FiniteField(3^200); Time: 0.420 time F := FiniteField(3^100); Time: 0.050 That paper is particularly frustrating -- if you're trying to figure out exactly this, you end up getting referred around the paper a few times, only to discover a paragraph where they say and in the case that the Conway polynomial can't be found, we make another default choice. Wow, thanks. :) -cc --~--~-~--~~~---~--~~ 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: Noncanonical coercion (finite fields)
Grrr... I clicked reply, and then tried to click on the text field to begin typing, and it scrolled down at exactly the wrong moment and the right amount so that I clicked send insteady. Sorry about that. David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: I haven't worked on this much, aside from keeping it in mind when designing the coercion system. Once we have the coercion branch merged back in, we should have the appropriate framework for writing all this and making it happen in an appropriately automatic fashion. As for timeline, the conclusion that Robert and Michael came to sounds reasonable to me. I'll try to finish the work we want to do before the 3.0 release so that once 3.0 comes out we can just merge. When the coercion release comes (which sounds like 3.1), Robert and I will write about how YOU can help. :-) Basically, we're trying to make the global changes that need to happen all at once across all of Sage, but there will be a lot of places where we've left intermediate solutions in place: keeping the current functionality of Sage operational while transforming the structure to make improvement possible on a local scale. As a result, there will be lots of little things that you can do, in your favorite part of Sage, to take advantage of the new framework. We'll give you more details in a few weeks. 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: canonicalize or evaluate
Ondrej Certik wrote: On Mon, Apr 14, 2008 at 6:26 PM, Carl Witty [EMAIL PROTECTED] wrote: On Apr 13, 11:07 pm, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, yesterday on IRC I realized I don't understand these terms. :) x + x - 2*x is this evaluation? x +y, vs. y+x ... is this canonicalization? Is this how everyone understands these terms? If so, we need to fix SymPy all over. :) I would call x+x - 2*x simplification, and x+y - y+x canonicalization. evaluation would mean the process: x + y evaluated at x=2, y=3 is 5. Right. After discussing this with Garry on IRC, we would call x+x - 2*x canonical simplification. Now the question is, how to call the method, that does just that. I don't think it should be just called simplify(), because simplify does more -- for example it chooses just one way of (x+1)**3 or (1 + 3*x + 3*x**2 + x**3), but canonical simplify will just remove things like x*x, or x+x, but will not perform any expensive operation. We came up with: cs() or canonical_simplify(), which is either too short or too long imho. I'm not sure about canonical_simplify...I guess I'm not sure about where the canonical part comes from. But it sounds like you're saying that the function is a cheap simplifying function, as opposed to more expensive simplifying operations: simplify_cheap? simplify_trivial? simplify_simple? 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: canonicalize or evaluate
Jason Grout wrote: Ondrej Certik wrote: On Mon, Apr 14, 2008 at 6:26 PM, Carl Witty [EMAIL PROTECTED] wrote: On Apr 13, 11:07 pm, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, yesterday on IRC I realized I don't understand these terms. :) x + x - 2*x is this evaluation? x +y, vs. y+x ... is this canonicalization? Is this how everyone understands these terms? If so, we need to fix SymPy all over. :) I would call x+x - 2*x simplification, and x+y - y+x canonicalization. evaluation would mean the process: x + y evaluated at x=2, y=3 is 5. Right. After discussing this with Garry on IRC, we would call x+x - 2*x canonical simplification. Now the question is, how to call the method, that does just that. I don't think it should be just called simplify(), because simplify does more -- for example it chooses just one way of (x+1)**3 or (1 + 3*x + 3*x**2 + x**3), but canonical simplify will just remove things like x*x, or x+x, but will not perform any expensive operation. We came up with: cs() or canonical_simplify(), which is either too short or too long imho. I'm not sure about canonical_simplify...I guess I'm not sure about where the canonical part comes from. But it sounds like you're saying that the function is a cheap simplifying function, as opposed to more expensive simplifying operations: simplify_cheap? simplify_trivial? simplify_simple? Sorry for replying to myself, but I vote that we keep functions that are variants of each other to having the same prefix so that tab-completion is more useful. So for the above, I vote, for whatever my vote counts, that the function starts with simplify. In fact, would it be hard to just make this an option to simplify? simplify(trivial=True) or simplify(method=trivial) These ideas keep the namespace slightly less cluttered or at least organized. 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: canonicalize or evaluate
On Mon, Apr 14, 2008 at 10:06 PM, Ondrej Certik [EMAIL PROTECTED] wrote: Now the question is, how to call the method, that does just that. How about normalize() or standardize() ? (Wikipedia says: Generally, in mathematics, a canonical form (often called normal form or standard form) of an object is a standard way of presenting that object.) Fredrik --~--~-~--~~~---~--~~ 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: canonicalize or evaluate
simplify(trivial=True) I hate options so much it's not even funny. Two ideas, two functions! Names express intent! Nick --~--~-~--~~~---~--~~ 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: canonicalize or evaluate
On Mon, 14 Apr 2008, Jason Grout wrote: Jason Grout wrote: Ondrej Certik wrote: On Mon, Apr 14, 2008 at 6:26 PM, Carl Witty [EMAIL PROTECTED] wrote: On Apr 13, 11:07 pm, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, yesterday on IRC I realized I don't understand these terms. :) x + x - 2*x is this evaluation? x +y, vs. y+x ... is this canonicalization? Is this how everyone understands these terms? If so, we need to fix SymPy all over. :) I would call x+x - 2*x simplification, and x+y - y+x canonicalization. evaluation would mean the process: x + y evaluated at x=2, y=3 is 5. Right. After discussing this with Garry on IRC, we would call x+x - 2*x canonical simplification. Now the question is, how to call the method, that does just that. I don't think it should be just called simplify(), because simplify does more -- for example it chooses just one way of (x+1)**3 or (1 + 3*x + 3*x**2 + x**3), but canonical simplify will just remove things like x*x, or x+x, but will not perform any expensive operation. We came up with: cs() or canonical_simplify(), which is either too short or too long imho. I'm not sure about canonical_simplify...I guess I'm not sure about where the canonical part comes from. But it sounds like you're saying that the function is a cheap simplifying function, as opposed to more expensive simplifying operations: simplify_cheap? simplify_trivial? simplify_simple? Sorry for replying to myself, but I vote that we keep functions that are variants of each other to having the same prefix so that tab-completion is more useful. So for the above, I vote, for whatever my vote counts, that the function starts with simplify. In fact, would it be hard to just make this an option to simplify? simplify(trivial=True) or simplify(method=trivial) These ideas keep the namespace slightly less cluttered or at least organized. +1 --~--~-~--~~~---~--~~ 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: Noncanonical coercion (finite fields)
On Apr 14, 11:20 pm, David Roe [EMAIL PROTECTED] wrote: Grrr... I clicked reply, and then tried to click on the text field to begin typing, and it scrolled down at exactly the wrong moment and the right amount so that I clicked send insteady. Sorry about that. David Roe and I (and probably some other people) talked about this way back at SD3, and ultimately decided that we had no idea what Magma was doing. ;) David (and/or others) may have discovered more by now. Magma definitely has a way on deciding on a default choice, in the sense that if you create the finite fields in the same order, the same polynomial is generated between different Magma runs. It's interesting that it changes when you change the order you created the fields with -- I don't recall us discovering this way back when. I also find this somewhat interesting -- though it's probably just the fact that it's checking something for consistency: I haven't worked on this much, aside from keeping it in mind when designing the coercion system. Once we have the coercion branch merged back in, we should have the appropriate framework for writing all this and making it happen in an appropriately automatic fashion. Hi David, As for timeline, the conclusion that Robert and Michael came to sounds reasonable to me. I'll try to finish the work we want to do before the 3.0 release so that once 3.0 comes out we can just merge. The interesting issue I see right now if the symbolics framework by Gary will go in before or after the coercion rewrite. I would prefer if coercion went in first, but that is something you guys should talk about. Other than that I do not see anything that would interact badly with coercion come up in the next couple weeks. When the coercion release comes (which sounds like 3.1), Robert and I will write about how YOU can help. :-) Basically, we're trying to make the global changes that need to happen all at once across all of Sage, but there will be a lot of places where we've left intermediate solutions in place: keeping the current functionality of Sage operational while transforming the structure to make improvement possible on a local scale. As a result, there will be lots of little things that you can do, in your favorite part of Sage, to take advantage of the new framework. We'll give you more details in a few weeks. Ok, if I understand this correctly after the merge we will have the following situation: * everything will keep working [modulo a buglet here or there] * but people need to modify some code to take advantage of the new shiny features Am I getting this wrong? Am I missing anything. David 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 -~--~~~~--~~--~--~---
[sage-devel] symbolic logic code
Hi All, I'm looking to get some propositional calculus code that I wrote reviewed and refereed. The code allows operations such as simplification, conversion to normal form, truth table creation, etc. The code is at: http://www.sagemath.org:9002/sage_trac/ticket/545 if anyone is interested that would be great. -Chris Gorecki --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
