[sage-devel] Four final reviews missing for 3.4.2

[mabshoff]

Hello folks,

we are missing 4 rather easy reviews for 3.4.2.final. The main problem
has been fixed, reviewed and merged, i.e. the Maxima related doctest
failure, so now we need to have reviews for the tickets at

   
http://trac.sagemath.org/sage_trac/query?status=assigned&status=new&status=reopened&group=status&milestone=sage-3.4.2

to get 3.4.2 out.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[Fidel]

Hello Rob,

I spent some time this weekend coding a function to get the tkz-graph
string of a graph. You can find what I have got in

http://fidelinux.googlepages.com/tkz-string.sage

That is what I have got so far, it has very basic functionality. I
would still like to incorporate edge and vertex colors as well as
capability for drawing directed graphs.

I also did a minor modification to the graph.py file in sage, I added
a simple check_pos_validity function.

I have no idea about how to use the trac system but I would be very
happy to learn, so I can start to contribute in sage.

Thanks for your attention.

Gretings,
Fidel

On May 4, 1:50 am, Rob Beezer  wrote:
> I've created a ticket for implementing  latex(g)  using tkz-graph 
> athttp://trac.sagemath.org/sage_trac/ticket/5975
>
> I've spent some time with tkz-graph and it should be relatively
> straightforward to get some basic functionality implemented into Sage
> by building on this.  John Palmieri has started implementing some ways
> to customize Latex output (such as choices for matrix delimiters), and
> tkz-graph seems to have 8 or 10 pre-defined styles (sort of like
> Beamer does), so being able to select one of those styles might be a
> good first approximation.  When I get the chance, i'll try to put up a
> demonstration patch for discussion.
>
> I'm looking forward to more from Rado with his Javascript editor.
>
> David and Nicolas - I'll be at Sage Days 15 for most of the week (I
> live close by, and will need to miss Sunday).  If you have time
> between other projects, I'd enjoy making some progress on the items
> mentioned in this thread.
>
> Rob
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: notebook() hangs in SXCE and OpenSolaris

[mabshoff]

On May 3, 7:36 pm, bbarker  wrote:
> Some additional information:
>
> Trying to exit the server during hang by pressing Ctrl-C repeatedly
> will only yield the following (repeatedly):
> ^Cselect() error: Interrupted system call
> ^Cselect() error: Interrupted system call
> ^Cselect() error: Interrupted system call
> ^Cselect() error: Interrupted system call

Hmmm, select() - not sure what is going on here. Can you use 'truss'
and send some relevant excerpt from the logs?

> Doing the same after running sage -dbg, notebook() ... will eventually
> crash and fall back to the sage shell:
>
> ~/sage-3.4.1-beta-i86pc+toolchain-SunOS >./sage -gdb
> --
> | Sage Version 3.4.1, Release Date: 2009-04-21                       |
> | Type notebook() for the GUI, and license() for information.        |
> | WARNING: This is a beta release that does not pass all tests.      |
> | For more info seehttp://wiki.sagemath.org/solaris                |
> --
> /export/home/brandon/sage-3.4.1-beta-i86pc+toolchain-SunOS/local/bin/
> sage-ipython
> GNU gdb 6.3.50_2004-11-23-cvs
> Copyright 2004 Free Software Foundation, Inc.



This is a little long in the tooth. I compile gdb 6.8 a couple days
ago and I was quite happy with it. It needed one trivial source code
fix to get it to compile on Solaris 10, but other than that it worked.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.4.2.rc0 release!

[mabshoff]

On May 3, 5:54 am, "Dr. David Kirkby"  wrote:
> mabshoff wrote:
> > Ok, I would suggest we do the following:
>
> >  * In 3.4.2 cap prime_pi at 2^40 since that is what Andrew suggests as
> > correct range for his algorithm
> >  * add the following #long doctest (it takes about 25 seconds total in
> > sage.math):
>
> > sage: for n in (30..40):
> > :     time prime_pi(2^n)
> > 
>
> >  * For the range of 2^40+1 to 2^46 I am uncomfortable to have it
> > available per default, especially if we don't at least spot check the
> > values via doctesting and it would be getting slow to do so - even for
> > #long. But we could add some keyword to force the upper limit up to a
> > 2^46 - the issue should be revisited post 3.4.2 - maybe even
> > implementing a better algorithm?
>
> I personally can't see the point in stopping the algorithm working at
> 2^40, if it does work at 2^46. I realise you can't specifically test
> 2^46 on every occasion, but surely that argument could apply to sine,
> cosine and every other function that exists. It's impractical to check
> every single value that might be thrown at it. Of course, if there is
> reason to believe the algorithm will fail, rather than just become very
> slow, then there is good reason for putting a limit.
>
> >  * In 3.4.1 prime_pi() was completely broken for even 2^35 because len
> > (prime_range(2^35)) aborts on sage.math since pari fails to allocate
> > 124 *GB* of memory.
>
> Em, but a failure to allocate sufficient memory should not cause a seg
> fault - whether or not the memory allocation is sensible or not.

Yeah,  tell me. Either pari and/or Sage's pari interface sucks. It is
absolutely ridiculous that pari seems to require that much memory, but
it wouldn't be the first time we find an absolutely insane memory leak
in pari.

> Perhaps this is why you are intending putting a limit. I can understand
> that.

We are talking about two different limits here.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.4.2.rc0 release!

[mabshoff]

On May 3, 5:54 am, "Dr. David Kirkby"  wrote:
> mabshoff wrote:



Sorry, I forgot to reply to this part of the post since I thought it
was in another independent post.

> >  * For the range of 2^40+1 to 2^46 I am uncomfortable to have it
> > available per default, especially if we don't at least spot check the
> > values via doctesting and it would be getting slow to do so - even for
> > #long. But we could add some keyword to force the upper limit up to a
> > 2^46 - the issue should be revisited post 3.4.2 - maybe even
> > implementing a better algorithm?
>
> I personally can't see the point in stopping the algorithm working at
> 2^40, if it does work at 2^46.

We don't know it works on every for for 2^46 since we basically have a
sample of two computers. The past has taught me that this isn't even
close to what I would consider acceptable. I have put in the limit of
2^40 and the doctests to check correctness for 2^n for n in 30..40 and
that will be widely tested. Once that works we can think about
extending the tests or implementing another algorithm. Given a choice
between shipping potentially broken code or limiting Sage's
capabilities I always chose to disable code. We are beating the pants
off every known open implementation prime_pi() and lack MMA by a small
constant factor - that is an excellent improvement for Sage 3.4.2 - no
need to get greedy ;)

>  I realise you can't specifically test
> 2^46 on every occasion, but surely that argument could apply to sine,
> cosine and every other function that exists. It's impractical to check
> every single value that might be thrown at it. Of course, if there is
> reason to believe the algorithm will fail, rather than just become very
> slow, then there is good reason for putting a limit.

No, sin(2^n) and so on for large n is computed via MPFR which is
provably correct (modulo bugs of course) and has been tested by many
people for many, many years and is written by world experts in the
field. I can trust that code as much as I can trust code.

Cheers,

Michael


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] showcasing your features in Sage 3.4.2

[Minh Nguyen]

Hi folks,

Sage 3.4.2 is basically done by now. So if you contributed some cool
features to that release, you're invited to showcase those features on
the release tour at

http://wiki.sagemath.org/sage-3.4.2

Of course, you're welcome to add other suggestions to the release tour
as well. Come on, let the world know about the cool features you've
added to Sage 3.4.2.

-- 
Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Final 3.4.2 sources released

[mabshoff]

Hello folks,

the final release for 3.4.2 is done and sources, the upgrade bits and
a sage.math binary are in the usual place at

  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/

I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
I am pretty confident we won't need another 3.4.2 release. The final
release contains more changes than I wanted, but I feel that all of
the changes have been well tested and should not cause any trouble
(famous last words). Should a show stopper bug pop up we could do a
really small 3.4.3, but I hope this won't be needed.

