Re: [sage-support] huge virtual memory size when launching 7.3
I moved discussion to sage-devel, but wanted to add for anyone who comes across this and has problems: my simple temporary workaround is to change the line paristack_setsize(size, mem.virtual_memory_limit() // 4) to paristack_setsize(size, min(mem.virtual_memory_limit() // 4, 10)) in the file src/sage/libs/pari/pari_instance.pyx. (And then run sage -b.) On Tue, Sep 20, 2016 at 12:02 PM, Jeroen Demeyer wrote: > On 2016-09-20 12:54, Jonathan Bober wrote: > >> From reading what you've sent, I guess that what you have in mind is >> calling mmap with PROT_NONE and then calling mprotect() to change that >> to read/write whenever growing the stack? That seems like it might be a >> reasonable thing to do (though I'm only basing that on spending a few >> minutes reading what you sent, not from any actual knowledge that I had >> before). >> > > Yes, that is my idea. > > I'm willing to devote some time (not today) to figuring out what the >> right thing to do is (maybe the above is already the right thing) / >> implementing this / reviewing this. >> > > I don't mind implementing it. What I *do* mind is that I implement it and > that the patch rots away on Sage Trac in needs_review state (highly > specialized patches like these have a higher chance of that). That's why I > asked for a commitment to review. > > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] huge virtual memory size when launching 7.3
>From reading what you've sent, I guess that what you have in mind is calling mmap with PROT_NONE and then calling mprotect() to change that to read/write whenever growing the stack? That seems like it might be a reasonable thing to do (though I'm only basing that on spending a few minutes reading what you sent, not from any actual knowledge that I had before). I'm willing to devote some time (not today) to figuring out what the right thing to do is (maybe the above is already the right thing) / implementing this / reviewing this. On Mon, Sep 19, 2016 at 7:31 PM, Jeroen Demeyer wrote: > After spending some time reading on the subject, I think I might have a > solution to this "problem". It involves calling mmap() with PROT_NONE, > which will require a patch to upstream PARI. > > However, before implementing this, I would like a *strong commitment* from > somebody to review my patch when I'm finished. Otherwise I'm just wasting > my time. > > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: huge virtual memory size when launching 7.3
On Mon, Sep 19, 2016 at 12:13 PM, Jeroen Demeyer wrote: > On 2016-09-19 13:02, Jonathan Bober wrote: > >> If I ulimit -v 8 GB, say, (which is 512/64), and the PARI allocater >> immediately grabs 2 GB of the virtual address space for itself, then >> that seems like it leaves only 6 GB for malloc/sage_malloc/whatever >> else, which would be effectively limiting the physical memory available >> in some situations. >> > > Then use a larger value for "ulimit -v" or add some swap space. > > That doesn't really solve the problem, which I phrased poorly. The machine has an (antiquated) setup where, when a process requests X bytes of memory, the kernel reserves X bytes of physical memory for it. This is usually fine because users usually use the memory they request, and when they don't, well, there are 512 GB of it. But it does mean that every virtual memory allocation has a physical memory cost. (It also has benefits, like when someone screws up they usually notice immediately, instead of when the OOM killer kills sshd or the login process.) > This is not the default, and you probably wouldn't want to >> run your laptop this way >> > > But it is an advanced setting. Given that, I assume that you are clever > enough to do the right thing. With overcommit_memory set to 2, I'm not sure that there is a right thing to do. If I'm the only person in the world with this problem, then I should keep my mouth shut and get with the times, but I don't think this setup is so unreasonable. Anyway, where exactly is this allocation coming from? Is it a default PARI setting, or does it come from the way that Sage uses PARI? (I mean, to whom should I address my "hate mail"? :) > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: huge virtual memory size when launching 7.3
On Mon, Sep 19, 2016 at 11:04 AM, Jeroen Demeyer wrote: > On 2016-09-19 11:54, Jonathan Bober wrote: > >> But in that case the memory does effectively get "used", if it is the >> case that a quarter of the machine's memory is only available from the >> PARI memory allocater. If I'm not using the PARI parts of Sage, is that >> memory completely wasted? >> > > There should not be any consequences apart from the artificially high > value of virtual memory used. It certainly does not affect the physical > memory or swap space which is effectively available. > So the question becomes: what uses the "virtual memory used" value? > Apparently, the Linux overcommit thing does use that value (which is > surprising to me, I never really understood how this overcommit stuff > works). > > If I ulimit -v 8 GB, say, (which is 512/64), and the PARI allocater immediately grabs 2 GB of the virtual address space for itself, then that seems like it leaves only 6 GB for malloc/sage_malloc/whatever else, which would be effectively limiting the physical memory available in some situations. This specific machine has overcommit_memory set to 2, which means that the total amount of non-file-backed writable virtual memory that the kernel will allocate is fixed (probably to somewhere around the physical size of RAM). This is not the default, and you probably wouldn't want to run your laptop this way, but is not so unreasonable for a shared computer with a lot of RAM, where it usually doesn't cause problems. (It's a setting that might get changed from the default after the first or second time someone crashes the machine by using too much memory, especially if this happens on a Friday afternoon and leaves the machine unavailable all weekend...) When it does cause problems, it's usually because a process with a lot of writable virtual memory allocated to it forks, as is happening here. -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: huge virtual memory size when launching 7.3
On Mon, Sep 19, 2016 at 8:29 AM, Jeroen Demeyer wrote: > Why don't you use ulimit -v to limit the per-process available memory? > That would make sense when starting lots of processes even without the PARI > non-issue. Because I was being stupid. That seems like it should work ok. But in that case the memory does effectively get "used", if it is the case that a quarter of the machine's memory is only available from the PARI memory allocater. If I'm not using the PARI parts of Sage, is that memory completely wasted? -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: huge virtual memory size when launching 7.3
I just ran into this problem on a machine with 512 GB of ram, where the Sage virtual memory usage is around 128 GB. Volker might consider that a tiny fraction of the possible address space, but it still seems a bit ridiculous. I noticed this when I tried to use @parallel to 64 processes. (overcommit_memory is set to 2 on this machine.) I could @parallel(2) but not @parallel(3). I can change the overcommit settings, but not everyone is so lucky. I haven't actually tried (I'm just using an old version of sage for now) and I don't actually know what the default overcommit policy would do with this. 8 TB is not such a small fraction of the possible address space anymore. Also, there could be situations where I want to fork significantly more processes than the number of cpus. Also, 2 TB of ram is not so unreasonable these days (is PARI going allocate 500 GB?) and neither is > 64 cores, so this seems like it could be problematic for some users, and, in any case, it is annoying. On Wed, Aug 31, 2016 at 8:23 AM, Jeroen Demeyer wrote: > On 2016-08-31 08:57, Thierry Dumont wrote: > >> On machine 2, sage stating process (as mesured with top) uses about 39GB >> (no more...) out of 153.79 available. >> > > It doesn't actually "use" that memory. It is reserved virtual memory but > it does not take up physical memory or swap space. > > > -- > You received this message because you are subscribed to the Google Groups > "sage-support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: what happens when I load a cython file?
Thanks! Adding those include statements was almost good enough. Cython also needs an include directory, and knowing the files helped me find it, so to annotate I can now use sage -cython --annotate -I`sage -root`/devel/sage/sage/ext filename.pyx and running cython without annotating works as well, of course. I haven't actually tried to compile the resulting c code, because I don't care about that right now, but getting it to work and making an importable module is just a matter of finding the right compiler arguments. On Mon, Mar 5, 2012 at 3:15 AM, Simon King wrote: > Hi Jonathan, > > On 5 Mrz., 08:00, Jonathan Bober wrote: > > In this case, what I really want to do right now > > it look at annotated cython output to see if some things are compiling > the > > way that I think they should be compiling, but this is a slightly more > > general question than that. > > If all what you want is to see an annotated cython output, and your > file is not too long, then you can copy-and-paste it into a cell of > the notebook, prepending it with %cython. After evaluating the cell, > you should get two links. One provides the resulting C-code, the other > provides the annotated cython code. > > In that way, you can also see that Sage would prepend your code from > the notebook cell with the following: > include "interrupt.pxi" # ctrl-c interrupt block support > include "stdsage.pxi" # ctrl-c interrupt block support > include "cdefs.pxi" > > Perhaps these are the missing bits causing trouble for "sage -cython > filename.pyx"? > > Cheers, > Simon > > -- > To post to this group, send email to sage-support@googlegroups.com > To unsubscribe from this group, send email to > sage-support+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-support > URL: http://www.sagemath.org > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] what happens when I load a cython file?
I've learned that I can easily build and use a cython file by just typing "load filename.pyx" at the Sage command prompt (and this is wonderful). I'm guessing that when I do this, Sage automatically adds some include files or compilation flags or something, because it works and I don't have to define malloc or any other basic stuff. However, I can't just compile the same file now with cython; I get lots of errors when I type "sage -cython filename.pyx" because whatever magic happens when I use the load command isn't happening. So what I'm wondering is: what does Sage do when I type "load filename.pyx" and how can I do the same thing myself? (For some reason, I always seem to have lots of trouble figuring out how to compile cython code. Maybe I don't do it frequently enough.) In this case, what I really want to do right now it look at annotated cython output to see if some things are compiling the way that I think they should be compiling, but this is a slightly more general question than that. -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: Ubuntu 11.10 SAGE compilation
Did the build work? (Maybe I need to wait 7 more hours for an answer.) I use Ubuntu 11.10, 64 bit, and I have a core i7-2600. I think building Sage using many processes usually takes me about 2 hours + 15 minutes, where the 2 hours is all ATLAS, and the 15 minutes is everything else. I'm building 4.8 now with the SAGE_ATLAS_LIB environment variable set, so maybe it will be faster (but I have a feeling that it doesn't make a difference for me). If you're still having trouble, I can post a binary. Maybe I should do that anyway. When ATLAS is trying to tune, it can get really messed up if there are other programs using the cpu too much, because that can make its timings inconsistent, and it can even get messed up if nothing else is running but cpu frequency scaling is turned on (and it is on my default, as it should be), and it can also messed up by the "turboboost" stuff that all processors do nowadays. So you might try turning off cpu frequency scaling, and if you get desperate you can probably go into the bios to turn off turboboost. (These clever tricks really make CPUs better, but they make it so much harder to get reliable benchmarks...) Also, some things that make the build go faster are: export SAGE_PARALLEL_SPKG_BUILD="yes" export MAKE="make -j8" (For some reason, you can't just type "make -j8" to make things build in parallel.) On Thu, Feb 9, 2012 at 6:02 AM, firebird wrote: > Thanks Jason/Volker > > Will persevere... Type of computer is I5-2320 Quadcore... Not on your > list of known processors. > Will try and find how to save tuning information after next test. > I am getting the message that compilation will take many hours. So I > will give it 12-24 hours. > I guess that I am compiling many of the packages to which there is a > SAGE interface as well. > > For me and others, how long is a typical compiliation and how big > should the install.log file be? > Are there any sample install.logs that I could check out? > > Finally, is there a Ubuntu 11.10 version pending? > If not, I would be happy to go through a few extra loops and try to > publish mine! > > FireBird > > > On Feb 8, 6:27 pm, Jason Grout wrote: > > On 2/8/12 10:39 AM, firebird wrote: > > > > > Thanks for the prompt response, but it is barely credible... > > > > Atlas will sometimes do tuning, which means that it will run the same > > program lots of times with different values in order to ascertain > > exactly what parameters to use to get the fastest linear algebra. > > Sometimes this tuning takes hours and hours, if atlas doesn't already > > know about your CPU and computer configuration. The important thing > > then is to save that tuning information for the next time you compile > > atlas, or even better, submit that tuning information back upstream to > > the atlas project. > > > > How long did you let it go before terminating? What kind of computer > > are you compiling on? > > > > Thanks, > > > > Jason > > -- > To post to this group, send email to sage-support@googlegroups.com > To unsubscribe from this group, send email to > sage-support+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-support > URL: http://www.sagemath.org > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: Programming animation
On Thu, Feb 9, 2012 at 6:19 PM, Nils Bruin wrote:
>
> Another thing is that for longer animations, an animated GIF is
> probably not the best format. You should probably use something that
> can collate a bunch of frames into an mpeg movie or similar. I am sure
> there are command-line programs for that which would allow you to take
> the same approach as with "convert". Good luck!
>
>
I usually use mencoder for animations. I almost always need to look up
command syntax, so here is the same example, except it makes a 10 second
avi with 100 frames. One note about this, though: I feel like mencoder
often (always?) produces avi files that many programs can't understand.
There are probably some command line options which will fix the format, but
I think my current strategy is to use HandBrake after mencoder to convert
the movie to a different format.
Another note: for this sort of thing I find @parallel to be great. (Except
it won't really help here because the bottleneck is Tachyon, which is
already multithreaded and, at least on my desktop, already hits all my cpus
at 100%.)
##
var('t')
s = vector((2*cos(t)^2,3*sin(t),2*t))
t1 = 0
t2 = 4*pi
C = parametric_plot(s,(t,t1,t2),color='orange',thickness=6, opacity=.7)
def scene(f):
return C + point3d(s(t=f*(t2-t1)),size=15,color='purple')
os.mkdir("my_anim")
number_of_frames = 100
for frame_number in range(number_of_frames):
scene(frame_number/number_of_frames).save("my_anim/frame%s.png"%sage.misc.misc.pad_zeros(frame_number,8))
frames_per_second = 10
cmd = '''cd "my_anim"; sage-native-execute mencoder "mf://*.png" -mf fps=%d
-ovc lavc -o movie.avi '''% int(frames_per_second)
from subprocess import check_call, CalledProcessError
check_call(cmd, shell=True)
os.system("mv my_anim/movie.avi movie.avi; rm my_anim/*; rmdir my_anim")
##
(I had no idea if this would work on sagenb.org, so I tried, and it does.
Sure enough, though, the output of mencoder is some format that Chrome
won't play. I can download the movie and play it locally, though, and maybe
some other web browsers would play it.)
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
Re: [sage-support] sagenb.org timeout
I could be wrong, but I think that sagenb.org has a timeout on all computations, which may be different than any timeout due to idleness. It may reset everything every 10 minutes or so, to prevent long-running or otherwise intensive computations from using up all of the resources on the server. So I think might be a "feature", not a bug. If it happens on a local notebook server that wasn't intentionally setup this way, then I think that would be a bug. On Thu, Aug 25, 2011 at 10:01 PM, VictorMiller wrote: > I'd been running some computations on sagenb.org which involved > (implicitly) asking Singular to make some groebner basis > calculations. I was never able to complete it because it would > eventually appear to finish, but at that point it acted as though the > worksheet was restarted (and silently -- at least if it were going to > do this it would be nice to have a message). Upon reading some posts > today I realized that this was happening because of a timeout > parameter in the notebook. However, if I'm in the middle of a > calculation I'm not idle! I understand that because the calculation > is being farmed out to Singular it might look like SAGE is idle, but > it isn't. Should there be a trac ticket for this? > > Victor > > -- > To post to this group, send email to sage-support@googlegroups.com > To unsubscribe from this group, send email to > sage-support+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-support > URL: http://www.sagemath.org > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] modifying a plot after creation
Sometimes I plot a function that takes a long time to compute: P = plot(f, 0, 10) # (wait a long time) and then I decide that, oops, I wanted that plot to be red, or I wanted the lines to be dashed, or... So then I make a new plot by typing P = plot(f, 0, 10, rgbcolor=(1, 0, 0)) # (wait a long time again) Is there a way to change the color, or change the line type, etc. without recalculating the plot (and waiting a long time again)? -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] plotting a matrix with pixels corresponding to entries
Does anyone know how to plot a matrix so that each pixel in the output picture corresponds precisely to an entry in the matrix? To see the problem that I have, you might see the odd results that occur when you do: M = zero_matrix(GF(2), 1000) sage: M 1000 x 1000 dense matrix over Finite Field of size 2 sage: for n in range(1000): : for m in range(1000): : if (n + m) % 2 == 0: : M[n,m] = 1 : sage: M sage: plot(M).show(figsize=[5,5]) sage: plot(M).show(figsize=[6,6]) # <-- This one in particular might be very surprising. sage: plot(M).show(figsize=[7,7]) I'm pretty sure that I understand why these problems occur, and I'm not sure if there is any good way to fix them. What I would like to be able to do is be able to take the above matrix and produce an image with alternating black and white pixels, for example. Is this possible? I'm not particularly concerned about the border, or labels for the matrix, right now. I just want the picture of the matrix itself to look right. --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Summation
The trac ticket listed in the other email is relevant for symbolic
summation, when you want to represent 1 + x^2 + ... + x^n for n a
symbolic variable. It looks like you just want to do this for a fixed
number, such as n = 10. For this, you can write
sage: sum(x^i for i in (0..10))
x^10 + x^9 + x^8 + x^7 + x^6 + x^5 + x^4 + x^3 + x^2 + x + 1
or
sage: sum(x^i for i in (0..100))
x^100 + x^99 + x^98 + x^97 + x^96 + x^95 + x^94 + x^93 + x^92 + x^91 +
x^90 + x^89 + x^88 + x^87 + x^86 + x^85 + x^84 + x^83 + x^82 + x^81 +
x^80 + x^79 + x^78 + x^77 + x^76 + x^75 + x^74 + x^73 + x^72 + x^71 +
x^70 + x^69 + x^68 + x^67 + x^66 + x^65 + x^64 + x^63 + x^62 + x^61 +
x^60 + x^59 + x^58 + x^57 + x^56 + x^55 + x^54 + x^53 + x^52 + x^51 +
x^50 + x^49 + x^48 + x^47 + x^46 + x^45 + x^44 + x^43 + x^42 + x^41 +
x^40 + x^39 + x^38 + x^37 + x^36 + x^35 + x^34 + x^33 + x^32 + x^31 +
x^30 + x^29 + x^28 + x^27 + x^26 + x^25 + x^24 + x^23 + x^22 + x^21 +
x^20 + x^19 + x^18 + x^17 + x^16 + x^15 + x^14 + x^13 + x^12 + x^11 +
x^10 + x^9 + x^8 + x^7 + x^6 + x^5 + x^4 + x^3 + x^2 + x + 1
On Thu, 2009-10-08 at 08:33 -0500, Kim, In-Jae wrote:
> Hello,
>
> I was wondering how I can write the polynomial, 1+x+x^2 + ...+x^10, using
> summation.
> I tried
> sage: var('i,x')
> sage: sum(x^i, (i,0,10)),
>
> but I got the following error message:
>
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/sage/sagenb/sage_notebook/worksheets/matrix89/26/code/6.py",
> line 7, in
> sympy.sum(x**i, (i,_sage_const_0 ,_sage_const_10 ))
> File "", line 1, in
>
> NameError: name 'sympy' is not defined
>
> Thank you.
>
> In-Jae
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: problem with GCD in notebook
I'm not sure why you are getting different results from sagenb.com and from the "shell", but I would guess that you must be using two different versions of Sage. Either way... The problem is that when you divide two integers, the result is always a rational number, whether or not that rational number happens to be an integer. Then, when you ask for the divisors of a rational number (Not that I'm even sure why this should make sense), you get back a list of rational numbers. For rational numbers, Sage decides to always return a GCD of 1: sage: a.gcd sage: a.gcd? Type: builtin_function_or_method Base Class: String Form: Namespace: Interactive Docstring: Return a gcd of the rational numbers self and other. If self = other = 0, this is by convention 0. In all other cases it can (mathematically) be any nonzero rational number, but for simplicity we choose to always return 1. EXAMPLES:: sage: gcd(1/3, 2/1) 1 sage: gcd(1/1, 0/1) 1 sage: gcd(0/1, 0/1) 0 In particular, we have: sage: gcd(3/1, 3) 1 sage: gcd(3, 3) 3 You can get the behavior that you want by forcing quot to be an Integer, as in: quot = Integer(D/dhat) I feel like Sage is doing something wrong here, but I'm not sure what the right thing to do is. A strange example: sage: factor(15/2) 2^-1 * 3 * 5 sage: a = divisors(15/2); a [1, 3, 5, 15] sage: type(a[0]) On Mon, 2009-03-02 at 18:12 -0600, Martin Mereb wrote: > I had this function in a worksheet at sagenb.com > > def Z(D,t,dhat): > quot=D/dhat > sum=0 > for l in divisors(quot): > a=l*dhat > print a, t, GCD(a,t) > sum=sum+GCD(a,t) > return sum > > > and Z(3,3,1) returns > 1 3 1 > 3 3 1 > 2 > > which means GCD(3,3)=1 > > I know that in order to solve the problem I had to put quot=ZZ(D/dhat) > instead of quot=D/dhat > (I took me a while, though). > > I didn't have that problem in the Shell > sage: def Z(D,t,dhat): > : quot=D/dhat > : sum=0 > : for l in divisors(quot): > : a=l*dhat > : print a, t, GCD(a,t) > : sum=sum+GCD(a,t) > : return sum > : > sage: Z(3,3,1) > 1 3 1 > 3 3 3 > 4 > > so I see a difference here. > cheers > > > tincho > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: simplifying exponents
On Tue, 2008-06-10 at 12:56 -0700, Carl Witty wrote:
> On Jun 10, 10:44 am, polo0691 <[EMAIL PROTECTED]> wrote:
> > Thanks for creating sage! I can really see how useful sage could be
> > for engineering purposes. I've been playing around with sage for a
> > couple of days and I have had trouble with the following:
> >
> > 1) simplifying equations with exponents:
> >
> > sage: var('vgs vt n')
> > (vgs, vt, n)
> > sage: f = (vgs - vt)^n
> > sage: f^(1/n)
> > ((vgs - vt)^n)^(1/n)
> > sage: f^(1/n).simplify()
> > ((vgs - vt)^n)^(1/n)
> >
> > It doesn't seem to easily simplify the exponent. I'm guessing it
> > is a limitation of the CAS engine used. I also tried the same test
> > case on YACAS and it didn't seem to want to simplify the exponent
> > either.
>
> I'm not surprised this doesn't simplify: there's no consistent
> definition for exponentiation that lets you safely apply the
> simplification you want. To pick a simple case, over the reals,
> squaring followed by square root gives the absolute value:
>
> sage: ((-2)^2)^(1/2)
> 2
Sometimes you can use 'assume' to get the behavior you want, however. In
this case, for example:
sage: var('vgs vt n')
(vgs, vt, n)
sage: f = (vgs - vt)^n
sage: assume(vgs > vt)
sage: f^(1/n)
vgs - vt
sage: forget()
sage: f^(1/n)
((vgs - vt)^n)^(1/n)
sage:
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] old downloads spkgs
An old sage directory that I have that's been upgraded only a few times has an spkg directory that's got more than 850 megs. This was only upgraded from 2.8.15.alpha1 to 2.10.1, so I imagine that this directory can get even larger. With the exception of the 'installed' directory, can everything else be safely deleted? (Actually, the same question stands for a new sage install, in which the spkg directory holds abound 200 megs. Is there a reason that already installed spkg's should be kept around?) -bober --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Animation "wiggling" question
The documentation for plot() says: The actual sample points are slightly randomized, so the above plots may look slightly different each time you draw them. I assume that this an easy way to get the behavior: Note that this function does NOT simply sample equally spaced points between xmin and xmax. Instead it computes equally spaced points and add small perturbations to them. This reduces the possibility of, e.g., sampling sin only at multiples of 2pi, which would yield a very misleading graph. So, perhaps this is a "feature". But it seems to me that the endpoints, at least, should be always included (if possible) when graphing a function, so maybe this is a bug. (Although it is nice to not include the endpoints when plotting something like sin(1/x).) But anyway, I think that you should be able to instead do: f = x*sin(x^2) v = [] graph = plot(f, [-1, 3], thickness = 1, rgbcolor = (1, 0 ,0)) for i in srange(50): v.append(graph) curve = animate(v) curve.show() On Wed, 2008-02-20 at 16:01 -0600, Jason Grout wrote: > dean moore wrote: > > I ran the code now living at < https://www.sagenb.org/home/pub/1691/ >, > > but the function's graph > > "wiggles," most notably by the right endpoint. Tested, both Firefox & > > Internet Explorer. Same thing. > > Read through < > > http://www.sagemath.org/doc/html/ref/module-sage.plot.plot.html >, but > > found nothing. > > > > I am animating a graph, so it appears in all frames. > > > > I fiddled a good deal, but was left wondering, "Is it weirdness with > > SAGE, or my bad coding?" I beat > > the problem to a snippet: > > > > /f = x*sin(x^2) > > v = [] > > for i in srange(50): > >graph = plot(f, [-1, 3], thickness = 1, rgbcolor = (1, 0 ,0), > > plot_points = 1000) > >v.append(graph) > > curve = animate(v)/ > > /curve.show() > > > > Wow, this is a great animation. Sorry the plotting is so distracting at > the ends! > > To narrow down the issue, I executed the following after the code you gave: > > sage: endpoints = [v[i][0].xdata[-1] for i in srange(50)] > sage: max(endpoints) - min(endpoints) > 0.0039542538407206784 > > This computes the endpoints for the x-values that are sampled to plot > the graph. That's quite a spread for having the exact same inputs, > which explains the noticable wiggling. > > So now the question is: why in the world do we have such different > endpoints? > > I might point out that the wiggling is not just at the endpoints of the > graph. The wiggling is throughout the graph; it's just really > noticeable at the endpoints. > > Jason > > > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: strange list behavior
Hi.
short answer: immediately after the line
while i < 4:
add the line
P = [0,0]
Your problem seems to be that when you put something in a list, python
does not make a copy of it, but instead stores that actual object in the
list. So the line
pts.append(P)
appends the object P (or, rather, the object that P references) to the
list pts. Thus, when you change P, you also 'change' the list. (A better
way to think of it, though, is that you don't actually change the list
by changing P. Instead, you might think of the list as eventually
looking like
[P, P, P, ..., P]
because all you did was append the same object a bunch of times, so of
course all of the entries in pts are the same at the end.)
The line
P = [0,0]
creates a new list (which P now references). Putting that line in the
while loop should fix the problem because you will be adding a different
object to the list each time.
A simpler example is
sage: x = ['something']
sage: y = x # now x and y are the SAME OBJECT
sage: x
['something']
sage: y
['something']
sage: x[0] = 'something else'
sage: y # since x and y are the same object, they have the same contents
['something else']
sage: x = ['something else again'] # now x references a new object,
sage: y# so y doesn't change
['something else']
-bober
On Wed, 2008-01-09 at 21:25 -0800, benjamin antieau wrote:
> Code for the worksheet attached below.
>
> There must surely be a simple answer to this problem, but I have not
> been able to figure it out. I loop through i,j print the list
> [i,j], and append the list to pts. However, once appended to points
> something goes wrong, and all that points sees are the constant lists
> [3,3]. I have changed the various constants and such, but I am at a
> loss to explain why this is happening.
>
> What I need is for pts to contain the correct information. Any help
> would really be appreciated.
>
> Ben
>
> {{{id=125|
> P=[0,0]
> i=0
> pts=[]
> while i<4:
> P[0]=i
>
> j=0
> while j<4:
> P[1]=j
> print P
> pts.append(P)
> j+=1
> i+=1
> pts
> ///
> [0, 0]
> [0, 1]
> [0, 2]
> [0, 3]
> [1, 0]
> [1, 1]
> [1, 2]
> [1, 3]
> [2, 0]
> [2, 1]
> [2, 2]
> [2, 3]
> [3, 0]
> [3, 1]
> [3, 2]
> [3, 3]
> [[3, 3], [3, 3], [3, 3], [3, 3], [3, 3], [3, 3], [3, 3], [3, 3], [3,
> 3], [3, 3], [3, 3], [3, 3], [3, 3], [3, 3], [3, 3], [3, 3]]
> }}}
>
> >
>
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~--~~~~--~~--~--~---
[sage-support] Re: "Wall time leak"?
On Sat, 2007-10-27 at 12:03 -0700, Simon King wrote: > Problem was: > i) When i computed some cup product out of copies of these cocycles, > then the CPU time was 0.4s, but the Wall time 2.2s. I think this is an > inacceptable overhead. I suspect that part of the reason for this is that cpu time spent in the maxima process is not counted by 'time'. (Because it is going on in a different process.) > ii) When i repeated this computation several times, then the CPU time > remained about 0.4s, but the Wall time increased up to more than 7s. > I'm not talking about increasingly complicated computations -- it was > a repetition of THE SAME computation! > iii) When i analysed the problem using "prun", i observed that the > "time per call" of some Maxima functions increased under repetition. > > Solution: > Replace "log(f,10)+1" by "len(str(f))", and do this computation only > if f (which is the field size) has changed. Something does seem wrong here to me. What is f, exactly? (Well, I assume that f is an integer, but is its type sage.rings.integer.Integer, or something else? Also, how big is f, typically?) As an aside, both of these are bad ways of finding the number of digits of an integer (although I don't think there is a better way right now). log(f,10) converts f to a base 10 string so that it can send it to maxima, so, internally, it does str(f). Meanwhile, the first thing that str(f) does is compute the number of digits of f so that it knows how much space it needs to allocate for the string. There should probably be an Integer.number_of_digits() function, or something like that. In fact, I wrote such a function a while back (just wrapping the equivalent function in gmp) but I never actually sent it in as a patch. I'm opening a ticket for this now I will probably put in a patch sometime in the next few days if no one beats be to it. (It's very simple, but I don't quite have time at the moment.) --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Systemwide 2.8.4.1 install on Ubuntu Feisty
> This is actually an unrelated issue. A user must have write permissions > to the *current* directory to run the notebook, since it stores its state > files in the current directory. Try instead: I've noticed this before, but I've never really thought too much about it. Because of this, I've got sage_notebook directories sprinked throughout different random places on my machine, and it's a little annoying. (And I also think that it is a little "rude" of sage to do this without my knowlegde.) Is there a good reason that sage doesn't simply use the .sage directory that it creates under my home directory for this? If not, then I would like to call this a bug. And even if there is a good reason, then I still might like to call it a bug. --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Bug: running scripts broken
My memory could be wrong, but I feel that this exact problem has
occurred before. (The problem of running scripts on the command line not
working -- not necessarily the exact same underlying cause for the
problem.)
This kind of basic functionality should probably be tested somewhere
automatically. Maybe a doctect with a line like
sage: os.system('.\sage something_or_other.sage')
might work. Or maybe this would need to be somehow tested outside the
doctest framework. I don't know. Just a thought.
On Tue, 2007-09-04 at 23:09 -0700, William Stein wrote:
> On 9/4/07, Markus Fraczek <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > after upgrading to 2.8.3.3 running scripts on command line (./sage
> > example.sage)
> > doesn't work anymore
> >
>
> Thanks. I will post a 2.8.3.4 version that fixes this problem and
> remove 2.8.3.3. You can wait for that (an hour), or just pull
> in a fix for this one problem by doing:
>sage: hg_scripts.pull()
>
> William
>
>
> > Best,
> > Marek
> >
> > [EMAIL PROTECTED] ~/temp/sage-2.7.3 $ ./sage
> > --
> > | SAGE Version 2.8.3.3, Release Date: 2007-09-04 |
> > | Type notebook() for the GUI, and license() for information.|
> > --
> >
> > sage: quit
> > Exiting SAGE (CPU time 0m0.00s, Wall time 0m1.61s).
> > [EMAIL PROTECTED] ~/temp/sage-2.7.3 $ ./sage example.sage
> > /home/marek/temp/sage-2.7.3/local/bin/sage-sage: line 686: syntax error near
> > unexpected token `<<<'
> > /home/marek/temp/sage-2.7.3/local/bin/sage-sage: line 686: `<<<
> > /tmp/sage-sage~base.IcHt1Y'
> >
> >
> >
> >
> > >
> >
>
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~--~~~~--~~--~--~---
[sage-support] Re: How to use SAGE from within C++ CGI?
On Tue, 2007-08-07 at 23:37 -0700, Yigal wrote: > Hi, > I'm building web site for interactive solving school math problems > using C++ CGI and open source math software. > As I've been told in maxima mailing list, instead of reinventing the > weel, i.e. carrying for interfaces to several CAS and other math > software (GiNaC, Pari, Maxima, Octave and so on), I should use SAGE. > So my question is, how can I use SAGE from within C++ CGI? I don't know if it is possible. If it is possible, then the correct question is probably "How can I use Python from within C++?" > Or may be I > should change the concept and to choose other CGI options like PHP or > Perl for it? If you want to use SAGE, then the correct answer is, probably, just use SAGE. More specifically, python has built-in support for CGI through the cgi module: http://docs.python.org/lib/module-cgi.html and SAGE is built on top of python. So you should be able to use everything in the cgi module (or any other python module) just fine from within SAGE. (Alternately, you may think of SAGE as just python with a bunch of extra modules preloaded.) > Thanks for the help in advance. > Yigal Asnis > > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Sage freezes
The problem is that Primes() is an infinite set and that the line P = (x for x in Primes() if x<1) essentially "filters" Primes(). That is, as you iterate through, it examines each member of Primes(), and then asks, "is this number < 1"? Unfortunately, the syntax used knows nothing about the fact that Primes() is sorted, so it has to examine every element of Primes(). Anyway, you should use P = prime_range(1,1) instead. That should work. Alternately, you can use P = (x for x in xrange(1) if x in Primes()) or P = primes(1) to get a generator object. (The capitalization here is important.) On Mon, 2007-06-11 at 18:42 -0700, mak wrote: > I type in the following: > > eu=[-1,-2,-3,-7,-11] > > P=(x for x in Primes() if x<1) > > for p in P: > if sum((kronecker(D,p) for D in eu))==5: > print p > > and I do get my list of primes printed out, but sage seizes up: in the > shell version I don't get the next prompt, in the notebook the little > waiting wheel keeps spinning and it won't evaluate new cells. Help?? > > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
