[sage-devel] Re: polytopes, triangulation, proposal to add lrs
2008/9/23 mhampton <[EMAIL PROTECTED]>: > > Thanks Arnaud. I have reviewed it on trac. > > Because of the issues I mentioned in the review, I didn't test your > code on larger high-dimensional examples. But you did say it was slow > in high-dimensions. If that is still the case after fixing the > current problems it might make sense to use a random lifting first, > which is pretty fast, and then if that fails use your code. I will > also eventually add an option at least to use lrs, since that's > probably faster on hard problems than anything we can write in a > reasonable amount of time. I believe I have addressed all issues in my latest patch. Now the time it takes depends on the number of faces and the number of points these faces have. Dimension is irrelevant. To give some data points, the first example in doctest takes about 110ms and the two others take about 200ms (not including the time it takes to build the polyhedron). Please review again. Arnaud > Cheers, > Marshall Hampton > > On Sep 23, 1:01 am, "Arnaud Bergeron" <[EMAIL PROTECTED]> wrote: >> My code is up for review at #4164 >> >> Arnaud > > > -- La brigade SnW veut vous recruter - http://brigade.snw.googlepages.com --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to make tut and ref
On Sep 23, 2008, at 20:17 , mabshoff wrote: > > > > On Sep 23, 8:14 pm, mabshoff <[EMAIL PROTECTED]> wrote: > > > >> IIRC "." is sh syntax, but also works with bash. "source" does not >> work on csh and its descendants, i.e. tcsh to mention the most >> common. > > Oops, do I look like an idiot now. "source" obviously works with csh & > friends, but the sage-env script only works with bash. Time to catch > some sleep Ah... FWIW, you don't look like an idiot (just sleepy :-}) Cheers, Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- My wife 'n kids 'n dogs are gone, I can't get Jesus on the phone, But Ol' Milwaukee's Best is my best friend. --- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to make tut and ref
On Sep 23, 2008, at 20:14 , mabshoff wrote: > On Sep 23, 7:30 pm, "Justin C. Walker" <[EMAIL PROTECTED]> wrote: >> On Sep 23, 2008, at 11:15 , CristianCantoro wrote: > > > >>> Thanks Michael, that worked! >>> just to know... what does "source local/bin/sage-env" do? >>> I will start the translation as soon as I can. >> >> 'source' is a shell built-in that reads shell commands from the named >> file (until EOF) and then goes back to its previous source of input. >> It executes the commands in its own process, not in a subshell, so >> the >> effects remain after the end of the file. >> >> See the man page for the shell you are using for details (I'm not >> sure >> that all shells support this; and the name of the command may change. >> '.' is a synonym for 'source' [at least for "bash"]). > > IIRC "." is sh syntax, but also works with bash. "source" does not > work on csh and its descendants, i.e. tcsh to mention the most common. > Any Unix person knows that csh and tcsh are canonically evil ;). To > get everybody fired up: Emacs sucks, vi is the one true editor. > Recently I have felt that notepad.exe is the answer to all questions, > but I need to lie down for a while That's odd. "man tcsh" definitely says source [-h] name [args ...] The shell reads and executes commands from name. The commands are not placed on the history list. If any args are given, they are placed in argv. (+) source commands may be nested; if they are nested too deeply the shell may run out of file descriptors. An error in a source at any level terminates all nested source commands. With -h, commands are placed on the history list instead of being executed, much like `history -L'. (and I tried this; it works). At least on Mac OS X (10.5.4 to be specific), 'source' does what it should with bash, sh, zsh, tcsh, and csh. YMMV :-} Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- My wife 'n kids 'n dogs are gone, I can't get Jesus on the phone, But Ol' Milwaukee's Best is my best friend. --- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to make tut and ref
On Sep 23, 8:14 pm, mabshoff <[EMAIL PROTECTED]> wrote: > IIRC "." is sh syntax, but also works with bash. "source" does not > work on csh and its descendants, i.e. tcsh to mention the most common. Oops, do I look like an idiot now. "source" obviously works with csh & friends, but the sage-env script only works with bash. Time to catch some sleep Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to make tut and ref
On Sep 23, 7:30 pm, "Justin C. Walker" <[EMAIL PROTECTED]> wrote: > On Sep 23, 2008, at 11:15 , CristianCantoro wrote: > > Thanks Michael, that worked! > > just to know... what does "source local/bin/sage-env" do? > > I will start the translation as soon as I can. > > 'source' is a shell built-in that reads shell commands from the named > file (until EOF) and then goes back to its previous source of input. > It executes the commands in its own process, not in a subshell, so the > effects remain after the end of the file. > > See the man page for the shell you are using for details (I'm not sure > that all shells support this; and the name of the command may change. > '.' is a synonym for 'source' [at least for "bash"]). IIRC "." is sh syntax, but also works with bash. "source" does not work on csh and its descendants, i.e. tcsh to mention the most common. Any Unix person knows that csh and tcsh are canonically evil ;). To get everybody fired up: Emacs sucks, vi is the one true editor. Recently I have felt that notepad.exe is the answer to all questions, but I need to lie down for a while > HTH > > Justin Cheers, Michael > -- > Justin C. Walker, Curmudgeon at Large > Director > Institute for the Enhancement of the Director's income > --- > -- > They said it couldn't be done, but sometimes, > it doesn't work out that way. > - Casey Stengel > -- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to make tut and ref
On Sep 23, 2008, at 11:15 , CristianCantoro wrote: > > Hi! > > On Sep 23, 3:03 am, mabshoff <[EMAIL PROTECTED]> wrote: >> There is a README.txt in devel/doc which might be hepful. You should >> also "source local/bin/sage-env" from $SAGE_ROOT before running make >> in the doc directory. Another thing worth trying is to delete all of >> the various temporary TeX remnants like *.toc files since those tend >> to cause trouble when switching from TeTeX to certain distributions >> like TeX Live. > > Thanks Michael, that worked! > just to know... what does "source local/bin/sage-env" do? > I will start the translation as soon as I can. 'source' is a shell built-in that reads shell commands from the named file (until EOF) and then goes back to its previous source of input. It executes the commands in its own process, not in a subshell, so the effects remain after the end of the file. See the man page for the shell you are using for details (I'm not sure that all shells support this; and the name of the command may change. '.' is a synonym for 'source' [at least for "bash"]). HTH Justin -- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's income --- -- They said it couldn't be done, but sometimes, it doesn't work out that way. - Casey Stengel -- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: ATLAS compilation failure with SAGE 3.1.2
On Sep 23, 2:14 pm, bourbabis <[EMAIL PROTECTED]> wrote: Hi, > 1) My computer is a desktop with an Athlon k7 800Mhz + 384 Mo RAM. Ouch. > The hardware sensor checking the temperature is up an running but > never > set off an alarm. Ok, but that does not mean that the CPU is not overheating. > 2) I've given it a try again, but compilation has leaded to the same > failure. > I saw this in the log file : > "ATLAS failed to build because your system is too heavily loaded to > obtain > accurate timing. Please restart the build by typing make, when the > load on > your system has decreased." This is different than the previous crash. Does the kernel you use have throttling enabled? If so turn that off (you need to be root to do that). > This message has appeared although I took care not launching others > parallel > tasks to avoid overload. > > 3) I saw in the trac list a ticket suggesting to reuse the Atlas > package provided by the current stable debian distro (this is the one > I use). May be I just have to be patient. I currently use a pre- > compiled > Sage version 2.11 provided by the sage team (named Debian+k7). But I > don't > want to bother you asking for a new one since my architecture is > somewhat > outdated now, and I suppose, there is too little demand. Well, don't worry. What you should do is to follow the FAQ at http://wiki.sagemath.org/faq - sepcifically "QUESTION: I downloaded a Sage binary and it crashes on startup with Illegal instruction. What can I do?". In order to make Sage believe that ATLAS is installed run touch spkg/installed/atlas-3.8.1.p3 from $SAGE_ROOT and then restart the build process with make after copying the system ATLAS in the $SAGE_LOCAL/bin directory and the headers in $SAGE_LOCAL/include/atlas, i.e. it should look something like [EMAIL PROTECTED]:/scratch/mabshoff/release-cycle/sage-3.1.3.alpha0$ ls - la local/include/atlas/ total 176 drwxr-xr-x 2 mabshoff 1090 4096 2008-09-17 20:36 . drwxr-xr-x 28 mabshoff 1090 4096 2008-09-23 18:56 .. -rw-r--r-- 1 mabshoff 1090 2179 2008-09-17 20:36 atlas_buildinfo.h -rw-r--r-- 1 mabshoff 1090 90 2008-09-17 20:36 atlas_cacheedge.h -rw-r--r-- 1 mabshoff 1090 147 2008-09-17 20:36 atlas_cmv.h -rw-r--r-- 1 mabshoff 1090 2717 2008-09-17 20:36 zmm.h -rw-r--r-- 1 mabshoff 1090 528 2008-09-17 20:36 zXover.h [EMAIL PROTECTED]:/scratch/mabshoff/release-cycle/sage-3.1.3.alpha0$ > Anyway, if you have some suggestions, I listen to you... > > And thanks again for this great soft ! No problem, hope this helps. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to make tut and ref
On Sep 23, 11:15 am, CristianCantoro <[EMAIL PROTECTED]> wrote: > Hi! > Thanks Michael, that worked! Good. > just to know... what does "source local/bin/sage-env" do? It sets up the Sage environment properly, i.e. the location of Sage and so on which is needed for a couple scripts that assume file to be in certain places. > I will start the translation as soon as I can. Good, have fun. > Cristian Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: fixes to the real precision for Pari library (trac #4096)
Hi Georg, Thanks for volunteering to look at this. Craig's also doing this, but a second pair of eyes is always welcome. Don't hesitate to ask questions if something in the patches looks fishy. I have updated Jason Grout's notes on mercurial queues at http://wiki.sagemath.org/MercurialQueues so that it can be used as a quick start tutorial. You should be able to follow those steps to review any patches from trac, or to submit your own code. There's no need to install anything, since mercurial (and the extension mercurial queues) comes bundled with Sage. Best, Alex On Wed, Sep 24, 2008 at 8:37 AM, Georg S. Weber <[EMAIL PROTECTED]>wrote: > > it's not the smallest of patches, but at a first and at a second sight > it is not only very well done, e.g. with accurate doctests for the > nice new functions, but also presented "on a silver plate". > I still have to learn how to use Mercurial, how to apply a patch on a > branch, and such; and it would take me probably more than one weekend. > But if nobody else steps up, I'll volunteer to review. > Of course, if somebody is already doing this, please tell me, to > combine efforts (not blindly just double them), thanks! > > -- Alex Ghitza -- Lecturer in Mathematics -- University of Melbourne -- Australia --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: does PARI know the primes up to 35?
> sage: K. = CyclotomicField(23) > sage: K.class_number() > > ... > > PariError: not enough precomputed primes, need primelimit ~ (35) > Hah, that's pretty hilarious. :) Actually, what it's telling you is that it needs primes up to a primelimit, and then it doesn't actually put in the primelimit. (This is a bug in our processing of Pari's error messages.) It's then saying that this is PariError #35. The effect is awesome, though. The real answer to your question, though, is that Pari can't provably certify its result for the class number of K without using more than the default number of primes. Of course, it's more than happy to just run along without certifying the result: sage: K.class_number(proof=False) 3 I just ran a GP session, and set it going with a much larger primelimit; it's still computing. So this brings up at least two interesting questions: 1) If we try to compute something for the user, with proof, and Pari tells us that it couldn't do it using whatever information it has prerendered, how many times should we add to that info and try again? For instance, we happily add memory and try again until we're out of memory; should we do the same thing in this case? Should we let the user know? Should we bail out and give a non-verified answer, along with telling the user that this is what we did? 2) Should we have better documentation for certain functions (such as this one!) saying, "Even in moderately sized cases, certifying this result can be computationally intensive. Consider using proof=False." And maybe one last good question: David, were you surprised that Pari/Sage couldn't tell you this? Would you have preferred a non-verified answer (along with information that it wasn't provably correct, of course), what you got, or something else entirely? -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.3.alpha0 released
On Sep 23, 4:05 pm, "Georg S. Weber" <[EMAIL PROTECTED]> wrote: > Hi, > > On 24 Sep., 00:34, mabshoff <[EMAIL PROTECTED]> wrote: > > > > > On Sep 23, 3:27 pm, "Georg S. Weber" <[EMAIL PROTECTED]> > > wrote: > > > > On 23 Sep., 10:07, "John Cremona" <[EMAIL PROTECTED]> wrote: > > > > > > > I'll open more tickets for other failures, as soon I can say for sure > > > "it' only timing" and have a new "good" timing constant. > > > Please do not open any more tickets, but post the logs somewhere so I > > can take a long. The timeout for long is 30 minutes, so if the test > > does not finish it is most likely that the job either got pushed > > deeply into swap or something else bad happened. "testlong" is not > > meant for ancient PPC boxen :) Oops, I meant to answer this, too. > Well, that's a question of how much robustness you want. > If it does work even on five-year old PPCs, it is less likely to break > randomly in other "unforseen" circumstances. E.g. porting should be > the easier, the more robust and stable Sage is ;-) Sure, I agree. But if you start some test series that explicitly mentions that it is "long" don't expect it to work on some ancient piece of hardware. I agree that you uncovered and fixed some long outstanding bug which is highly appreciated, but there is a limit to what is fixable, i.e. when you do hit swap deeply it is game over and there is nothing we can do. What might be a good idea is to add "#large" to the doctests so that we can do more fine tuned doctesting and on machines with known little memory -long would work and not run the tests that will bring it to its knees because of memory consumption. I just talked to Mike Hansen and we will upgrade clisp as well as Maxima in 3.1.3.alpha1 tonight, so let's see how that plays out on your PPC machine :) Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.3.alpha0 released
On Sep 23, 4:05 pm, "Georg S. Weber" <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> On 24 Sep., 00:34, mabshoff <[EMAIL PROTECTED]> wrote:
>
> > On Sep 23, 3:27 pm, "Georg S. Weber" <[EMAIL PROTECTED]>
> > wrote:
>
> > > On 23 Sep., 10:07, "John Cremona" <[EMAIL PROTECTED]> wrote:
>
> >
>
> > > I'll open more tickets for other failures, as soon I can say for sure
> > > "it' only timing" and have a new "good" timing constant.
>
> > Please do not open any more tickets, but post the logs somewhere so I
> > can take a long. The timeout for long is 30 minutes, so if the test
> > does not finish it is most likely that the job either got pushed
> > deeply into swap or something else bad happened. "testlong" is not
> > meant for ancient PPC boxen :)
>
> Well, that's a question of how much robustness you want.
> If it does work even on five-year old PPCs, it is less likely to break
> randomly in other "unforseen" circumstances. E.g. porting should be
> the easier, the more robust and stable Sage is ;-)
>
> > > Cheers,
> > > gsw
>
> > Cheers,
>
> > Michael
>
> Here are the log snippets, first three "good ones" to give you a
> timing impression of this old box:
>
> sage -t -long devel/sage/sage/algebras/algebra.py
> [45.0 s]
> sage -t -long devel/sage/sage/algebras/algebra_element.py
> [13.7 s]
> sage -t -long devel/sage/sage/algebras/algebra_ideal.py
> [14.5 s]
>
>
>
> sage -t -long devel/sage/sage/calculus/calculus.py
> **
> File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/calculus.py",
> line 2262:
> sage: (z + exp(x)).laplace(x, s)
> Expected:
> z/s + 1/(s - 1)
> Got:
> Maxima crashed -- automatically restarting.
> _tmp_
> **
> 1 items had failures:
> 1 of 26 in __main__.example_64
> ***Test Failed*** 1 failures.
> For whitespace errors, see the file /Volumes/SageVolume/sage/
> sage-3.1.3.alpha0/tmp/.doctest_calculus.py
> [791.4 s]
>
>
>
> sage -t -long devel/sage/sage/crypto/mq/sr.py
> halt 14
>
> error: no more memory
> System 430592k:434784k Appl 425481k/5110k Malloc 4058k/37k Valloc
> 426496k/5073k Pages 106518/106 Regions 833:841
>
> A mysterious error (perphaps a memory error?) occurred, which may have
> crashed doctest.
> [1318.0 s]
>
>
>
> sage -t -long devel/sage/sage/dsage/dist_functions/
> dist_factor.py*
> *
> For whitespace errors, see the file /Volumes/SageVolume/sage/
> sage-3.1.3.alpha0/tmp/.doctest_dist_factor.py
> [99.3 s]
>
>
Ok, this is a known issue. There are four DSage tickets in trac that
will hopefully be reviewed and merge soon that will fix that issue.
> sage -t -long devel/sage/sage/functions/piecewise.py
> [1013.0 s]
Maxima goes off to the deep end - not much we can do, but upgrade
clisp :)
>
>
> sage -t -long devel/sage/sage/groups/perm_gps/partn_ref/
> refinement_matrices.pyx*** *** Error: TIMED OUT! *** ***
> *** *** Error: TIMED OUT! *** ***
> [45062.1 s]
Hmm, this is insane, but I think you end up eating large amounts of
swap. Once you compute in swap it is game over. The code does not leak
by the way since we did valgrind it very intensely.
>
>
> sage -t -long devel/sage/sage/interfaces/psage.py
> **
> File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/psage.py", line
> 23:
> sage: w = [x('factor(2^%s-1)'% randint(250,310)) for x in v]
> Exception raised:
> Traceback (most recent call last):
> File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
> python2.5/doctest.py", line 1228, in __run
> compileflags, 1) in test.globs
> File "", line 1, in
> w = [x('factor(2^%s-1)'% randint(Integer(250),Integer(310)))
> for x in v]###line 23:
> sage: w = [x('factor(2^%s-1)'% randint(250,310)) for x in v]
> File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
> python2.5/site-packages/sage/interfaces/sage0.py", line 225, in
> __call__
> return SageElement(self, x)
> File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
> python2.5/site-packages/sage/interfaces/expect.py", line 1281, in
> __init__
> raise TypeError, x
> TypeError: Unable to start sage
Lack of memory space. Not much you can do. This does not mean that
enough virtual space is available, but that for example clisp cannot
be started twice in that setting on the same machine. clisp is a piece
of shit, i.e. on RHEL 5/Itanium it claims to have no memory available
to it even though 8GB are free and during configure its mmap interface
reports it to work. Oh well
>
> sage -t -long devel/sage/sage/matrix/
> matrix_symbolic_dense.pyx**
>
> File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/
> m
[sage-devel] Re: Sage 3.1.3.alpha0 released
Hi,
On 24 Sep., 00:34, mabshoff <[EMAIL PROTECTED]> wrote:
> On Sep 23, 3:27 pm, "Georg S. Weber" <[EMAIL PROTECTED]>
> wrote:
>
> > On 23 Sep., 10:07, "John Cremona" <[EMAIL PROTECTED]> wrote:
>
>
>
> > I'll open more tickets for other failures, as soon I can say for sure
> > "it' only timing" and have a new "good" timing constant.
>
> Please do not open any more tickets, but post the logs somewhere so I
> can take a long. The timeout for long is 30 minutes, so if the test
> does not finish it is most likely that the job either got pushed
> deeply into swap or something else bad happened. "testlong" is not
> meant for ancient PPC boxen :)
>
Well, that's a question of how much robustness you want.
If it does work even on five-year old PPCs, it is less likely to break
randomly in other "unforseen" circumstances. E.g. porting should be
the easier, the more robust and stable Sage is ;-)
> > Cheers,
> > gsw
>
> Cheers,
>
> Michael
Here are the log snippets, first three "good ones" to give you a
timing impression of this old box:
sage -t -long devel/sage/sage/algebras/algebra.py
[45.0 s]
sage -t -long devel/sage/sage/algebras/algebra_element.py
[13.7 s]
sage -t -long devel/sage/sage/algebras/algebra_ideal.py
[14.5 s]
sage -t -long devel/sage/sage/calculus/calculus.py
**
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/calculus.py",
line 2262:
sage: (z + exp(x)).laplace(x, s)
Expected:
z/s + 1/(s - 1)
Got:
Maxima crashed -- automatically restarting.
_tmp_
**
1 items had failures:
1 of 26 in __main__.example_64
***Test Failed*** 1 failures.
For whitespace errors, see the file /Volumes/SageVolume/sage/
sage-3.1.3.alpha0/tmp/.doctest_calculus.py
[791.4 s]
sage -t -long devel/sage/sage/crypto/mq/sr.py
halt 14
error: no more memory
System 430592k:434784k Appl 425481k/5110k Malloc 4058k/37k Valloc
426496k/5073k Pages 106518/106 Regions 833:841
A mysterious error (perphaps a memory error?) occurred, which may have
crashed doctest.
[1318.0 s]
sage -t -long devel/sage/sage/dsage/dist_functions/
dist_factor.py**
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/dist_factor.py",
line 29:
sage: f.wait(timeout=60) # long time
Exception raised:
Traceback (most recent call last):
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
python2.5/doctest.py", line 1228, in __run
compileflags, 1) in test.globs
File "", line 1, in
f.wait(timeout=Integer(60)) # long time###line 29:
sage: f.wait(timeout=60) # long time
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
python2.5/site-packages/sage/dsage/dist_functions/dist_function.py",
line 183, in wait
time.sleep(0.5)
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
python2.5/site-packages/sage/dsage/dist_functions/dist_function.py",
line 179, in handler
raise RuntimeError('Maximum wait time exceeded.')
RuntimeError: Maximum wait time exceeded.
**
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/dist_factor.py",
line 30:
sage: f.done # long time
Expected:
True
Got:
False
**
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/dist_factor.py",
line 32:
sage: print f # long time
Expected:
Factoring "42535295865117307932921825928971026431"
Prime factors found so far: [31, 601, 1801, 269089806001,
4710883168879506001]
Got:
Factoring "42535295865117307932921825928971026431"
Prime factors found so far: [31, 601, 1801]
**
1 items had failures:
3 of 10 in __main__.example_0
***Test Failed*** 3 failures.
[DSage] Closed connection to localhost
For whitespace errors, see the file /Volumes/SageVolume/sage/
sage-3.1.3.alpha0/tmp/.doctest_dist_factor.py
[99.3 s]
sage -t -long devel/sage/sage/functions/piecewise.py
**
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/tmp/piecewise.py",
line 399:
sage: Q = rsf.plot(rgbcolor=(0.7,0.6,0.6), plot_points=40)
Exception raised:
Traceback (most recent call last):
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
python2.5/doctest.py", line 1228, in __run
compileflags, 1) in test.globs
File "", line 1, in
Q =
rsf.plot(rgbcolor=(RealNumber('0.7'),RealNumber('0.6'),RealNumber('0.6')),
plot_points=Integer(40))###line 399:
sage: Q = rsf.plot(rgbcolor=(0.7,0.6,0.6), plot_points=40)
File "/Volumes/SageVolume/sage/sage-3.1.3.alpha0/local/lib/
python2.5/site-packages/sage/functions/piecewise.py", line 810
[sage-devel] Re: does PARI know the primes up to 35?
On Sep 23, 3:49 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> --
> | SAGE Version 3.1.2, Release Date: 2008-09-19 |
> | Type notebook() for the GUI, and license() for information. |
> --
>
> sage: K. = CyclotomicField(23)
> sage: K.class_number()
>
> *** Warning: large Minkowski bound: certification will be VERY
> long.
>
> ---
> PariError Traceback (most recent call
> last)
>
> /home/dmharvey/ in ()
>
> /home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
> number_field.py in class_number(self, proof)
> 2068 """
> 2069 proof = proof_flag(proof)
> -> 2070 return self.class_group(proof).order()
> 2071
> 2072 def composite_fields(self, other, names=None):
>
> /home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
> number_field.py in class_group(self, proof, names)
> 2038 except AttributeError:
> 2039 self.__class_group = {}
> -> 2040 k = self.pari_bnf(proof)
> 2041 cycle_structure = eval(str(k.getattr('clgp.cyc')))
> 2042
>
> /home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
> number_field.py in pari_bnf(self, certify, units)
> 1901 try:
> 1902 if certify:
> -> 1903 self.pari_bnf_certify()
> 1904 return self.__pari_bnf
> 1905 except AttributeError:
>
> /home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
> number_field.py in pari_bnf_certify(self)
> 1934 raise TypeError, "Unable to coerce number field
> defined by non-integral polynomial to PARI."
> 1935 if not self.__pari_bnf_certified:
> -> 1936 if self.pari_bnf(certify=False,
> units=True).bnfcertify() != 1:
> 1937 raise ValueError, "The result is not correct
> according to bnfcertify"
> 1938 self.__pari_bnf_certified = True
>
> /home/dmharvey/gen.pyx in sage.libs.pari.gen._pari_trap (sage/libs/
> pari/gen.c:33124)()
>
> PariError: not enough precomputed primes, need primelimit ~ (35)
:)
> david
IIRC pari to 2.3.4 which has some fixes in that are is out. We ought
to check and either way then upgrade to it.
Either way I have a list of eight spkgs that I want to upgrade in 3.2
and so far none of them has a trac ticket.
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@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-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: tests hang with 3.1.2
On Sep 23, 3:46 pm, "Georg S. Weber" <[EMAIL PROTECTED]> wrote: > Hi Dan, Hi Georg, > I can see this issue pretty often on my old PPC box. > However I'll sacrifice my time first for the pari precision patch to > get as soon as possible into 3.1.3, before going to look into more > detail into this maxima-sage thing. > It will not be forgotten, but probably take some time. > (And maybe I can't be of any help at all, but let's see.) There are two possibilities here: a) upgrade to prerelease 4 of clisp 2.47 b) switch to ecl (a) is less work for now and there are some fixes in there that solve some issues on Solaris/Sparc, so my hope is that it will fix those random-ish crashes we are seeing on x86-64 and also ppc. clisp-2.46 is known broken on Solaris/Sparc, i.e. Maxima and clisps' test suite itself segfaults. (b) is more work and not something I want to do this week since 3.1.3 is supposed to go out the door quickly. Since I want to update Maxima from 5.16.2 to 5.16.3 I will likely attempt to do the clisp update, but sooner or later I will do (b). > Cheers, > gsw Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: fixes to the real precision for Pari library (trac #4096)
> it's not the smallest of patches, but at a first and at a second sight > it is not only very well done, e.g. with accurate doctests for the > nice new functions, but also presented "on a silver plate". > I still have to learn how to use Mercurial, how to apply a patch on a > branch, and such; and it would take me probably more than one weekend. > But if nobody else steps up, I'll volunteer to review. > Of course, if somebody is already doing this, please tell me, to > combine efforts (not blindly just double them), thanks! > Hey Georg, I was planning on reviewing that patch tonight, since I'm fairly familiar with that part of the code -- but if you're interested, I could gladly give it a once-over, and leave you with the brunt of the work. :) If nothing else, getting one more person (especially someone who knows about modular forms!) up to speed with reviewing is a good thing. -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] does PARI know the primes up to 35?
--
| SAGE Version 3.1.2, Release Date: 2008-09-19 |
| Type notebook() for the GUI, and license() for information.|
--
sage: K. = CyclotomicField(23)
sage: K.class_number()
*** Warning: large Minkowski bound: certification will be VERY
long.
---
PariError Traceback (most recent call
last)
/home/dmharvey/ in ()
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in class_number(self, proof)
2068 """
2069 proof = proof_flag(proof)
-> 2070 return self.class_group(proof).order()
2071
2072 def composite_fields(self, other, names=None):
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in class_group(self, proof, names)
2038 except AttributeError:
2039 self.__class_group = {}
-> 2040 k = self.pari_bnf(proof)
2041 cycle_structure = eval(str(k.getattr('clgp.cyc')))
2042
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in pari_bnf(self, certify, units)
1901 try:
1902 if certify:
-> 1903 self.pari_bnf_certify()
1904 return self.__pari_bnf
1905 except AttributeError:
/home/was/s/local/lib/python2.5/site-packages/sage/rings/number_field/
number_field.py in pari_bnf_certify(self)
1934 raise TypeError, "Unable to coerce number field
defined by non-integral polynomial to PARI."
1935 if not self.__pari_bnf_certified:
-> 1936 if self.pari_bnf(certify=False,
units=True).bnfcertify() != 1:
1937 raise ValueError, "The result is not correct
according to bnfcertify"
1938 self.__pari_bnf_certified = True
/home/dmharvey/gen.pyx in sage.libs.pari.gen._pari_trap (sage/libs/
pari/gen.c:33124)()
PariError: not enough precomputed primes, need primelimit ~ (35)
david
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@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-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: tests hang with 3.1.2
Hi Dan, On 23 Sep., 14:37, Dan Drake <[EMAIL PROTECTED]> wrote: > On Wed, 17 Sep 2008 at 08:55PM -0700, mabshoff wrote: > > > but when I run 'make test', some test will simply stop. This happens > > > every time, and often with different tests. The CPU usage is zero, > > > and nothing happens. The test just sits there. > > > You can log the Sage<->Maxima communication and we can then poke > > around. Another thing is to run say calculus.py under -verbose and > > attempt to narrow it down. > > I was going to ignore that problem and just use a precompiled > binary...but I was getting similar problems with that when I did a lot > of calculus. So I'm hoping to understand this problem better. > > I've run doctests on calculus.py, and most of the time it finishes, but > sometimes it hangs. Using -verbose doesn't help; it gets to some test > and just waits. If I kill the relevant lisp.run process, the testing > will continue and report the failure. > > How I can log the Sage-Maxima communication? Does anyone know more about > this problem? > > Thanks, > > Dan > > -- > --- Dan Drake <[EMAIL PROTECTED]> > - KAIST Department of Mathematical Sciences > --- http://math.kaist.ac.kr/~drake > > signature.asc > < 1KViewDownload I can see this issue pretty often on my old PPC box. However I'll sacrifice my time first for the pari precision patch to get as soon as possible into 3.1.3, before going to look into more detail into this maxima-sage thing. It will not be forgotten, but probably take some time. (And maybe I can't be of any help at all, but let's see.) Cheers, gsw --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: fixes to the real precision for Pari library (trac #4096)
Hi, On 20 Sep., 01:58, "Alex Ghitza" <[EMAIL PROTECTED]> wrote: > Hi folks, > > John Cremona and I have been working for the past two weeks on fixing the > way real precision gets passed from Sage to the Pari library and back. > Things were extremely broken, due mostly to a misunderstanding of how the > Pari library (as opposed to GP sessions) deals with precision for inexact > numbers. Precision arguments were either ignored or passed with > ridiculously huge values. Although the most important conversion-to-pari > functions in the Sage library did things properly, many others were either > plain wrong or inconsistent. > > We have been working on this at trac #4096, where there is now a source > patch and a doc patch for your (re)viewing pleasure. The patch is large, > but the bulk of it consists of fixing precision in doctests. The new > (correct) precision behavior is documented toward the top of the file > libs/pari/gen.pyx. In a nutshell, the default real precision in > interactions with the Pari library is now 53 bits, the same as the default > real precision in Sage. This is also the precision with which Pari library > objects get printed (i.e. 15 significant decimals). The patch implements > this across the Sage code, resulting in a consistent and better documented > behavior. Happy side-effects include the removal of some bugs related to > special functions, more clear and consistent code, and uniform behavior > (where possible) on both 32-bit and 64-bit machines. > > We would greatly appreciate it if someone could review this. I am happy to > answer any questions/concerns you might have about the changes. > > Best, > Alex it's not the smallest of patches, but at a first and at a second sight it is not only very well done, e.g. with accurate doctests for the nice new functions, but also presented "on a silver plate". I still have to learn how to use Mercurial, how to apply a patch on a branch, and such; and it would take me probably more than one weekend. But if nobody else steps up, I'll volunteer to review. Of course, if somebody is already doing this, please tell me, to combine efforts (not blindly just double them), thanks! Cheers, gsw --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.3.alpha0 released
On Sep 23, 3:27 pm, "Georg S. Weber" <[EMAIL PROTECTED]> wrote: > On 23 Sep., 10:07, "John Cremona" <[EMAIL PROTECTED]> wrote: > I'll open more tickets for other failures, as soon I can say for sure > "it' only timing" and have a new "good" timing constant. Please do not open any more tickets, but post the logs somewhere so I can take a long. The timeout for long is 30 minutes, so if the test does not finish it is most likely that the job either got pushed deeply into swap or something else bad happened. "testlong" is not meant for ancient PPC boxen :) > Cheers, > gsw Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.3.alpha0 released
On 23 Sep., 10:07, "John Cremona" <[EMAIL PROTECTED]> wrote:
> 2008/9/23 William Stein <[EMAIL PROTECTED]>:
>
> I still don't know if this is going to help the MACOS problem with my
> sll_finite_field odctest though!
>
> John
>
Hi all,
first some on-topic data:
on my PPC PowerBook with Mac OS X 10.4 (and now Xcode 2.5, too):
Sage 3.1.3.alpha0 builds fine, and I got the following "make testlong"
failures:
sage -t -long devel/sage/sage/calculus/calculus.py
sage -t -long devel/sage/sage/crypto/mq/sr.py
sage -t -long devel/sage/sage/dsage/dist_functions/
dist_factor.py
sage -t -long devel/sage/sage/functions/piecewise.py
sage -t -long devel/sage/sage/groups/perm_gps/partn_ref/
refinement_matrices.pyx
sage -t -long devel/sage/sage/interfaces/psage.py
sage -t -long devel/sage/sage/matrix/matrix_symbolic_dense.pyx
sage -t -long devel/sage/sage/schemes/elliptic_curves/
ell_finite_field.py
sage -t -long devel/sage/sage/schemes/elliptic_curves/
ell_rational_field.py
sage -t -long devel/sage/sage/schemes/elliptic_curves/sha.py
Nothing surprising here. The hope that by using Xcode 2.5 instead
Xcode 2.4.1 would make vanish some failures vanish, was in vain, but
at least it does not seem that something new crept in by that.
As noted elsewhere, some failures are the sporadic "Maxima crashed --
automatically restarting" thing, for which no ticket exists yet due to
no really good description existing yet (but see the other sage-devel
thread "test hang with 3.1.2").
In sr.py it is noted in the doctest that the doctest will fail on
boxes with 2 GB of RAM "only", so no surprise either (768 MB < 2 GB).
In dist_factor.py, we just run into "f.wait(timeout=60) # long time"
and consequently "raise RuntimeError('Maximum wait time exceeded.')",
I opened trac #4178 for this.
In "ell_finite_field.py", we run into some seemingly Mac OS X specific
problem (maybe only 10.4, not 10.5, I can't check that).
Since that problem, as seems obvious by now, has absolutely nothing to
do with ellipitic curves or the algorithms as such, I have opened two
trac tickets. One that changes the doctest so that it tests what it
shall, but does not run into this bug, trac #4179. And one ticket for
the bug proper: trac #4181 it is now. Is there a "system doctest" or
some file where one could put this, until one knows how to fix it?
(Then, the fix must be accompanied by the doctest, of course.)
@John:
Would you please review #4179? Having thought over it, I came up with
this splitting of the issue, and we should heal the ellipitc curves
doctest, while persecuting the bug on other grounds.
Finally, the doctest failures in sha.py and "elliptic_real_field"
should go away with the pari precision patch.
I'll open more tickets for other failures, as soon I can say for sure
"it' only timing" and have a new "good" timing constant.
Cheers,
gsw
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@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-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: tests hang with 3.1.2
On Tue, Sep 23, 2008 at 3:11 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On Sep 23, 3:07 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > > >> > You can give the interface an optional log parameter. But I don't have >> > a patch at the moment, give me a while if you still have problems. >> >> This is slightly OT, but Michael would you like it to so that >> one could more easily turn on logging of the interfaces? >> If so, what would be your dream interface? Setting an >> environment variable? What would happen? > > Yeah, I think it would greatly help if users could send an env > variable that dumps the pexpect communication to a file. Currently I > have to debug some Singular vs. pexpect problems on Solaris, but I > guess with mhansen's help I will finally learn how to fix those > issues. But for random users out there a magic switch that gives us > logs and helps us hunt down "random" problems would be a great thing > IMHO. > This is now trac #4180: http://trac.sagemath.org/sage_trac/ticket/4180 If you have any specific ideas about what interface you might like, e.g., names of environment variables, etc., please posts those to the ticket. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: tests hang with 3.1.2
On Sep 23, 3:07 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > > You can give the interface an optional log parameter. But I don't have > > a patch at the moment, give me a while if you still have problems. > > This is slightly OT, but Michael would you like it to so that > one could more easily turn on logging of the interfaces? > If so, what would be your dream interface? Setting an > environment variable? What would happen? Yeah, I think it would greatly help if users could send an env variable that dumps the pexpect communication to a file. Currently I have to debug some Singular vs. pexpect problems on Solaris, but I guess with mhansen's help I will finally learn how to fix those issues. But for random users out there a magic switch that gives us logs and helps us hunt down "random" problems would be a great thing IMHO. > William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: tests hang with 3.1.2
On Tue, Sep 23, 2008 at 11:12 AM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On Sep 23, 5:37 am, Dan Drake <[EMAIL PROTECTED]> wrote: >> On Wed, 17 Sep 2008 at 08:55PM -0700, mabshoff wrote: > > Hi Dan, > >> > > but when I run 'make test', some test will simply stop. This happens >> > > every time, and often with different tests. The CPU usage is zero, >> > > and nothing happens. The test just sits there. >> >> > You can log the Sage<->Maxima communication and we can then poke >> > around. Another thing is to run say calculus.py under -verbose and >> > attempt to narrow it down. >> >> I was going to ignore that problem and just use a precompiled >> binary...but I was getting similar problems with that when I did a lot >> of calculus. So I'm hoping to understand this problem better. > > Ok. > >> I've run doctests on calculus.py, and most of the time it finishes, but >> sometimes it hangs. Using -verbose doesn't help; it gets to some test >> and just waits. If I kill the relevant lisp.run process, the testing >> will continue and report the failure. > > This looks like some synchronization issue. > >> How I can log the Sage-Maxima communication? Does anyone know more about >> this problem? > > You can give the interface an optional log parameter. But I don't have > a patch at the moment, give me a while if you still have problems. > This is slightly OT, but Michael would you like it to so that one could more easily turn on logging of the interfaces? If so, what would be your dream interface? Setting an environment variable? What would happen? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: real number parsing issue
On Sep 9, 2008, at 9:20 AM, Robert Bradshaw wrote:
> On Sep 9, 2008, at 2:30 AM, Martin Albrecht wrote:
>
>>
>> On Tuesday 09 September 2008, William Stein wrote:
On a related note, recently I wrote a simple loop that went
something
like this:
while abs(err) < 1e-6:
...
The most expensive part of the operation, by far, was computing
RealNumber('1e-6') in every iteration of the loop. What would
people
think about pulling such constants out of the body via the
preparser (and
sticking them into some kind of globals and/or inserting lines at
the
top.)
>>>
>>> This has been on my mental todo list for at least two years. Of
>>> course
>>> all constants should be factored out. That it hasn't been done
>>> yet is
>>> just because nobody has got around to it.
>>
>> Is that the point where the preparser becomes a just-in-time
>> compiler/interpreter? I might be overestimating the complexity, but
>> this
>> seems like something beyond the scope of regular expression matching?
>
> It shouldn't be to hard--we already replace 1.2 with RealNumber
> ('1.2'). Instead we replace it with __sage_const_1p2, and inject that
> name into the namespace (either with a line at the top of the code,
> or into the relevant namespace).
See http://trac.sagemath.org/sage_trac/ticket/249
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@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-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: ATLAS compilation failure with SAGE 3.1.2
1) My computer is a desktop with an Athlon k7 800Mhz + 384 Mo RAM. The hardware sensor checking the temperature is up an running but never set off an alarm. 2) I've given it a try again, but compilation has leaded to the same failure. I saw this in the log file : "ATLAS failed to build because your system is too heavily loaded to obtain accurate timing. Please restart the build by typing make, when the load on your system has decreased." This message has appeared although I took care not launching others parallel tasks to avoid overload. 3) I saw in the trac list a ticket suggesting to reuse the Atlas package provided by the current stable debian distro (this is the one I use). May be I just have to be patient. I currently use a pre- compiled Sage version 2.11 provided by the sage team (named Debian+k7). But I don't want to bother you asking for a new one since my architecture is somewhat outdated now, and I suppose, there is too little demand. Anyway, if you have some suggestions, I listen to you... And thanks again for this great soft ! --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Notebook Version #
> You can always type "version()" in a cell to get the version number, but > I agree, it would be a nice touch to have it Yes, of course! But it's unlikely a first-time bug reporter will know to do that. > yesterday, i had exactly the same idea ;) Harald, glad I wasn't the only one! > (but please make it small > and not very distracting). Yes, the request for small font is in the trac ticket. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Notebook Version #
kcrisman wrote: > As far as I can tell, when one uses the notebook directly, there is no > announcement of the version number of Sage; for that matter, it's not > even on the front page of the help. This is not a really big deal, > but might occasionally be nice, say maybe right under the "Sage > notebook" header on the home page and on individual notebooks. > I suppose it would be most useful for enhancing bug reports from non- > installing users. In case anyone also thinks this is useful, for > posterity I have recorded it as http://trac.sagemath.org/sage_trac/ticket/4177 > .. As usual, apologies if this one already exists; I couldn't find it > anywhere on the trac. You can always type "version()" in a cell to get the version number, but I agree, it would be a nice touch to have it (but please make it small and not very distracting). Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Notebook Version #
yesterday, i had exactly the same idea ;) +1 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Notebook Version #
As far as I can tell, when one uses the notebook directly, there is no announcement of the version number of Sage; for that matter, it's not even on the front page of the help. This is not a really big deal, but might occasionally be nice, say maybe right under the "Sage notebook" header on the home page and on individual notebooks. I suppose it would be most useful for enhancing bug reports from non- installing users. In case anyone also thinks this is useful, for posterity I have recorded it as http://trac.sagemath.org/sage_trac/ticket/4177 . As usual, apologies if this one already exists; I couldn't find it anywhere on the trac. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to make tut and ref
Hi! On Sep 23, 3:03 am, mabshoff <[EMAIL PROTECTED]> wrote: > There is a README.txt in devel/doc which might be hepful. You should > also "source local/bin/sage-env" from $SAGE_ROOT before running make > in the doc directory. Another thing worth trying is to delete all of > the various temporary TeX remnants like *.toc files since those tend > to cause trouble when switching from TeTeX to certain distributions > like TeX Live. Thanks Michael, that worked! just to know... what does "source local/bin/sage-env" do? I will start the translation as soon as I can. Cristian --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: tests hang with 3.1.2
On Sep 23, 5:37 am, Dan Drake <[EMAIL PROTECTED]> wrote: > On Wed, 17 Sep 2008 at 08:55PM -0700, mabshoff wrote: Hi Dan, > > > but when I run 'make test', some test will simply stop. This happens > > > every time, and often with different tests. The CPU usage is zero, > > > and nothing happens. The test just sits there. > > > You can log the Sage<->Maxima communication and we can then poke > > around. Another thing is to run say calculus.py under -verbose and > > attempt to narrow it down. > > I was going to ignore that problem and just use a precompiled > binary...but I was getting similar problems with that when I did a lot > of calculus. So I'm hoping to understand this problem better. Ok. > I've run doctests on calculus.py, and most of the time it finishes, but > sometimes it hangs. Using -verbose doesn't help; it gets to some test > and just waits. If I kill the relevant lisp.run process, the testing > will continue and report the failure. This looks like some synchronization issue. > How I can log the Sage-Maxima communication? Does anyone know more about > this problem? You can give the interface an optional log parameter. But I don't have a patch at the moment, give me a while if you still have problems. > Thanks, > > Dan > Cheers, Michael > -- > --- Dan Drake <[EMAIL PROTECTED]> > - KAIST Department of Mathematical Sciences > --- http://math.kaist.ac.kr/~drake > > signature.asc > < 1KViewDownload --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Advanced topics in linear algebra algorithmic class
Will you provide videos of your lectures online? The outline looks very interesting. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Advanced topics in linear algebra algorithmic class
Hi, I wanted to advertise a class that I am going to teach this fall semester, and which can be of interest for sage developers and users. As its title suggests, it will be about theoretical and practical topics on computational exact linear algebra. You can check out the web page with the syllabus and outline here: http://www.math.washington.edu/~pernet/Math581.html The first lecture is happening tomorow at 12:30 in Smith 309 on UW campus. I hope to see you there! Cheers, Clément Pernet --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: read some calculus?
I think this looks great, very nicely done. I am wondering if it would be possible to modify/include the "virtual" files like htmlhead.shtml, since they are not in the zipped version, and I had trouble finding them online. Cheers, M. Hampton On Sep 18, 3:30 pm, Elliott <[EMAIL PROTECTED]> wrote: > All done editing--the updated tutorial should be up in a few minutes. > I discovered that the nonsensical equations on the "Definition of the > Derivative" page were due to an incomplete update of the images folder > yesterday...they should be better, now ;). I'm not really sure how to > account for the OverflowError you encountered, though--I have a VMWare > image of Sage 3.0.5 running on Vista (my Internet is really slow, so I > haven't updated for a while). I haven't tried that code on my Ubuntu > boot, but it works from the 3.0.5 virtual machine and in the on-line > Notebook, which is 3.1.2.rc2. Hopefully that won't be a common issue > for readers, anyway. > > I must thank you again for all your work, though! Spelling issues > bother me especially, so I'm glad that you caught (hopefully) all of > them. Now we just need students and teachers to catch onto the > tutorial...then we'll be in business! > > Elliott Brossard > > On Sep 18, 12:56 pm, "Minh Nguyen" <[EMAIL PROTECTED]> wrote: > > > Hi, > > > On Thu, Sep 18, 2008 at 2:25 PM, William Stein <[EMAIL PROTECTED]> wrote: > > > [...] > > > This will be going on the main sagemath.org webpage, and could be a > > > superb way of getting > > > students really interested in sage. I wonder if somebody could > > > volunteer to read through > > > the tutorial and make some comments, find typos, etc.? It's fun, not > > > too long, etc. > > > From the "The Definition of the Derivative" at > > >http://sage.math.washington.edu/home/elliottd/calctut/derivative.html > > > here are some typos and suggestions: > > > [1] You might want to rewrite the sentence > > > "'h' is assumbed to be approaching zero." > > > as > > > "The symbol 'h' is assumed to be approaching zero." > > > That is, avoid starting a sentence with a maths symbol; also remove > > the "b" from "assumbed". > > > [2] You might want to rewrite the snippet > > > "The change in Bob's car's speed over time was his acceleration," > > > as > > > "The change in the speed of Bob's car over time was his acceleration," > > > or something similar. In particular, avoid double possessive > > apostrophes like "Bob's car's speed". > > > [3] For the constant rule of differentiation: > > > "If f(x) = a and a is a natural number, then f'(x) = 0" > > > Do you mean to say "...and a is a real number..."? If so, then you > > might want to reflect the change at > > >http://sage.math.washington.edu/home/elliottd/calctut/diffrules.html > > > The same comment applies for the constant multiple rule. > > > [4] You might want to rewrite the snippet > > > "If f is the quotient of g(x)/h(x)" > > > as > > > "If f is the quotient g(x)/h(x)" > > > and reflect the change at > > >http://sage.math.washington.edu/home/elliottd/calctut/diffrules.html > > > [5] You might want to rewrite the sentence > > > "f'(x) (pronounced 'f prime of x') signifies the first derivative of f(x)." > > > as > > > "The symbol f'(x) (pronounced 'f prime of x') signifies the first > > derivative of f(x)." > > > or as > > > "The function f'(x) (pronounced 'f prime of x') signifies the first > > derivative of f(x)." > > > That is, avoid starting a sentence with a maths symbol. > > > [6] In the image at > > >http://sage.math.washington.edu/home/elliottd/calctut/pix/calctut/der... > > > we have > > > 3*(x + h)^2 = 3*x^2 + 6*h*x + 3*h^2 > > > not this: > > > 3*(x + h)^2 = 3*x^2 + 3*h*x + 3*h^2 > > > [7] Following the snippet > > > "so I'll use an actual number in tandem with the Constant Multiple Rule." > > > are 2 lines of equations. I'm not sure what you're trying to say with > > those equations, since it looks like the first such line says > > something like this: > > > "If = (3xh + 3h^2) / h = ..." > > > [8] You might want to rewrite the sentence > > > "v(t) is a better representation for instantaneous velocity than > > x'(t), which explains the above." > > > as > > > "The function v(t) is a better representation for instantaneous > > velocity than x'(t), which explains the above." > > > or something like > > > "The symbol v(t) is a better representation for instantaneous velocity > > than x'(t), which explains the above." > > > Again, avoid starting sentences with maths symbols. > > > [9] You might want to rewrite the sentence > > > "You can see that as Bob's velocity gradually increased (the red line) > > that his distance traveled (the blue line) began to rise more > > quickly." > > > as > > > "You can see that as Bob's velocity gradually increased (the red > > line), his distance traveled (the blue line) began to rise more > > quickly." > > > [10] You might want to rewrite the snippet > > > "it's much safer just to leave it how it is," > > > as > > > "it's m
[sage-devel] Re: tests hang with 3.1.2
On Wed, 17 Sep 2008 at 08:55PM -0700, mabshoff wrote: > > but when I run 'make test', some test will simply stop. This happens > > every time, and often with different tests. The CPU usage is zero, > > and nothing happens. The test just sits there. > > You can log the Sage<->Maxima communication and we can then poke > around. Another thing is to run say calculus.py under -verbose and > attempt to narrow it down. I was going to ignore that problem and just use a precompiled binary...but I was getting similar problems with that when I did a lot of calculus. So I'm hoping to understand this problem better. I've run doctests on calculus.py, and most of the time it finishes, but sometimes it hangs. Using -verbose doesn't help; it gets to some test and just waits. If I kill the relevant lisp.run process, the testing will continue and report the failure. How I can log the Sage-Maxima communication? Does anyone know more about this problem? Thanks, Dan -- --- Dan Drake <[EMAIL PROTECTED]> - KAIST Department of Mathematical Sciences --- http://math.kaist.ac.kr/~drake signature.asc Description: Digital signature
[sage-devel] Re: polytopes, triangulation, proposal to add lrs
Thanks Arnaud. I have reviewed it on trac. Because of the issues I mentioned in the review, I didn't test your code on larger high-dimensional examples. But you did say it was slow in high-dimensions. If that is still the case after fixing the current problems it might make sense to use a random lifting first, which is pretty fast, and then if that fails use your code. I will also eventually add an option at least to use lrs, since that's probably faster on hard problems than anything we can write in a reasonable amount of time. Cheers, Marshall Hampton On Sep 23, 1:01 am, "Arnaud Bergeron" <[EMAIL PROTECTED]> wrote: > My code is up for review at #4164 > > Arnaud --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.3.alpha0 released
2008/9/23 William Stein <[EMAIL PROTECTED]>: > > On Mon, Sep 22, 2008 at 6:11 PM, Craig Citro <[EMAIL PROTECTED]> wrote: >> >> Hi John, >> >>> That is not in itself slow: >>> sage: time pp=pari.primes_up_to_n(10^8) >>> CPU times: user 0.69 s, sys: 0.30 s, total: 1.00 s >>> Wall time: 1.00 s >>> >>> However note that >>> >>> sage: time pp=prime_range(10^8) >>> CPU times: user 143.74 s, sys: 1.51 s, total: 145.26 s >>> Wall time: 145.93 s >>> >>> with all the extra time being spent converting pari integers to Sage ones. >>> >> >> Actually, it's not the Pari <--> Sage conversion that's slow: the list >> pp is about 6 million entries long, and even for large numbers, we >> have: >> >> sage: n = pari(10**8) >> sage: %time for _ in range(600): foo = ZZ(n) >> CPU times: user 4.40 s, sys: 0.03 s, total: 4.43 s >> Wall time: 4.44 s >> >> I haven't checked into all the details, but I'm pretty sure that >> what's actually going so slow is iteration over the Pari list! I just >> wrote a few lines of Cython to do this, and here is the timing for the >> same problem above, and it seems to work: >> >> sage: %time ls = my_prime_range(1,10**8) >> CPU times: user 1.99 s, sys: 0.89 s, total: 2.88 s >> Wall time: 2.89 s >> >> sage: type(ls[0]) >> >> sage: ls[-5:] >> [9931, 9941, 9959, 9971, 9989] >> >> I'm about to eat dinner, but I'll get this cleaned up (and possibly >> start investigating iteration on Pari objects, if I'm right about >> that) tonight. It's shameful that we let it be that slow in the first >> place! :) > > Well, we = "me", and it's a good thing I have no shame! None would be appropriate. You did an enormous amount in an incredibly short time way back then! Alex and I are also hoping that Craig will review our major pari precision-andling patch (#4096) soon, and this is in some ways similar (though smaller). I still don't know if this is going to help the MACOS problem with my sll_finite_field odctest though! John > > But I'm really glad you guys are fixing this. > > Regards, > William > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@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-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