I am already building my 4.0.alpha0 merge tree and the time to get
everything done as planned is definitely tight. Alpha0 should drop
fairly quickly since there is plenty of material in trac ready to go
in, i.e. unless something goes wrong in the next 24 hours.

Please build, test and report issues as usual.

Cheers,

Michael

Merged in Sage 3.4.2.final:

#5951: John Palmieri: fix a few minor issues with the reference manual
in 3.4.2.rc0 [Reviewed by Michael Abshoff]
#5953: Michael Abshoff, John Palmieri: sage/modular/modform/
vm_basis.py is missing verbatim areas for doctests [Reviewed by Minh
Van Nguyen]
#5955: Michael Abshoff: Sage 3.4.2.rc0: Set stacksize during
clisp.spkg build to 32kb [Reviewed by David Roe]
#5957: Michael Abshoff: 3.4.2.rc0: Maxima related doctest failure in
matrix/matrix_symbolic_dense.pyx [Reviewed by Michael Abshoff]
#5963: Michael Abshoff: 3.4.2.a0: prime_pi returns wrong results on
some platforms for large input [Reviewed by David Roe]
#5966: Michael Abshoff: sage/sets/primes.py: change doctest so that we
check for Primes being != to x^2+x [Reviewed by David Roe]
#5972: William Stein: segfault in degenerate matrix multiply [Reviewed
by Michael Abshoff]
#5973: Michael Abshoff: Fix spkg-check target for FLINT on OSX 64 bit
[Reviewed by William Stein]

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[William Stein]

On Mon, May 4, 2009 at 7:36 AM, mabshoff  wrote:
>
>
>
> On May 4, 7:30 am, Jaap Spies  wrote:
>> mabshoff wrote:
>> > Hello folks,
>>
>> > the final release for 3.4.2 is done and sources, the upgrade bits and
>> > a sage.math binary are in the usual place at
>>
>> >  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>
>> > I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
>> > I am pretty confident we won't need another 3.4.2 release.
>>
>> Except setting testing in FLINT off!
>
> Well, I knew FLINT still ran its test suite and given we updated MPIR
> I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> off :p.

It takes like 2-3 hours to run on some of my build machines, nearly
doubling the time of building Sage from source.

> In Sage 4.0 I will hopefully have a more flexible system for testing
> so that people who don't want to run the "mandated" testing can turn
> it off more easily.

What's wrong with the current SAGE_CHECK (or whatever) system where
spkg-check is run only if a certain environment variable is set?

>
> Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
> testing it I saw a doctest failure in some cohomology code and I did
> not feel like tracking this down since the main change in FLINT 1.2.5
> was the update to zn_poly 0.9 (which contained a fix that was supposed
> to resolve the problem completely). The issue that popped up might
> also be a padics problem since 2/3 of the doctest failure has been
> resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
> 4.0.x. ;)
>

Good.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Jaap Spies]

mabshoff wrote:
> Hello folks,
> 
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
> 
>   http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
> 
> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
> I am pretty confident we won't need another 3.4.2 release.

Except setting testing in FLINT off!

Jaap


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Jaap Spies]

mabshoff wrote:
> 
> 
> On May 4, 7:30 am, Jaap Spies  wrote:
>> mabshoff wrote:
>>> Hello folks,
>>> the final release for 3.4.2 is done and sources, the upgrade bits and
>>> a sage.math binary are in the usual place at
>>>  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
>>> I am pretty confident we won't need another 3.4.2 release.
>> Except setting testing in FLINT off!
> 
> Well, I knew FLINT still ran its test suite and given we updated MPIR
> I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> off :p.
> 

This testing feels ok for alpha and rc releases, but not on a final
source release. IIRC this was standard procedure.

Jaap


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[William Stein]

On Mon, May 4, 2009 at 7:52 AM, mabshoff  wrote:
>
>
>
> On May 4, 7:40 am, William Stein  wrote:
>> On Mon, May 4, 2009 at 7:36 AM, mabshoff  wrote:
>>
>> > On May 4, 7:30 am, Jaap Spies  wrote:
>> >> mabshoff wrote:
>> >> > Hello folks,
>>
>> >> > the final release for 3.4.2 is done and sources, the upgrade bits and
>> >> > a sage.math binary are in the usual place at
>>
>> >> >  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>
>> >> > I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
>> >> > I am pretty confident we won't need another 3.4.2 release.
>>
>> >> Except setting testing in FLINT off!
>>
>> > Well, I knew FLINT still ran its test suite and given we updated MPIR
>> > I do prefer for it to run. There was also no 3.4.2 ticket to turn it
>> > off :p.
>>
>> It takes like 2-3 hours to run on some of my build machines, nearly
>> doubling the time of building Sage from source.


>
> I seriously doubt that. On sage.math the tests run in roughly 10
> minutes. Since building FLINT is more or less instant you should show

You're right, it's just over an hour on ATOM:

real62m23.286s
user57m57.825s
sys 3m24.089s
Successfully installed flint-1.2.4.p1
Now cleaning up tmp files.
Making Sage/Python scripts reloc


> me the build log, but then the total build time is not going to be in
> the 4 to 6 hour range. Running the FLINT test suite flushes out bugs
> and I am running it on Solaris/Sparc where this is quite painful and
> from experience I would claim that the build on Sparc takes even
> longer than on Atom for example.
>
>> > In Sage 4.0 I will hopefully have a more flexible system for testing
>> > so that people who don't want to run the "mandated" testing can turn
>> > it off more easily.
>>
>> What's wrong with the current SAGE_CHECK (or whatever) system where
>> spkg-check is run only if a certain environment variable is set?
>
> That system is all or nothing and since for example R's spkg-check
> fails on every platform I do not use it. Something that white- or
> blacklists individual spkgs via a control file seems a much saner
> mechanism to me.

You're right. Just like with "make test", we should change the
spkg-check system to simply report the results at the end, instead of
stopping if anything isn't perfect.

>
>> > Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
>> > testing it I saw a doctest failure in some cohomology code and I did
>> > not feel like tracking this down since the main change in FLINT 1.2.5
>> > was the update to zn_poly 0.9 (which contained a fix that was supposed
>> > to resolve the problem completely). The issue that popped up might
>> > also be a padics problem since 2/3 of the doctest failure has been
>> > resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
>> > 4.0.x. ;)
>>
>> Good.
>
> I did list the failure in the FLINT 1.2.5 update ticket if anyone
> wants to take a look.
>
> Cheers,
>
> Michael
> >
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[Rob Beezer]

Hi Fidel,

That looks great!  We might be able to also take advantage of the
styles/themes that tkz-graph implements to quickly get a variety of
{consistent|pleasing} output options with very little code on our
end.  ;-)

Three exams to give and grade today, but I'll write more later about
getting this into Trac, etc.

Rob


On May 4, 1:13 am, Fidel  wrote:
> Hello Rob,
>
> I spent some time this weekend coding a function to get the tkz-graph
> string of a graph. You can find what I have got in
>
> http://fidelinux.googlepages.com/tkz-string.sage
>
> That is what I have got so far, it has very basic functionality. I
> would still like to incorporate edge and vertex colors as well as
> capability for drawing directed graphs.
>
> I also did a minor modification to the graph.py file in sage, I added
> a simple check_pos_validity function.
>
> I have no idea about how to use the trac system but I would be very
> happy to learn, so I can start to contribute in sage.
>
> Thanks for your attention.
>
> Gretings,
> Fidel
>
> On May 4, 1:50 am, Rob Beezer  wrote:
>
> > I've created a ticket for implementing  latex(g)  using tkz-graph 
> > athttp://trac.sagemath.org/sage_trac/ticket/5975
>
> > I've spent some time with tkz-graph and it should be relatively
> > straightforward to get some basic functionality implemented into Sage
> > by building on this.  John Palmieri has started implementing some ways
> > to customize Latex output (such as choices for matrix delimiters), and
> > tkz-graph seems to have 8 or 10 pre-defined styles (sort of like
> > Beamer does), so being able to select one of those styles might be a
> > good first approximation.  When I get the chance, i'll try to put up a
> > demonstration patch for discussion.
>
> > I'm looking forward to more from Rado with his Javascript editor.
>
> > David and Nicolas - I'll be at Sage Days 15 for most of the week (I
> > live close by, and will need to miss Sunday).  If you have time
> > between other projects, I'd enjoy making some progress on the items
> > mentioned in this thread.
>
> > Rob
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 7:57 am, Jaap Spies  wrote:
> mabshoff wrote:



