[sage-devel] Sage: Very suitable for rapid prototyping
I am proud to report that Sage has been "officially" recognized as "very suitable for rapid prototyping". Also, Sage is "a fine tool for many applications". This recognition is because I won the lightning round (for the "rapid prototyping" recognition) and got second place in the main contest (for the "fine tool" recognition) in the 2010 ICFP Programming Contest (http://icfpcontest.org/2010/) using Sage (the recognition is part of the prize). (Normally the recognition would be for a programming language, but the organizers let me claim Sage rather than Python as the programming language I used.) >From Sage, I used: * matrices over multivariate integer polynomials * the Polyhedron class, to find vertices of a polyhedron given its definition as linear inequalities * ZZ's arbitrary-base support, to convert integers to and from base-3 strings The prize ceremony was videotaped, but I don't know if the video will be available. (If so, it would be part of the segment "Report on the Thirteenth ICFP Programming Contest".) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: ICMS 2010 video; Sage demo
On Mon, Sep 13, 2010 at 5:32 AM, Nathann Cohen wrote: >> I've posted the .sws tohttp://wiki.sagemath.org/Talks. You can see >> video of my demo, and (eventually) of all the talks at ICMS 2010, >> athttp://fe.math.kobe-u.ac.jp/Movies/ms/icms2010/icms2010-video.html. > > Looks like all the links toward streaming version are identical, same > with low resolution and high resolution. And of course they all lead > to a 404 :-) > > Nathann Oops... they told us the video would be available tomorrow, but I saw the link next to my name and assumed it was already there. Looks like I jumped the gun. I guess you should wait until tomorrow and try again... Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] ICMS 2010 video; Sage demo
A few hours I gave a Sage demo at ICMS 2010 (to a room full of developers of mathematical software). I think it went reasonably well. I've posted the .sws to http://wiki.sagemath.org/Talks. You can see video of my demo, and (eventually) of all the talks at ICMS 2010, at http://fe.math.kobe-u.ac.jp/Movies/ms/icms2010/icms2010-video.html . Carl Witty -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Anyway able to check two lines of inline assembler?
On Mon, Aug 23, 2010 at 3:45 PM, Dr. David Kirkby wrote: > I've created a patch for sympow, which the release manager has agreed to > merge in 4.5.3 - in fact, he has kindly made it a blocker!! > > He is happy with it, but wants someone able to comment on the changes I made > to the file fpu.c. ... > Please add comments on #9703 I just put a positive review on #9703. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Floating point on Intel based OS X systems.
On Fri, Aug 20, 2010 at 9:26 PM, Dr. David Kirkby
wrote:
> Unless OS X rounds by default to 64-bits, I can't understand how this would
> have ever worked. Why was it not necessary to change the rounding behavior
> of an Intel based OS X system?
Modern x86 family chips actually have two totally separate
floating-point units (at least logically, I don't know if they share
hardware). The older uses the "x87" instructions, dating back to the
8087; this rounds to 80 bits by default. SYMPOW's fpu.c changes the
x87 instructions to round to 64 bits. The newer is the SSE/SSE2
floating-point unit (SSE only had single-precision floating point,
SSE2 extended this to double precision); this rounds to 64 bits (or 32
bits for single-precision instructions).
In general, SSE2 is faster than x87 (partly because SSE2 has a real
register-based instruction set, instead of x87's mostly stack-based
instruction set); so people prefer to generate SSE2 code whenever the
option is available.
Debian's gcc for 32-bit x86 defaults to generating x87 code, because
Debian supports 80486 and up and SSE2 code wouldn't work on such old
chips. Debian's gcc for 64-bit x86 defaults to SSE/SSE2, because all
64-bit x86 processors have SSE2, so there are no
backward-compatibility issues to worry about.
I don't know what defaults gcc has if you compile it from upstream
source, but I suspect the behavior may match the default Debian
behavior I described in the previous paragraph.
So on Debian (and any similarly configured systems), fpu.c would be
necessary for 32-bit x86 but not 64-bit x86.
I checked on bsd.math, and there gcc uses SSE2 by default (mulsd is an
SSE2 instruction):
bsd:tmp cwitty$ cat testfpu.c
double prod(double a, double b) {
return a*b;
}
bsd:tmp cwitty$ gcc -O2 -S testfpu.c
bsd:tmp cwitty$ grep mulsd testfpu.s
mulsd %xmm1, %xmm0
as opposed to my Debian 32-bit x86 system that uses x87 by default
(fmull is an x87 instruction):
cwi...@magnetar:/tmp$ grep fmull testfpu.s
fmull 8(%ebp)
My guess is that OSX does not target pre-SSE2 processors, so they were
able to safely change their gcc default.
(technical nit: "round to 64 bits" isn't quite correct; better would
be "rounds to the precision of the standard 64-bit IEEE754 floating
point type", which actually has a 53-bit mantissa.)
Carl
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Longest and most pointless Sage build ever?
On Tue, Feb 17, 2009 at 8:52 PM, Carl Witty wrote: > I have compiled and run Sage 3.2.3 on my T-Mobile G1 cell phone, and > large portions of it actually work. Two people have asked me for a copy of my build. Let me emphasize that many doctests failed, and you'd need an ARM device with lots of memory to make such a thing useful. Also, I have no idea how portable the result is. (It was built on a T-Mobile G1, using a copy of Debian testing from early 2009.) I've uploaded my entire Android home directory; this includes lots of random log files and build artifacts, aside from the Sage build. (I figure that if the build has value, it's at least as likely to be in the hacks I applied to make things build as in the actual final result.) When a spkg failed to build, I went in and edited it and then rebuilt it by hand. And I didn't delete the build trees for those spkgs. So if you look at sage/spkg/build, you can see that the packages I had trouble with were atlas, gap, libfplll, singular, and tachyon; and you can see whatever changes I made to get them to compile in the respective subdirectories of sage/spkg/build. You can also see lots of log files (install.log and test.log, and then when I hacked the failing spkgs and installed them with spkg-install I logged those to separate log files in my home directory). I suppose I could try to answer questions if anybody has any, but I will have forgotten a lot of the details by now. The whole thing is at http://sage.math.washington.edu/home/cwitty/android-build-tree.tar.bz2; that file is almost a gigabyte. Or, you can just browse the build tree at http://sage.math.washington.edu/home/cwitty/android-build-tree/ . Unfortunately, when I copied the tree using "scp -rp", the symlinks were converted to copies. I converted a few of the biggest copies back to symlinks, but I didn't convert all of them. Other than that, this should be an exact copy of my build tree. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] How much RAM is needed to build Sage?
On Thu, Aug 19, 2010 at 10:35 AM, Dr. David Kirkby wrote: > Of course I know it depends on swap space, operating system, lots of things, > so nobody can give an exact answer, but I'd be interested to know if > building Sage on a machine with only 1 GB of RAM is likely to be possible. > > The machine, which runs AIX (or it would if I can fix the PSU), has 4 CPUs, > though I don't think I'll be building 4 packages in parallel with only 1 GB > RAM! I built sage 4.1 on my netbook with 1 GB of RAM, so it's possible. I'm going to start a build of 4.5.2 on the netbook. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sage on Android
On Wed, Aug 18, 2010 at 6:47 AM, tuxiano wrote: > Hi everybody > > I've tried to search in the archive but couldn't find if Sage is > available or will ever available on Android operating system. As far > as I know, Android is Linux-based so I was wondering if porting Sage > to Android is feasible. Android uses a Linux kernel, but does not include many of the programs and libraries that you would typically see on a Linux system. A port of Sage to the Android SDK/NDK (that would bundle the whole thing into a .apk) would be a lot of work; I'm not sure it's possible at all. On the other hand, if you manage to install a real Linux userspace (all of those standard programs and libraries) on your Android device, then you have a (probably ARM-based) Linux distribution, at which point you're just interested in a port of Sage to ARM. That's well within the realm of feasibility. I followed this latter route, and managed to get Sage to build (I'm the person who started the "Longest and most pointless Sage build ever?" thread), although there were lots of bugs -- many of the doctests failed. I gave up on the project because my Android device was far too small to reasonably run Sage. On a more powerful device it would make more sense. (The most important thing is to have enough memory not to go into swap space for whatever Sage task you want to do. My T-Mobile G1 did not have nearly enough memory.) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage+bpython
On Mon, Aug 16, 2010 at 1:22 PM, Jay wrote: > Hi! > > Yes, bpython is quite wonderful :). > > If I try to `easy_install bpython` from within a sage subshell I get > > ... (Full traceback if you'd like) > ImportError: /opt/sage/local/lib/python2.6/lib-dynload/operator.so: > undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString > > which incidentally is the same error as I get if I try to change > LD_LIBRARY_PATH from outside a subshell. If I try to run This error almost certainly means you're trying to mix a module compiled for a wide-Unicode Python build with a narrow-Unicode Python. Sage's Python is unconditionally built with wide-Unicode; if your system Python is narrow-Unicode, then you'll never be able to use your distribution's extension modules with Sage's Python, or vice versa. I'm not sure how it's happening, though. If you're in a sage subshell, then "which python" should be Sage's python, and your system python should never be involved in the easy_install. Do you have any extra environment variables set? (Did you change your PATH or PYTHONPATH while you were in the Sage subshell?) In your sage subshell, what do you get if you type: which python which easy_install ? Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] It is reasonable to change doctest from asinh(1.0) to asinh(2.0)?
On Fri, Aug 13, 2010 at 12:08 AM, Dr. David Kirkby wrote: > How can I add a comment to the doc test, which will not be printed in the > documentation? I'd like to add the result from a high-precision computation, > so anyone looking at the doctest in future could see what's a reasonable > answer and what is not. I get very frustrated when I see an expected result > of "23.32233298" or something like that, with no explanation why that result > is expected. I don't know of a way to add a comment to the doctest that won't be shown as part of the documentation. I'd recommend either letting it show in the documentation or adding it as a Python comment just after the doctest (at the first line of the function body). Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Next version of alglib.spkg (and some thoughts about debugging)
On Mon, Aug 9, 2010 at 1:42 AM, Sergey Bochkanov wrote: > It is somehow connected to patch by Carl Witty which adds ability to > work with Sage matrices/vectors. This patch works OK when package is > used from Sage. But when we run test suite from spkg-check with > "python check.py", it fails at the "from sage.matrix.all import > is_Matrix". Does someone have any idea? Unfortunately, you can't import only part of the Sage library; you have to import the whole thing first, to make sure it's all initialized correctly. (I consider this a bug, but it's a low-priority one because the workaround is easy.) Add this line at the top of check.py: import sage.all Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: What components of Sage would most benefit from SPARC assembly code?
On Fri, Aug 6, 2010 at 9:18 AM, Dr. David Kirkby wrote: > On 08/ 6/10 05:14 AM, Robert Bradshaw wrote: >> >> On Thu, Aug 5, 2010 at 3:25 AM, Bill Hart >> wrote: >>> >>> The single biggest improvement in my mind would be made to MPIR. And I >>> know the MPIR devels would absolutely love to have them contribute. >>> >>> Jason and Brian have been working very hard on simplifying MPIR so >>> that it can be more easily modified. > Bill mentioned a couple of names, but no surnames and no email addresses. > Could he provide a bit more information (by private email if he wishes). I > should see the SPARC guru later this month and will discuss with him. I'm pretty sure he's referring to Brian Gladman and Jason Moxham, the first two names in the "Contributors" list at http://www.mpir.org/ . That page also has contact information (the mailing list http://groups.google.com/group/mpir-devel) and a list of "important development directions" that includes "# Assembly support for Itanium, recent Sparc chips and MIPS." Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: A sage development utility?
On Thu, Aug 5, 2010 at 4:06 PM, Simon King wrote: > I think it is easier to do > from sage.all import ZZ > instead of providing its exact location (from sage.rings.integer...). > > Moreover, using sage.all is more stable, because the exact location of > things can change (so that "from sage.rings" would break), but > "from sage.all" will still work. > > I don't know if "from sage.all import *" works, but I guess it is not > recommended to load such a huge amount of things if you just need few > of them. This probably won't work for code that goes into the Sage library -- at least, for code that is somehow exposed in sage.all. It will create circular import problems as sage.all imports your module (possibly indirectly) and your module imports sage.all. For code that's not in sage.rings, I sometimes do from sage.rings.all import ZZ but in code that's (directly or indirectly) imported by sage.rings.all that would cause the same problem. > Cheers, > Simon Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: doctest failure with leading zero not printing
On Thu, Aug 5, 2010 at 2:59 PM, Dr. David Kirkby wrote: > On 08/ 5/10 06:17 PM, Sergey Bochkanov wrote: >> >> Hello, >> >>> Hmmm... Didn't thought about this situation yet. Definitely we can't >>> solve this problem with any kind of regular expressions. One >>> possible solution is to round data before printing. So both >>> 1.01 and 0.99 will become 1.00. >> >> ...however, we still can have problems when rounding X=0.00049 up >> to three digits. With original X we will have 0.000. But with >> perturbation as small as 0.2 we will round to 0.001. > > I've never done this, but the most logical thing to me seems to be to look > at the absolute magnitude of the relative error, for all cases except when > the expected value is 0. But I guess on cases where the numbers are not > close to 1, or other special cases one could think up, the current system is > probably the simplest. That would be nice. But it's a bit tricky to write, since the doctest check happens solely on the basis of string comparison; to do something clever like looking at relative error would require some sort of marking in the expected output to turn on the relative-error check, and some sort of parser to find the numbers in the expected/found outputs, and possibly some sort of marking on a per-number basis in the expected output to say what relative error is allowed on that number. (If the expected output is 1.23456*x^1, with a relative error allowed of 1e-3, you probably don't want to allow 1.23456*x^10001 !) I would be in favor of something like this, if we could decide on a set of markings in the expected output that didn't interfere too much with the documentation aspect; but nobody has written it yet. The three-dots notation is much, much stupider than this... it is just a wildcard that will match an arbitrary string of characters (the equivalent of .* as a regex, or * as shell globbing). And we didn't even write it; it's a standard part of the Python doctest system. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: doctest failure with leading zero not printing
On Thu, Aug 5, 2010 at 10:23 AM, David Kirkby wrote:
> BTW, do you have any ideas why the second failure at #9099 might occur
>
> sage -t -long devel/sage/sage/symbolic/expression.pyx
> **
> File
> "/home/palmieri/fulvia/sage-4.5.2.rc0/devel/sage-main/sage/symbolic/expression.pyx",
> line 498\
> 3:
> sage: maxima('sinh(1.0)')
> Expected:
> 1.175201193643801
> Got:
> 1.175201193643802
> **
> File
> "/home/palmieri/fulvia/sage-4.5.2.rc0/devel/sage-main/sage/symbolic/expression.pyx",
> line 508\
> 8:
> sage: maxima('asinh(1.0)')
> Expected:
> 0.881373587019543
> Got:
> .8813735870195429
> **
>
>
> Why should the zero be missing in the case observed on Solaris x86?i
> In other words, why do we see .8813735870195429 instead of
> 0.8813735870195429 ? Te exact value of the last digit is unimportant,
> and one clearly can't expect to get all digits spot on, but one would
> hope that a zero should be printed when its needed.
Well, it seems likely that the issue is within maxima (either in
maxima itself or in the Common Lisp implementation). To verify that
the problem has nothing to do with Sage, you can use "sage -maxima"
and try the test case on both machines:
cwi...@red-spider:~/sage$ ./sage -maxima
;;; Loading #P"/home/cwitty/sage/local/lib/ecl/defsystem.fas"
;;; Loading #P"/home/cwitty/sage/local/lib/ecl/cmp.fas"
;;; Loading #P"/home/cwitty/sage/local/lib/ecl/sysfun.lsp"
Maxima 5.20.1 http://maxima.sourceforge.net
using Lisp ECL 10.2.1
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) asinh(1.0);
(%o1) 0.881373587019543
(Don't forget the semicolon on the "asinh(1.0);" line; without that,
maxima will wait forever for more input.)
If the results do differ with "sage -maxima", I guess the next step
would be to report the problem to the maxima mailing list or the bug
tracker (bearing in mind that the problem may actually be in the
Common Lisp implementation we use).
Carl
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: doctest failure with leading zero not printing
On Thu, Aug 5, 2010 at 9:44 AM, David Kirkby wrote: > With all the numerical noise issues I've seen in Sage, the three dots > solves its. So if we expect > > 1.00 > but get > 1.01 > we can change that to > 1.0... > and the test will pass. > > However, what if we get > > 0.99 > > That's very close to 1, but not a single digit is the same. I'm not > sure how one would handle that case. I've seen a couple of approaches used in this case. First, simply change the doctest. For example, if you're testing a numerical root-finder on the polynomial x^2-x, change the polynomial to x^2-x-1. Second, include the test code in the doctest. Change: sage: foo() 1.0 to: sage: abs(foo() - 1) < 1e-12 True This is less preferred, because while it keeps the doctest useful as a test, it can reduce its value as documentation (especially if the test code is more complicated than the above). Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] ALGLIB spkg is released (second version)
On Wed, Jul 28, 2010 at 11:38 PM, Sergey Bochkanov wrote: > My proposal is to make > * boolean vector/matrix = GF(2), RDF (non-zero = True) > * integer vector/matrix = RDF > * real = RDF > * complex = CDF I've attached a patch to make alglib allow input in the following formats: * boolean vector/matrix: GF(2), RDF, numpy.bool, numpy.float64 * integer vector/matrix: RDF, numpy.int32, numpy.float64 * real: RDF, numpy.float64 * complex: CDF, numpy.complex128 This is entirely untested, except that the following examples (adapted from your "ALGLIB for Sage" page, and modified to use Sage or numpy types) work: sage: from alglib import conv sage: conv.convr1d(# real convolution of signal and response : vector(RDF, [1, 0, 0, 0.1]), # signal : 4, # signal length : vector(RDF, [1, 0.1, 0.01]), # response : 3) # response length [1.0, 0.10001, 0.01, 0.10001, 0.010002, 0.001] sage: from alglib import conv sage: conv.convr1d(# real convolution of signal and response : vector(RDF, [1, 0, 0, 0.1]).numpy(), # signal : 4, # signal length : vector(RDF, [1, 0.1, 0.01]).numpy(), # response : 3) # response length [1.0, 0.10001, 0.01, 0.10001, 0.010002, 0.001] sage: from alglib import rcond, densesolver sage: a = matrix(RDF, [[ 1.0, 0.1], : [-0.1, 1.0]]) sage: b = vector(RDF, [ 1.1, 0.9]) sage: rcond.rmatrixrcond1(# condition number : a, # matrix : 2) # matrix size 0.83471074380165278 sage: info, rep, x = densesolver.rmatrixsolve(a, 2, b) # solve linear system sage: x # solution [1.0, 1.0] sage: rep.r1 # condition number 0.83471074380165278 sage: from alglib import rcond, densesolver sage: a = matrix(RDF, [[ 1.0, 0.1], : [-0.1, 1.0]]).numpy() sage: b = vector(RDF, [ 1.1, 0.9]).numpy() sage: rcond.rmatrixrcond1(# condition number : a, # matrix : 2) # matrix size 0.83471074380165278 sage: info, rep, x = densesolver.rmatrixsolve(a, 2, b) # solve linear system sage: x # solution [1.0, 1.0] sage: rep.r1 # condition number 0.83471074380165278 (So I would not be at all surprised if there are bugs in my code.) Note that I did not touch *_vector_from_x, *_matrix_from_x; so results are still returned as lists. Also, I didn't worry about efficiency. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org --- ORIG._alglib.py 2010-08-02 18:52:05.0 -0700 +++ _alglib.py 2010-08-02 19:34:40.0 -0700 @@ -15,6 +15,12 @@ import ctypes import sys import os +import numpy +from sage.matrix.all import is_Matrix +from sage.modules.all import is_FreeModuleElement +from sage.rings.all import RDF, CDF, GF + +GF_2 = GF(2) DT_BOOL = 1 DT_INT = 2 @@ -163,9 +169,9 @@ # 'msg' parameter to generate error message # def safe_len(msg,v): -if type(v)!=list: -raise ValueError(msg) -return len(v) +if isinstance(v, (list, numpy.ndarray)) or is_FreeModuleElement(v): +return len(v) +raise ValueError(msg) # # safe matrix size @@ -176,6 +182,10 @@ # def safe_cols(msg,v): if type(v)!=list: +if is_Matrix(v): +return v.ncols() +if isinstance(v, numpy.ndarray) and v.ndim == 2: +return v.shape[1] raise ValueError(msg) if len(v)==0: return 0 @@ -198,6 +208,10 @@ # def safe_rows(msg,v): if type(v)!=list: +if is_Matrix(v): +return v.nrows() +if isinstance(v, numpy.ndarray) and v.ndim == 2: +return v.shape[0] raise ValueError(msg) if len(v)==0: return 0 @@ -213,6 +227,10 @@ def is_bool_vector(v): if type(v)!=list: +if is_FreeModuleElement(v) and (v.base_ring() == GF_2 or v.base_ring() == RDF): +return True +if isinstance(v, numpy.ndarray) and v.ndim == 1 and (v.dtype == numpy.bool or v.dtype == numpy.float64): +return True return False for x in v: try: @@ -223,6 +241,10 @@ def is_bool_matrix(v): if type(v)!=list: +if is_Matrix(v) and (v.base_ring() == GF_2 or v.base_ring() == RDF): +return True +if isinstance(v, numpy.ndarray) and v.ndim == 2 and (v.dtype == numpy.bool or v.dtype == numpy.float64): +return True return False if len(v)==0: return True @@ -244,6 +266,10 @@ def is_int_vector(v): if type(v)!=list: +if is_FreeModuleElement(v) and v.base_ring() == RDF: +return True +if isinstance(v, numpy.ndarray) and v.ndim == 1 and v.dtype == numpy.int32: +
Re: [sage-devel] ALGLIB spkg is released (second version)
On Wed, Jul 28, 2010 at 11:38 PM, Sergey Bochkanov wrote: >> My suggestion would be to support Sage vectors and matrices over >> GF(2), RDF, and CDF (machine floats and complex numbers), as well as >> numpy arrays and matrices of appropriate types. > > +1 > > My proposal is to make > * boolean vector/matrix = GF(2), RDF (non-zero = True) > * integer vector/matrix = RDF > * real = RDF > * complex = CDF > >>> because ALGLIB uses Python's list-of-lists to store matrices, and Sage >>> uses its own matrix class. But only several functions from _alglib.py >>> have to be fixed to work with Sage matrices/vectors: >>> * safe_len/safe_cols/safe_rows >>> * is_bool_vector/is_int_vector/is_real_vector/is_complex_vector >>> * is_bool_matrix/is_int_matrix/is_real_matrix/is_complex_matrix >>> * x_from_list/x_from_listlist > > Sorry, I've forgot to add several functions to this list: > * bool_vector_from_x/bool_matrix_from_x > * int_vector_from_x/int_matrix_from_x > * real_vector_from_x/real_matrix_from_x > * complex_vector_from_x/complex_matrix_from_x But this raises another API question... should bool_matrix_from_x return a matrix over GF(2) or over RDF? (I'll start looking at the Sage -> ALGLIB direction for now.) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] ALGLIB spkg is released (second version)
On Thu, Jul 29, 2010 at 10:25 AM, Sergey Bochkanov wrote: > Hello, Carl. > > Here is some documentation about Python-ALGLIB interface (called > X-interface in this document): > > http://www.alglib.net/share/2010-07-26-alglib-for-sage/x-interface.pdf Thanks. > It is very short, but should give a hint about meaning of all these > functions, expectations, functionality and etc. It describes functions > which are located in the _alglib.py unit. > > I'll add more information and some case studies later, but I thin > kthat it is better to post early than to post later :) Sure; unfortunately, I probably won't be able to work on this until Monday. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] "is" and python integers
On Wed, Jul 28, 2010 at 7:07 PM, William Stein wrote: > On Wednesday, July 28, 2010, kcrisman wrote: >> But for True and False, we would rather have >> >> if n is True: >> >> not >> >> if n==True: >> >> correct? I've seen that cause some problems in code I've reviewed, >> where things that shouldn't be True were True. >> > > I would use > > If n: > > If you want to make sure n is a book, do: > > if isinstance(n,bool) and n: I disagree. I think "n is True" is fine. It works, and it's documented to work; "bool?" says, Returns True when the argument x is true, False otherwise. The builtins True and False are the only two instances of the class bool. so there can't be any booleans that are true other than True. (And "n is True" is going to be vastly faster than "isinstance(n, bool) and n".) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] ALGLIB spkg is released (second version)
On Mon, Jul 26, 2010 at 4:43 AM, Sergey Bochkanov wrote: > Hello! > > Second beta of ALGLIB.spkg is ready. It can be downloaded from > http://www.alglib.net/share/2010-07-26-alglib-for-sage/ Cool. Compiles for me, but I didn't try any tests. > -- SAGE INTEGRATION -- > > Well, ALGLIB can be called from Python and Sage by now. But I think > that more can be done to integrate it with Sage. For example, we can't > write > > sage: A = Matrix([[3,2],[2,3]]) > sage: matdet.rmatrixdet(A) > > because ALGLIB uses Python's list-of-lists to store matrices, and Sage > uses its own matrix class. But only several functions from _alglib.py > have to be fixed to work with Sage matrices/vectors: > * safe_len/safe_cols/safe_rows > * is_bool_vector/is_int_vector/is_real_vector/is_complex_vector > * is_bool_matrix/is_int_matrix/is_real_matrix/is_complex_matrix > * x_from_list/x_from_listlist > > I think that it is very easy to do for someone familiar with Sage > internals. Anyone interested in helping me with this issue? Sure, I can help. I have some API questions first. What are the bool and int vectors and matrices used for? (Sage doesn't really have vectors or matrices of booleans or of machine ints. It has vectors and matrices over GF(2) (integers mod 2, so 1+1=0), which could be used as booleans. There are also numpy arrays and matrices of these types.) My suggestion would be to support Sage vectors and matrices over GF(2), RDF, and CDF (machine floats and complex numbers), as well as numpy arrays and matrices of appropriate types. If people think this is the right choice, I can help write the code. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Making 32-bit PARI pretend to be 64-bit
On Tue, Jul 27, 2010 at 2:22 PM, Jeroen Demeyer wrote: > My working on the big PARI-upgrade (#9343) has sprouted many ideas. One > of these (possibly crazy) ideas is the following: we might manage to > some extent to make 32-bit PARI behave like 64-bit PARI. Because right > now various doctests return different results depending on the word size > (32 or 64 bits). But if we make sure that the internal precision in > PARI is always a multiple of 64 bits, the results should be the same on > 32 and 64 bit machines. I already managed to do this as a > proof-of-concept for the sin() function. It might not be easy to do > this for every possible function in every possible case, but I guess > something can be done easily. The main disadvantage that I see is that > this might cause slowdowns, especially when working with small > precisions. What does sage-devel think of this? I like the idea. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Cython and #define
On Mon, Jul 26, 2010 at 2:52 AM, Simon King wrote: > Nonetheless, Cython needs to know what argument type and type of > output to expect. Therefore, one has "long lgefint(GEN x)" in the > Cython header. > > It works (at least for me). I admit that it somehow looks wrong, and > indeed it results in a compiler (or linker?) warning. This is how it's supposed to work. You declare the API (not the ABI) of the external module to Cython, and Cython generates code that uses that ABI; it doesn't know or care whether the API is implemented as a function or macro. What compiler or linker warning do you get? I just searched through my install.log (from sage-4.5.2.alpha0), and didn't see anything relevant when I searched for lgefint or decl.pxi. > Probably one "clean" way of usage would be to define a proper function > that wraps the macro. There might be a penalty for calling that > function, though (or am I mistaken that using a macro is slightly > faster than using a function of the same content, but results in a > bigger .so file?). It depends :) A macro does duplicate the code everywhere; a function generally does not, but it might duplicate if the compiler is optimizing aggressively or if you hint to the compiler that it should do so (by marking the function "inline"). This may or may not make the code bigger; a sufficiently simple macro will actually lead to generating less machine code than a function call, so macros would lead to smaller code than non-inline functions. And if code duplication from a macro does make the code larger, that will quite possibly make it slower as well, because it will mean less code will fit inside the processor's instruction cache. > Cheers, > Simon Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] doctests for hashes
On Sun, Jul 25, 2010 at 8:11 PM, Dan Drake wrote: > On Sun, 25 Jul 2010 at 07:11PM -0700, Carl Witty wrote: >> Hmm... looks like the current state of affairs is a mess. Looking >> through the 'def __hash__' grep hits in sage/rings, there are quite a >> few of each of the following: >> >> 1) no doctest at all >> 2) provide both 32-bit and 64-bit doctests >> 3) define your hash function to produce a 32-bit output that's the >> same on 32-bit and 64-bit systems; doctest an instance of that output >> 4) doctest hash value equality without ever showing a doctest output >> >> plus one instance where the hash output is marked "# random". >> >> So whatever you do with this particular patch, it won't make things >> much worse :) > > Yeah! That's what I like to hear. :) > >> As for the desired state of affairs: I have a slight preference for >> providing both 32-bit and 64-bit doctest outputs, because it increases >> our chance of noticing if something changes unexpectedly. But I could >> also make a good case for only testing hash equality, because it >> slightly reduces the effort involved in changing hash functions, >> internal representations, etc. :) > > If the hash values are supposed to be 32- or 64-bit integers, perhaps > testing that would be useful; something like > > sage: hash(foo) > 0 and is_integer(hash(foo)) > True > sage: hash(foo) < 2^sys_bits() > True > > where sys_bits() is a function that we could add that returns "32" or > "64", depending on your system. (Maybe such a function is already in > Sage.) Or we could just do two tests: > > sage: hash(foo) < 2^32 # 32-bit > True > > and so on. The above setup ignores the particular value and instead > insures that it has the necessary properties, which I think is what we > really want. Thoughts? 1) We want more properties than that; a constant hash (that returned 17 for all elements of a given ring) would not be so useful. (Of course, very few (possibly none?) of the existing doctests test for non-constant hashes.) 2) The Python code in hash() that calls your __hash__ method already enforces your properties (hashes must be integers, and if they're not in the correct range, Python will re-hash them into a small enough integer). So just having hash(foo) not return an error is enough to check those properties. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] doctests for hashes
On Sun, Jul 25, 2010 at 6:33 PM, Dan Drake wrote: > Hello, > > Ticket #9590 fixes a problem with hashing; it looks like the hash value > in the doctest is 32- or 64-bit specific, and of course it fails on > systems that don't match. The solution there is to change a doctest like > > sage: hash(foo) > 574575757575 > > into > > sage: hash(foo) == hash(foo) > True > > That avoids using the particular value, which we don't really care about > anyway, but I'm not certain this is a good solution, since the new > doctest really only tests that the hash function actually returns a > value. > > I don't know much about the hashing functions, so maybe the new doctest > is fine. There are some other fixes proposed on that ticket; should I > merge the current fix, or should we use 32-bit and 64-bit tags to use > different values? Hmm... looks like the current state of affairs is a mess. Looking through the 'def __hash__' grep hits in sage/rings, there are quite a few of each of the following: 1) no doctest at all 2) provide both 32-bit and 64-bit doctests 3) define your hash function to produce a 32-bit output that's the same on 32-bit and 64-bit systems; doctest an instance of that output 4) doctest hash value equality without ever showing a doctest output plus one instance where the hash output is marked "# random". So whatever you do with this particular patch, it won't make things much worse :) As for the desired state of affairs: I have a slight preference for providing both 32-bit and 64-bit doctest outputs, because it increases our chance of noticing if something changes unexpectedly. But I could also make a good case for only testing hash equality, because it slightly reduces the effort involved in changing hash functions, internal representations, etc. :) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Scary things in Sage's Digraphs
On Sun, Jul 25, 2010 at 10:27 AM, Robert Miller wrote:
> On Sun, Jul 25, 2010 at 2:01 PM, Nathann Cohen
> wrote:
>> Nononon, I understood why there are two copies of what appears to
>> be a "zero", and I think it's fine like that !
>
> This is definitely *not* fine, since we have
>
> sage: int(0) == Mod(0, 20)
> True
You seem to want to make the vertex dictionary respect the equivalence
relation defined by Sage equality. If so, you're going to be in
trouble, since Sage equality actually is not an equivalence relation:
sage: 3 == Mod(7, 4)
True
sage: 3 == Mod(8, 5)
True
sage: Mod(7, 4) == Mod(8, 5)
False
This means that mixing Sage objects of different parents as elements
of a single set or keys of a single dictionary is asking for trouble;
in general, it cannot work (or at least we haven't figured out a way
to make it work). (As long as you stick to a single parent you should
be fine.)
> So as I said before, the problem is created by line 1084 (in
> sage-4.5/4.5.1) of c_graph.pyx, namely:
>
> {{{ if (not isinstance(u, (int, long, Integer)) or }}}
>
> In fact this should check for any Sage object X for which {{{
> Integer(Y) == X }}} is true for any Y.
Sounds like what you want is "u in ZZ", which is equivalent to "u ==
ZZ(u)" except that it returns False if ZZ(u) fails.
Carl
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] arithmetic with True and False
On Sat, Jul 24, 2010 at 2:29 PM, Burcin Erocal wrote: > Hi, > > At Sage Days 24, I learned that Python allows the user to do arithmetic > with bools: > > In [1]: 5+True > Out[1]: 6 > > In [2]: True + False > Out[2]: 1 > > In [3]: 5+False > Out[3]: 5 > > Sage seems to follow this convention as well: > > sage: 5 + True > 6 > sage: 5. - True > 4.00 > > I can't see any use cases for this convention. I believe all these > examples should just raise a TypeError. IMHO, code relying on this > feature is very likely to be buggy. > > Apparently the symbolic ring doesn't handle things so well [1], but I'm > not decided what the "fix" should be. :) > > [1] http://trac.sagemath.org/sage_trac/ticket/9560 > > Any comments? I do think that Sage symbolics should (eventually) support symbolic booleans where True maps to 1 and False maps to 0. See http://en.wikipedia.org/wiki/Iverson_bracket for use cases and prior art. However, I would slightly prefer an explicit rather than implicit conversion. Implicit: sgn(x) = (x > 0) - (x < 0) Explicit: sgn(x) = iverson(x > 0) - iverson(x < 0) So I wouldn't mind if the implicit conversions from bools to SR became an error instead. At any rate, the current behavior is definitely wrong :) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Sorting vertices of a graph
On Sat, Jul 24, 2010 at 11:54 AM, Rob Beezer wrote: > So it is a verb. ;-) > > Looks like similar comments apply to edges(). > > I'm thinking that optionally passing in a comparison function would be > a nice thing to add - a minor convenience, but also it would drive > home the point that the sorting is somewhat the caller's > responsibility in non-trivial situations (ie for not most users). > > I'll get a ticket started soon. Note that Python 3 has removed the comparison function argument for List.sort() and similar functions, in favor of a "key" argument giving a function that transforms a list element into a sortable element. For example, if you want to sort by string representations, currently you could do: verts.sort(cmp=lambda a, b: cmp(str(a), str(b))) but in Python 3 you would have to do: verts.sort(key=str) The idea is to discourage inefficient programming; the Python 3 version is better, because it calls str() on each element only once, whereas the old version calls str() on each element O(log(N)) times. Our current Python also has a key= argument for sort(). I suggest that we should follow Python 3 here for such APIs, and optionally pass in a key= function rather than a cmp= comparison function. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] What went wrong with this build of IML?
On Fri, Jul 23, 2010 at 3:45 AM, Dr. David Kirkby wrote: > I just tried to build Sage, and got a failure with building IML. See log > here. > > http://boxen.math.washington.edu/home/kirkby/iml-1.0.1.p12.log > > As soon as I restarted "make" again, so the build completed ok. Well, in the following lines: gcc -DHAVE_CONFIG_H -I. -I. -I.. -O2 -g -m64 -I/export/home/drkirkby/sage-4.5.1/local/include -I. -O2 -g -m64 -MT libiml_la-basisop.lo -MD -MP -MF .deps/libiml_la-basisop.Tpo -c basisop.c -o libiml_la-basisop.o >/dev/null 2>&1 make[4]: *** [libiml_la-basisop.lo] Error 1 the >/dev/null 2>&1 means we don't get to see the actual compile error. It would be interesting, and perhaps informative, to see what the error was. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] strange symbolics/import problem: cannot import SR with #9502
On Thu, Jul 22, 2010 at 5:20 PM, Dan Drake wrote: > Hello, > > Ticket #9502, when applied to 4.5.2.alpha0, prevents Sage from even > starting -- the result is "ImportError: cannot import name SR", even > though the patch at #9502 barely touches the symbolics code, and does so > in a way that, to me, could not possibly prevent the module from being > imported. > > The patch seems to work fine with 4.5.1. > > I suspect this problem will be easy to fix for someone who knows more > about the symbolics code, Python imports, and Cython than I do. Can such > a person take a look at that ticket? > > Dan I don't have time to look at it tonight, but just judging from the sketchy description, I suspect a circular import error. Look at the traceback, and see if the error appears when it tries to import a module that is already in the process of being imported somewhere else up the call stack. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: Re: [sage-devel] M4RIE: linear algebra over small extensions of GF(2)
On Thu, Jul 22, 2010 at 3:05 PM, Martin Albrecht wrote: ... Pretty pictures! It would be nice, though, to have some sort of indication on the picture whether Magma is red or blue... For example, you could put "Magma" next to the 4 on the right-hand scale, and "Sage" next to the -4 -- or vice-versa, whichever is appropriate :) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage -b in parallel?
On Tue, Jul 20, 2010 at 9:46 PM, Dan Drake wrote: > Hello all, > > When building from source, I can set MAKE and have the Sage library > build in parallel. Is there a way I can do the same thing when using > "sage -b"? In analogy to "sage -t" and "sage -tp", it would be nice to > have "sage -bp". Yes: set MAKE :) export MAKE='make -j10' sage -b (In fact, when you build from source, it just does a "sage -b", I'm pretty sure.) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Suggested spkg: Modelica
On Tue, Jul 20, 2010 at 2:46 PM, Vincent D <20100.delecr...@gmail.com> wrote: > Jmodelica seems to be very interesting... but from > http://www.jmodelica.org/page/14 > (or see the copy below) they argue that the software is their property > (is that a problem for inclusion in Sage?). On the other hand very few > is said about the user license "The code base is provided under > standard licenses approved by the Open Source Initiative. > JModelica.org is subject to dual licensing and Modelon AB offers > complementing commercial licenses." I think this is all fine. The important bit is: http://www.jmodelica.org/page/24 which says that JModelica is available under GPLv3, which is OK for Sage. Almost any software is going to be the property of somebody; that's fine. > from http://www.jmodelica.org/page/14 > """ > JModelica.org is an open source project maintained and owned by > Modelon AB. The JModelica.org Contributor License Agreement (CLA) > means, in simple terms, that: > > * You assign and transfer the copyright of your JModelica.org > contribution to the Project owner to the extent permitted by > applicable law. In return you receive back a broad license to re-use > and distribute your contribution. > * You grant a patent license to the Project owner and the > JModelica.org users, in the event that you own a patent that covers > your contribution. > * You represent that you coded and own the contribution, and are > legally entitled to grant the assignment and license. > * You may provide support for free, for a fee, or not at all. > * The Project owner has no obligation to accept or use your > contribution. > """ This is if you want your contribution to be accepted into their copy of the codebase. It doesn't restrict your freedom to fork the project, which is the important bit. (The Free Software Foundation also requires copyright assignment to submit code to any of their projects, like gcc or emacs.) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage -pkg ?
On Tue, Jul 20, 2010 at 7:37 AM, John Cremona wrote: > I am having trouble with sage -pkg to make a new spkg from a directory > my-spkg/. (I have done this before). Am I doing something stupid? > > After typing > > sage -pkg my-spkg > > nothing apparently happens (no new prompt) BUT a file with the right > name my-spkg.spkg is being created in the current directory, and grows > and grows until I kill it with Ctrl-C. Have you checked the size of the my-spkg directory with "du"? Maybe you accidentally copied some huge directory in there? Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] WebGL backend for Sage plot3d
I've created a proof-of-concept WebGL backend for Sage plot3d in the notebook; if you have a WebGL-enabled browser, see http://sagenb.org/home/pub/2263/ . And if you don't have a WebGL-enabled browser, you should get one; see http://learningwebgl.com/blog/?p=11 . WebGL is an emerging standard for doing hardware-accelerated 3D graphics directly in the browser (no plugins). Firefox 4 beta 1 and the latest version of Chrome both support it on Linux, OSX, and Windows, if you have sufficiently good OpenGL support. (People are working on a Direct3D backend for use in the web browsers; hopefully in a few months, WebGL will work on Windows without OpenGL.) For both Firefox and Chrome, you need to explicitly enable WebGL; see the above link for details. I'm excited about WebGL; I think it has promise to be the primary Sage graphics interface in the notebook (although not this year, and maybe not next year). My current code is buggy, ugly, and limited. I plan to keep working on it (well, basically rewrite it from scratch); if people are interested in collaborating, let me know. I'm sending this email to both sage-notebook and sage-devel. Presumably any technical discussion should be on sage-notebook. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] How to I debug a crashing Sage?
On Mon, Jul 19, 2010 at 9:10 AM, David Kirkby wrote: > Yes - see below. > > sage: quit > Exiting Sage (CPU time 0m0.29s, Wall time 0m3.52s). > > Program received signal SIGSEGV, Segmentation fault. > 0x7e6627ec in _free_unlocked () from /lib/64/libc.so.1 > (gdb) bt > #0 0x7e6627ec in _free_unlocked () from /lib/64/libc.so.1 > #1 0x7e662784 in free () from /lib/64/libc.so.1 > #2 0x78c13154 in ?? () > #3 0x78c13154 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) > > I don't know how to approach this. Well, under Linux I would try valgrind next; but evidently valgrind doesn't work under Solaris. I'm guessing the problem is some sort of malloc heap corruption. If so, here are some tips on debugging that. Is there a way under Solaris to turn on some sort of memory debugging in libc? (For example, glibc does some extra heap corruption checks if the MALLOC_CHECK environment variable is set.) Otherwise, here's a list of malloc debug libraries. Probably some of them work on Solaris. http://www.fortran-2000.com/ArnaudRecipes/FreeMemoryDB.html If that fails, here's a technique I've used for pinpointing crash locations. It works if the crash is sufficiently reproducible (happens the same way on every run). Run "sage -gdb". Once you get the prompt, break into the debugger. Set breakpoints on a few frequently-called functions (they don't have to have anything to do with your problem, "frequently-called" is the real requirement). Type "continue 1". Now you're back at the Sage prompt; exit Sage. If you hit a breakpoint, type "continue 1" again. Repeat until the crash. Now you know that the crash happens, say, between 20,000 and 30,000 breakpoints after you exit Sage. Now you can restart Sage, set the same breakpoints, and do binary search to find, eventually, that the crash happens between breakpoint 23,456 and 23,457. Now restart once again, do "continue 23456", and then start stepping through the code line-by-line -- you will be fairly close to the crash, so hopefully this won't take too long. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] graph_plot.py : Image width or height is zero in IHDR
On Sat, Jul 17, 2010 at 5:57 AM, Robert Miller wrote: > Although > > http://trac.sagemath.org/sage_trac/ticket/5906 > > was supposed to eliminate this problem for good, sometimes random > (i.e. spring-layout) algorithms seem to trigger it, in particular when > a short path happens to get put into a straight vertical or horizontal > line. What surprises me is that it is not reproducible, even though > the doctesting framework is supposed to not be random in these types > of cases. When I developed randstate.pyx (reproducible "random" numbers), I found the places I needed to fix by searching for doctests that weren't being run because they were marked "# random" and trying to make them reproducible. So I wouldn't have fixed any use of random numbers that wasn't exposed in a "# random" doctest. It looks like there are a few such uses in graphs/; I'll look into fixing them. Everybody, let me know if you know of other places in Sage where randomness is not under the control of the randstate framework (for example, places you haven't been able to doctest because the answer changes on every run). Or fix it yourself! It isn't hard, and randstate has copious documentation. By the way, I'm testing "sage -t graph_plot.py" in an infinite loop on my machine, and no failures so far. It's run a lot more than 20 iterations by now. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Import problems
On Fri, Jul 16, 2010 at 8:21 PM, koffie wrote: > Dear All, > > I was writing some code for sage and ran into trouble. The code was > working just fine when it was a standalone function. Then I tried to > add it to a pyx file (sage/rings/fraction_field_element.pyx to be > precise) and ran into trouble. Somewhere in the code I would like to > use the command PolynomialRing, so I had to import it for else it > wouldn't build. So I added the line > > from sage.rings.polynomial.polynomial_ring_constructor import > PolynomialRing > > to the file. After having done this sage will build, but when running > sage I get into trouble. I have no idea about how importing and stuff > works in python/cython so if someone could help me with this I would > be very glad. It looks like you've got a problem with a circular import, where file A imports file B, which imports file C, ..., which imports file A. I don't know of a simple, systematic, efficient way to solve such problems. The easy way is to move this line: from sage.rings.polynomial.polynomial_ring_constructor import PolynomialRing inside the function you just added. (For example, just put it on the line before you use PolynomialRing.) The only problem with this solution is that it adds a tiny bit of time (maybe a few microseconds) to your function. If your function is very time-critical, you should find another solution; but otherwise this should work fine. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] ATLAS - proposal to allow a threaded build.
On Fri, Jul 16, 2010 at 4:34 PM, Dr. David Kirkby wrote: > How does this sound. > > 1) We add an environment variable SAGE_ATLAS_THREADS > 2) If unset, then the behavior is unchanged, so we build an unthreaded > ATLAS. > 3) If set to "auto": > > $ export SAGE_ATLAS_THREADS=auto > > then we let ATLAS automatically determine the number of threads. (I think > that is what ATLAS determines as the number of processors on your system. > IIRC, on 't2.math' this was 128). > > 4) If set to an integer N, > > $ export SAGE_ATLAS_THREADS=8 > > we use N (in this case 8) threads. +1 for this plan. Thanks for looking into this; I'm looking forward to seeing what ATLAS does on my desktop. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Unreasonable docfails in symbolic/random_tests.py
On Thu, Jul 15, 2010 at 1:38 PM, Andrey Novoseltsev wrote: > Hi Carl, > > For example this installation of sage-4.5.alpha1 > > novos...@sage:/scratch/novoselt/sage-4.5.alpha1/devel/sage-main$ hg > qapplied > trac_9502_basis_parent_bug_in_FreeModule.patch > trac_9128-sphinx_links_all-fh.patch > trac_9128-intersphinx_python_database-fh.patch > trac_9188_fix_facet_normal.patch > trac_9188_fix_facet_normal_reviewer.patch > trac_9062_add_support_for_toric_lattices.patch > trac_9062-cmp_fix.2.patch > trac_8986_add_support_for_convex_rational_polyhedral_cones.patch > trac_8986_cmp_fix.patch > trac_8987_add_support_for_rational_polyhedral_fans.patch > trac_8987_add_enhanced_cones_and_fans.patch > trac_8987_review_changes.patch > trac_8987_repr_changes.patch > trac_8987_cmp_fix.patch > trac_8988_add_support_for_toric_varieties.patch > > shows two broken doctests in symbolic/random_tests. Moreover, it seems > that my doctest patch does not fix one of the issues anymore! It will > be very very good if you could fix this issue, as I have no idea > what's going on... Thanks, that's exactly what I needed to track down the issue. Turns out it was a bug in random_tests.py. (I was inadvertently depending on the order of the output of .values() on a dict, which is a Bad Idea. The question isn't why it broke, it's why did it ever work.) There's a patch up at #9514. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Should there be some *good* examples on notebook?
On Thu, Jul 15, 2010 at 1:27 PM, Carl Witty wrote: > One very simple change might be easier to implement/use. How about if > there were both a "share" button and a "publish" button, and these > went in to separate sections? I'm guessing that people asking for > help with an error message, etc., would be perfectly happy to choose > "share" rather than "publish". Of course, now that I actually look at the notebook, I see that such buttons already exist. Sorry for the noise. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Should there be some *good* examples on notebook?
On Tue, Feb 23, 2010 at 1:14 PM, Robert Bradshaw wrote: > On Feb 23, 2010, at 8:39 AM, Dr. David Kirkby wrote: > >> If one sets up a Sage server for public use, there is the opportunity for >> someone to publish worksheets, there is a section: >> >> >> "Browse published Sage worksheets >> (no login required)" >> >> But often those worksheets are bad examples, error message, or just plain >> people experimenting. I do not think they generally reflect well on Sage. ... > > A simple rating system would probably let the decent stuff float to the top > (or at least the random, messy experimentation sink to teh bottom). One very simple change might be easier to implement/use. How about if there were both a "share" button and a "publish" button, and these went in to separate sections? I'm guessing that people asking for help with an error message, etc., would be perfectly happy to choose "share" rather than "publish". Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Unreasonable docfails in symbolic/random_tests.py
On Tue, Jul 13, 2010 at 6:39 AM, Andrey Novoseltsev wrote: > On Jul 13, 3:37 am, Carl Witty wrote: >> On Thu, Jun 17, 2010 at 2:18 PM, Volker Braun wrote: >> > Unsurprisingly, setting the random seed makes the random_expr() always >> > return the same value: >> >> > sage: set_random_seed(0xdeadbeef) >> > sage: random_expr(5) >> > tanh(-pi^real_part(v1)*sin(log(pi)*imag_part(v1))) >> > sage: set_random_seed(0xdeadbeef) >> > sage: random_expr(5) >> > tanh(-pi^real_part(v1)*sin(log(pi)*imag_part(v1))) >> > sage: random_expr(5) >> > v1 + arccos(e/golden_ratio) >> >> > I suggest that the doctests for sage.symbolic.random_tests simply set >> > the random seed to a fixed value. >> >> The testing framework automatically runs set_random_seed(0) before >> testing every docstring, so this shouldn't be necessary. >> >> Carl Witty > > I completely agree that this should not be necessary, but the output > of this function does change!!! > > Andrey OK. Setting the random seed seems like a fine workaround for getting your patch in... the problem is unlikely to be in your patch, as you point out. But as the author of both sage.misc.randstate and sage.symbolic.random_tests, it makes me nervous when I don't understand what my code is doing. I tried to look into this, but I couldn't figure out how to reproduce the problem. Could you do me a favor and give nice simple instructions? (In particular, what version of Sage do I start with and what is the complete list of patches to apply?) Thanks, Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on making GNU patch a standard package
On Sat, Jul 3, 2010 at 6:27 AM, Volker Braun wrote: > I would propose a mercurial patch queue in the spgk root directory. > Then sage -pkg simply checks that either all patches in the queue are > applied or that there exists an old-style /patches directory and no > queue. Since we all seem to like mercurial queues, we could also consider using quilt (which could be thought of as "mercurial queues without mercurial"). (Actually, I'm pretty sure that quilt came first, and then mq based its command-line interface on quilt.) Debian, who has the same sort of issue with upgrading packages that we do (times several hundred!), uses quilt for many of their packages, and recommends quilt in the "New Maintainers' Guide". The revision-control portion of the workflow for updating a package in the easiest case would go something like this: 1) extract spkg 2) rename directory to new version 3) remove old src/, unpack new source into src/ 4) type: "quilt push -a"; make sure that all patches apply 5) type: "quilt pop -a" 6) edit SPKG.txt, check in changes to top-level repository 7) sage -pkg The spkg-install would include: "quilt push -a" If there's an error in step 4 (some old patch doesn't apply correctly to the new source), then the procedure for fixing it is the same as with queues: push patches one at a time with "quilt push"; when you get to the patch that fails to apply, hand-apply it and do "quilt refresh". For cases where we have multiple variants, quilt supports multiple series files; instead of "quilt push -a", it would be "QUILT_SERIES=series.sun4v quilt push -a". In the above variant of the proposal, we would need to include quilt as an spkg. The source is a 420 kilobyte .tar.gz. On my desktop, it takes 3.5 seconds to build (2 seconds to run configure, 1.5 seconds to run make). We could avoid shipping quilt as a standard spkg by rewriting "quilt push -a" as our own shell script. (This is quite simple, and actually recommended by the documentation. All the shell script needs to do is take the series file and remove comments; then all that's left is a list of patches to apply, one patch filename per line.) Then only developers who want to work on spkgs including patches would need quilt, so it could be an optional spkg (or we could require such developers to just install quilt themselves). We could avoid shipping either patch or quilt by going back to William's suggestion at the top of the thread, where we automatically make copies of the patched files at "sage -pkg" time, so that we can copy the files at spkg build time without needing patch. With the extra structure provided by quilt, with every variant represented by a series.FOO file, I believe this would be straightforward even in the case of multiple variants (although the multiple copies of patched files would certainly make the spkg bigger). I feel strongly (but have no hard evidence, of course) that the problem of package updating with quilt would be much, much easier than our current system, and also much easier than a system using patch files in the case where the patches don't apply cleanly and a "quilt refresh" is needed. I'd be willing to put some effort into switching to quilt as the recommended way to deal with patches in Sage, up to and including: * make an spkg for quilt * convert one spkg to using quilt, try to upgrade it with the above workflow, and report on the process * if people like the third variant, where we don't ship patch and instead we automatically generate the patched versions of files at spkg-build time, I'd be willing to write that tool Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] global options for python
On Wed, Jul 14, 2010 at 2:43 PM, Mike Hansen wrote:
> On Wed, Jul 14, 2010 at 2:31 PM, Johannes wrote:
>> i want to check which part of the sagecode makes problems when trying to
>> port it to python 3.x. For that, I want want to build it with the '-3'
>> option, but i dont want to edit every single makefile. is the a special
>> place to put something like a global python build parameter?
>
> This is a runtime option you pass to python rather than a build
> option. To make use of it , you can make the following change in
> $SAGE_ROOT/local/bin/sage-sage
>
>
> --- a/sage-sage
> +++ b/sage-sage
> @@ -205,7 +205,7 @@
>
> sage() {
> sage_setup
> - sage-ipython "$@" -i
> + python -3 sage-ipython "$@" -i
> }
>
> if [ $# -eq 0 ]; then
>
>
> Then, you'll see a lot of deprecation warnings when Sage starts.
Also, you can change this line in sage-doctest:
--- a/sage-doctest Tue Jul 13 18:13:17 2010 -0700
+++ b/sage-doctest Wed Jul 14 14:56:40 2010 -0700
@@ -125,7 +125,7 @@
##
# The Python binary
##
-PYTHON = "python"
+PYTHON = "python -3"
def pad_zeros(s, size):
and any doctests will be run in -3 mode. (Which means that huge
numbers of doctests will fail, because the "expected" outputs don't
have the deprecation warnings.)
Carl
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: The Sage Nagbot
On Sun, Jul 11, 2010 at 5:38 AM, William Stein wrote: > Cool. There are numerous parameters one could imagine a nagbot > having. E.g,. max emails per week, how often messages sent, etc., > which should be easily customized by each recipient. Ideas? Please > suggest them. It should keep track of what (ticket,person) pairs it has sent email about, and not send the same email to the same recipient for a (configurable by each recipient) interval. (I'd suggest a default of a month.) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: R graphics on the command line
On Thu, Jul 1, 2010 at 8:36 AM, kcrisman wrote: > > > On Jul 1, 10:30 am, Jason Grout wrote: >> Is there an easy way to make this work? >> >> % sage -R >> >> R version 2.10.1 (2009-12-14) >> Copyright (C) 2009 The R Foundation for Statistical Computing >> ISBN 3-900051-07-0 >> >> R is free software and comes with ABSOLUTELY NO WARRANTY. >> You are welcome to redistribute it under certain conditions. >> Type 'license()' or 'licence()' for distribution details. >> >> R is a collaborative project with many contributors. >> Type 'contributors()' for more information and >> 'citation()' on how to cite R or R packages in publications. >> >> Type 'demo()' for some demos, 'help()' for on-line help, or >> 'help.start()' for an HTML browser interface to help. >> Type 'q()' to quit R. >> >> [Previously saved workspace restored] > > Did you try this (on your Mac, I assume)? > > >> quartz() >> demo(graphics) > > > At some point it will say > > Hit to see next plot: > > And then hitting gives me (for instance) January pie sales... > It should work VERY nicely. > > The point is that demo(graphics) probably won't work unless you open a > graphics device; maybe this happens automatically for 'native' R. On > Linux I assume that > >> png() > > instead of > >> quartz() > > will work, but I can't test this since I don't have a Linux box. I just tried this on my Linux box (Debian testing, 64-bit, Sage compiled from source): ./sage -R ... > demo() and it worked fine, popping up a graphics window. I didn't do anything to select a graphics device. (BTW, the first "graphic" is evidently just a blank white window... don't worry, they get more interesting.) Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Unreasonable docfails in symbolic/random_tests.py
On Thu, Jun 17, 2010 at 2:18 PM, Volker Braun wrote: > Unsurprisingly, setting the random seed makes the random_expr() always > return the same value: > > sage: set_random_seed(0xdeadbeef) > sage: random_expr(5) > tanh(-pi^real_part(v1)*sin(log(pi)*imag_part(v1))) > sage: set_random_seed(0xdeadbeef) > sage: random_expr(5) > tanh(-pi^real_part(v1)*sin(log(pi)*imag_part(v1))) > sage: random_expr(5) > v1 + arccos(e/golden_ratio) > > I suggest that the doctests for sage.symbolic.random_tests simply set > the random seed to a fixed value. The testing framework automatically runs set_random_seed(0) before testing every docstring, so this shouldn't be necessary. Carl Witty -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Randomised testing against Mathematica
I realize this thread is 4 months old, but let me respond to this one technical question: On Thu, Mar 4, 2010 at 2:10 AM, Simon King wrote: > Hi! > > On Mar 4, 8:24 am, Robert Bradshaw > wrote: >> I believe there is also some randomized testing that is done in the >> category code that takes random elements and verifies they have the >> correct properties (e.g. commutativity, associativity, etc.) that has >> exposed some bugs. > > One technical question about randomised doc tests: Perhaps I remember > incorrectly; but isn't it the case that the random seed is initialised > to a fixed value when one runs the doc tests? Hence, isn't that type > of "random" test only repeating the same computation? > > But I agree that random (I mean *really* random) consistency test suit > would be a good thing to have! It's true that by default, random testing in a doctest won't really be random. However, there is also a framework (a design pattern and a little bit of supporting code) for doing truly random testing in doctests; see sage/misc/random_testing.py . (I just counted it up; by my estimate, random_testing.py is <10% useful code and >90% documentation/comments/doctests.) This only has two users in Sage currently (homology/tests.py and rings/tests.py); in particular, the category testing code that Robert mentioned does not use it, but could. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Default representation of intervals
Dirk, I'd prefer to have this discussion on sage-devel, where it will
be archived and other people can chip in as well. So I'm replying
both to you and to sage-devel... I hope you don't mind.
On Sun, Jul 11, 2010 at 3:56 AM, Dirk Laurie wrote:
> On Fri, Jul 09, 2010 at 11:39:15PM -0700, Carl Witty wrote:
>> The problem is that it's easy to know a lot about an interval while
>> knowing very few digits. For example, consider the interval [0.99
>> .. 1.01]. With the current definition, we can print this as
>> 1.00?; with your suggestion, we'd have to print it as 0.?e1
>> (meaning that the number is between 0 and 10 -- we know that the 10s
>> digit is 0).
>>
>
> OK, that kills my suggestion.
>
> Note that your example has the following beautiful properties:
> (a) 1.00 is inside the interval.
> (b) 0.01 is a better approximation to the interval's
> half-diameter than 0.1 or 0.001.
> These reflect exactly what one would like 1.00? to mean.
Actually, IMHO the 0.01 MUST be >= the half-diameter; that's much
more important than whether it's a better approximation. (If I'm
using interval arithmetic, I always want the interval property -- that
the internal interval, or the interval as printed, contains every
possible correct answer -- to hold.)
> But when I try to explain to students why [3.1310 .. 3.1321] displays
> as 3.14?, when (a) 3.14 is not in the interval (b) 0.01 is a terrible
> approximation to the half-diameter, I can simply sense that I'm
> not getting across and only the fact that Africans are brought up
> to respect their elders is protecting me from derisive howls.
>
> Your example shows that my suggestion is not the answer. My example,
> I respectfully contend, shows that the current definition is not it
> either.
>
> If we could define the question mark to have those properties, life
> would be perfect. Unfortunately, if the interval width is to be deduced
> from the number of digits shown, no definition works.
>
> How about the following modification?
> If properties (a) and (b) are not satisfied, extend the question
> format to show the interval half-width in ulp, so that
> [3.1310 .. 3.1321] displays as 3.1315?6.
You can globally set the error_digits parameter; is that good enough?
sage: loose_pi = RIF(3+10/71, 3+1/7)
sage: loose_pi
3.15?
sage: sage.rings.real_mpfi.printing_error_digits=1
sage: loose_pi
3.142?2
I believe that with printing_error_digits=1, the base number will
always be within the interval. (Your suggestion would be to leave off
the interval half-width digit when it's equal to 1; this won't do
that, it will always print the digit.)
Should error_digits=1 be the default?
> Even better, if in the Unicode era we can tear ourselves away from
> 95-character ASCII Luddism, 3.1315ą6.
I'm guessing you typed a plus-or-minus symbol there? I see a strange
symbol I've never seen before, an "a" with a descender -- sort of a
mixture of "a" and "q". Maybe it's not time to tear ourselves away
from 95-character ASCII Luddism just yet :)
> This also suggests another constructor: RIF("3.14?") to mean
> [3.13 .. 3.15] and RIF("3.1315?6") to mean [3.1309 .. 3.1321].
Hmm... tricky.
The problem is the difference between the printing in base 10 and the
internal representation in base 2, combined with the general rule that
intervals must always be too big, never too small.
If we made RIF("3.14?") be the same as RIF("3.13", "3.15"), that
probably wouldn't be what you want:
sage: RIF('3.13', '3.15')
3.2?
This prints as 3.2? because the interval half-diameter is actually
slightly more than 0.01:
sage: RIF('3.13', '3.15').str(style='brackets')
'[3.1298 .. 3.1504]'
And we pick a floating-point number that's less than 3.13 as the lower
bound, because the next available floating-point number would create
an interval that doesn't include 3.13 (or even 3.1301) at
all:
sage: RIF('3.13', '3.15').lower().nextabove().str(truncate=False)
'3.1303'
We could instead define RIF("3.14?") to be something like "the biggest
RIF interval that could print as 3.14?". I could implement that
definition, but it has a couple of drawbacks. First, it means that
you could print out an interval, then read it back in and get a
smaller interval (by switching between different RealIntervalFields).
For example:
sage: RR128 = RealField(128)
sage: RIF128 = RealIntervalField(128)
sage: RIF128(RR128('3.13').nextabove(), RR128('3.15').nextbelow())
3.14?
RIF("3.14?") would actually
Re: [sage-devel] Re: Multiplying inequality by negative number
On Thu, Dec 10, 2009 at 3:56 PM, Jason Grout
wrote:
> VictorMiller wrote:
>> To do this correctly in full generality one needs to get into
>> "cyclindrical algebraic decomposition" -- a set in R^n has a
>> cylindrical algebraic
>> decomposition if it is written as a finite union of sets of the form
>> { x : f(x) > 0 } where f is a polynomial. There is an algorithm due
>> to Tarski
>> for creating such sets.
I don't understand what CAD has to do with the problem. It could be
used to verify a theorem like "If a!=0, then x>y iff (a>0 and a*x>a*y)
or (a<0 and a*xy).
sage: qepcad('[a /= 0 ==> [x > y <==> [ [a x > a y /\ a > 0] \/ [a x <
a y /\ a < 0] ] ] ]', vars=('a','x','y'))
TRUE
> Carl Witty has (unreleased) Sage code for doing such things. We also
> have an optional spkg for qepcadb, which computes such things.
>
> Unfortunately, it seems like Carl has not been active in the project
> lately, so I don't know who else could or wants to do this. Carl: if
> you are reading these messages, is there the possibility you could post
> your code somewhere so interested people could work from there?
I'm back to being active. If there are people interested in
half-written, slow CAD code I'd be happy to work with them! My
impression, though, was that there were a few people interested in
having my work in Sage, but nobody interested in actually helping me
write the code. (Which is fine, it just means it'll take a while to
get finished.)
> I might note that Mathematica has a very powerful CAD implementation,
> from what I understand.
>
> Jason
Carl
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: bool() on an inequality
(Yes, I realize I'm responding to an 8-month-old email.) On Wed, Nov 11, 2009 at 12:38 PM, kcrisman wrote: > > It would be worth trying this out in Maxima. If Maxima can do it, we > can try to expose more stuff; if not, we'll have to return to other > things if people really need this. A while ago QEPCAD was made an > optional package, I think, but I know nothing about it or whether it > can do this kind of thing. Yes, QEPCAD can decide whether any set of polynomial equalities/inequalities implies any other polynomial inequality/inequality. However, it's quite difficult to predict whether the performance will be adequate; some fairly small-looking examples could easily take longer than the lifetime of the universe to run (except that they would run out of memory much sooner). So I'm dubious whether a CAD-based solution is a good idea for dealing with symbolic assumptions. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Default representation of intervals
Sorry to be so late (10 months late!) in responding to this; I'm
getting back to Sage development and I'm reading through my sage-devel
archives.
Dirk, I don't know if you still care about this... I'm the original
author of the code (and documentation) in question. I basically made
up the behavior based on what made sense to me. Please ignore this
email if you don't care about intervals in Sage any more...
On Wed, Sep 9, 2009 at 10:48 AM, Dirk wrote:
>
>
>
> On Sep 9, 6:17 pm, Jason Grout wrote:
>
>> That's how I understand it from the documentation. Wow, I really like
>> your explanation. Would you care if we included that in the
>> documentation? Are you comfortable submitting a patch to the documentation?
> Not really, in view of my response to the next suggestion.
>
>> On the other hand, how would you change the above design to be better?
>> Maybe this could just be a patch making the code better, rather than a
>> patch to the documentation.
> Now you're talking.
>
> If I understand you right, the notation 3.14? is a convenience and
> nothing will break if it is changed. I suggest that it should mean
> the half-open interval [3.14,3.15).
> Advantages:
> (a) No need for a tie-breaking rule.
> (b) Half the length of [3.13,3.15].
> (c) The displayed digits are guaranteed to be correct, in the sense
> that any number in that interval starts out with them.
> (d) Easy to explain to an idiot.
The problem is that it's easy to know a lot about an interval while
knowing very few digits. For example, consider the interval [0.99
.. 1.01]. With the current definition, we can print this as
1.00?; with your suggestion, we'd have to print it as 0.?e1
(meaning that the number is between 0 and 10 -- we know that the 10s
digit is 0).
> Extension to error digits: rather than having one pair of error digit
> sequences giving the width of the interval of uncertainty in units
> that require a bit of thought, give two pairs that actually specify
> the possibilities.
>
> I.e. for the Archimedes interval x=RIF(3+10/71,3+1/7) , it would be
> nice to have
> sage: x.str(error_digits=2)
> 3.14?08..29
> In the GUI as opposed to the command line, the 08 could appear as a
> subscript and the 29 as a superscript: $3.14_{08}^{29}$ in TeX
> notation.
> The fact that 08..29 is left-closed and right-open is very Pythonic
> too.
Again, how does this work for [0.99 .. 1.01]? I could imagine
something like 0.?99..01 (where the fact that the 99..01 is in the
"wrong" order indicates that the upper endpoint has actually wrapped
to 1.01), but I think that's more confusing than the present
system.
> Related: if I say "style='brackets'", error_digits is ignored. Why
> not allow:
> sage: x.str(error_digits=2,style="brackets")
> [ 3.1408 .. 3.1429 ]
> Two error digits might even be the default for brackets. After all,
> if a number is correct to so few digits, who wants to see sixteen
> decimals of it?
So, for [0.123 .. 456.0] would you print [0.12 .. 460.0]? Or [0.0 ..
460.0]? I wouldn't object to either of these changes, although I
wouldn't implement it myself.
The thread start seemed to suggest that in the question-mark notation,
if we have multiple choices, we should use the choice that's closer to
the midpoint of the interval. Again, this is reasonable, but I
wouldn't implement it myself.
I do have a reason to prefer the current definition (pick the choice
farther from zero): it can be computed quickly and exactly. If the
docstring said that the choice closer to the midpoint of the interval
was chosen, I think that requires either: some potentially very slow
code, some very tricky code that is usually fast but occasionally
slow, or that we sometimes give the wrong answer according to the
specification.
Carl
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Typesetting regression in Sage-4.0
On Tue, Jun 9, 2009 at 6:08 PM, Golam Mortuza
Hossain wrote:
>
> Hi,
>
> On Tue, Jun 9, 2009 at 9:45 PM, Jason Grout
> wrote:
>
>>> (4) Should we switch to old maxima format for "diff"?
>>
>> Can you clarify with an example what you mean? In other words, can you
>> give an example of the "new" way and the "old" way?
>
> In new symbolics, "df(x)/dx" is
>
> (a) represented as: D[0] f(x)
> (b) typeset as: D[0] f(x)
>
>
> In old symbolics, the same was
>
> (a) represented as: diff( f(x), x)
> (b) typeset as: \frac{d f(x)}{d x}
Is it even possible to use the old typesetting format with the new
symbolic representation? For example, "df(sin(x)*cos(x))/dx" is
represented as -(sin(x)^2 - cos(x)^2)*D[0](f)(sin(x)*cos(x)); it seems
likely to be difficult to invert that to produce
{{{\it \partial}}\over{{\it \partial}\,x}}\,f\left(\cos x\,\sin x \right)
(which is what the old symbolics produced). And what should
"D[0](f)(sin(x)*cos(x))" be typeset as?
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: change_ring returns self or a copy of self, depending on R
On Thu, Jun 4, 2009 at 4:36 PM, Jason Grout wrote: > > It seems confusing and inconsisent that for a matrix m, m.change_ring(R) > returns m when R==self.base_ring(), but otherwise returns a copy of m > (coerced to the right ring). > > If you always just do new_mat = m.change_ring(R), you don't know if > you're working with a copy of m or a new version of m, i.e., you don't > know if it's safe to then do new_mat[0,0]=1. > > Should this be changed so that m.change_ring(R) always returns a copy? Yes, I think so. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan ; categories
On Mon, May 25, 2009 at 7:06 PM, Nicolas M. Thiery
wrote:
> Adding a couple calls like:
>
> register_unpickle_override('sage.categories.category', 'Sets', Sets)
>
> did the trick (thanks Carl!). By the way, where in the Sage source
> tree should I put those?
Well, obviously we don't have a convention for this yet; but my
suggestion would be that if you rename sage.foo.X to sage.bar.Y, then
you put the register_unpickle_override just after the definition of
class Y in sage/bar.py .
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.0.rc0 - division bug on second and subsequent evaluation of cell?
On Fri, May 22, 2009 at 2:00 PM, Nick Alexander wrote: > >> We do this to avoid the (large) overhead of re-creating constants in >> the bodies of loops, functions, etc. Perhaps we need to detect the >> Integer=xxx line explicitly? > > Doing this accurately is equivalent to the halting problem. This is > what pragmas are for, but do we really want to start supporting all > these compiler features? When is sage no longer python? Another possibility, which is much easier than the halting problem :) and would fix at least this issue, is to put the constant-creation code just before the top-level statement that uses the constant. (So if method in a class uses a constant, I'm proposing to put the constant creation just before the class.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Complex interval fields
On Wed, May 13, 2009 at 11:02 AM, Robert Bradshaw wrote: > > I recently noticed that complex interval fields have a very different > notion of equality than real interval fields. For RIF, a != b if a is > *definitely* not equal to b, but CIF just compares endpoints. I think > we should change CIF's behavior to be more like RIF, does anyone have > any objections? No objection from me. (Sorry, this is surely my fault; I don't remember what I was thinking at the time.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: loads(dumps(G)) for G a graphics object
On Thu, May 7, 2009 at 7:01 AM, kcrisman wrote: > I am hoping to help the push to 75% by adding some doctests to some of > the plotting primitives. But for some reason, the following always > occurs: > > sage: G = some graphics object > sage: G == loads(dumps(G)) > False > > Nonetheless, no matter how hard I try, I cannot actually find a > difference between G and loads(dumps(G)) when I view both of them, > look at xmin(), options(), etc. Why aren't they ==? Because graphics objects don't implement equality (there are no __eq__ or __cmp__ methods defined), so the default implementation is used, which is "is" (object identity, pointer equality). Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: strange rounding with SymbolicArithmetic
On Wed, May 6, 2009 at 2:16 PM, Yann wrote: > or print the error digit 4.?1 (expicit is better than implicit, > etc :) ) Well, again this was an explicit decision; the thinking was that if somebody saw 1.234567? they might be able to guess approximately what it means without reading the documentation, but 1.234567?1 is more confusing and less likely to have somebody correctly guess what it means. What do other people think? Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: strange rounding with SymbolicArithmetic
On Wed, May 6, 2009 at 1:46 PM, Yann wrote: >> In other words, >> sage: RealIntervalField(4)(0, 1) >> 1.? >> prints as the interval [0 .. 2], rather than [-1 .. 1], because IMHO >> it is useful to be able to know that an interval is nonnegative; and >> we do this by always picking the result farther from zero whenever >> there are two possible "correct" printings. (Note that 3.? and 4.? >> would both include the interval [3.00 .. 3.25], so they are both >> correct in that sense.) > > I would agree if it was 4.?1 (even I find something like 4.?±1 easier > to understand) > but without the error explicitely written, I would prefer to do what > is in the docstring: > " In question style (the default), we print the "known correct" > part of the number " > My understanding of this sentence is that we print the digits known > for sure. And if a > number is in the interval [3.00 .. 3.25], this should be 3.? > The design you decision si only relevant IMHO if the error digits are > explicitely written We definitely don't want to print "the digits known for sure". Consider the interval [0.99 .. 1.01], which would print as 1.00? with the current code (I'm ignoring the fact that the endpoints are not exactly representable in binary). With printing "the digits known for sure", the first digit that we know for sure is the tens digit, which is known to be zero; that would give 0.?e1, which gives vastly less information than 1.00?. Perhaps the docstring you quote should be adjusted? Elsewhere (in the module docstring) we find this variant: In question style, we print the "known correct" part of the number, followed by a question mark. The question mark indicates that the preceding digit is possibly wrong by +/- 1. Maybe that second sentence should be copied into the docstring for .str()? Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: strange rounding with SymbolicArithmetic
On Wed, May 6, 2009 at 2:20 AM, Yann wrote: > > Just for the record, > isn't the following a bug? > > sage: p=RealIntervalField(4)(3.1) > sage: p.str(style='brackets') > '[3.00 .. 3.25]' > sage: p > 4.? It's a deliberate design decision. To quote from real_mpfi.pyx: When there are two possible results of equal precision and with the same error width, then we pick the one which is farther from zero. (For instance, RIF(0, 123) with two error digits could print as 61.?62 or 62.?62. We prefer the latter because it makes it clear that the interval is known not to be negative.) In other words, sage: RealIntervalField(4)(0, 1) 1.? prints as the interval [0 .. 2], rather than [-1 .. 1], because IMHO it is useful to be able to know that an interval is nonnegative; and we do this by always picking the result farther from zero whenever there are two possible "correct" printings. (Note that 3.? and 4.? would both include the interval [3.00 .. 3.25], so they are both correct in that sense.) It would be possible to use a different rule for choosing between two correct answers, but I like the current one. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Fri, Apr 24, 2009 at 5:36 AM, Pat LeSmithe wrote:
>
> chris wuthrich wrote:
>> * In one of my files i have a line "power_series = series". This
>> produces the full docstring of series to appear twice in the
>> documentation, once under series and once under power_series. How can
>> I exclude the alias ?
>
> According to
>
> http://sphinx.pocoo.org/ext/autodoc.html
>
> the autodoc directives
>
> .. autoclass:: pAdicLseriesOrdinary
> :members: series, is_ordinary, is_supersingular
>
> might work in Sphinx v0.5 and
>
> .. autoclass:: pAdicLseriesOrdinary
> :exclude-members: power_series
>
> in Sphinx v0.6. However, I believe the current version of builder.py
> does not scan for custom directives when it auto-generates the .rst
> files. I don't know if it's OK simply to put them in a docstring.
>
> Another possibility is to add to builder.py an auto-skip-member()
> handler that skips certain methods, along the lines of
>
> http://groups.google.com/group/sphinx-dev/browse_thread/thread/852fbec28bc4ba15/719dbcf762c9db18?#719dbcf762c9db18
>
>
> except that it scans the first part of a __doc__ attribute for some phrase.
Of course, looking at __doc__ for a keyword won't help distinguish
power_series from series after "power_series = series".
I definitely do like the idea of using keywords to the docstrings to
control whether they show up in the reference manual, though. (This
could override the current decision, which I think is "non-underscore
methods are included, underscore methods are not".)
It seems like the first line of the docstring (on the same line as the
triple-quotes) would be a good place for such a keyword:
def foo():
r"""exclude
Docs for foo.
"""
pass
I really want about three different levels of reference manual for a
lot of my code. For instance, sage/misc/sage_input.py has one
function that's useful to people working from the command line or
notebook, one class (with a bunch of methods) that's useful to people
writing Sage library code (writing new types, and wanting to support
sage_input on those types), and a bunch of classes that are only
useful to people (only me, so far) working on sage_input itself. It
would be nice to be able to mark these ("public", "library", and
"private", perhaps), and then be able to produce three different
reference manuals (small, medium, and huge) with different subsets of
the documentation.
As far as aliases go, it should be possible to automatically detect
aliases inside sphinx and produce appropriate documentation (once we
decide what the appropriate documentation is). (This would mean
patching sphinx, or forking the autodoc extension; hopefully this
would be considered a useful feature that would be accepted upstream.)
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Thu, Apr 23, 2009 at 9:19 PM, Jason Grout wrote: > Anyone know where the CSS file is? The color is set in a default.css > file, but the only default.css files I see are in _static directories, > which sounds like they are automatically generated somehow. It comes (originally) from src/sphinx/static/default.css in the sphinx spkg. (No, I don't know the right way to customize it.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: programming: define a new function
On Wed, Apr 22, 2009 at 3:59 PM, Tim Lahey wrote: > > On Wed, Apr 22, 2009 at 6:54 PM, Carl Witty wrote: >> >> >> Would it be better to test the results numerically? (For instance, >> evaluate the integral returned and the desired result at 100 random >> points to high precision, and ensure that the relative error between >> the answers at each point is small.) > > > How can one do that with symbolic variables? Most of the test integrals > have symbolic constants (w.r.t the integration) so it isn't just the > integration > variable. I thought about numerical testing, but it isn't generally feasible. Couldn't you just pick random values for all of the symbolic constants, as well? Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: programming: define a new function
On Wed, Apr 22, 2009 at 3:35 PM, Tim Lahey wrote: > The problem arises with all the different integration systems. Usually some > kind of simplification is needed on the integral returned, even if there > aren't > multiple solutions. This complicates the testing procedure since the steps to > perform the simplification are often specific to the returned result. > > I'm currently aiming to finish the test suite just for Sage/Maxima and > I'll go back > and address the various issues (like testing SymPy) once that's complete. Would it be better to test the results numerically? (For instance, evaluate the integral returned and the desired result at 100 random points to high precision, and ensure that the relative error between the answers at each point is small.) Of course, this wouldn't count as a proof that the result was correct, but IMHO it would be good enough (it seems unlikely that integration bugs would result in wrong answers that were numerically almost equivalent to the right answer). (Actually, I might actually trust a numeric result more than a symbolic simplification-based result, given the theoretical possibility that a simplification bug might cancel out an integration bug, leading to a false pass in the test suite; especially if simplification and integration are done in the same system.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: programming: define a new function
On Sun, Apr 19, 2009 at 7:44 AM, Maurizio wrote:
> Carl, I took advantage of your suggestion, even though I assume I
> can't still go through the whole process with the current gcd
> capabilities in Pynac. But before than that, I'd like to point out
> something strange I did notice, and maybe also Burcin can help with
> that:
>
> reset()
> P. = QQ[]
>
> B = x^3 + x
>
> var('x, zs', ns = 1)
> from sage.symbolic.ring import NSR
> Bs = NSR(B)
> Bs
> x^3 + x
> Bs.diff(x)
> 0
>
> So, the derivative is not working. Which is the cause? It seems that
> the "x" in Bs is not the "x" I declared, so the derivative gets 0 as a
> result. Which is the reason?
Looks like a bug to me.
Burcin, any comments?
> Moreover, I don't see this being the right way to do this, because
> (for this particular problem: integration) I don't like having the
> numerical representation of things like sqrt(5), even if the result is
> still correct, so that
>
> temp = QQbar(sqrt(5)); temp
> 2.236067977499790?
>
> temp^2
> 5.000?
Note that it's only the representation that's numerical; internally
these are actually exact numbers. (For instance, if you do "temp^2 ==
5" and Sage prints "True", then that means that temp really is exactly
the square root of 5.) I use a numeric representation because not all
algebraic numbers can be represented with radicals, and solving by
radicals is much more difficult than the symbolic-numeric algorithms I
used in QQbar.
> So, please tell me. Which should be the right way to try to approach
> this indefinite integration problem? You can see that I'm not that
> good in deep mathematical theory, but approaching the simplest problem
> (that could be different from this one I'm looking at right now) is
> fun :)
Unfortunately, I think the right way is a lot of work.
1) Teach yourself enough math that you can mostly understand the
algorithm in the paper. (Not just mechanically follow the steps, but
understand what each step does, and have some idea why the algorithm
as a whole works.)
For some parts of this task, wikipedia and mathworld.wolfram.com will
be useful resources (planetmath.org is also interersting); but you'll
probably also need to read some books, etc.
2) Implement each missing sub-algorithm in Sage.
3) Implement the entire algorithm in Sage.
This sounds glib, but it really is possible... I'm implementing
cylindrical algebraic decomposition in Sage following this program.
I've been working on it in my spare time for several years; I probably
spent a couple of years on step 1, then I started step 2 a couple of
years ago, and now I'm working on step 2 and step 3.
The problem is that the Risch algorithm just is not simple.
A good integration algorithm probably has a couple of phases -- first
you try some heuristics, and pattern-match against a database of known
integrals; if those fail, then you bring out the big guns and apply
the decision procedure. If you're interested in working on
integration, maybe you'd rather work on the first phase? That
probably requires more computer science and less math than the second
phase.
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: programming: define a new function
On Sat, Apr 18, 2009 at 6:55 PM, William Stein wrote: >>> First problem with QQbar: it seems that resultant() doesn't like it, >>> because it is not able to convert it to a Singular ring (this is the >>> error, I'm not attaching all the output, tell me if you need it) >>> >>> TypeError: no conversion of this ring to a Singular ring defined >> >> Looks like this hasn't been implemented yet. > > I think Singular doesn't have QQbar as a base ring, so I don't think > this is likely to be implemented for a while. Well, we just need a resultant algorithm that doesn't go through Singular. I'm planning to write such a thing as part of my cylindrical algebraic decomposition implementation sometime in the next few months. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: programming: define a new function
On Sat, Apr 18, 2009 at 6:04 PM, Maurizio wrote: >> QQ is the rational numbers (fractions). QQbar is the algebraic >> closure of QQ; this means it includes every complex number which is >> the root of a polynomial with rational coefficients. So it includes >> things like sqrt(2) (which is a root of x^2-2), and sqrt(-1) (a root >> of x^2+1), as well as more exotic numbers like the roots of x^5-x-1, >> which can't be expressed using radicals (roots). (QQbar does not >> include all complex numbers, though; for instance, it does not include >> pi or e, which are transcendental rather than algebraic.) >> > > I understand. This means (as I was kind of suspecting) that QQbar > could have been a good candidate to try to work with (I am just trying > to solve examples 1.4 and 1.5 of that web page). Unfortunately, QQbar > doesn't provide resultant() yet, so it should jump in after the > resultant has been calculated over QQ[]. I think that is not really an > elegant solution (and probably very suboptimal...). It's not elegant, but it's probably much more efficient... QQbar is vastly less efficient than QQ, so it's definitely a good idea to stick with QQ as long as possible before jumping to QQbar. You can use .roots(ring=QQbar) on a polynomial over QQ. > if I don't define a ring containing x and z, how do I inject z into > the workspace? certainly not as a symbolic variable, so what else? I > know that at the very end this is a univariate polynomial ring root > finding problem, I'm just wondering how to correctly manage it. If you have a polynomial in a multivariate ring, but your actual polynomial actually contains only one variable, you can get the corresponding univariate polynomial with .univariate_polynomial(). > I understand, but let's consider the problem I'm coming from: > indefinite integral. I'm not using polynomials because I'm well aware > of the implications, rather because I found resultant() implemented > there :) > What I intended with my sentences was: imagine a polynomial like: x^2 > + a^2. The solutions of x^2 - a^2 = 0 with respect to x over any field > wouldn't always coincide with +/- a? That is the kind of reasoning I > would make to solve the indefinite integral, like when I work with > symbolic variables that have a precise meaning (i.e. they are not > really variables in the problem, it's just that I want to keep that > degree of freedom with respect to the solution, especially if I want > to see the effect of that value over the solution) into my problem. I think it's going to be almost impossible to carry through the algorithm with parameters... it's definitely not where you should be starting :) Consider x^5-x-a. In general I don't know of a better description of the roots of this polynomial as a function of a than "the roots of x^5-x-a as a function of a" :) (And if you want the distinct roots, that's even worse. The number of distinct roots will depend on the values of the parameters. Fortunately it probably doesn't matter whether the roots are distinct, if you carefully adapt the algorithm...) >> > Finally, I still would like to know which is the best way to translate >> > the output of a calculation with polynomial rings into a symbolic >> > expression, that can be carried on with maxima or pynac. Can you help >> > me? >> >> If p is a polynomial, then SR(p) is a symbolic expression. >> > > Funny, the next minutes I spent, I recognized how to do that in this > same way :) By the way, is there a SR equivalent for the new pynac > symbolic? Something like NSR (new symbolic ring)? I can see that pynac > already has gcd implemented, although I can already (unfortunately) > see: > RuntimeError: gcd: arguments must be polynomials over the rationals There is an NSR, but it's not available on the command line by default; you can get it with: from sage.symbolic.ring import NSR Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: programming: define a new function
On Sat, Apr 18, 2009 at 2:46 PM, Maurizio wrote: > Could you be clearer? As I told, I'm not familiar with rings. I don't > even know the meaning of the argument of GF (I took the number 5 from > an example I see in sage-support group, I think). Do you think that QQ > [] could fit in this case? Moreover, what's the difference between QQ > and QQbar? GF(5) means the Galois field of characteristic 5, a.k.a. the integers modulo 5. (So in GF(5), you have 2*3 = 1, 3+4 = 2, etc.) It's probably quite irrelevant for computing integrals. QQ is the rational numbers (fractions). QQbar is the algebraic closure of QQ; this means it includes every complex number which is the root of a polynomial with rational coefficients. So it includes things like sqrt(2) (which is a root of x^2-2), and sqrt(-1) (a root of x^2+1), as well as more exotic numbers like the roots of x^5-x-1, which can't be expressed using radicals (roots). (QQbar does not include all complex numbers, though; for instance, it does not include pi or e, which are transcendental rather than algebraic.) > Now let's go to Carl's help... > >> Taking a quick look at that page, it looks like they want the exact >> roots in CC of a polynomial with algebraic coefficients. In Sage, we >> can get this with QQbar: >> >> sage: K. = QQbar[] >> sage: (x^5-x-1).roots(ring=QQbar) >> > > First problem with QQbar: it seems that resultant() doesn't like it, > because it is not able to convert it to a Singular ring (this is the > error, I'm not attaching all the output, tell me if you need it) > > TypeError: no conversion of this ring to a Singular ring defined Looks like this hasn't been implemented yet. > On the contrary, QQ[] seems to work fine with resultant (but it > doesn't have roots() ) Univariate polynomials over QQ definitely have roots(); were you using a multivariate polynomial ring? > Moreover, it seems that QQbar roots() is not working for multivariate > polynomials ring... is it true or am I just missing something else? In > that case, is possible to let it work in multivariate polynomials? As > you can imagine, I would like to think about this as a method of > solving integrals, so it is very likely to have a symbolic expression > with more than just a single symbolic variable. > > Apart from this, is there another way to solve an equation (with more > than a single symbolic variable) obtaining exact roots? It seems that > maxima would do the work (with algebraic numbers...), is it possible > that it is the only symbolic equation solver within SAGE? What about > SymPy or anything else? What does this even mean? .roots() gives a list of all the solutions of a univariate polynomial equation. But a multivariate polynomial equation will usually have an infinite number of solutions; for instance, x^2+y^2-1=0 has an infinite number of solutions over the rationals (or the reals, or the algebraic reals, etc.) If you have a system of multivariate polynomial equations, then the system might have only finitely many solutions. > Finally, I still would like to know which is the best way to translate > the output of a calculation with polynomial rings into a symbolic > expression, that can be carried on with maxima or pynac. Can you help > me? If p is a polynomial, then SR(p) is a symbolic expression. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Adding a trivial docstring confuses testing
On Sat, Apr 18, 2009 at 2:46 PM, William Stein wrote: > I posted a patch so that > > (1) doctests are ran in the same order as the file > (2) doctests can be run in random order > (3) doctests can be run in random order specified by a seed > > Carl, maybe you can referee it: > > http://trac.sagemath.org/sage_trac/ticket/5816 OK, what should happen now? I like the patch (except for the name of the command-line argument); but it can't be applied because it makes doctests fail. As far as I can tell, there are two options: 1) go through and fix all the broken doctests, and add new patches to #5816 for all of them 2) leave out the zero-padding from this patch, so that the default doctest order doesn't change. Then once all the broken doctests are eventually fixed, the zero-padding can be reinstated. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Adding a trivial docstring confuses testing
On Tue, Apr 14, 2009 at 11:57 AM, John H Palmieri wrote: > I figured out how to fix the problem, although I still don't know why > adding a docstring should cause it. > > To fix it: the docstring for "print_or_typeset" contains the lines ... Well, I can tell you why adding a docstring will cause the problem. The Sage doctest system works by translating files with Sage-style doctests into files with Python-style doctests and then running the Python doctest system. (You can see the translated file at $SAGE_ROOT/tmp/.doctest_latex.py .) During this translation, the doctests get named example_1 through example_NN (example_12 in our case). print_or_typeset ends up being example_9. Then the Python doctest system sorts the names ALPHABETICALLY, and runs them in this order: example_1 example_10 example_11 example_12 example_2 ... example_9 Adding a new doctest to a function near the beginning of the file bumps print_or_typeset from example_9 (where it is the last doctest to be run, so it doesn't affect any other doctests) to example_10 (where it is the second doctest to be run, and affects almost all the other doctests). Probably there should be a way to randomize the doctest order, so we can verify that it doesn't matter what order they are run in. I'll add that to my list of small Sage projects... Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: programming: define a new function
On Thu, Apr 16, 2009 at 3:43 PM, Maurizio wrote: > Finally, even assuming that I can get the right answer from this, > which is the recommended way to get the roots of an equation given by > a "univariate polynomials == 0"? This is supposed to be the next step > of the algorithm. Taking a quick look at that page, it looks like they want the exact roots in CC of a polynomial with algebraic coefficients. In Sage, we can get this with QQbar: sage: K. = QQbar[] sage: (x^5-x-1).roots(ring=QQbar) [(1.167303978261419?, 1), (-0.7648844336005847? - 0.3524715460317263?*I, 1), (-0.7648844336005847? + 0.3524715460317263?*I, 1), (0.181232698754? - 1.083954101317711?*I, 1), (0.181232698754? + 1.083954101317711?*I, 1)] (AFAIK, maxima can't do this; I don't think maxima can handle general algebraic numbers. Since Sage's solve() is implemented using maxima, solve() won't work for this problem.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: .subs(locals()) causes problems
On Thu, Apr 9, 2009 at 12:22 AM, Stan Schymanski wrote:
>
> Dear all,
>
> I encountered some mysterious problems earlier when I used .subs(locals
> ()), where some global variables such as pi and e were lost (see. e.g.
> thread
> http://groups.google.com/group/sage-support/browse_thread/thread/0f1086c43611242a?).
>
> Now I found an example that demonstrates this a bit better:
>
> sage: var('a b c blah')
> sage: varsdict = dict(blah = exp(b))
> sage: y = (1/blah*a - sin(pi*c)).subs(varsdict)
> sage: y.arguments()
> (a, b, c)
>
> But, doing the same thing using .subs(locals()) gives:
>
> sage: var('a b c')
> sage: blah = exp(b)
> sage: y = (1/blah*a - sin(pi*c)).subs(locals())
> sage: y.arguments()
> (a, b, c, e, pi)
>
> Here, sage suddenly seas e and pi as variables, which leads to all
> sorts of problems when using fast_float or simplifying, or plotting.
> The original behaviour is only restored after restarting the notebook!
> E.g. using the previous approach again now gives:
>
> sage: var('a b c blah')
> sage: varsdict = dict(blah = exp(b))
> sage: y = (1/blah*a - sin(pi*c)).subs(varsdict)
> sage: y.arguments()
> (a, b, c, e, pi)
>
> Shall I open a ticket for this or is it intended behaviour?
I have a guess as to what is going on. Perhaps it's using maxima to
do the substitution, and so it tells maxima that every local variable
name is actually a symbolic variable?
If this is the problem, I'm not sure how to fix it, though.
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Notebook problem with sympy
On Tue, Apr 7, 2009 at 12:16 PM, Brian Granger wrote:
>
> Ahh, that makes sense. It is the sympy.python thing that causes the
> problem. This hack seems to work fix the issue in the notebook:
>
> import sympy
> sympy.sage_python = sympy.python
> del sympy.python
> from sympy import *
>
> But any code in sympy that uses sympy.python will now fail. Really
> this is a bug in sage though.
That seems awfully complicated. How about (untested):
sage_python = python
from sympy import *
python = sage_python
or (even shorter, and still untested):
from sympy import *
restore('python')
The %whatever syntax in the notebook works by calling the function
"whatever" in the notebook process's current global scope. I actually
kind of like this design; it means you can easily add new handlers
(for instance, you could define a function in one notebook cell and
use it with the % syntax in the next cell).
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: approximation of pi bug
On Sun, Apr 5, 2009 at 12:33 AM, jeffblakeslee wrote: > > Here's how I got it. Ctrl-c after a couple seconds on the first one, > and then try the next. > -- > | SAGE Version 3.0.6, Release Date: 2008-07-30 | > | Type notebook() for the GUI, and license() for information. | > -- > > sage: pi.n(999) > ^C ... > sage: pi.n(999) Oh, interesting! I've always worried about _sig_on/_sig_off, but this is the first reproducible bug I've seen them cause. When Sage is computing pi to many digits (and in many other cases), it sets up a signal handler; if you press Control-C, then it will longjmp out of the signal handler. This lets you interrupt long-running computations, but it's a really nasty thing to do... you can easily get memory leaks, and I can imagine lots of (somewhat unlikely) situations where you would crash Sage or get wrong answers. I'm not sure what to do about the problem, though. The "right" fix is to go through all the C libraries that Sage calls, and add periodic checks for Control-C; but that's pretty impractical. Another possibility would be to disable _sig_on, so that Control-C doesn't work in long-running C computations. This would fix the bug, but it would also be vastly annoying. One workaround that might fix this particular problem is to catch KeyboardInterrupt exceptions in the .pi() method (and in .euler_constant(), .catalan_constant(), and .log2()), and call mpfr_free_cache() if one is seen. Hopefully then MPFR would no longer believe it has a higher precision value computed than it actually does have. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage's trac dead slow or completely unresponsive
On Sat, Apr 4, 2009 at 6:53 PM, mabshoff wrote: > > Hello folks, > > for the last couple hours Sage's trac has been very slow or completely > unresponsive. This is caused by the MS as well as Yahoo search engines > hammering the website (as can be seen by the proxy error log as well > as trac's log). It is non-obvious to me how to fix this, i.e. the > tracd does not support a robots.txt out of the box for example. Well, trac.sagemath.org claims to be served by apache; I'm guessing this means that apache is serving as a proxy? (You mentioned the "proxy error log".) Can apache be configured to serve its own robots.txt and proxy everything else? Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: approximation of pi bug
On Sat, Apr 4, 2009 at 11:55 AM, jeffblakeslee wrote: > > Hello, This looks like a bug. It seems that after 3316 bits of > precision > the approximation of pi just puts out 0's. This doesn't seem to > occur with the approximation of e. > > pi.n(3330) > 3.14159265358979323846264338327950288419716939937510582097 ... > 94175496324896812438964843750 This is exactly what I get if I do: sage: pi = pi.n(1000) sage: pi.n(3330) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pynac switch todo list
On Sun, Mar 29, 2009 at 4:13 PM, Rob Beezer wrote:
> So is the following *hypothetical* behavior not possible (or not
> desirable)?
>
> sage: preparse( 'differentiate(y^3, y)' )
> '_ = var("y"); differentiate(y**Integer(3), y)'
>
> If such a thing were indeed possible, I think it would make simple
> uses of Sage for calculus a whole lot easier for students.
I agree with William's response. In addition, I think it would be confusing if:
differentiate(y^3, y)
worked, but
expr = y^3
differentiate(expr, y)
failed.
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: syntax for creating symbolic functions
On Sun, Mar 29, 2009 at 5:27 AM, Burcin Erocal wrote: > * We raise an error whenever a function object is specified without > variables. > > Comments? +1 for raising an error. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: quick reference
On Sat, Mar 28, 2009 at 7:59 PM, William Stein wrote: > > Hi, > > I created a new 2-page Sage quick reference based on the one Peter > Jipsen made a while ago. > > http://sage.math.washington.edu/home/wstein/patches/quickref.pdf > > It's different than Peter's because it has some pictures and has > sections about graph theory, combinatorics, group theory, linear > algebra, number theory, etc. > > I would really like to know about any typos or mistakes. Very nice! The following isn't typos or mistakes, but rather suggestions for things it might be nice to add (if you can fit them in): change "insert text cell" to "insert text/HTML cell" Command line: mention *foo*? list command names containing "foo" 3D graphics: mention viewer='tachyon' Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: rich comparision for elements
On Sat, Mar 28, 2009 at 10:50 AM, Martin Raum wrote: > Are you aware of any discussion about what should be comparable? > Otherwise I will work our something and post it to Trac. I think this > is the way to do it, isn't it? People have specifically complained about the complex numbers and number fields being ordered. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Custom inline operators in python
On Sat, Mar 28, 2009 at 10:37 AM, Florent Hivert wrote: > I also like the following one because it has a very high precedence and also > because it reminds XML tags > > [1,2,3] [1,2,3] That one is nice; it's very pretty. Unfortunately, it doesn't work with the same implementation, because "A B" is equivalent to "(AB)". (It could probably work with the original implementation, that stored A inside the global foo; but that doesn't work with (A (B C)). Maybe it could work if foo had a stack, where AB popped a value off the stack. That seems like it's getting fairly fragile, though.) (BTW, I think you mean "very low precedence".) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Custom inline operators in python
On Sat, Mar 28, 2009 at 5:28 AM, Jason Grout wrote: > Aha, the one custom infix operator that I know of in Sage. > > In the backslash operator and in the article posted, the rmul only > stored the argument and the __mul__ only performed the operation. Are > you always guaranteed that __rmul__ will be called right before __mul__ > for the same invocation of the operation? Hmm... probably not. Consider A *emul* (B *emul* C) Since multiplication is left-associative, this is: (A*emul)*((B*emul)*C) This is probably (I don't know if Python guarantees left-to-right evaluation, but I'm guessing it does) evaluated in this order: t1 = A*emul t2 = B*emul t3 = t2*C t4 = t1*t3 So for safe general-purpose use, A*emul needs to return a new object. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Python Performance Improvement
On Fri, Mar 27, 2009 at 4:35 PM, Bill Hart wrote: > > Not to press the point, but isn't: > > "Our long-term proposal is to replace CPython's custom virtual machine > with a JIT built on top of LLVM, while leaving the rest of the Python > runtime relatively intact." > > the explanation of how they propose to get some speed out of it. In > other words they are using a technologically superior method of > interpreter operation. I'm interested to know if you have an opinion > on that. Well, just reading that paragraph isn't enough... replacing ceval.c with an LLVM-based JIT in a straightforward way should be more-or-less equivalent to Cython's performance on pure-Python code (that is, the speedup is much less than 2x). You really need type information to do much better; fortunately, they do plan to use type information (either using type annotations, or by guessing that the types will likely be the same every time the code is executed). I'm pretty sure that Javascript implementations have speed up by more than 5x in the last year; IMHO similar speedups should be possible for Python. (Whether this is possible while remaining 100% compatible with current Python source and extension modules is another question.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.0
On Wed, Mar 25, 2009 at 10:13 PM, William Stein wrote: > 3. I would also like to see the default symbolics switch from > maxima-based to pynac, which would I think really clearly justify the > switch to 4.0, since it will have a *dramatic* impact on the usability > of Sage by many users (the speedup over maxima-based symbolics for > basic arithmetic is "orders of magnitude"). What's involved here? Is there a checklist somewhere of things that have to be fixed before the switch can happen? Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ambiguous binomial
On Wed, Mar 25, 2009 at 4:42 PM, Dan Drake wrote: > On Wed, 25 Mar 2009 at 03:05PM -0700, Henryk Trappmann wrote: >> I just encountered the ambiguouty: >> >> binomial(-1.0,2) == 1.0 >> binomial(-1,2) == 0 >> >> do we need 2 diferent names? I think the second form is also needed >> somewhere. >> But of course one needs the first form also for integers. > > This has been fixed in http://trac.sagemath.org/sage_trac/ticket/5589. > It's a trivial patch, which needs review. Any volunteers? I just gave this a positive review. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: plot float arguments
On Sun, Mar 22, 2009 at 3:55 AM, Henryk Trappmann wrote: > > Another evil example: > parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2), > (-1000,1000)) > > It seems that the plot algorithm is somehow deficient in those cases. In both cases, it's plotting points approximately evenly spaced throughout the given range; since the functions being plotted are very nonlinear, this gives bad results here. You can use marker= to see what's going on: parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-1000,1000),marker='.') You can get a nicer plot by either increasing the plot_points, or decreasing the range: parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-1000,1000),marker='.', plot_points=1) parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),(-10,10),marker='.') Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE possible improvement
On Thu, Mar 19, 2009 at 3:45 PM, Maurizio wrote:
> For example, how does SAGE generate an instance of
> "sage.rings.integer.Integer"? I hope this can help me.
Well, I can at least answer this question. When you type at the sage:
prompt, or in the notebook, the input is run through the "preparser";
this transforms the input from Sage's extended Python syntax into
standard Python.
You can see what it does using the preparse function:
sage: preparse('3')
'Integer(3)'
sage: preparse('3.14159')
"RealNumber('3.14159')"
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: local html documentation missing trailing /index.html
On Wed, Mar 18, 2009 at 11:40 PM, Jan Groenewald wrote: > > Hi > > I did sage -docbuild all html to provide local > documentation on each of 100 PCs on which I image > from a central server. It is a nice way to provide > a lab in a low-bandwidth environment with > sage and sage docs locally. > > The docs are viewed via a browser to > file:usr/local/src/sage-3.4/devel/sage/doc/output/html/en/index.html > not via a web server. It looks just like this: > http://www.sagemath.org/doc/ > > I edited above file to add a trailing /index.html to each of the > eight links to separate sections, else the browser goes to a directory > listing instead of to index.html. Perhaps this can be patched. > It seems at all lower levels there are not so many or any nested > directories which cause this problem. This is http://trac.sagemath.org/sage_trac/ticket/5550 Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: what TeX macros should be available for docstrings? [was Re: LaTeX in docstrings]
On Wed, Mar 18, 2009 at 6:28 PM, John H Palmieri wrote:
> This is a very interesting idea, and I think I can do it for ZZ,
> QQbar, etc., but I don't know how to deal with GF(p). That is, in
> docstrings, you presumably want GF(p) to appear as is, while to
> evaluate latex(GF(p)), indeed to evaluate GF(p), p has to be an actual
> integer. Any ideas how to use the _latex_ method for GF() to typeset
> 'GF(p)' for p a variable or a string?
Well, it's a bit of a hack, but this works:
sage: latex(GF(2^5, 'a')).replace('2', 'p').replace('5', 'k')
'\\mathbf{F}_{p^{k}}'
Of course, just hardcoding \mathbf{F}_{p^k} also works, and is much simpler :)
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: completing the doc changeover
On Wed, Mar 18, 2009 at 5:35 AM, John Cremona > Therefore (if I am right) there needs to be a planned procedure for > completing the ReSTification of Sage. For a start, is there anywhere > a list showing which files have not yet been converted? You can generate such a list for yourself, using sage -docbuild reference print_unincluded_modules (sage -docbuild -help explains all the sage -docbuild options). Currently my version of Sage is at: $ ./sage -docbuild reference print_unincluded_modules | wc 614 614 19055 (with some patches applied; official Sage 3.4 probably has slightly different numbers). Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: what TeX macros should be available for docstrings? [was Re: LaTeX in docstrings]
On Tue, Mar 17, 2009 at 4:46 PM, William Stein wrote: > > On Tue, Mar 17, 2009 at 4:41 PM, John H Palmieri > wrote: >> So I think it's easy to implement TeX macros into Sage: see > trac.sagemath.org/sage_trac/ticket/>. What macros should we >> implement? I have \ZZ, \CC, \RR, and \QQ so far. The file $SAGE_ROOT/ >> devel/sage/doc/common/macros.tex has lots of other choices, way too >> many I think. If we can settle on a good selection, I will modify the >> ticket to add them. >> > > Could we have a macro for every shortcut ring name in sage/rings/all.py? > E.g. QQbar, CDF, etc.? What would CDF render as? When would you use the macro? Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: LaTeX in docstrings
On Tue, Mar 17, 2009 at 11:55 AM, John H Palmieri wrote: > Well, I've been trying to modify 'latex_preamble' in sage/doc/common/ > conf.py, and I'm having no luck at all: no changes I make have any > effect. It seems like a good place to put a few macros (like \ZZ), but > maybe that variable isn't used either? I modified latex_preamble, did "sage -docbuild a_tour_of_sage latex", and the changes I made showed up in doc/output/latex/en/a_tour_of_sage/a_tour_of_sage.tex. (I picked a_tour_of_sage because it's the smallest document, so presumably the fastest to play with.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: aftermath of Sage Days 14 (was: hyperelliptic curve constructor)
On Tue, Mar 17, 2009 at 11:28 AM, Justin Walker wrote: > > > On Mar 17, 2009, at 10:07 AM, Nicolas M. Thiery wrote: >> Just a mini-warning so that we don't stomp on each other's foot: I >> made a couple very minor changes in the schemes code for the >> categories (essentially in the parent's constructors/import lists). I >> also moved the corresponding categories in separate files. You may >> want to double check categories-nt.patch on >> combinat.sagemath.org/patches/. > > I don't see 'categories-nt.patch' there. Click on "browse", which will take you (currently) to http://combinat.sagemath.org/hgwebdir.cgi/patches/file/c0de6498fbf7 (this URL will change every time somebody makes a commit to that repository). Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: LaTeX in docstrings
On Tue, Mar 17, 2009 at 11:10 AM, John H Palmieri wrote: > I think \ZZ is a good option, too. Does anyone know if the file > $SAGE_ROOT/devel/sage/doc/common/macros.tex has any role, currently? I'm pretty sure it doesn't. (I searched through the whole sage/doc tree for the word "macros", and it looks like nothing in that tree refers to that file at all.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: LaTeX in docstrings
On Tue, Mar 17, 2009 at 9:59 AM, Martin Albrecht
wrote:
>
> On Tuesday 17 March 2009, Carl Witty wrote:
>> My vote would be for `H_d(X, \ZZ)` (for easier typing), combined with
>> some sort of LaTeX-to-plain-text processing to change \ZZ to Z or ZZ
>> (I'm not sure which). (We have some LaTeX-to-plain-text already,
>> although it could definitely be improved.)
>
> Can't we just define a global macro like before?
>
> e.g. \newcommands{\ZZ}{\mathbb{ZZ}}
>
> ?
I was only talking about the LaTeX-to-plain-text for command-line help
('?' help at the sage: prompt).
For other purposes (the HTML and PDF documentation) we would use a
global macro, although I'm not sure if there's a place to put global
macros in the current process; we may need to adjust the build process
some.
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: LaTeX in docstrings
On Tue, Mar 17, 2009 at 9:35 AM, John H Palmieri wrote:
>
> Do we have any conventions or standards for the use of LaTeX in
> docstrings? Consider this:
>
> r"""
> This computes the integral homology `H_d(X, ZZ)` of `X` in
> dimension `d`.
> """
>
> versus
>
> r"""
> This computes the integral homology `H_d(X, \mathbb{Z})` of `X` in
> dimension `d`.
> """
>
> (or with \mathbf{Z} instead of \mathbb{Z}). The first of these looks
> better with interactive help ('sage: homology?'), and the second looks
> better in the reference manual. So which should we use? Should we
> have a style guide which settles such issues?
My vote would be for `H_d(X, \ZZ)` (for easier typing), combined with
some sort of LaTeX-to-plain-text processing to change \ZZ to Z or ZZ
(I'm not sure which). (We have some LaTeX-to-plain-text already,
although it could definitely be improved.)
This also requires that we fix things so that jsmath knows about the
macros we use, where we use jsmath. (According to the jsmath
documentation, this shouldn't be hard; there are several ways to do
it.)
And yes, we should definitely have a style guide.
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Introduction with Time
On Mon, Mar 16, 2009 at 9:58 PM, J Elaych wrote: > Also, I built sage-3.4 from source on 64bit Ubuntu 8.10 AMD XP2 with > 'export MAKE=make -j2' and I have to say that you folks have done an > amazing job in that it all just built. Not so lucky with some 'sage - > i' commands, but the problem was that I hadn't installed python-dev > (!), so my bad. After I fixed that, all of the 'sage -i's that I've > tried have worked flawlessly. Interesting. Which packages were these? Sage includes its own copy of Python and is not supposed to interact with the system Python at all, so this is surprising, and probably a bug. For example, such packages might not work on OSX, where, IIRC, Sage's python is not ABI-compatible to the system Python. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: deprecating calling of symbolic expressions without variable names
On Mon, Mar 16, 2009 at 11:51 AM, Joel B. Mohler wrote: > > On Monday 16 March 2009 12:27:10 pm kcrisman wrote: >> sage: integrate(y^2) >> --- >> TypeError Traceback (most recent call >> last) >> TypeError: cannot coerce type '> 'sage.symbolic.expression.Expression'>' into a SymbolicExpression. >> >> Of course, the current error is because we haven't done the switch to >> Pynac for everything yet. Why this would not still be valid input (to >> echo Ronan) after the switch is mystifying to me - again, or perhaps I >> have misinterpreted the deprecation proposal. > > Here's my reason for wanting it deprecated. It's fragile in the face of > unexpected input (I don't like being lulled into a false sense that my code > works when suddenly it wouldn't work for a constant input): > > sage: f=x > sage: # many lines of code > sage: integrate(f) > x^2/2 > > sage: f=1 > sage: # many lines of code > sage: integrate(f) # what does this mean? > ... hangs maxima ... > sage: integrate(f,x) # what does this mean? This seems like an excellent reason to deprecate integrate(SYMBOLIC_EXPR), and I would vote in favor of doing so, but my patch won't do it. (My patch is about deprecating __call__, and things that invoke __call__ or the equivalent; symbolic integration doesn't call the expression.) Note that plot(1, (5, 7)) and numerical_integral(1, (5, 7)) don't have the same problem, and I'm currently not planning to deprecate them. (It's not always entirely clear who was agreeing to what proposal, but I get the impression that this is a compromise everybody can live with.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
