[sage-combinat-devel] GradedAlgebrasWithBasis
Hi gurus! I just hadto implement a GradedAlgebrasWithBasis, the basis being StandardTableaux() and the degree given by the size of the tableau (and a peculiar multiplication). Now, everything works fine except that the output of the elements is not sorted by degree. How could I accomplish that? Or did I possibly make a mistake? (my mouse is defunct, so I cannot easily copy paste. If necessary, I would, of course!) Thanks, Martin -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] GradedAlgebrasWithBasis
Martin Rubey martin.ru...@math.uni-hannover.de writes: Hi gurus! I just hadto implement a GradedAlgebrasWithBasis, the basis being StandardTableaux() and the degree given by the size of the tableau (and a peculiar multiplication). and another, more important, question: what I actually want to do is to compute t - t^2 + t^3 - + ... for a certain element t. Even computing t^3 takes far too long. Fortunately, I am only interested in low degree terms of the ressult. Is there an easy trick to compute only those? (the real thing would be a lazy formal power series ring, I suppose) Many thanks, Martin -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] GradedAlgebrasWithBasis
Martin Rubey martin.ru...@math.uni-hannover.de writes: Martin Rubey martin.ru...@math.uni-hannover.de writes: Hi gurus! I just hadto implement a GradedAlgebrasWithBasis, the basis being StandardTableaux() and the degree given by the size of the tableau (and a peculiar multiplication). and another, more important, question: what I actually want to do is to compute t - t^2 + t^3 - + ... for a certain element t. Please excuse me for answering my own question... LazyPowerSeriesRing does both! Thank you, Martin -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-devel] Re: genus() for Function Fields
Hi Maarten, I see this in Florian Hess's codes ### # Genus GffDifferentDeg := function(K) local of, oi, df, di; of := GffOrderMaxFinite(K); oi := GffOrderMaxInfty(K); df := GffOrderDisc(of); di := GffOrderDisc(oi); return (PolyDeg(df) + InftyVal(di))/GffDimExactConstField(K); end; #GffGenus := function(K) # local d, dim, n; # # n := GffDeg(K); # dim := 1; # d := GffDifferentDeg(K); # # return d/2 - n/dim + 1; #end; Which basically uses Riemann-Hurwitz to compute the Genus. But I don't think it's the fastest way to do it. I think analyzing the singularities is faster than analyzing the ramification. (It might be the reason that he commented GffGenus out) Anyway, I sent him an email and asked him about his opinion. First: I couldn't find the implementation for GffOrde... functions. On 17 דצמבר, 04:12, Maarten Derickx m.derickx.stud...@gmail.com wrote: It'shttp://trac.sagemath.org/sage_trac/ticket/12170. For Florian Hess ideas see my post inhttps://groups.google.com/forum/#!searchin/sage-devel/function$20fiel... of wich you are probably already aware. -- 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: Statistics on Printouts of open source Sage books
Thanks William and Rob for your feedback! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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: Help with automated testing of ECL
On Wednesday, December 21, 2011 3:23:41 AM UTC, Dima Pasechnik wrote: That's what the Sage's patchbot does, pulls patches from Sage's trac, and tests them. Just for the record, this is a completely separate automated testing system: the build bot compiles potential releases on a variety of systems, the patch bot builds patches from the sage trac on a single system. -- 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: Anyone developing Differential System and Cartan--Kaehler in sage?
Back in 2008, I said I was interested in adding support for Clifford algebras / Geometric Algebra to Sage. Since then I have found out that there is some support available in Axiom. Now that there is renewed interest in Exterior algebras, I would like to better understand how to incorporate both the Exterior algebras and the Clifford algebras into Sage in a way that makes sense both in terms of coercion and in terms of Categories, Is there an existing structure we could bolt our implementations into, or do we need to define these ourselves? I would much prefer elegance and logical consistency over convention. I do know that there are lots of conventions hanging around Clifford algebras and spinors, but I don't want these to get in the way. As a prototype, I added a Python interface to GluCat http://glucat.sf.net, implemented via Cython code. (GluCat implements both the Clifford and the exterior product, as well as inner products and the left contraction.) I began the Python interface at Sage Days 10 in Nancy, and am still refining this interface in anticipation of Cython v0.16. I did not try to add this to Sage (1) because it only implements a special case (up to 64 generators, Real field via float, double, dd_real or qd_real), (2) because it employs its own convention for generators and basis elements (signed index sets), (3) because I did not understand coercion or Categories in Sage, (4) because my ARC grant applications which included this work were unsuccessful, but mostly (5) because I did not make the time to do this. -- 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: @cached_method using strong references?
Hi Volker, On 21 Dez., 13:08, Volker Braun vbraun.n...@gmail.com wrote: You'll see that the size of __classcall__.cache increases dramatically. I've worked around this in my program by periodically purging stuff from the cache, but that shouldn't be the actual solution. I think * all unique objects should use weak refs I strongly agree, and actually I am right now working on two related tickets, namely #11521 (needs review, introducing weak references for caching homsets) and #715 (needs a lot of work, eventually aiming at using weak references for caching coerce maps). * @cached_method should also use weak refs Maybe there is any reason why this is not the case? Because cached_method is supposed to work on anything that can be used as a dictionary key -- on None, for example. However, None and many other things do not allow weak references. Also, what we need in the case of UniqueRepresentation is: Weak references to the return value (not to the key). Again, this can't be used in @cached_method by default. But I think it would be a good idea to introduce weak variants of @cached_method, and specifically a version @weak_value_cached_method. I'll try to implement such thing on top of #5. Do you have a ticket for the memory leak? Best regards, Simon -- 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: @cached_method using strong references?
Even with #11521, one gets sage: import gc sage: len(gc.get_objects()) 164699 sage: for i in range(2,1000): ring = ZZ.quotient(ZZ(i)) vectorspace = ring^2 : sage: gc.collect() 63 sage: len(gc.get_objects()) 375660 So, there is work to do. However, I think using weak references in UniqueRepresentation would not solve the problem: sage: from sage.structure.unique_representation import UniqueRepresentation sage: len(UniqueRepresentation.__classcall__.cache.keys()) 5136 sage: UniqueRepresentation.__classcall__.cache.clear() sage: gc.collect() 18 sage: len(gc.get_objects()) 335493 I think the strong references in the coercion cache are equally to blame. So, I suggest to deal with #715 before introducing weak cached methods. Cheers, Simon -- 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: @cached_method using strong references?
How about the following implementation: If the return values is weakref-able, we store a weakref. Otherwise, we just store the object. Upon lookup, if the value is a weakref it is dereferenced. I now understand that @cached_method might be useful to cache the result of a long computation even if nobody holds a reference to the result. But I'm feeling a bit uneasy that the cached value then remains alive unconditionally. Aging the cache to only keep the last n values would make me much happier. This could be implemented by a global ring buffer holding strong references to the last n (otherwise only weakly referenced) cache elements. Anyways, I haven't made a ticket yet. -- 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: Help with automated testing of ECL
On Wed, Dec 21, 2011 at 4:23 AM, Dima Pasechnik dimp...@gmail.com wrote: do you like this to pull updates/patches from somewhere for testing, too? That's what the Sage's patchbot does, pulls patches from Sage's trac, and tests them. Or only full releases? No, as I said in my original email, I would like to test the consistency of the current git/CVS tree, or of a tagged release with Sage's buildbot. If this does make sense at all, I really do not know. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- 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: Help with automated testing of ECL
On Tue, Dec 20, 2011 at 3:27 PM, kcrisman kcris...@gmail.com wrote: Because Sage may sometimes have custom patches to ECL that weren't in upstream at the time but are now, I don't know if it can be done 100% automatically. I really wonder what those patches are about. AFAIK they are related to backporting changes to releases, but the need for this disappears completely if the upstream sources are all the time consistent with Sage. But what you *could* do is the following: [...] and see what happens. Hmm, again, it is not something that I would like to do on my own computer, but rather provide a daily tarball or spkg to be tested in that bot. However, I don't see that you'd be able to just test ECL inside of Sage, because of the very specific config and deleting of tons of stuff we don't use, and linking against Sage-specific things. There is not so much stuff that you can delete: just the libraries that ECL ships with it (GMP, Boehm-GC, libffi). Assuming that they are already available in Sage, they are not even needed in a normal build -- for instance, on my copy of Ubuntu, I rarely use the versions that come with ECL, as the operating system already provides better versions --. The rest is very much integrated and is what has to be tested. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- 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: @cached_method using strong references?
Hi Volker, On 21 Dez., 14:22, Volker Braun vbraun.n...@gmail.com wrote: How about the following implementation: If the return values is weakref-able, we store a weakref. Otherwise, we just store the object. Upon lookup, if the value is a weakref it is dereferenced. But that costs time, and I thus wouldn't like to make it the default. What do other people think? I now understand that @cached_method might be useful to cache the result of a long computation even if nobody holds a reference to the result. But I'm feeling a bit uneasy that the cached value then remains alive unconditionally. Aging the cache to only keep the last n values would make me much happier. This could be implemented by a global ring buffer holding strong references to the last n (otherwise only weakly referenced) cache elements. I'll first focus on #715, ... Anyways, I haven't made a ticket yet. ... and then perhaps a weak cache for UniqueRepresentation could be discussed there. Cheers, Simon -- 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: Help with automated testing of ECL
I really wonder what those patches are about. AFAIK they are related to backporting changes to releases, but the need for this disappears completely if the upstream sources are all the time consistent with Sage. Under the current development and testing model, that would be extremely hard to do. But what you *could* do is the following: [...] and see what happens. Hmm, again, it is not something that I would like to do on my own computer, but rather provide a daily tarball or spkg to be tested in that bot. Yeah, I don't know whether that could be 100% automated or not. Possibly? There is not so much stuff that you can delete: just the libraries that ECL ships with it (GMP, Boehm-GC, libffi). Assuming that they are already available in Sage, they are not even needed in a normal build -- for instance, on my copy of Ubuntu, I rarely use the versions that come with ECL, as the operating system already provides better versions --. The rest is very much integrated and is what has to be tested. Just for reference, here is what we delete, and a few other things. == Special Update/Build Instructions == * Deleting the following directories saves space: without doing this, the spkg can grow from under 2.5 megabytes to almost 7 megabytes. Deleting these files is done automatically by the `spkg-make` script. - The directory src/msvc/ - The directory src/src/gc-unstable - The directory src/src/libffi - Most of the contents of the src/src/gmp directory: everything except install-sh, config.*, configfsf.* - The directory src/contrib/encodings/ - The directory src/contrib/unicode/ * The directories src/contrib/encodings/ and src/contrib/unicode/ may be removed because we build with --enable-unicode=no. Building with --enable-unicode=yes, the default in the latest ECL source, leads to problems with some strings in the Sage-Maxima-ECL interface. * Note: the way we configure Sage, CXX and CXXFLAGS are unused. * Do NOT quote SAGE_LOCAL when setting CPPFLAGS and/or LDFLAGS, in spkg-install as this caused the build to break. See http://trac.sagemath.org/sage_trac/ticket/10187#comment:117 * TODO: Add the ECL test suite, and an spkg-check file to run it. * TODO: Make ECL use Sage's Boehm GC on MacOS X as well (but perhaps put some changes from ECL's into Sage's Boehm GC), then remove the src/src/gc directory, too. The only current patch is from #9 [2] diff -r -u src/src/c/ffi/libraries.d src.patched/src/c/ffi/libraries.d --- src/src/c/ffi/libraries.d 2011-11-07 21:16:18.0 +0100 +++ src.patched/src/c/ffi/libraries.d 2011-11-15 11:13:42.0 +0100 @@ -70,6 +70,7 @@ #endif /* ENABLE_DLOPEN */ #include ecl/ecl-inl.h #include ecl/internal.h +#include sys/stat.h cl_object ecl_make_codeblock() This is for Cygwin. We should only apply it then, but that was before I knew how to do that. Sorry we didn't report that upstream. [1] http://cygwin.com/ml/cygwin/2011-04/msg00336.html [2] http://trac.sagemath.org/sage_trac/ticket/9 -- 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] plotting in sage-4.8.alpha5 is serious fubar'd
Hi,
I've been trying to use sage-4.8.alpha5 for daily work during the last
few days. I don't know what was done to plotting in sage-4.8.alpha5,
but it is seriously messed up.Basically, something is broken so
that figsize doesn't work at all. Often I have to set an aspect ratio
of 1000 just to see anything, etc. Anybody have a clue what this is
about?
This is a BLOCKER for release, since it will cause massive trouble to
a lot of users.
Here's a simple example, in which both outputs looks fine in sage-4.7.2:
g = Graphics(); g += line([(0, 120.93), (1, 120.92)])
g.show()
g.show(figsize=[8,4])
To see this on a remote install, just use save('a.png') in place of show.
Even though the first show is broken, perhaps due to something being
set by default, the g.show(figsize=[8,4]) is supposed to produce an
8 inch by 4 inch figure, but instead it makes something that is 0
inches tall. What's going on? What broke stuff?
This is now blocker trac #12213.
William
P.S. And FUBAR is literally the right acronym to describe this.
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
attachment: b.png
Re: [sage-devel] plotting in sage-4.8.alpha5 is serious fubar'd
On Wed, Dec 21, 2011 at 07:46:27AM -0800, William Stein wrote: I've been trying to use sage-4.8.alpha5 for daily work during the last few days. Let me quote from http://boxen.math.washington.edu/home/release/sage-4.8.alpha5/README.FIRST: This version of Sage is under construction, it has not been officially released. There is no point in testing it. In particular, you should *not* report bugs for this version. First of all, the issue might already be known to the release manager, but more importantly: since the release can still change, any bug reports might be difficult to reproduce. I don't know what was done to plotting in sage-4.8.alpha5, but it is seriously messed up.Basically, something is broken so that figsize doesn't work at all. Often I have to set an aspect ratio of 1000 just to see anything, etc. Anybody have a clue what this is about? Probably the new matplotlib (#11915) which will *not* be merged in sage-4.8.alpha5 but at some point I did include it. So please check your matplotlib version in your sage-4.8.alpha5 Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: plotting in sage-4.8.alpha5 is serious fubar'd
I'm pretty sure this is http://trac.sagemath.org/sage_trac/ticket/11963, which changed the aspect ratio handling. The default is now 1.0: sage: Graphics().aspect_ratio() 1.0 If you request 'automatic' then you get a plot of the specified width/height: sage: g.show(figsize=[8,4], aspect_ratio='automatic') I don't have a strong opinion about what the best default aspect_ratio is, but a warning/error if it conflicts with the chosen aspect_ratio seems in order. -- 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: plotting in sage-4.8.alpha5 is serious fubar'd
On Dec 21, 11:17 am, Volker Braun vbraun.n...@gmail.com wrote: I'm pretty sure this ishttp://trac.sagemath.org/sage_trac/ticket/11963, which changed the aspect ratio handling. The default is now 1.0: sage: Graphics().aspect_ratio() 1.0 More precisely, when an empty graphics object is added to something nonempty which would ordinarily have an 'automatic' aspect ratio, it goes to the g.set_aspect_ratio(other.aspect_ratio()) but maybe that's not the best solution. Let's continue this discussion on ticket. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] plotting in sage-4.8.alpha5 is serious fubar'd
On Wed, Dec 21, 2011 at 8:07 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On Wed, Dec 21, 2011 at 07:46:27AM -0800, William Stein wrote: I've been trying to use sage-4.8.alpha5 for daily work during the last few days. Let me quote from http://boxen.math.washington.edu/home/release/sage-4.8.alpha5/README.FIRST: This version of Sage is under construction, it has not been officially released. There is no point in testing it. In particular, you should *not* report bugs for this version. First of all, the issue might already be known to the release manager, but more importantly: since the release can still change, any bug reports might be difficult to reproduce. I don't know what was done to plotting in sage-4.8.alpha5, but it is seriously messed up. Basically, something is broken so that figsize doesn't work at all. Often I have to set an aspect ratio of 1000 just to see anything, etc. Anybody have a clue what this is about? Probably the new matplotlib (#11915) which will *not* be merged in sage-4.8.alpha5 but at some point I did include it. So please check your matplotlib version in your sage-4.8.alpha5 It's not 11915. This was caused by a bad ticket merged in sage-4.8.alpha3. I'm glad I found this issue, and am reporting it, irregardless of that README quote. I would hate for this to have been released. -- William Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Minor question about ask.sagemath settings
It turns out that askbot has two different possible settings for when you click on unanswered questions. It can mean no accepted answers or no answers. Currently, it's the former. I sort of feel like that is confusing and it should be the other way, but I'm not strongly in favor of either option. What do heavy users think? See http://askbot.org/en/question/802/does-unanswered-just-give-backwards-sort-by-number for context. In other news, Evgeny says that our askbot is a bit out of date :) but that he can fix that if we wish. - kcrisman -- 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: @cached_method using strong references?
On Wednesday, December 21, 2011 2:03:36 PM UTC, Simon King wrote: Anyways, I haven't made a ticket yet. ... and then perhaps a weak cache for UniqueRepresentation could be discussed there. This is now http://trac.sagemath.org/sage_trac/ticket/12215 -- 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: @cached_method using strong references?
Hi Volker, On 21 Dez., 21:05, Volker Braun vbraun.n...@gmail.com wrote: This is nowhttp://trac.sagemath.org/sage_trac/ticket/12215 There are further tickets related with weak references * #11521 has already be mentioned * #715 * #5970 (which is about the cache of polynomial rings). I have patches for all three of them, but even with all of them together, the following simple example is still leaking: sage: for p in primes(2,100): : print get_memory_usage() : R.x,y,z = GF(p)[] So, it seems to be a very complex problem. Cheers, Simon -- 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: new flask notebook-please review
Please check for the following issue: 1) Can you logout when using FF? I've seen problems with this on a Linux box. Can anybody reproduce it? Otherwise, everything looks good to me. Also, questions about handling the Jmol update as I will have some time over the next week to work on that: 1) It appears that trac #11053 (http://trac.sagemath.org/sage_trac/ticket/11503) as I've now modified it will update the version of Jmol and work. 2) Since we were tracking changes to jmol_lib in mercurial the spkg installed (trac #11503) does not include the updated jmol_lib. Might it be cleaner to include the jmol_lib in the spkg? Jonathan -- 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: Minor question about ask.sagemath settings
On 12/21/11 12:48 PM, kcrisman wrote: It turns out that askbot has two different possible settings for when you click on unanswered questions. It can mean no accepted answers or no answers. Currently, it's the former. I sort of feel like that is confusing and it should be the other way, but I'm not strongly in favor of either option. What do heavy users think? See http://askbot.org/en/question/802/does-unanswered-just-give-backwards-sort-by-number for context. In other news, Evgeny says that our askbot is a bit out of date :) but that he can fix that if we wish. I think no answers should be the default, and I feel moderately strongly about this. It seems that lots of times there are good answers, but the original author hasn't clicked the button to accept them. Jason -- 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: @cached_method using strong references?
On Wed, Dec 21, 2011 at 12:35 PM, Simon King simon.k...@uni-jena.de wrote: Hi Volker, On 21 Dez., 21:05, Volker Braun vbraun.n...@gmail.com wrote: This is nowhttp://trac.sagemath.org/sage_trac/ticket/12215 There are further tickets related with weak references * #11521 has already be mentioned * #715 * #5970 (which is about the cache of polynomial rings). I have patches for all three of them, but even with all of them together, the following simple example is still leaking: sage: for p in primes(2,100): : print get_memory_usage() : R.x,y,z = GF(p)[] So, it seems to be a very complex problem. When I'm in a get-shite-done mood, and hence have temporarily given up on dealing with the above sort of sad annoying memory leak crap, I just use fork: for p in primes(2,100): print get_memory_usage() @fork def f(): R.x,y,z = GF(p)[] return (x-y+z)^p print f() I don't want to encourage you to do this, because of course Sage is benefiting a lot from you worrying about this problem. But just for the record, using @fork can be handy in some cases like this, when you *need* to get work done. By the way, @fork does not work well if you are using pexpect interfaces, since it just resets them for the child. -- William -- 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: @cached_method using strong references?
On Wed, Dec 21, 2011 at 5:22 AM, Volker Braun vbraun.n...@gmail.com wrote: How about the following implementation: If the return values is weakref-able, we store a weakref. Otherwise, we just store the object. Upon lookup, if the value is a weakref it is dereferenced. I now understand that @cached_method might be useful to cache the result of a long computation even if nobody holds a reference to the result. But I'm feeling a bit uneasy that the cached value then remains alive unconditionally. Aging the cache to only keep the last n values would make me much happier. This could be implemented by a global ring buffer holding strong references to the last n (otherwise only weakly referenced) cache elements. +1 It's unlikely that the key or the value for cached_method will actually be referenced elsewhere to be useful, unlike e.g. unique representation. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