> > Well, I knew FLINT still ran its test suite and given we updated MPIR
> > I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> > off :p.
>
> This testing feels ok for alpha and rc releases, but not on a final
> source release. IIRC this was standard procedure.

Nope, it was commonly handled that way. But since the 'real' releases
are build more widely that either alpha or rc releases I have been
changing this to even run some test suites even then. This has already
flushed out various bugs in MPIR and in the past also FLINT. This
might seem like a waste of time to some people, but compared to
running Sage's test suite it seems like a low price to pay.

You wouldn't consider running the test suite a waste of time either I
assume. If someone really wants to we can introduce a special
SAGE_CHECK_OVEWRITE flag that completely turns off all checks if
anyone does thing this is really desirable, but I am hesitant to do
so. Testing makes software better and way too often has a point
upgrade that was supposedly safe introduced problems, so I am always
in favor of testing.

> Jaap

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: showcasing your features in Sage 3.4.2

[mabshoff]

On May 4, 5:52 am, Minh Nguyen  wrote:
> Hi folks,
>
> Sage 3.4.2 is basically done by now. So if you contributed some cool
> features to that release, you're invited to showcase those features on
> the release tour at
>
> http://wiki.sagemath.org/sage-3.4.2
>
> Of course, you're welcome to add other suggestions to the release tour
> as well. Come on, let the world know about the cool features you've
> added to Sage 3.4.2.

Well, two things I partially mentioned to Minh in IRC:

 * prime_pi() isn't new, byt 2000 times as fast for large n and way
more memory efficient - see also what William wrote about that at the
end of the 3.4.2.rc0 release thread

 * FLINT has worked on 64 bit OSX for a long time, spkg-check had a
bug that prevented the tests from running

More to come ..

Cheers,

Michael

> --
> Regards
> Minh Van Nguyen
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Jaap Spies]

mabshoff wrote:
> 
> 
> On May 4, 7:57 am, Jaap Spies  wrote:
>> mabshoff wrote:
> 
> 
> 
>>> Well, I knew FLINT still ran its test suite and given we updated MPIR
>>> I do prefer for it to run. There was also no 3.4.2 ticket to turn it
>>> off :p.
>> This testing feels ok for alpha and rc releases, but not on a final
>> source release. IIRC this was standard procedure.
> 
> Nope, it was commonly handled that way. But since the 'real' releases
> are build more widely that either alpha or rc releases I have been
> changing this to even run some test suites even then. This has already
> flushed out various bugs in MPIR and in the past also FLINT. This
> might seem like a waste of time to some people, but compared to
> running Sage's test suite it seems like a low price to pay.
> 

Agreed, but how often did you get feedback from failures in the FLINT
library from users of the 'real' releases in the field?

> You wouldn't consider running the test suite a waste of time either I
> assume. If someone really wants to we can introduce a special
> SAGE_CHECK_OVEWRITE flag that completely turns off all checks if
> anyone does thing this is really desirable, but I am hesitant to do
> so. Testing makes software better and way too often has a point
> upgrade that was supposedly safe introduced problems, so I am always
> in favor of testing.
> 

+1 for the last sentence.

On relative slow hardware it looks like a good idea to make
installation of ATLAS and e.g. FLINT less time consuming.

Jaap


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.4.2.rc0 release!

[William Stein]

On Mon, May 4, 2009 at 1:55 AM, mabshoff  wrote:
>
>
>
> On May 3, 5:54 am, "Dr. David Kirkby"  wrote:
>> mabshoff wrote:
>
> 
>
> Sorry, I forgot to reply to this part of the post since I thought it
> was in another independent post.
>
>> >  * For the range of 2^40+1 to 2^46 I am uncomfortable to have it
>> > available per default, especially if we don't at least spot check the
>> > values via doctesting and it would be getting slow to do so - even for
>> > #long. But we could add some keyword to force the upper limit up to a
>> > 2^46 - the issue should be revisited post 3.4.2 - maybe even
>> > implementing a better algorithm?
>>
>> I personally can't see the point in stopping the algorithm working at
>> 2^40, if it does work at 2^46.
>
> We don't know it works on every for for 2^46 since we basically have a
> sample of two computers. The past has taught me that this isn't even
> close to what I would consider acceptable. I have put in the limit of
> 2^40 and the doctests to check correctness for 2^n for n in 30..40 and
> that will be widely tested. Once that works we can think about
> extending the tests or implementing another algorithm. Given a choice
> between shipping potentially broken code or limiting Sage's
> capabilities I always chose to disable code. We are beating the pants
> off every known open implementation prime_pi() and lack MMA by a small
> constant factor - that is an excellent improvement for Sage 3.4.2 - no
> need to get greedy ;)
>
>>  I realise you can't specifically test
>> 2^46 on every occasion, but surely that argument could apply to sine,
>> cosine and every other function that exists. It's impractical to check
>> every single value that might be thrown at it. Of course, if there is
>> reason to believe the algorithm will fail, rather than just become very
>> slow, then there is good reason for putting a limit.

+1 in general, but prime_pi is very new code written by a new sage dev
who strangely has not made any comments at all about this issue (and
the algorithm he implemented is very sensitive to input size).  Until
we get some feedback from him, I like Michael suggestion.

>
> No, sin(2^n) and so on for large n is computed via MPFR which is
> provably correct (modulo bugs of course) and has been tested by many
> people for many, many years and is written by world experts in the
> field. I can trust that code as much as I can trust code.
>
> Cheers,
>
> Michael
>
>
> >
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 7:40 am, William Stein  wrote:
> On Mon, May 4, 2009 at 7:36 AM, mabshoff  wrote:
>
> > On May 4, 7:30 am, Jaap Spies  wrote:
> >> mabshoff wrote:
> >> > Hello folks,
>
> >> > the final release for 3.4.2 is done and sources, the upgrade bits and
> >> > a sage.math binary are in the usual place at
>
> >> >  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> >> > I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
> >> > I am pretty confident we won't need another 3.4.2 release.
>
> >> Except setting testing in FLINT off!
>
> > Well, I knew FLINT still ran its test suite and given we updated MPIR
> > I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> > off :p.
>
> It takes like 2-3 hours to run on some of my build machines, nearly
> doubling the time of building Sage from source.

I seriously doubt that. On sage.math the tests run in roughly 10
minutes. Since building FLINT is more or less instant you should show
me the build log, but then the total build time is not going to be in
the 4 to 6 hour range. Running the FLINT test suite flushes out bugs
and I am running it on Solaris/Sparc where this is quite painful and
from experience I would claim that the build on Sparc takes even
longer than on Atom for example.

> > In Sage 4.0 I will hopefully have a more flexible system for testing
> > so that people who don't want to run the "mandated" testing can turn
> > it off more easily.
>
> What's wrong with the current SAGE_CHECK (or whatever) system where
> spkg-check is run only if a certain environment variable is set?

That system is all or nothing and since for example R's spkg-check
fails on every platform I do not use it. Something that white- or
blacklists individual spkgs via a control file seems a much saner
mechanism to me.

> > Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
> > testing it I saw a doctest failure in some cohomology code and I did
> > not feel like tracking this down since the main change in FLINT 1.2.5
> > was the update to zn_poly 0.9 (which contained a fix that was supposed
> > to resolve the problem completely). The issue that popped up might
> > also be a padics problem since 2/3 of the doctest failure has been
> > resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
> > 4.0.x. ;)
>
> Good.

I did list the failure in the FLINT 1.2.5 update ticket if anyone
wants to take a look.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 8:26 am, Jaap Spies  wrote:



> > Nope, it was commonly handled that way. But since the 'real' releases
> > are build more widely that either alpha or rc releases I have been
> > changing this to even run some test suites even then. This has already
> > flushed out various bugs in MPIR and in the past also FLINT. This
> > might seem like a waste of time to some people, but compared to
> > running Sage's test suite it seems like a low price to pay.
>
> Agreed, but how often did you get feedback from failures in the FLINT
> library from users of the 'real' releases in the field?

At least once, but these days I tend to catch the majority of build
and testing issues in FLINT before it makes it even into a Sage
release. But with more exotic CPUs, i.e MIPS, Sparc and Itanium it
isn't very hard to catch a miscompilation of FLINT depending on the
gcc release used and I much rather catch those in the test suite than
some incredibly odd segfaults in Sage's test suite. FLINT is also the
first test to determine if MPIR/GMP use truly working inline semantics
since that is not caught in either the MPIR or GMP test suites and
that cannot be determined by just building FLINT, the test suite
shakes that problem out if it exists by linking bits from FLINT. And
that is something that can easily break on OSX 10.4 for example (and
indeed, FLINT caught this in the past :))

At least on Linux on x86 and x86-64 it is admittedly not very useful
to run the test suite in the vast majority of the cases since it is so
well tested already, but there is no obvious heuristic to determine
when it is worth testing and when it isn't because if we knew we would
have already fixed the problem. And once you assume that it will not
break you will run out of luck and get hit by a bug ;)

> > You wouldn't consider running the test suite a waste of time either I
> > assume. If someone really wants to we can introduce a special
> > SAGE_CHECK_OVEWRITE flag that completely turns off all checks if
> > anyone does thing this is really desirable, but I am hesitant to do
> > so. Testing makes software better and way too often has a point
> > upgrade that was supposedly safe introduced problems, so I am always
> > in favor of testing.
>
> +1 for the last sentence.
>
> On relative slow hardware it looks like a good idea to make
> installation of ATLAS and e.g. FLINT less time consuming.

Well, for ATLAS we don't even run the test suite, so what you see at
the moment is as close to optimum as it gets. You can reuse a
previously build ATLAS (assuming we didn't upgrade).

> Jaap

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 7:30 am, Jaap Spies  wrote:
> mabshoff wrote:
> > Hello folks,
>
> > the final release for 3.4.2 is done and sources, the upgrade bits and
> > a sage.math binary are in the usual place at
>
> >  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> > I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
> > I am pretty confident we won't need another 3.4.2 release.
>
> Except setting testing in FLINT off!

Well, I knew FLINT still ran its test suite and given we updated MPIR
I do prefer for it to run. There was also no 3.4.2 ticket to turn it
off :p.

In Sage 4.0 I will hopefully have a more flexible system for testing
so that people who don't want to run the "mandated" testing can turn
it off more easily.

Originally FLINT 1.2.5 was supposed to go into 3.4.2, but while
testing it I saw a doctest failure in some cohomology code and I did
not feel like tracking this down since the main change in FLINT 1.2.5
was the update to zn_poly 0.9 (which contained a fix that was supposed
to resolve the problem completely). The issue that popped up might
also be a padics problem since 2/3 of the doctest failure has been
resolved by the new zn_poly, I guess we might find out in Sage 4.0 or
4.0.x. ;)

> Jaap

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Jaap Spies]

mabshoff wrote:
> Hello folks,
> 
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
> 
>   http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
> 
> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final since
> I am pretty confident we won't need another 3.4.2 release. The final
> release contains more changes than I wanted, but I feel that all of
> the changes have been well tested and should not cause any trouble
> (famous last words). Should a show stopper bug pop up we could do a
> really small 3.4.3, but I hope this won't be needed.
> 
> I am already building my 4.0.alpha0 merge tree and the time to get
> everything done as planned is definitely tight. Alpha0 should drop
> fairly quickly since there is plenty of material in trac ready to go
> in, i.e. unless something goes wrong in the next 24 hours.
> 
> Please build, test and report issues as usual.
> 

On Fedora 9, 32 bit upgraded from alpha0 -> rc0-> sage-3.4.2
and on Fedora 10, 32 bit upgraded from rc0 I get tons
of failures with prime_pi, e.g.:

sage -t  "devel/sage/sage/functions/prime_pi.pyx"
**
File 
"/home/jaap/Download/sage-3.4.2.rc0/devel/sage/sage/functions/prime_pi.pyx", 
line 74:
 sage: prime_pi(7)
Exception raised:
 Traceback (most recent call last):
   File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/ncadoctest.py", line 
1231, in run_one_test
 self.run_one_example(test, example, filename, compileflags)
   File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/sagedoctest.py", line 
38, in run_one_example
 OrigDocTestRunner.run_one_example(self, test, example, filename, 
compileflags)
   File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/ncadoctest.py", line 
1172, in run_one_example
 compileflags, 1) in test.globs
   File "", line 1, in 
 prime_pi(Integer(7))###line 74:
 sage: prime_pi(7)
   File "prime_pi.pyx", line 175, in 
sage.functions.prime_pi.PrimePi.__call__ (sage/functions/prime_pi.c:1101)
 NotImplementedError: computation of prime_pi() greater 2**40 not 
implemented
**
File 
"/home/jaap/Download/sage-3.4.2.rc0/devel/sage/sage/functions/prime_pi.pyx", 
line 76:
 sage: prime_pi(100)
Exception raised:


Jaap


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 5:53 am, mabshoff  wrote:
> Hello folks,



> #5957: Michael Abshoff: 3.4.2.rc0: Maxima related doctest failure in
> matrix/matrix_symbolic_dense.pyx [Reviewed by Michael Abshoff]

Oops, author credit here goes to William. I uploaded the patch, so
that caused the confusion. Sorry :(

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 9:07 am, Jaap Spies  wrote:
> mabshoff wrote:
> > Hello folks,



> > Please build, test and report issues as usual.
>
> On Fedora 9, 32 bit upgraded from alpha0 -> rc0-> sage-3.4.2
> and on Fedora 10, 32 bit upgraded from rc0 I get tons
> of failures with prime_pi, e.g.:
>
> sage -t  "devel/sage/sage/functions/prime_pi.pyx"
> **
> File 
> "/home/jaap/Download/sage-3.4.2.rc0/devel/sage/sage/functions/prime_pi.pyx", 
> line 74:
>      sage: prime_pi(7)
> Exception raised:
>      Traceback (most recent call last):
>        File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/ncadoctest.py", 
> line 1231, in run_one_test
>          self.run_one_example(test, example, filename, compileflags)
>        File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/sagedoctest.py", 
> line 38, in run_one_example
>          OrigDocTestRunner.run_one_example(self, test, example, filename, 
> compileflags)
>        File "/home/jaap/Download/sage-3.4.2.rc0/local/bin/ncadoctest.py", 
> line 1172, in run_one_example
>          compileflags, 1) in test.globs
>        File "", line 1, in 
>          prime_pi(Integer(7))###line 74:
>      sage: prime_pi(7)
>        File "prime_pi.pyx", line 175, in 
> sage.functions.prime_pi.PrimePi.__call__ (sage/functions/prime_pi.c:1101)
>      NotImplementedError: computation of prime_pi() greater 2**40 not 
> implemented
> **
> File 
> "/home/jaap/Download/sage-3.4.2.rc0/devel/sage/sage/functions/prime_pi.pyx", 
> line 76:
>      sage: prime_pi(100)
> Exception raised:

