Re: [sage-devel] ticket #12068 : normalizing rational expressions
On Friday, April 27, 2012 11:31:55 PM UTC-4, David Roe wrote: So we need an updated GiNaC spkg? I think that is the fundamental solution. The current pynac spkg forked off of GiNaC 1.4.x, which is now 4 years old. However, as of 18 months ago, Burcin didn't think this bug warranted the effort that it would take to make a pynac spkg that forked off a recent GiNaC. In the 1.5.x series, GiNaC added a new polynomials/ subdirectory. So, it is possible that this bug could be fixed by creating a new pynac spkg that -- Dropped that (hopefully self-contained) polynomials/ directory into pynac -- Overwrote pynac's normal.cpp with GiNaC's 1.6.x normal.cpp, which differs primarily in that it adds a #include polynomial/chinrem_gcd.h and adjusts the gcd() functions in normal.cpp accordingly. I did try to do that myself, but the pynac spkg is so old that you can't even roll up the *existing* pynac spkg with sage 4.8 goodrich@CYBERPOWERPC:/opt/sage-4.8$ ./sage --pkg /tmp/sage_patches/pynac-0.2.2/ Creating Sage package /tmp/sage_patches/pynac-0.2.2/ Traceback (most recent call last): File /opt/sage-4.8/local/bin/sage-pkg, line 131, in module main() File /opt/sage-4.8/local/bin/sage-pkg, line 81, in main tar_file(dir, no_compress = options.no_compress) File /opt/sage-4.8/local/bin/sage-pkg, line 37, in tar_file tar.add(dir, exclude=lambda f: f == .DS_Store) File /opt/sage-4.8/local/lib/python/tarfile.py, line 1966, in add tarinfo = self.gettarinfo(name, arcname) File /opt/sage-4.8/local/lib/python/tarfile.py, line 1835, in gettarinfo statres = os.lstat(name) OSError: [Errno 2] No such file or directory: 'pynac-0.2.2' goodrich@CYBERPOWERPC:/opt/sage-4.8$ ls /tmp/sage_patches/pynac-0.2.2/ spkg-install SPKG.txt src So, I wasn't able to test my theory. Is there someone who knows more about the internals of spkg's that could help? The link for pynac is http://pynac.sagemath.org/ GiNaC has a git repository git://www.ginac.de/ginac.git If nothing else can you wrap the call to GiNaC with a sig_on() / sig_off() so that you can Ctl-C? That was brought up when sig_on() / sig_off() were first being introduced to sage. I don't recall if I tried that and it didn't help or if I didn't actually try that, but I think I would recall if I tried it and it allowed me to interrupt. Thanks, Ben -- 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] ticket #12068 : normalizing rational expressions
Hi,
The patches attached to ticket #12068 (Numerator for symbolic expression
shouldn't use maxima) were applied to sage-5.0.beta, which I was happy to
see because I had tried to do something similar (#10268, which can probably
be closed) to use GiNaC's normal() function for rational expressions
instead of the corresponding Maxima function. However, my version was
stalled by a GCD bug (#10284) that was fixed in GiNaC but not in sage.
Basically, when normal() is called it puts expressions under a common
denominator and then tries to cancel the greatest common factor, which can
cause sage to hang. Alas, the same issue arises when the patches on #12068
are applied:
sage: a = var('a')
sage: b = var('b')
sage: c = var('c')
sage: x = 4*(b^2 + 1)^2*(2*a^4*b*c^2 + a^3*b^2*c^2 - 2*a^4*b + a^3*b^2 -
a^3*c^2 - a*b^2*c^2 - a^3 - a*b^2 + a*c^2 + 2*b*c^2 + a - 2*b)^2/((c^2 +
1)^2*((3*a^4 + 2*a^2 + 3)*b^4 + 3*a^4 + 2*(a^4 - 2*a^2 + 1)*b^2 + 2*a^2 +
3)^2) + 4*(a^2 + 1)^2*(a^2*b^3*c^2 + 2*a*b^4*c^2 - a^2*b^3 - a^2*b*c^2 +
2*a*b^4 - b^3*c^2 + a^2*b + 2*a*c^2 + b^3 + b*c^2 + 2*a - b)^2/((c^2 +
1)^2*((3*a^4 + 2*a^2 + 3)*b^4 + 3*a^4 + 2*(a^4 - 2*a^2 + 1)*b^2 + 2*a^2 +
3)^2) + 4*(a^4*b^3*c^2 - a^3*b^4*c^2 - a^4*b^3 - a^4*b*c^2 - a^3*b^4 -
2*a^3*b^2*c^2 + 2*a^2*b^3*c^2 + a*b^4*c^2 + a^4*b - 2*a^3*b^2 - a^3*c^2 -
2*a^2*b^3 - 2*a^2*b*c^2 + a*b^4 + 2*a*b^2*c^2 + b^3*c^2 - a^3 + 2*a^2*b +
2*a*b^2 + a*c^2 - b^3 - b*c^2 + a + b)^2/((c^2 + 1)^2*((3*a^4 + 2*a^2 +
3)*b^4 + 3*a^4 + 2*(a^4 - 2*a^2 + 1)*b^2 + 2*a^2 + 3)^2)
sage: x.simplify_rational() # less than 1 second
8*(a^2*b^4 + (a^2*b^4 + (a^3 - a)*b^3 + (a^4 + 1)*b^2 - (a^3 - a)*b +
a^2)*c^4 - (a^3 - a)*b^3 + (a^4 + 1)*b^2 + 2*(a^2*b^4 - (a^4 + 1)*b^2 +
a^2)*c^2 + (a^3 - a)*b + a^2)/((3*a^4 + 2*a^2 + 3)*b^4 + ((3*a^4 + 2*a^2 +
3)*b^4 + 3*a^4 + 2*(a^4 - 2*a^2 + 1)*b^2 + 2*a^2 + 3)*c^4 + 3*a^4 + 2*(a^4
- 2*a^2 + 1)*b^2 + 2*((3*a^4 + 2*a^2 + 3)*b^4 + 3*a^4 + 2*(a^4 - 2*a^2 +
1)*b^2 + 2*a^2 + 3)*c^2 + 2*a^2 + 3)
sage:
sage: x.normalize() # hang in infinite loop
So, does anyone have any ideas about how to proceed. Using GiNaC's normal()
is very useful, but it is hard to know in advance when it will hang and
when it does you have to kill your sage session.
Thanks,
Ben
--
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: simplify_rational and Pynac
On Nov 13, 9:45 pm, kcrisman kcris...@gmail.com wrote: That's a little orthogonal to your main question, which I should know the answer to, but have forgotten off hand. Might this be in sage/ libs/ginac/ ? Thanks for the tip, which seems to have worked. I opened a ticket (10268), attached my patch, and uploaded a benchmark. The new GiNaC option is about 10x faster than the default. It would be interesting to benchmark it again when Maxima can be used as a library. Then again, my benchmark was not too clever. Is there something else out there that I should analyze? Thanks, Ben -- 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: simplify_rational and Pynac
On Nov 15, 10:56 am, Ben Goodrich goodrich@gmail.com wrote: Thanks for the tip, which seems to have worked. I opened a ticket (10268), attached my patch, and uploaded a benchmark. Now I have a un-minimal example of using GiNaC's normal function that finishes in about 1 minute when done directly in the GiNaC shell. But doing it via patched sage / Pynac is taking hours and still not finishing. Can someone try my patch and help me figure out why there is such a disparity? Everything is attached at http://trac.sagemath.org/sage_trac/ticket/10268 Thanks, Ben -- 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] simplify_rational and Pynac
Hi, The simplify_rational method has three choices for Maxima functions, but I wanted to try GiNaC's normal method described here http://www.ginac.de/tutorial/Rational-expressions.html#Rational-expressions to see if it was faster. Has someone already tried this and concluded Maxima was better? I see that there is an expand_rational method in sage that uses Pynac whose main part is just _sig_on cdef GEx x = self_.gobj.expand(0) _sig_off return new_Expression_from_GEx(self._parent, x) So I guess I would need to copy those lines and change .expand(0) to .normal(). But how do I add the .normal() method to Pynac's table of eligible GiNaC functions? Thanks, Ben -- 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: libpari segfault related to 64bit?
On Oct 15, 3:48 am, Jan Groenewald j...@aims.ac.za wrote: Can some people on 32bit and 64bit and different CPUs (amd as well) send in the output of 64bit Debian here, no problem goodr...@y560:/media/disk30/sage-4.6.alpha3$ grep name /proc/cpuinfo model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz goodr...@y560:/media/disk30/sage-4.6.alpha3$ uname -a Linux Y560 2.6.35-7.slh.1-aptosid-amd64 #1 SMP PREEMPT Wed Sep 29 02:30:35 UTC 2010 x86_64 GNU/Linux goodr...@y560:/media/disk30/sage-4.6.alpha3$ ./sage -v | Sage Version 4.6.alpha3, Release Date: 2010-10-08 | * Warning: this is a prerelease version, and it may be unstable. * goodr...@y560:/media/disk30/sage-4.6.alpha3$ ./sage -t devel/sage/sage/ interfaces/sage0.py sage -t devel/sage/sage/interfaces/ sage0.py [26.3 s] -- All tests passed! Total time for all tests: 26.5 seconds goodr...@y560:/media/disk30/sage-4.6.alpha3$ dmesg | grep pari [167793.880983] ACPI: Preparing to enter system sleep state S3 [201102.253580] ACPI: Preparing to enter system sleep state S3 [253592.296030] ACPI: Preparing to enter system sleep state S3 [254532.778486] ACPI: Preparing to enter system sleep state S3 goodr...@y560:/media/disk30/sage-4.6.alpha3$ Ben -- 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: How can this be avoided in future?
On Jun 12, 8:09 am, David Kirkby david.kir...@onetel.net wrote:
kir...@sage:~$ /usr/local/bin/sage
--
| Sage Version 4.4.3, Release Date: 2010-06-04 |
| Type notebook() for the GUI, and license() for information. |
--
sage: r.library('tools')
sage: r.testInstalledBasic(basic)
Error: object 'sage1' not found
sage: r.testInstalledBasic('basic')
Error: object 'sage2' not found
sage:
Ok. I get the same behavior. But once tools is loaded then the desired
functions are visible, i.e.
sage: r.testTAB
r.testInheritedMethods r.testInstalledBasic
r.testInstalledPackage r.testInstalledPackages
r.testPlatformEquivalence r.testVirtual
So, the fact that it does not work seems to be some other bug. My
guess is that the bug would be on entry because
sage: r.testInstalledBasic(basic)
Error: object 'sage9' not found
sage: r.traceback()
NULL
indicates that there is nothing in R's error stack.
Ben
--
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: How can this be avoided in future?
On Jun 12, 9:07 am, kcrisman kcris...@gmail.com wrote:
1) Get a list of recommended packages from that version of R -
preferably in a way that does not require them to be hard-coded in a
test script, but generated by R.
Unfortunately, I couldn't find one when I was looking for it. It might
be worth asking the R list whether there is something like this that
does not require Internet (which, after all, should not be a
requirement for building Sage once one actually has a Sage copy), nor
parsing some huge list of *all* packages.
The shell script could parse the directory where the Recommended
packages live by calling (from the root of the R directory)
ls src/library/Recommended/*.tar.gz
src/library/Recommended/boot_1.2-42.tar.gzsrc/library/
Recommended/Matrix_0.999375-38.tar.gz
src/library/Recommended/class_7.3-2.tar.gzsrc/library/
Recommended/mgcv_1.6-2.tar.gz
src/library/Recommended/cluster_1.12.3.tar.gz src/library/
Recommended/nlme_3.1-96.tar.gz
src/library/Recommended/codetools_0.2-2.tar.gzsrc/library/
Recommended/nnet_7.3-1.tar.gz
src/library/Recommended/foreign_0.8-40.tar.gz src/library/
Recommended/rpart_3.1-46.tar.gz
src/library/Recommended/KernSmooth_2.23-3.tar.gz src/library/
Recommended/spatial_7.3-2.tar.gz
src/library/Recommended/lattice_0.18-5.tar.gz src/library/
Recommended/survival_2.35-8.tar.gz
src/library/Recommended/MASS_7.3-5.tar.gz
Ben's way of testing them should work
(seehttp://cran.r-project.org/doc/manuals/R-admin.html,
and he is right that library('tools') is needed), but I don't know how
to get a shell script like spkg-check to run these commands in R, or
anything else. Of course, this would do a lot more than check their
presence, and would be more or less like running spkg-check, I guess.
If the commands can be put into a .R file, then spkg-check can just
run that file, e.g.
R --no-save myFile.R myOutput.txt
If something dynamic needs to be done then something like
echo thisFunctionDoesNotExist(); norThisOne() | R --no-save
would work, and by work I mean fail in this case.
There are some other ways too.
Ben
--
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: How can this be avoided in future?
On Jun 12, 6:38 am, David Kirkby david.kir...@onetel.net wrote: On 12 June 2010 04:06, Ben Goodrich goodrich@gmail.com wrote: If the goal were to test that the R functions in these packages are working correctly, that is documented at http://cran.r-project.org/doc/manuals/R-admin.html#Testing-a-Unix-Ins... In particular, one might want to call library(tools) That takes only 30 ms on sage.math, and 140 ms on my old SPARC, but generates no error on my broken Solaris installation. testInstalledBasic(basic) How could I call that from Sage? On sage.math I get: sage: r.testInstalledBasic(basic) Error: object 'sage2' not found t Plane about to take off. Cannot check for sure. I think you need to load the tools library first. Then you should see the test* functions from Sage. Ben The only 'test' related things in Sage with R seem to be r.testInheritedMethods r.testVirtual r.testPlatformEquivalence which would probably take less than a minute on decent hardware. That link also explains how to run every example in every Recommended package, but that would take a lot longer. Ben Dave -- 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: How can this be avoided in future?
I know nothing about Solaris or what might be causing this problem, but if you put these two lines into a script called TestPackages.R packages - rownames(installed.packages()) for(i in seq_along(packages)) stopifnot(require(packages[i], character.only = TRUE)) and then put something like R --vanilla TestPackages.R TestOutput.txt at the end of the shell script that installs R, it will fail if any installed R package fails to load properly and something informative will be written to TestOutput.txt . Ben -- 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: How can this be avoided in future?
On Jun 11, 3:56 pm, Ben Goodrich goodrich@gmail.com wrote: I know nothing about Solaris or what might be causing this problem, but if you put these two lines into a script called TestPackages.R packages - rownames(installed.packages()) for(i in seq_along(packages)) stopifnot(require(packages[i], character.only = TRUE)) and then put something like R --vanilla TestPackages.R TestOutput.txt at the end of the shell script that installs R, it will fail if any installed R package fails to load properly and something informative will be written to TestOutput.txt . Ben Upon reading the ticket more closely, it seems that maybe the problem is that some packages are not even installed correctly, in which case the above would be insufficient because it only tests correctly installed packages. So, if you know that the Recommended R packages (and perhaps some others) are supposed to be installed with Sage, then you could hardcode those in the TestPackages.R script. packages - c(Matrix, grid) # add more packages as necessary for(i in seq_along(packages)) stopifnot(require(packages[i], character.only = TRUE) Ben -- 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: How can this be avoided in future?
On Jun 11, 5:29 pm, Dr. David Kirkby david.kir...@onetel.net wrote: Given actually reading in these 6 libraries takes very little time, it would not seem unreasonable to me to make a test that they actually import properly part of the normal doctests that people run each time people test Sage. Any reoccurring problem is far more likely to be found there, than by setting SAGE_CHECK=yes, where its simply not practical to run that on the SPARC hardware we have available. Building on 't2' already takes over 24 hours, though that should be reduced dramatically soon. If reading such a library took a long time, I could see a more reasoned argument for not doing so. But even on my 10 year old workstation, it does not take long to load an R library. Dave I believe there are 15 recommended R packages (plus base) currently, [1] boot class clustercodetools foreign [6] KernSmooth latticeMASS Matrix mgcv [11] nlme nnet rpart spatialsurvival but a loop that loads each one would still only take a few seconds. Ben -- 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: How can this be avoided in future?
If the goal were to test that the R functions in these packages are working correctly, that is documented at http://cran.r-project.org/doc/manuals/R-admin.html#Testing-a-Unix-Installation In particular, one might want to call library(tools) testInstalledBasic(basic) which would probably take less than a minute on decent hardware. That link also explains how to run every example in every Recommended package, but that would take a lot longer. Ben -- 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: Debian package...
On Mar 6, 9:59 am, Dima Pasechnik dimp...@gmail.com wrote: well, this is trickier than you think. E.g. Python 2.6 has not made it into Debian stable yet. And installing Python 2.6 on Debian stable using the standard Debian source package installation mechanisms does not work. Python is needed for functioning of many other system components on Debian, meaning that you just cannot just have a system-wide Python 2.6 on a Debian stable... Dmitrii That is true and if I understand correctly Python 2.6 is not even going to be available in the *next* stable release. But neither would Debian allow the sagemath package to embed a different version of Python (or anything else) in a stable release. So having a useful sagemath in the Debian stable repository seems like an impossible goal for now. At the moment, we are stuck with sagemath 3.0.5 in unstable and that is on the verge of being asked to be removed. So, I wish that something could be done to facilitate getting a more recent version of sage into unstable or experimental. That would also be the relevant consideration for Ubuntu releases. Ben -- 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: Debian package...
On Mar 6, 3:37 pm, ma...@mendelu.cz ma...@mendelu.cz wrote: I think, it does not have too much sense to have Debian package. It would be better to put compiled Debian binaries to sagemath.org download page. Cheers, Robert Marik I agree that compiling sage is not too difficult, and I actually use one of the Ubuntu binaries on a Debian machine, which seems to work fine. But is your argument specific to Debian / Ubuntu? It seems to me that either it is worthwhile to try to package sage for popular distros or it is better to tell everyone to get the appropriate binary from the sage website only. I can see arguments both ways, but I agree that it is not good to have a broken sagemath in the Debian repository without a realistic possibility of being able to package a newer version. Ben -- 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: Debian package...
In the past, Tim Abbott asked to be cc'ed on threads like these. I think his primary difficulty is keeping up with all the dependencies of sage, especially when sage releases with a patched version of a dependency that has not made it upstream yet. Debian package maintainers are unlikely to quickly apply such patches for the unstable or testing branch, although they might for the experimental branch. Earlier there was some discussion of creating an environmental variable that would attempt to build sage with system versions of the libraries and other dependencies, rather than the versions shipped with sage. Did anything come of that? Ben -- 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: Debian package...
On Mar 5, 8:35 pm, François Bissey f.r.bis...@massey.ac.nz wrote: Earlier there was some discussion of creating an environmental variable that would attempt to build sage with system versions of the libraries and other dependencies, rather than the versions shipped with sage. Did anything come of that? Nothing came out of that, but it would be useful to us packagers. There are things to carefully consider. Time as always is the biggest obstacle to anything like that. Francois +1 to more consideration, although I don't have much to contribute. One thing I do think is that if sage is packaged for distributions, the target audience for those binaries is probably not the people who are doing cutting-edge mathematical research. So if a dependency has a bug, certainly the patch should try to go upstream ASAP, but a lot of people in the target audience wouldn't be affected by that bug, even though for some people the bug breaks a needed feature or possibly produces wrong results. If people are doing really important stuff, then they can get the latest sage from sage's website. Ben -- 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: Debian package...
On Mar 5, 11:27 pm, Dr. David Kirkby david.kir...@onetel.net wrote: I suspect the Debian people are reasonable and could be persuaded to accept things if there were aware of just how many patches have needed to be made to 'standard' packages. They are reasonable. My guess is they would usually email upstream to ask about a patch and if upstream agrees but isn't planning to release for a while, then the maintainers might well apply it, particularly in experimental. But all that would take time and may have to be coordinated across several package maintainers. That is why I agree with you about having an option to build sage with reasonably up-to- date versions of system libraries and dependencies. I think that would probably be the biggest thing that could be done to make life easier on Tim and the other package maintainers. Also, with Debian in particular, when they freeze the testing branch to start preparing it for the stable release, there is going to be extra reluctance to take new patches, often even for the unstable branch. The maintainers just devote all their energy toward stabilizing and other things get backlogged. Being Debian, freezes have been known to last a long time. Ben -- 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: iconv - has a circular dependency of gettext
If I am interpreting it correctly, I believe the first sentence of http://cran.r-project.org/doc/manuals/R-admin.html#Useful-libraries-and-programs implies that the R source includes a minimal version of gettext that would be sufficient as long as one is not interested in doing new translations. -- 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: Build logs
On Nov 27, 12:50 pm, William Stein wst...@gmail.com wrote: I wonder what Gentoo, Debian, etc., do? Do they do anything, or just leave the output of logging to the user. William Do you mean this? https://buildd.debian.org/pkg.cgi?pkg=sagemath -- 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: Nelder-Mead Simplices Algorithm for Minimization.
On Jun 16, 11:44 am, Prof. Gregory V. Bard b...@fordham.edu wrote: I'm working on a very fast implementation of the Nelder-Mead algorithm for optimizing functions. This is a particularly good algorithm if the function is noisy, or is not smooth. Is it in SAGE already? R (which is included in Sage) also has a C-based optimizer (optim) for double-precision parameters where a Nelder-Mead algorithm is the default, but if your approach is better or more general, then I am sure it would be welcome for all sorts of open source projects. --~--~-~--~~~---~--~~ 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: 2d math input
On May 22, 1:52 pm, Serge A. Salamanka salsa-...@tut.by wrote: It will be great to enable Sage with 2D input. Any ideas how to do this ? #Serge R has 2D input for numerics or characters that conceivably could be wrapped and parsed by Sage. Still ugly though. Ben --~--~-~--~~~---~--~~ 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
On Apr 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: On Thu, 23 Apr 2009, Jason Grout wrote: Jqueryui can actually be updated to the latest release, which is later than the svn version shipping with Sage, so that shouldn't be a problem. Matplotlib should be releasing a new version Real Soon Now, and then can be upgraded. Currently, we use some features from SVN that are not available in the latest release (arrow drawing stuff). We also ship an SVN version of scipy. Before a couple of months ago, everyone did, though (I think even debian), since it hadn't had a release in a very long time. We should upgrade to the latest release of scipy now, though. If people have time to do these updates before the Sage 4.0 release, I would be grateful. -Tim Abbott On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Ben --~--~-~--~~~---~--~~ 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
On Apr 24, 5:20 pm, mabshoff mabsh...@googlemail.com wrote: On Apr 24, 2:12 pm, Ben Goodrich goodrich@gmail.com wrote: On Apr 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: SNIP Hi Ben, On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Sure. In general anything in Debian stable one day will be woefully out of date by the time the freeze in Debian is over. I think the only viable option to use Sage in Debian is to use it from experimental/testing since any support request for say a year old version of Sage will likely start with the question Can someone reproduce this in the current release. Any patch from our end will only go in the next release unless we decide one day to do support some stable release for a while (and I am honestly not seeing that happening for a while). So having Ubuntu package Sage like in 9.04 and having that distro live for a year (assuming they had packaged something current) seems to be reasonable for the casual user who does not want to live on the bleeding edge of Sage. Ben Cheers, Michael Right, anyone (mostly servers) using Debian stable or oldstable is not going to be able to keep up with Sage easily. But what I think Tim is saying is that he can't easily get a recent version of Sage into unstable (and subsequently testing) because unstable and especially testing usually have official releases of things Sage depends on. So, I was just suggesting that we could perhaps convince Debian maintainers of Sage dependencies to put pre-release versions into experimental, in addition to the official versions they maintain for unstable / testing. This would be annoying for them but maybe they would do it if we asked nicely. Then, Tim can get Sage 4.x into experimental when it is convenient for him, while Sage 3.0.x stays in unstable and testing until there is a window to sync some relatively recent version of Sage with 100% officially released dependencies. Experimental, more so than unstable, does tend to have pre-releases of packages. Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
