Re: [sage-combinat-devel] Re: map_coefficients factor
On Sat, Apr 18, 2015 at 12:10:47PM -0700, 'Martin R' via sage-combinat-devel wrote: Sorry, I should have made myself clearer: I do not understand the design decision behind the way map_coefficients works. Shouldn't it rather check whether the function actually produces something in the coefficient ring? That's the usual speed vs safety vs flexibility. We definitely want to have a fast map_coefficients that does no check, for those cases where we know that f is an endofunction as specified by the documentation. In some cases the user can find it handy to abuse the system a bit (like Mike is doing), just for output. In all other cases it would be preferable to have systematic checks. Supporting both speed vs safety boils down to adding an option `check=True`, and if possible going trough the Sage code and setting `check=False` wherever we know we are on the safe side. It's an easy change. Volunteers welcome! For supporting cleanly Mike's needs for flexibility, we really would need to change the base ring. It would be nice to have some idiom like: sage: f.map_coefficients(factor, codomain=SR) or sage: f.change_base_ring(SR).map_coefficients(factor) This one is a bit trickier. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Fwd: Sage Math on Raspbian /Raspberry Pi 2
-- Forwarded message -- From: Roberto Panai robertopa...@sardus.it Date: Mon, Apr 20, 2015 at 4:00 PM Subject: Sage Math on Raspbian /Raspberry Pi 2 To: wst...@gmail.com Dear William, I just bought one Raspberry Pi 2 and I saw Wolfram Mathematica is already in. Apparently there is not a (updated) binary file for this device and to compile it you need a couple of days. I was wondering if you wish to have some binary for this device/os or not. I could eventually compile it for you. An other option is to made a small app which open a browser on cloud.sagemath.com as the gmail app for ubuntu does. Best, Roberto PS. On https://en.wikipedia.org/wiki/List_of_computer_algebra_systems Sage Math version was not updated. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
On 04/20/2015 09:31 PM, Jeroen Demeyer wrote: For the record, this is what I did as release manager: 1. take a bunch of tickets with positive_review, make a private Sage release with them, test them on the buildbot. 2a. if there are buildbot failures and it's clear which ticket caused them: set the ticket to needs_work and GOTO 1. 2b. if there are buildbot failures and it's NOT clear which ticket caused them: take a different set of tickets with positive_review and GOTO 1. 2c. as long as the set of chosen tickets is too small to merit a new beta/rc or it is missing a ticket which certainly should be included, GOTO 1. 3. Close all chosen tickets on Trac. 4. Make a new private release with the chosen closed tickets. 5. If any of the merged tickets do not correspond to the tested tickets (easy to check: in steps 1 and 4, store the hash of the tickets; now just compare those), there are several actions I could take: * The change is minor (for example, a typo in the documentation): assume that buildbot tests still pass and just accept the change. * The change is major and we want a new release soon: re-open the ticket on Trac and GOTO 4 (postponing the ticket to the next beta). * The change is major but we really want the ticket in this release: GOTO 1 to test it again (keeping the tickets closed). 6. Make the release from step 4 public as new Sage release. For me, this worked well enough in practice. I know the release management scripts would have to be adjusted to store the hashes, but it's not really difficult either. Include rebasing (including artificially creating dependencies for concurrent tickets) and we'll get a nice HOWTO. :-) Fortunately one nowadays doesn't have to keep trac[k] of ticket descriptions, attached patches and referenced spkgs... -leif P.S.: GOTO is not pythonic. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Can't build Sage with 2GB RAM anymore
Hi Andrey I can confirm that sage-6.6 was built successfully on an 8 year old pentium with 2GB of RAM and about 10 GB of swap, I was looking from time to time at the swap use during the ~15 hours built, I think almost 3GB was the top. This was done with Debian Jessie, which I have to say, is the most stable OS I have ever seen, the whole machine was incredible slow during the built of sage, but in the end, everything (not only the sage built) was done as expected. I guess my Windows XP from 10 years ago would have completely frozen every 10 seconds ;-) Greetings, Georg On Monday, April 20, 2015 at 6:33:24 PM UTC+2, Andrey Novoseltsev wrote: Hello, Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has swap as well, but I don't think it was used much, the wall time was just a bit bigger than user+system, about 8-9 hours. With Sage-6.6 it gets stuck while processing rings directory: swap is not full yet, but it seems that necessary stuff does not fit RAM anymore - heavy disk usage, low CPU temperature, not much progress after more than a day, top was showing python setup.py if I recall correctly consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over several attempts with make distclean, with nothing running apart from MATE session and a terminal window. I realize that supporting builds on such computers may not be a high priority, if at all, but perhaps it is a manifestation of some bug. Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite common, especially with VMs. (In fact, all physical and virtual machines that I use frequently happen to have exactly this number, ranging from 2GB/1 core to 32GB/16 cores.) Thank you, Andrey -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Can't build Sage with 2GB RAM anymore
I have a somewhat related problem: Since February (I do not recall the exact revision, but might very well be early in the 6.6 release cycle), I cannot do a parallel build with 4 processes on my notebook with 4 GB RAM anymore. My observation was that cythonizing takes huge amounts of memory (~ 2 GB) per process. Interrupting it and typing make again reduced the maximum memory usage. I then tried to somehow compare that with 6.5 and tried to limit my memory with ulimit; but also then, cythonizing took lots of memory. I then stopped investigating this and resigned myself to parallel builds with two processes. Regards, CH Am 2015-04-20 um 19:10 schrieb Thierry: Hi, i confirm i had the same issue on a Genuine Intel(R) CPU T2050 @ 1.60GHz with 1GB of RAM (+1.5GB swap), the build of 6.5 was sucessful, but get stuck for 6.6. Ciao, Thierry On Mon, Apr 20, 2015 at 09:33:24AM -0700, Andrey Novoseltsev wrote: Hello, Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has swap as well, but I don't think it was used much, the wall time was just a bit bigger than user+system, about 8-9 hours. With Sage-6.6 it gets stuck while processing rings directory: swap is not full yet, but it seems that necessary stuff does not fit RAM anymore - heavy disk usage, low CPU temperature, not much progress after more than a day, top was showing python setup.py if I recall correctly consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over several attempts with make distclean, with nothing running apart from MATE session and a terminal window. I realize that supporting builds on such computers may not be a high priority, if at all, but perhaps it is a manifestation of some bug. Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite common, especially with VMs. (In fact, all physical and virtual machines that I use frequently happen to have exactly this number, ranging from 2GB/1 core to 32GB/16 cores.) Thank you, Andrey -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Univ.-Prof. Dr. Clemens HeubergerAlpen-Adria-Universität Klagenfurt Institut für Mathematik, Universitätsstraße 65-67, 9020 Klagenfurt, Austria Tel: +43 463 2700 3121Fax: +43 463 2700 99 3121 clemens.heuber...@aau.athttp://wwwu.aau.at/cheuberg -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Has PY_NEW changed?
Hi Jeroen, On 2015-04-20, Jeroen Demeyer jdeme...@cage.ugent.be wrote: Thank you! Is there a penalty for doing type(self) twice? I don't think so, but you should profile. When in doubt, use cdef type t = type(self) # The cdef type is very important! obj = t.__new__(t) See my previous post: This is what I already did. Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Has PY_NEW changed?
On Monday, April 20, 2015 at 12:55:27 PM UTC-7, Jeroen Demeyer wrote: Thank you! Is there a penalty for doing type(self) twice? I don't think so, but you should profile. When in doubt, use cdef type t = type(self) # The cdef type is very important! obj = t.__new__(t) Yes, very much so. Otherwise the lookup of the __new__ method is via generic code. I think it might even be a bug that if you have cdef object o = type(self) obj = (typeo).__new__(t) one gets different code than from t.__new__(t) . It looks like type propagation through expressions in cython can use some improvement. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Showing poset, which way up?
? I made http://trac.sagemath.org/ticket/16865 from this 8 months ago, but nobody has said which should be defined correct way. Do we at least have same opinion about that this is a bug? Given the following output, it would indeed make more sense if 2 were... at the top. sage: Poset([[1,2],[[1,2]]]).top() 2 I made http://trac.sagemath.org/ticket/16865 http://www.google.com/url?q=http%3A%2F%2Ftrac.sagemath.org%2Fticket%2F16865sa=Dsntz=1usg=AFQjCNEfU2XF5QoyLkqp6xQh0IJ_D21J6w from this 8 months ago, but nobody has said which should be defined correct way. Do we at least have same opinion about that this is a bug? Perhaps none of those who use the feature saw your ticket. Write the code, set your ticket to needs_review, and I am sure that it will not wait for long. Especially if you post here when it is ready. Nathann -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Has PY_NEW changed?
Hi, #17688: remove PY_NEW from Sage libs #18030: cimport it instead of using the .pxi Though I am not sure why you get these errors. Vincent On 20/04/15 15:00, Volker Braun wrote: Nothing changed as far as I know. You should be using the usual Python idiom of __new__ and not PY_NEW: https://github.com/cython/cython/wiki/FAQ#id21 On Monday, April 20, 2015 at 8:38:45 AM UTC-4, Simon King wrote: Hi! Currently I get new segfaults in some experimental code, and they arise when PY_NEW is called. Has something changed for that function? Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Has PY_NEW changed?
On 2015-04-20, Simon King simon.k...@uni-jena.de wrote: Currently I get new segfaults in some experimental code, and they arise when PY_NEW is called. Has something changed for that function? I found that the segfaults vanish when I remove optional arguments from __cinit__. I.e., instead of def __cinit__(self, *args, **kwds) I now have def __cinit__(self) But why is that needed in order to make PY_NEW(MyType) work? Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: update patchbot Gentoo Base System/2.2/x86_64/3.2.1-gentoo-r2/sage4
I would like to second this demand: see for example http://patchbot.sagemath.org/ticket/17821/ for one example of misbehavior of sage4 to update: sage -i http://chapoton.perso.math.cnrs.fr/patchbot-2.3.3.spkg Frederic Le dimanche 19 avril 2015 13:21:47 UTC+2, vdelecroix a écrit : Hello, It seems that the patchbot Gentoo Base System/2.2/x86_64/3.2.1-gentoo-r2/sage4 is somewhat broken! (it fails at a very early step while other build bot did well) Please update it or shut it down! Vincent -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Has PY_NEW changed?
Nothing changed as far as I know. You should be using the usual Python idiom of __new__ and not PY_NEW: https://github.com/cython/cython/wiki/FAQ#id21 On Monday, April 20, 2015 at 8:38:45 AM UTC-4, Simon King wrote: Hi! Currently I get new segfaults in some experimental code, and they arise when PY_NEW is called. Has something changed for that function? Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] sage always executes the binary found in SAGE_ROOT
On Monday, April 20, 2015 at 3:27:45 AM UTC+2, François wrote: On 04/20/15 09:23, ggrafendorfer wrote: Sagetex e.g., is one reason: http://www.sagemath.org/doc/installation/sagetex.html I have to agree with other that setting SAGE_ROOT is asking for trouble. For the case of of the makefile we probably could do something about it. However I want go back to your use of sagetex. While you could read that way if you are so minded I don't think the documentation you point to requires you to define SAGE_ROOT. In fact I would say it actively ask to use the value that SAGE_ROOT should have for the various scenarios. So for example if you define TEXINPUTS as suggested instead of doing export TEXINPUTS=SAGE_ROOT/local/share/texmf//: which wouldn't work I think, I would replace SAGE_ROOT by the appropriate path. In my case something like export TEXINPUTS=/home/fbissey/sandbox/sage-6.5.beta1/local/share/texmf//: This I believe would be working without ever having to set SAGE_ROOT. Francois Of course I can replace SAGE_ROOT by its value on every appearance of SAGE_ROOT, and this will work. And if my sage root dir ever changes, I have to change this everywhere it appears, instead of just changing SAGE_ROOT. ;-) Do I have to change my understanding of the proper use and naming of envirionment variables!? I could also define my personal MY_PERSONAL_SAGE_ROOT to achieve what I want. I think if sage uses environment variables for intern use only, the naming should be appropriate and they should not be mentioned in the user manual, and if, with a big warning! Georg To avoid this i thought I'm smart and going to set SAGE_ROOT, -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Has PY_NEW changed?
Hi! Currently I get new segfaults in some experimental code, and they arise when PY_NEW is called. Has something changed for that function? Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] sage always executes the binary found in SAGE_ROOT
On 20 April 2015 at 02:16, John H Palmieri jhpalmier...@gmail.com wrote: As far as I can tell, it is never a good idea to set SAGE_ROOT, nor is it ever suggested that you do so in the documentation. I think you could expect things to break if you set environment variables which Sage uses internally. One solution is to create a link '/usr/local/bin/sage' pointing to the executable sage script in SAGE_ROOT, whatever that happens to be. Then make sure that /usr/local/bin is in your PATH. THat is what I do (for system-wide installs, I have something else for current working development versions). I also use sagetex without any use of SAGE_ROOT. John Probably we should put a warning in the documentation that users should not set SAGE_ROOT, or at least if they set it, then they might run into problems. John On Sunday, April 19, 2015 at 2:23:09 PM UTC-7, ggrafendorfer wrote: Sagetex e.g., is one reason: http://www.sagemath.org/doc/installation/sagetex.html Georg On Sunday, April 19, 2015 at 6:43:27 PM UTC+2, John Cremona wrote: Do you have a reason for having SAGE_ROOT set at all? I don't. John On 19 April 2015 at 17:33, ggrafendorfer georg.gra...@gmail.com wrote: Hi When I build a new version of sage in a separate directory, and then, while beeing in that directory, execute ./sage then the current old version of sage, which can be found in SAGE_ROOT is executed. E.g., this looks as follows: .../data/sage-6.6$ pwd /mnt/data/sage-6.6 .../data/sage-6.6$ ./sage ┌┐ │ Sage Version 6.4.1, Release Date: 2014-11-23 │ │ Type notebook() for the browser-based notebook interface.│ │ Type help() for help.│ └┘ sage: after changing the path name SAGE_ROOT points to, such that SAGE_ROOT does not exist anymore, the following behaviour shows up (SAGE_ROOT is set to /mnt/software/sage): .../data/sage-6.6$ ./sage ./sage: line 118: cd: /mnt/software/sage: No such file or directory ./sage: cannot determine SAGE_ROOT directory Isn't that strange!? This imposes the common question Is this a bug or a feature? However, indeed it is the case that when doing .../data/sage-6.6$ make ptestlong that the whole test is done with sage 6.4.1 instead of sage 6.6!! While SAGE_ROOT still pointing to a non-existing directory: .../data/sage-6.6$ make ptestlong cd build \ ../build/pipestatus \ env SAGE_PARALLEL_SPKG_BUILD='' ./install all 21 \ tee -a ../logs/install.log Nothing to (re)build / all up-to-date. ./sage -b ./sage: line 118: cd: /mnt/software/sage: No such file or directory ./sage: cannot determine SAGE_ROOT directory Makefile:19: recipe for target 'build' failed make: *** [build] Error 1 after changing the according path name, such that SAGE_ROOT exists again, .../data/sage-6.6$ make ptestlong works again, and is executed with sage-6.4.1, which is definitely NOT WHAT ONE WOULD EXPECT in this case, I would say, or am I wrong? My usual workflow is that I build the new version of sage, the execute make ptestlong, and after that I copy the new built version to SAGE_ROOT, replacing the old one there. greetings, Georg -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com. To post to this group, send email to sage-...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Talks at PyCon
The correct link for Nicolas: https://www.youtube.com/watch?feature=player_detailpagev=JVVMMULwR4s#t=2701 Best, Bruno Le 20/04/2015 11:05, Viviane Pons a écrit : Hi everyone, we were a bunch of Sage people at PyCon this year. Here's a link to the talk I gave about combinatorics: https://www.youtube.com/watch?v=3LZiZKgVjaU Nicolas Thiery also gave a lightning (5 minutes) talk about our crazy class hierarchy. https://www.youtube.com/watch?v=3LZiZKgVjaU (at 45:00) Enjoy! Best, Viviane -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com mailto:sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com mailto:sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Talks at PyCon
Hi everyone, we were a bunch of Sage people at PyCon this year. Here's a link to the talk I gave about combinatorics: https://www.youtube.com/watch?v=3LZiZKgVjaU Nicolas Thiery also gave a lightning (5 minutes) talk about our crazy class hierarchy. https://www.youtube.com/watch?v=3LZiZKgVjaU (at 45:00) Enjoy! Best, Viviane -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: matrices: matrix space vs matrix group
On 20/04/15 04:54, David Roe wrote: On Sun, Apr 19, 2015 at 10:18 AM, Volker Braun vbraun.n...@gmail.com wrote: I agree, coercion G - M is probably the right thing to do here. +1 Thanks for your support! I opened #18258. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Has PY_NEW changed?
My guess would be that you just have a corrupt heap and then you fail randomly at new allocations. On Monday, April 20, 2015 at 8:45:14 AM UTC-4, Simon King wrote: On 2015-04-20, Simon King simon...@uni-jena.de javascript: wrote: Currently I get new segfaults in some experimental code, and they arise when PY_NEW is called. Has something changed for that function? I found that the segfaults vanish when I remove optional arguments from __cinit__. I.e., instead of def __cinit__(self, *args, **kwds) I now have def __cinit__(self) But why is that needed in order to make PY_NEW(MyType) work? Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
On Sunday, April 19, 2015 at 12:32:20 PM UTC-4, leif wrote: On 04/19/2015 05:41 PM, Nathann Cohen wrote: I often have a look at positively reviewed tickets and sometimes ask questions about the review. Positive review just mean that one person agreed that the changes were good to be integrated. But it might still interest other to have a look (or even the reviewer might think of something in the morning after setting the day before 'positive review'). So I would prefer a stand by period between the 'positive review' and the 'closed' (= currently testing if it merges cleanly). One week looks reasonable to me. And it should not be hard to script. It is true that several persons requested that tickets should stay in positive review for a while before being merged. On the other hand, if merging them becomes fully automatic, then changing something is really immediate and perhaps we will end up creating more tickets. Yep, with all consequences. It would IMHO be much more sensible to use the Merged in field (which Volker likes very much, I know), indicating that the branch has currently been merged into the next, not yet released, version. (No need to change that field later, upon closing the ticket, if everything went well.) That way, anybody would (or should) know that he/she must not change the ticket's branch, but it would also easily be possible to revert the ticket's state into needs work, in case other reviewers (or the original one(s)) happen to find further issues directly related to the ticket's changes (as opposed to desirable changes for a follow-up). Yes, this seems reasonable. Keeping a proliferation of tickets is good, having a way for the release manager to let everyone know that the ticket is being tested is also good, making the release manager's job not annoying is good. By the way, I would be very against completely automated merging. The release manager (as a human) is a last line of defense against scurrilous tickets/branches/changes to Sage. Otherwise it's too easy for a write/review team of two to put in a whole bunch of stuff that maybe isn't following convention (minor) or actively making Sage bad (major). I'm not defining those things, but just pointing out that having a real person who has been working with the project quite a while verifying that the changes could be relevant and useful is a good thing; otherwise we don't have a commit group like some projects, but essentially any pair of people becomes a committer. In practice that isn't a huge problem, but it's still worth having that role, very much so - and not just for testing for doctest errors, which could themselves be in error ;) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] cannot typeset output from maxima_calculus
If I have typeset_mode(True) in SMC and try to do
maxima_calculus('algebraic: true;')
I get a RuntimeError:
https://cloud.sagemath.com/projects/8a65b3c2-4322-4858-b6f9-e85fc7dac4f8/files/2015-04-20-093152.sagews
The problem seems to be that latex() on the output fails...which is a
bit strange, since the output is just true.
The problem seems to be in latex_() for Maxima objects, which runs tex()
in Maxima. But that seems to work: if I do maxima_console(), I get
(%i1) tex(algebraic: true);
$$\mathbf{true}$$
(%o1)false
Any ideas what's going on?
Dan
--
--- Dan Drake
- www.math.wisc.edu/~ddrake/
---
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
[sage-devel] Re: Can't build Sage with 2GB RAM anymore
On Monday, 20 April 2015 12:10:21 UTC-6, Volker Braun wrote: Which build step / which setup.py? Logs? I believe it was building Sage itself and getting stuck at rings. Can't provide a log now, will try to run it again overnight and post a log tomorrow. On Monday, April 20, 2015 at 12:33:24 PM UTC-4, Andrey Novoseltsev wrote: Hello, Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has swap as well, but I don't think it was used much, the wall time was just a bit bigger than user+system, about 8-9 hours. With Sage-6.6 it gets stuck while processing rings directory: swap is not full yet, but it seems that necessary stuff does not fit RAM anymore - heavy disk usage, low CPU temperature, not much progress after more than a day, top was showing python setup.py if I recall correctly consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over several attempts with make distclean, with nothing running apart from MATE session and a terminal window. I realize that supporting builds on such computers may not be a high priority, if at all, but perhaps it is a manifestation of some bug. Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite common, especially with VMs. (In fact, all physical and virtual machines that I use frequently happen to have exactly this number, ranging from 2GB/1 core to 32GB/16 cores.) Thank you, Andrey -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Can't build Sage with 2GB RAM anymore
Which build step / which setup.py? Logs? On Monday, April 20, 2015 at 12:33:24 PM UTC-4, Andrey Novoseltsev wrote: Hello, Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has swap as well, but I don't think it was used much, the wall time was just a bit bigger than user+system, about 8-9 hours. With Sage-6.6 it gets stuck while processing rings directory: swap is not full yet, but it seems that necessary stuff does not fit RAM anymore - heavy disk usage, low CPU temperature, not much progress after more than a day, top was showing python setup.py if I recall correctly consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over several attempts with make distclean, with nothing running apart from MATE session and a terminal window. I realize that supporting builds on such computers may not be a high priority, if at all, but perhaps it is a manifestation of some bug. Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite common, especially with VMs. (In fact, all physical and virtual machines that I use frequently happen to have exactly this number, ranging from 2GB/1 core to 32GB/16 cores.) Thank you, Andrey -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Can't build Sage with 2GB RAM anymore
Hi, i confirm i had the same issue on a Genuine Intel(R) CPU T2050 @ 1.60GHz with 1GB of RAM (+1.5GB swap), the build of 6.5 was sucessful, but get stuck for 6.6. Ciao, Thierry On Mon, Apr 20, 2015 at 09:33:24AM -0700, Andrey Novoseltsev wrote: Hello, Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has swap as well, but I don't think it was used much, the wall time was just a bit bigger than user+system, about 8-9 hours. With Sage-6.6 it gets stuck while processing rings directory: swap is not full yet, but it seems that necessary stuff does not fit RAM anymore - heavy disk usage, low CPU temperature, not much progress after more than a day, top was showing python setup.py if I recall correctly consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over several attempts with make distclean, with nothing running apart from MATE session and a terminal window. I realize that supporting builds on such computers may not be a high priority, if at all, but perhaps it is a manifestation of some bug. Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite common, especially with VMs. (In fact, all physical and virtual machines that I use frequently happen to have exactly this number, ranging from 2GB/1 core to 32GB/16 cores.) Thank you, Andrey -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Has PY_NEW changed?
On 2015-04-20 14:38, Simon King wrote: Has something changed for that function? Yes, very much. It gradually changed in various sub-tickets of http://trac.sagemath.org/ticket/17854 Solution: use t.__new__(t) instead of PY_NEW(t) *except* for the Sage types Integer and RealDoubleElement (which use custom allocation functions that Cython isn't aware of) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Scalability of the rich output supported types list
Right now there is no feature detection, so any discussion about possible performance issues are unlaid eggs. I don't think its going to be an issue, and it also can be delayed during startup. The _rich_repr_ have the job of deciding no the best representation for a particular object, so they would naturally query for multiple different output types anyways so you wouldn't benefit that much from changing the API at that point. The output types are intentionally rigid so you actually have to declare AND TEST them. I'm against dynamically constructing stuff that then isn't tested properly just so you can save a few keystrokes. On Monday, April 20, 2015 at 11:23:30 AM UTC-4, martin@gmx.net wrote: Hi! In http://trac.sagemath.org/ticket/7298 (on HTML5 video for animations) and some other tickets I'm currently dealing with the effects of the rich output framework introduced by Volker in http://trac.sagemath.org/ticket/17234. I've some concerns about the scalability of this approach, and would like your opinion on whether the following changes would make sense (so I'd create tickets for them). Currently, the list of formats supported by a backend is fixed. But in the long run, it might make sense to perform some auto-detection there, absed on what browser the notebook is running on, or what software the user has installed on their system, or whatever. Such computation could take a bit of time. Hopefully not much for each individual check, but it adds up. So I'd propose to change from a single list of all supported formats to an API where content creators can query for distinct formats. So you'd no longer ask the backend for all its supported formats, and then check whether a format you like is in that list, but directly ask the backend whether it supports a given format. The result of that query could be more than a single yes/no answer. It could come with a quality measure, the way the HTTP Accept header works. That quality could be used to distinguish between formats which can be reproduced well and formats which will give poorer results. It could also be used to distinguish between formats whose support is absolutely certain and formats where support is assumed but still depends on a number of factors which are difficult to check for, like e.g. support for a given codec within a supported video container format. Perhaps it's not a wise choice to identify output container types with output format identifiers. As it is, whenever I want to support an additional format, I have to create a new type. Statically this can lead to a lot of redundant code, since every type is supposed to come with a docstring and examples and whatnot, even though all of that except for the format name will probably copied and pasted from some other format. Things get even if someone at some point decides to create additional format identifiers at runtime. So far that would entail some dynamic type construction, which feels a bit like Voodoo, and might make this approach scarier than it has to be. So perhaps we should have one class (plus perhaps some subclasses) representing formats, and another class (again with subclasses) representing content. The content object could then contain a reference to the format for which it was created. These ideas obviously build on one another. Do you think they are worth pursuing? Right now there is no urgent need for any of this, but that might change in the long run, and the sooner we change the API, the less code we break in the process. Since the current API got released in Sage 6.6, I guess we'd have to follow deprecation procedures in any case, but I believe that it should be feasible to provide backwards-compatible transitions for all of the above. Greetings, Martin von Gagern -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Can't build Sage with 2GB RAM anymore
Hello, Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has swap as well, but I don't think it was used much, the wall time was just a bit bigger than user+system, about 8-9 hours. With Sage-6.6 it gets stuck while processing rings directory: swap is not full yet, but it seems that necessary stuff does not fit RAM anymore - heavy disk usage, low CPU temperature, not much progress after more than a day, top was showing python setup.py if I recall correctly consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over several attempts with make distclean, with nothing running apart from MATE session and a terminal window. I realize that supporting builds on such computers may not be a high priority, if at all, but perhaps it is a manifestation of some bug. Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite common, especially with VMs. (In fact, all physical and virtual machines that I use frequently happen to have exactly this number, ranging from 2GB/1 core to 32GB/16 cores.) Thank you, Andrey -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Scalability of the rich output supported types list
Hi! In http://trac.sagemath.org/ticket/7298 (on HTML5 video for animations) and some other tickets I'm currently dealing with the effects of the rich output framework introduced by Volker in http://trac.sagemath.org/ticket/17234. I've some concerns about the scalability of this approach, and would like your opinion on whether the following changes would make sense (so I'd create tickets for them). Currently, the list of formats supported by a backend is fixed. But in the long run, it might make sense to perform some auto-detection there, absed on what browser the notebook is running on, or what software the user has installed on their system, or whatever. Such computation could take a bit of time. Hopefully not much for each individual check, but it adds up. So I'd propose to change from a single list of all supported formats to an API where content creators can query for distinct formats. So you'd no longer ask the backend for all its supported formats, and then check whether a format you like is in that list, but directly ask the backend whether it supports a given format. The result of that query could be more than a single yes/no answer. It could come with a quality measure, the way the HTTP Accept header works. That quality could be used to distinguish between formats which can be reproduced well and formats which will give poorer results. It could also be used to distinguish between formats whose support is absolutely certain and formats where support is assumed but still depends on a number of factors which are difficult to check for, like e.g. support for a given codec within a supported video container format. Perhaps it's not a wise choice to identify output container types with output format identifiers. As it is, whenever I want to support an additional format, I have to create a new type. Statically this can lead to a lot of redundant code, since every type is supposed to come with a docstring and examples and whatnot, even though all of that except for the format name will probably copied and pasted from some other format. Things get even if someone at some point decides to create additional format identifiers at runtime. So far that would entail some dynamic type construction, which feels a bit like Voodoo, and might make this approach scarier than it has to be. So perhaps we should have one class (plus perhaps some subclasses) representing formats, and another class (again with subclasses) representing content. The content object could then contain a reference to the format for which it was created. These ideas obviously build on one another. Do you think they are worth pursuing? Right now there is no urgent need for any of this, but that might change in the long run, and the sooner we change the API, the less code we break in the process. Since the current API got released in Sage 6.6, I guess we'd have to follow deprecation procedures in any case, but I believe that it should be feasible to provide backwards-compatible transitions for all of the above. Greetings, Martin von Gagern -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: pushing to tickets after setting it to positive_review is incompatible with the current workflow
For the record, this is what I did as release manager: 1. take a bunch of tickets with positive_review, make a private Sage release with them, test them on the buildbot. 2a. if there are buildbot failures and it's clear which ticket caused them: set the ticket to needs_work and GOTO 1. 2b. if there are buildbot failures and it's NOT clear which ticket caused them: take a different set of tickets with positive_review and GOTO 1. 2c. as long as the set of chosen tickets is too small to merit a new beta/rc or it is missing a ticket which certainly should be included, GOTO 1. 3. Close all chosen tickets on Trac. 4. Make a new private release with the chosen closed tickets. 5. If any of the merged tickets do not correspond to the tested tickets (easy to check: in steps 1 and 4, store the hash of the tickets; now just compare those), there are several actions I could take: * The change is minor (for example, a typo in the documentation): assume that buildbot tests still pass and just accept the change. * The change is major and we want a new release soon: re-open the ticket on Trac and GOTO 4 (postponing the ticket to the next beta). * The change is major but we really want the ticket in this release: GOTO 1 to test it again (keeping the tickets closed). 6. Make the release from step 4 public as new Sage release. For me, this worked well enough in practice. I know the release management scripts would have to be adjusted to store the hashes, but it's not really difficult either. Jeroen. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Has PY_NEW changed?
On 2015-04-20 21:37, Simon King wrote: Hi Jeroen, On 2015-04-20, Jeroen Demeyer jdeme...@cage.ugent.be wrote: Solution: use t.__new__(t) instead of PY_NEW(t) *except* for the Sage types Integer and RealDoubleElement (which use custom allocation functions that Cython isn't aware of) Thank you! Is there a penalty for doing type(self) twice? I don't think so, but you should profile. When in doubt, use cdef type t = type(self) # The cdef type is very important! obj = t.__new__(t) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Has PY_NEW changed?
Hi Jeroen, On 2015-04-20, Jeroen Demeyer jdeme...@cage.ugent.be wrote: Solution: use t.__new__(t) instead of PY_NEW(t) *except* for the Sage types Integer and RealDoubleElement (which use custom allocation functions that Cython isn't aware of) Thank you! Is there a penalty for doing type(self) twice? I am thinking of PY_NEW(type(self)) versus type(self).__new__(type(self)), with typical application in the creation of elements in methods like _add_ or _mul_. Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Can't build Sage with 2GB RAM anymore
On 04/20/2015 06:33 PM, Andrey Novoseltsev wrote: Up to Sage-6.5 I was able to build it on my old laptop with 2GB RAM. It has swap as well, but I don't think it was used much, the wall time was just a bit bigger than user+system, about 8-9 hours. I hope the 8-9 hours refer to the total time, not walltime - (user + sys)... ;-) Is it really a single-core without hyperthreading? Otherwise I'd set SAGE_NUM_THREADS=1 since the Sage library is (almost) always built in parallel with as many jobs/threads as the CPU has hardware threads (usually twice the number of cores on a CPU with HT). With Sage-6.6 it gets stuck while processing rings directory: swap is not full yet, but it seems that necessary stuff does not fit RAM anymore - heavy disk usage, low CPU temperature, not much progress after more than a day, top was showing python setup.py if I recall correctly consuming 1.5GB RAM and over 2.5GB virtual memory. This consistent over several attempts with make distclean, with nothing running apart from MATE session and a terminal window. The more interesting figures of 'top' are load average, actual user CPU usage (%us), kernel CPU usage (%sy), and I/O wait (%wa)... If I'm not mistaken, the python setup.py includes cythonizing, i.e., that's performed in the same process, and presumably makes up most of the actively used memory (of that process). I realize that supporting builds on such computers may not be a high priority, if at all, but perhaps it is a manifestation of some bug. Besides, while 2GB total RAM seems small nowadays, 2GB/core is quite common, especially with VMs. (In fact, all physical and virtual machines that I use frequently happen to have exactly this number, ranging from 2GB/1 core to 32GB/16 cores.) Yep. To mitigate the problem, you could try to not have the main filesystem (which usually also contains the Sage installation), swap space and /tmp (i.e., $TMPDIR) and/or $SAGE_BUILD_DIR on the same physical drive, e.g. by temporarily plugging a small (but fast) external drive and (temporarily) migrating some portitions there (i.e. $TMPDIR, $SAGE_BUILD_DIR, or even swap space onto a USB-3.0 SSD, say). In my experience, disk I/O is much more the bottleneck than CPU speed when building Sage, and if the same disk is in addition heavily charged by swapping (in your case apparently rather thrashing), the situation gets even worse. -leif -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] update patchbot Gentoo Base System/2.2/x86_64/3.2.1-gentoo-r2/sage4
On 2015-04-19 13:21, Vincent Delecroix wrote: Hello, It seems that the patchbot Gentoo Base System/2.2/x86_64/3.2.1-gentoo-r2/sage4 is somewhat broken! (it fails at a very early step while other build bot did well) Once the new patchbot proves that it actually works better than the current one, I will upgrade. I am still constantly struggling to get the new patchbot to work correctly on arando, so I don't see why I should also potentially bring sage4 in trouble. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Has PY_NEW changed?
On 2015-04-20, Simon King simon.k...@uni-jena.de wrote:
Thank you! Is there a penalty for doing type(self) twice? I am
thinking of PY_NEW(type(self)) versus type(self).__new__(type(self)),
with typical application in the creation of elements in methods like
_add_ or _mul_.
There is a penalty, but one can cope with it:
from sage.ext.memory cimport *
def test1(C):
cdef size_t n
for n from 0=n100:
x = PY_NEW(type(C))
def test2(C):
cdef size_t n
for n from 0=n100:
x = (type(C)).__new__(type(C))
def test1b(C):
cdef size_t n
cdef type T
for n from 0=n100:
T = type(C)
x = PY_NEW(T)
def test2b(C):
cdef size_t n
cdef type T
for n from 0=n100:
T = type(C)
x = T.__new__(T)
and we obtain (with a cythoned version of path algebra elements):
sage: DiGraph({0:{1:['a'], 2:['b']}, 1:{0:['c'], 1:['d']},
2:{0:['e'],2:['f']}}).path_semigroup().algebra(ZZ).inject_variables()
Defining e_0, e_1, e_2, a, b, c, d, e, f
sage: %timeit test1(a)
10 loops, best of 3: 101 ms per loop
sage: %timeit test1b(a)
10 loops, best of 3: 105 ms per loop
sage: %timeit test2(a)
10 loops, best of 3: 196 ms per loop
sage: %timeit test2b(a)
10 loops, best of 3: 102 ms per loop
Hence, doing (type(C)).__new__(type(C)) is clearly slower than
PY_NEW(type(C)), but when one assigns type(C) to a local variable, there
is no difference. The only advantage of PY_NEW is that one has less to
write.
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