Arrg, this is cause by Integer(2**40) on 32 bit systems being "0" in
Cython. I didn't use any long representation of 2^40 to avoid running
into 32 vs. 64 bit issues. Oh well, please open a ticket, I guess
there will be another "final" 3.4.2 tarball :(

> Jaap

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 9:33 am, mabshoff  wrote:
> On May 4, 9:07 am, Jaap Spies  wrote:



> Arrg, this is cause by Integer(2**40) on 32 bit systems being "0" in
> Cython. I didn't use any long representation of 2^40 to avoid running
> into 32 vs. 64 bit issues. Oh well, please open a ticket, I guess
> there will be another "final" 3.4.2 tarball :(

This is now #5981 with a proto patch attached. With it prime_pi.pyx
passes doctests on a 32 bit box for me.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Jaap Spies]

mabshoff wrote:
> 
> 
> On May 4, 9:33 am, mabshoff  wrote:
>> On May 4, 9:07 am, Jaap Spies  wrote:
> 
> 
> 
>> Arrg, this is cause by Integer(2**40) on 32 bit systems being "0" in
>> Cython. I didn't use any long representation of 2^40 to avoid running
>> into 32 vs. 64 bit issues. Oh well, please open a ticket, I guess
>> there will be another "final" 3.4.2 tarball :(
> 
> This is now #5981 with a proto patch attached. With it prime_pi.pyx
> passes doctests on a 32 bit box for me.
> 

I'm ready to give this patch a positive review :)

  ./sage -t  "devel/sage/sage/functions/prime_pi.pyx"
sage -t  "devel/sage/sage/functions/prime_pi.pyx"
 [48.1 s]

--
All tests passed!
Total time for all tests: 48.1 seconds


Jaap


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 10:03 am, Jaap Spies  wrote:
> mabshoff wrote:



As mentioned on #5980 I checked if you had opened the ticket already
before I opened #5981, but you did open it parallel to my ticket - so
great minds think alike I guess ;)

> > This is now #5981 with a proto patch attached. With it prime_pi.pyx
> > passes doctests on a 32 bit box for me.
>
> I'm ready to give this patch a positive review :)
>
>   ./sage -t  "devel/sage/sage/functions/prime_pi.pyx"
> sage -t  "devel/sage/sage/functions/prime_pi.pyx"
>          [48.1 s]
>
> --
> All tests passed!
> Total time for all tests: 48.1 seconds
>
> Jaap

Good. I tested on 32 and 64 bit and it works for me, too. The patch is
formally up and the ticket is also open against 3.4.2, so feel free to
review. I will wait for all my other build tests to finish doctesting
before pushing out the new tarball (just in case something else pops
up).

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Jaap Spies]

mabshoff wrote:
> 
> 
> On May 4, 10:03 am, Jaap Spies  wrote:
>> mabshoff wrote:
> 
> 
> 
> As mentioned on #5980 I checked if you had opened the ticket already
> before I opened #5981, but you did open it parallel to my ticket - so
> great minds think alike I guess ;)
> 

:)

[...]

> 
> Good. I tested on 32 and 64 bit and it works for me, too. The patch is
> formally up and the ticket is also open against 3.4.2, so feel free to
> review. I will wait for all my other build tests to finish doctesting
> before pushing out the new tarball (just in case something else pops
> up).
> 

Done. I'll rerun all the tests too.


Jaap


> Cheers,
> 
> Michael
> > 
> 


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[John Cremona]

On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
sage -t  "devel/sage/sage/interfaces/sage0.py"
which is random, i.e. rerunning it usually works fine.  But not always.

Two other builds on slower / heavily loaded machines still building...

John

2009/5/4 Jaap Spies :
>
> mabshoff wrote:
>>
>>
>> On May 4, 10:03 am, Jaap Spies  wrote:
>>> mabshoff wrote:
>>
>> 
>>
>> As mentioned on #5980 I checked if you had opened the ticket already
>> before I opened #5981, but you did open it parallel to my ticket - so
>> great minds think alike I guess ;)
>>
>
> :)
>
> [...]
>
>>
>> Good. I tested on 32 and 64 bit and it works for me, too. The patch is
>> formally up and the ticket is also open against 3.4.2, so feel free to
>> review. I will wait for all my other build tests to finish doctesting
>> before pushing out the new tarball (just in case something else pops
>> up).
>>
>
> Done. I'll rerun all the tests too.
>
>
> Jaap
>
>
>> Cheers,
>>
>> Michael
>> >
>>
>
>
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[mabshoff]

On May 4, 11:30 am, John Cremona  wrote:

Hi John,

> On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
>         sage -t  "devel/sage/sage/interfaces/sage0.py"
> which is random, i.e. rerunning it usually works fine.  But not always.
>
> Two other builds on slower / heavily loaded machines still building...
>
> John

For the record: The 32 bit prime_pi() issue causes doctest failure in

sage -t -long "devel/sage/sage/numerical/optimize.py"
sage -t -long "devel/sage/sage/tests/book_stein_ent.py"
sage -t -long "devel/sage/sage/combinat/sloane_functions.py"
sage -t -long "devel/sage/sage/functions/transcendental.py"
sage -t -long "devel/sage/sage/functions/prime_pi.pyx"

so applying #5981 before reporting any failures might be a good idea.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] New machine in the sage.math network

[Tom Boothby]

Recently, Sun donated a new machine to the Sage community.  It's a Sun
T5240 with two SPARC T2 processors (8 cores total) and 32GB of RAM,
and runs Solaris 5.10.  As with the other machines in the network, you
have access to your home directory from there; and provided you
haven't changed your password this week, your login should be the same
as it is at sage.math.  Find it at t2.math.washington.edu, or from
sage.math, simply t2.

Thanks to Michael Abshoff, there's a custom-built toolchain sufficient
to build Sage.  Your admins are a little nexperienced with Solaris, so
the machine isn't quite as easy to use as we might like.  We're
working to fix little hiccups as we find them.  Also, none of
Mathematica, Matlab, or Maple are installed yet, but we plan to
install them soon.

Sun donated the hardware so that we could improve portability of
various open source projects.  The T2 processors are designed to be
highly multithreaded; though we haven't gotten very good performance
out of them yet, the specs indicate that the potential for the
processors is nothing short of incredible. So experiment away; and
please share if you figure out how to get the most out of the machine.

If you don't have access to sage.math and you have a good reason to
access the T2, please contact William Stein.

Enjoy,
   --tom

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] #5979: Parent: fixes broken (implicit) invariant between ._element_constructor and self._element_init_pass_parent

[Nicolas M. Thiery]

Dear Robert,

Could you please review http://sagetrac.org/sage_trac/ticket/5979

It's very short but quite sensitive.

sage -testall passes smoothly with sage-3.4.2-alpha0 (except for a
trivial broken test in interfaces.r which also fails before applying
the patch). Haven't tried it with sage-3.4.2 final (under compilation)

Thanks!
Nicolas

--
In Parent, there is a (previously implicit) invariant, namely that:

self._element_init_pass_parent == guess_pass_parent(between 
._element_constructor)

This invariant was broken when self._element_constructor was set from
self._element_constructor_ by __call__. This made the parent not to be
passed properly to _element_constructor.

This patch fixes this (one line), and adds a corresponding doctest.
It also includes a related trivial fix to a line that is apparently never used 
in coerce_maps, and adds a comment about this.

The category patch #5891 depends heavily on this one, as this way of
setting _element_constructor becomes the default one for simple
parents.
--
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Jaap Spies]

mabshoff wrote:
> 
> 

> 
> Good. I tested on 32 and 64 bit and it works for me, too. The patch is
> formally up and the ticket is also open against 3.4.2, so feel free to
> review. I will wait for all my other build tests to finish doctesting
> before pushing out the new tarball (just in case something else pops
> up).
> 

As a follow up: on Fedora 9 and Fedora 10, 32 bit all tests passed
after applying the patch.

Jaap





--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[John Cremona]

2009/5/4 mabshoff :
>
>
>
> On May 4, 11:30 am, John Cremona  wrote:
>
> Hi John,
>
>> On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
>>         sage -t  "devel/sage/sage/interfaces/sage0.py"
>> which is random, i.e. rerunning it usually works fine.  But not always.
>>
>> Two other builds on slower / heavily loaded machines still building...
>>
>> John
>
> For the record: The 32 bit prime_pi() issue causes doctest failure in
>
>        sage -t -long "devel/sage/sage/numerical/optimize.py"
>        sage -t -long "devel/sage/sage/tests/book_stein_ent.py"
>        sage -t -long "devel/sage/sage/combinat/sloane_functions.py"
>        sage -t -long "devel/sage/sage/functions/transcendental.py"
>        sage -t -long "devel/sage/sage/functions/prime_pi.pyx"
>
> so applying #5981 before reporting any failures might be a good idea.

OK on ubuntu 32-bit after applying the patch.

The odd failure on Bill's 64-bit machines was something else...

John

>
> Cheers,
>
> Michael
> >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Wigner 3j, 6j, 9j, Clebsch-Gordan, Racah and Gaunt coefficients

[Dan Christensen]

jyr  writes:

> The thought has occured to me that one could use the index functions
> for the 3j, 6j, and Gaunt coefficients for a much simpler storage
> scheme in python by using the index as a key for a dictionary of
> stored symbols. I could then extend the above published routines with
> an optional 'remember' keyword that would store them from one call to
> the next.
> However, I am not sure how much memory dictionaries consume in python
> and whether this is efficient. At the end of the day for any realistic
> calculation you are usually talking about millions of them.

In my experience doing extremely large-scale computations using 10^10 or
more 6j symbols, it is faster to evaluate a 6j symbol than to look it up
in a hash table.  On the other hand, if you repeatedly need sequences of
6j symbols with one argument varying, it does pay off to store arrays of
6j symbols in a hash table with the key being the 5 fixed arguments.
That is all in C using floating point, so it may be worthwhile using
a hash table if you want exact rational results.

By the way, I have a C library, written with Igor Khavkine, that
computes 3j, 6j, 10j and other networks using your choice of exact
rational or floating point arithmetic.  It also does the q-deformed
calculations, either for fixed complex q (returning a complex) or for
symbolic q (returning an exact rational function of q).  It is
optimized for speed and even has a python interface.

The bad news is that it is complicated to build, not well-documented,
and not really in a state for others to use.

So it would be great if Jens' library could be included in sage!

Dan

PS: I'm currently working on using sage to evaluate 3j and 6j symbols
for SU(n) for n > 2 (the above being the n=2 case).  I'll report to the
list if I come up with something appropriate for inclusion in sage.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Wigner 3j, 6j, 9j, Clebsch-Gordan, Racah and Gaunt coefficients

[Dan Christensen]

jyr  writes:

> def test_calc_factlist(nn):
> r"""
> Function calculates a list of precomputed factorials in order to
> massively accelerate consequetive calculations of the various
   

Typo.  And maybe say "future" instead of "consecutive"?

> EXAMPLES:
>
> Calculate list of factorials:
>
> sage: test_calc_factlist(10)
> [1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 3628800]
> """
> _calc_factlist(nn)
> return _Factlist

Maybe "return _Factlist[:nn+1]" to ensure that the test passes even
if other tests run which create a larger _Factlist?  

> This function uses the algorithm of [Edmonds74] to calculate the
> value of the 3j symbol exactly. Note that the formula contains
> alternating sums over large factorials and is therefore unsuitable
> for finite precision arithmetic and only useful for a computer
> algebra system [Rasch03].

Do you have a specific example illustrating what you mean by the last
sentence?  I've done lots of calculations of theta symbols which contain
a similar sum.  For these, if I use long double's in C, I retain good
precision even for fairly large arguments.

And I've found that floating point is also fine for 6j symbols.

> higher symmetry releations that the Clebsch-Gordan coefficient.

Typo  ^^

> prec - precission, default: None. Providing a precission can

Only one s in "precision" (twice here and also in other places).

Probably worth running the file through a spell-checker.

Dan


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Wigner 3j, 6j, 9j, Clebsch-Gordan, Racah and Gaunt coefficients

[Dan Christensen]

Jens,

I now see that you've written an article on this topic and tested
exactly the case I've also tested: floating point 6j symbols in a
compiled language.  Since your conclusions are different from mine, I'm
curious whether your storage system is faster or your 6j routine is
slower.  Is your code available somewhere?

Dan


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[rjf]

You might find this paper interesting, since it discusses the linkage
of an interactive graphics system (for graphs) to a computer algebra
system.

http://www.eecs.berkeley.edu/~fateman/papers/graphing7.pdf

After glancing at the pictures in the paper, you might be surprised by
how few lines of code it took to implement.
Sorry, not in python.


There are also comments about GraphViz etc.  It's not the only
program.
RJF



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Wigner 3j, 6j, 9j, Clebsch-Gordan, Racah and Gaunt coefficients

[Ondrej Certik]

On Mon, May 4, 2009 at 4:52 PM, Dan Christensen  wrote:
>
> Jens,
>
> I now see that you've written an article on this topic and tested
> exactly the case I've also tested: floating point 6j symbols in a
> compiled language.  Since your conclusions are different from mine, I'm
> curious whether your storage system is faster or your 6j routine is
> slower.  Is your code available somewhere?

Jens already replied above that it is not, until he publishes an
article. But I am certainly interested too in the C code, once the
article is done.

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[William Stein]

On Mon, May 4, 2009 at 5:03 PM, rjf  wrote:
>
> You might find this paper interesting, since it discusses the linkage
> of an interactive graphics system (for graphs) to a computer algebra
> system.
>
> http://www.eecs.berkeley.edu/~fateman/papers/graphing7.pdf
>
> After glancing at the pictures in the paper, you might be surprised by
> how few lines of code it took to implement.
> Sorry, not in python.
>
>
> There are also comments about GraphViz etc.  It's not the only
> program.
> RJF

That's a nice paper and I'm glad you guys wrote it.  Just out of
curiosity, where does one publish a paper like that?  (I hope there
are good places to publish such things.)

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New machine in the sage.math network

[mabshoff]

On May 4, 11:39 am, Tom Boothby  wrote:
> Recently, Sun donated a new machine to the Sage community.  It's a Sun
> T5240 with two SPARC T2 processors (8 cores total) and 32GB of RAM,

Well, it has 128 "threads".

> and runs Solaris 5.10.  As with the other machines in the network, you
> have access to your home directory from there; and provided you
> haven't changed your password this week, your login should be the same
> as it is at sage.math.  Find it at t2.math.washington.edu, or from
> sage.math, simply t2.
>
> Thanks to Michael Abshoff, there's a custom-built toolchain sufficient
> to build Sage.  

No, unfortunately it is broken on the t2 since it dies with an
internal compiler error when building gfortran. Give the seepd the t2
compiles with it is recommended to use the Sparc binaries I post
anyway since that is much faster and actually works.

> Your admins are a little nexperienced with Solaris, so
> the machine isn't quite as easy to use as we might like.  We're
> working to fix little hiccups as we find them.  Also, none of
> Mathematica, Matlab, or Maple are installed yet, but we plan to
> install them soon.

That would be interesting to see.

> Sun donated the hardware so that we could improve portability of
> various open source projects.  The T2 processors are designed to be
> highly multithreaded; though we haven't gotten very good performance
> out of them yet, the specs indicate that the potential for the
> processors is nothing short of incredible. So experiment away; and
> please share if you figure out how to get the most out of the machine.
>
> If you don't have access to sage.math and you have a good reason to
> access the T2, please contact William Stein.
>
> Enjoy,
>    --tom

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New machine in the sage.math network

[William Stein]

On Mon, May 4, 2009 at 6:50 PM, mabshoff  wrote:
>
>
>
> On May 4, 11:39 am, Tom Boothby  wrote:
>> Recently, Sun donated a new machine to the Sage community.  It's a Sun
>> T5240 with two SPARC T2 processors (8 cores total) and 32GB of RAM,
>
> Well, it has 128 "threads".

Unfortunately, it seems that this does *NOT* mean that if you write a
little C program, spawn 128 threads, and watch them run, then you can
do 128 times what you would do with 1 thread.  You still can only do 8
times as much as with 1 thread.   For raw computation, I don't think
that processor is any better than 8 single cores.   I still have no
idea how to leverage these 128 "threads".If anybody knows, please
tell me.

>> and runs Solaris 5.10.  As with the other machines in the network, you
>> have access to your home directory from there; and provided you
>> haven't changed your password this week, your login should be the same
>> as it is at sage.math.  Find it at t2.math.washington.edu, or from
>> sage.math, simply t2.
>>
>> Thanks to Michael Abshoff, there's a custom-built toolchain sufficient
>> to build Sage.
>
> No, unfortunately it is broken on the t2 since it dies with an
> internal compiler error when building gfortran.

Yep.  But if you're building C code (not Fortran), then you can use
the toolchain.   If you login via bash you get this toolchain (type
which gcc to confirm this).

> Give the seepd the t2
> compiles with it is recommended to use the Sparc binaries I post
> anyway since that is much faster and actually works.

That binary is installed system-wide.  Note that the last one I found
from you was Sage 3.2.3.

>
>> Your admins are a little nexperienced with Solaris, so
>> the machine isn't quite as easy to use as we might like.  We're
>> working to fix little hiccups as we find them.  Also, none of
>> Mathematica, Matlab, or Maple are installed yet, but we plan to
>> install them soon.
>
> That would be interesting to see.

Yep, to compare speed, etc.

>
>> Sun donated the hardware so that we could improve portability of
>> various open source projects.  The T2 processors are designed to be
>> highly multithreaded; though we haven't gotten very good performance
>> out of them yet, the specs indicate that the potential for the
>> processors is nothing short of incredible. So experiment away; and
>> please share if you figure out how to get the most out of the machine.
>>
>> If you don't have access to sage.math and you have a good reason to
>> access the T2, please contact William Stein.
>>
>> Enjoy,
>>    --tom
>
> Cheers,
>
> Michael
> >
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] prime_pi

[William Stein]

This is from the guy who wrote prime_pi:


-- Forwarded message --
From: R. Andrew Ohana 
Date: Mon, May 4, 2009 at 1:30 PM
Subject: Meeting
To: William Stein 


Hey,

Sorry, been away from technology for a bit. I unfortunately do not
have access to any 32-bit sage installs presently, and looking back at
my code, I don't see anything that is really jumping out at me as to
why there is a disagreement. Agreed that for now have 2^40 be the
upper bound -- I haven't tested much beyond that. If anyone is
interested in implementing the Lagarias, etc. algorithm, I'll post
some starter code  I have when I am back to my machines (it should be
much more readable for anyone familiar with prime counting
algorithms).

-Andrew



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New machine in the sage.math network

[mabshoff]

On May 4, 7:26 pm, William Stein  wrote:
> On Mon, May 4, 2009 at 6:50 PM, mabshoff  wrote:
>
> > On May 4, 11:39 am, Tom Boothby  wrote:
> >> Recently, Sun donated a new machine to the Sage community.  It's a Sun
> >> T5240 with two SPARC T2 processors (8 cores total) and 32GB of RAM,
>
> > Well, it has 128 "threads".
>
> Unfortunately, it seems that this does *NOT* mean that if you write a
> little C program, spawn 128 threads, and watch them run, then you can
> do 128 times what you would do with 1 thread.  You still can only do 8
> times as much as with 1 thread.   For raw computation, I don't think
> that processor is any better than 8 single cores.   I still have no
> idea how to leverage these 128 "threads".    If anybody knows, please
> tell me.

Yes, for FP or INT bound computations you won't get more than a 8 or
16 time speedup when going from 1 to 128 "threads", the box is really
meant for different things than HPC stuff. But it has some crypto
units for example and several build in 10GBit interfaces which can
actually be saturated. The box is a killer for databse and Java stuff
though.

> >> and runs Solaris 5.10.  As with the other machines in the network, you
> >> have access to your home directory from there; and provided you
> >> haven't changed your password this week, your login should be the same
> >> as it is at sage.math.  Find it at t2.math.washington.edu, or from
> >> sage.math, simply t2.
>
> >> Thanks to Michael Abshoff, there's a custom-built toolchain sufficient
> >> to build Sage.
>
> > No, unfortunately it is broken on the t2 since it dies with an
> > internal compiler error when building gfortran.
>
> Yep.  But if you're building C code (not Fortran), then you can use
> the toolchain.   If you login via bash you get this toolchain (type
> which gcc to confirm this).

Yeah, I just wanted to point out that building Sage is a problem. I am
working on a gcc 4.4.0 based toolchain and I am hoping the problem
with gfortran will go away.

> > Give the seepd the t2
> > compiles with it is recommended to use the Sparc binaries I post
> > anyway since that is much faster and actually works.
>
> That binary is installed system-wide.  Note that the last one I found
> from you was Sage 3.2.3.

Check out

  http://www.sagemath.org/bin/solaris/

for 3.4.1 binaries. There should be 3.4.2 binaries shortly. I found
one more critical, but trivial to fix issue in 3.4.2+prime_pi()
patch.

Cheers,

Michael

> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Final 3.4.2 sources released

[Justin C. Walker]

On May 4, 2009, at 05:53 , mabshoff wrote:

>
> Hello folks,
>
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
>
>  http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/

Built on Mac OS X, 10.5.6 (Dual Quad Xeon) with no problems.

Before patch #5981, I got these failures:

sage -t  "devel/sage/sage/combinat/sloane_functions.py"
sage -t  "devel/sage/sage/functions/prime_pi.pyx"
sage -t  "devel/sage/sage/functions/transcendental.py"
sage -t  "devel/sage/sage/numerical/optimize.py"
sage -t  "devel/sage/sage/tests/book_stein_ent.py"

After applying the patch, I reran all the tests, and all passed.

Justin

--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
---
Nobody knows the trouble I've been
---




--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New machine in the sage.math network

[Dan Drake]

Just as an amusing note about the T2, I started compiling 3.4.2 on that
machine (mostly to just see what happens), and in the FLINT test suite I
saw this:

  Testing fmpz_poly_evaluate_divconquer()... Cpu = -4008787 ms  Wall = 286189 ms

Uh oh. :)

Dan

-- 
---  Dan Drake 
-  KAIST Department of Mathematical Sciences
---  http://mathsci.kaist.ac.kr/~drake


signature.asc
Description: Digital signature

[sage-devel] Re: New machine in the sage.math network

[mabshoff]

On May 4, 8:49 pm, Dan Drake  wrote:

Hi Dan,

> Just as an amusing note about the T2, I started compiling 3.4.2 on that
> machine (mostly to just see what happens), and in the FLINT test suite I
> saw this:
>
>   Testing fmpz_poly_evaluate_divconquer()... Cpu = -4008787 ms  Wall = 286189 
> ms
>
> Uh oh. :)

Hehe, I have seen some issues with the timing code in FLINT on a
variety of machines, i.e.

  CPU time >> Wall time

as well as

  CPU time << Wall time

but I have never seen a negative CPU time ;)

> Dan

Cheers,

Michael

> --
> ---  Dan Drake 
> -  KAIST Department of Mathematical Sciences
> ---  http://mathsci.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 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New machine in the sage.math network

[William Stein]

On Mon, May 4, 2009 at 8:49 PM, Dan Drake  wrote:
> Just as an amusing note about the T2, I started compiling 3.4.2 on that
> machine (mostly to just see what happens), and in the FLINT test suite I
> saw this:
>
>  Testing fmpz_poly_evaluate_divconquer()... Cpu = -4008787 ms  Wall = 286189 
> ms
>
> Uh oh. :)
>

:-).  Damn those T2 are fast.  We forgot to mention the time travel
capabilities.

http://tvbythenumbers.com/wp-content/uploads/2009/02/terminator2_judgmentday_bluray.jpg

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: New machine in the sage.math network

[Minh Nguyen]

On Tue, May 5, 2009 at 3:53 AM, William Stein  wrote:
>
> On Mon, May 4, 2009 at 8:49 PM, Dan Drake  wrote:
>> Just as an amusing note about the T2, I started compiling 3.4.2 on that
>> machine (mostly to just see what happens), and in the FLINT test suite I
>> saw this:
>>
>>  Testing fmpz_poly_evaluate_divconquer()... Cpu = -4008787 ms  Wall = 286189 
>> ms
>>
>> Uh oh. :)
>>
>
> :-).  Damn those T2 are fast.  We forgot to mention the time travel
> capabilities.
>
> http://tvbythenumbers.com/wp-content/uploads/2009/02/terminator2_judgmentday_bluray.jpg

It's a perfect match: T2 and Skynet :-)

-- 
Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[Rob Beezer]

On May 4, 5:03 pm, rjf  wrote:
> You might find this paper interesting, since it discusses the linkage
> of an interactive graphics system (for graphs) to a computer algebra
> system.

Hi Richard,

Thanks for including that in the discussion - there are a lot of good
ideas in there.  I've thought of bending edges automatically
(especially for a graph with multiple edges), but hadn't thought about
adding in Beizer curves with controls.  Think we can get Javascript to
do that in a browser?

The key for me is having a change to the graph communicated, or
reflected, in the underlying data structure AND causing computations
to be recomputed and displayed "automatically.".   This can be a very
powerful tool for exploring conjectures in graph theory.  With Sage's
@interact framework, many of the most important bits are already in
place.

Rob

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[Rob Beezer]

On May 4, 1:13 am, Fidel  wrote:
> Hello Rob,
>
> I spent some time this weekend coding a function to get the tkz-graph
> string of a graph. You can find what I have got in
>
> http://fidelinux.googlepages.com/tkz-string.sage

Hi Fidel,

I got your code wrapped up into the graph object as a method, and
fiddled with a few small parts to get it working (nothing major, eg I
had to assume the graoh came with positions already since I didn't
have the position validity routine).  At

http://trac.sagemath.org/sage_trac/ticket/5975

is an experimental patch, a sample Sage session creating the latex/tkz
commands, and a PDF of the latex output.

> I have no idea about how to use the trac system but I would be very
> happy to learn, so I can start to contribute in sage.

Six months ago, I didn't have any idea either.  I've been threatening
to write something up about the basics, so maybe now is the time.

Rob
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[Rado]

Hello again,

As promised here is an updated version.

http://www.math.uiuc.edu/~rkirov2/processing/grapheditor.html

Controls are cleaned up (almost all mouse now). If you see something
buggy email me (or even better fix it :) the code is in page). I think
I will add some simple control for cloning vertices (i.e. inheriting
all the edges) in the future.

The controls are heavily inspired by Rob's java applet. It was the one
I liked the most because of its simplicity. I am a proponent of simple
vs. complex since running processing over javascript is a hack to
start with. I doubt we can push it too much, without breaking
something.

One major problem I see so far is that CANVAS js element has problems
with putting text. Processing JS has a workaround that works only on
firefox, which I don't think is good enough. So until something
changes, the graphs will have no labels :( Maybe jquery can overlay
html elements ...

For the next update I will try to include a simple "live" graph
implementation (i.e. real-time spring embedding) and graph input (i.e.
copy/paste from SAGE -> JS editor).

Fidel, thanks for the contribution. I have put it on the page. Email
me if you want your name to link to a homepage. In the version that
would go with SAGE we should hide that output and put everything in
the g.latex() function (which i see you are working on).

RJF, thanks for the paper. I skimmed over it, but bezier curves might
be an overkill for now. Say I manage to put them in JS (processing has
build in bezier curves) is there a good way to pass those to NetworkX
(which from what i understand is how g.show works).

In any case the way I see it is g.show to be the last stop before the
pretty picture pops out not the js editor. The editor should be
intermediate step for little tweaks.

Rado

On May 4, 11:00 pm, Rob Beezer  wrote:
> On May 4, 5:03 pm, rjf  wrote:
>
> > You might find this paper interesting, since it discusses the linkage
> > of an interactive graphics system (for graphs) to a computer algebra
> > system.
>
> Hi Richard,
>
> Thanks for including that in the discussion - there are a lot of good
> ideas in there.  I've thought of bending edges automatically
> (especially for a graph with multiple edges), but hadn't thought about
> adding in Beizer curves with controls.  Think we can get Javascript to
> do that in a browser?
>
> The key for me is having a change to the graph communicated, or
> reflected, in the underlying data structure AND causing computations
> to be recomputed and displayed "automatically.".   This can be a very
> powerful tool for exploring conjectures in graph theory.  With Sage's
> @interact framework, many of the most important bits are already in
> place.
>
> Rob
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: JavaScript Graph editor

[Rob Beezer]

Rado,

Very, very nice!  More later.

Rob

On May 4, 11:04 pm, Rado  wrote:
> Hello again,
>
> As promised here is an updated version.
>
> http://www.math.uiuc.edu/~rkirov2/processing/grapheditor.html
>
> Controls are cleaned up (almost all mouse now). If you see something
> buggy email me (or even better fix it :) the code is in page). I think
> I will add some simple control for cloning vertices (i.e. inheriting
> all the edges) in the future.
>
> The controls are heavily inspired by Rob's java applet. It was the one
> I liked the most because of its simplicity. I am a proponent of simple
> vs. complex since running processing over javascript is a hack to
> start with. I doubt we can push it too much, without breaking
> something.
>
> One major problem I see so far is that CANVAS js element has problems
> with putting text. Processing JS has a workaround that works only on
> firefox, which I don't think is good enough. So until something
> changes, the graphs will have no labels :( Maybe jquery can overlay
> html elements ...
>
> For the next update I will try to include a simple "live" graph
> implementation (i.e. real-time spring embedding) and graph input (i.e.
> copy/paste from SAGE -> JS editor).
>
> Fidel, thanks for the contribution. I have put it on the page. Email
> me if you want your name to link to a homepage. In the version that
> would go with SAGE we should hide that output and put everything in
> the g.latex() function (which i see you are working on).
>
> RJF, thanks for the paper. I skimmed over it, but bezier curves might
> be an overkill for now. Say I manage to put them in JS (processing has
> build in bezier curves) is there a good way to pass those to NetworkX
> (which from what i understand is how g.show works).
>
> In any case the way I see it is g.show to be the last stop before the
> pretty picture pops out not the js editor. The editor should be
> intermediate step for little tweaks.
>
> Rado
>
> On May 4, 11:00 pm, Rob Beezer  wrote:
>
> > On May 4, 5:03 pm, rjf  wrote:
>
> > > You might find this paper interesting, since it discusses the linkage
> > > of an interactive graphics system (for graphs) to a computer algebra
> > > system.
>
> > Hi Richard,
>
> > Thanks for including that in the discussion - there are a lot of good
> > ideas in there.  I've thought of bending edges automatically
> > (especially for a graph with multiple edges), but hadn't thought about
> > adding in Beizer curves with controls.  Think we can get Javascript to
> > do that in a browser?
>
> > The key for me is having a change to the graph communicated, or
> > reflected, in the underlying data structure AND causing computations
> > to be recomputed and displayed "automatically.".   This can be a very
> > powerful tool for exploring conjectures in graph theory.  With Sage's
> > @interact framework, many of the most important bits are already in
> > place.
>
> > Rob
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---