[sage-devel] Re: new style for Sage standard documentation

2010-09-12 Thread koffie
I definitely like the new compatible lay-out. When I looked at http://trac.sagemath.org/sage_trac/attachment/ticket/9850/walkthrough.png my eye spotted some details which leave room for some more improvement. 1. The grey background of the search button (with the tekst "GO" on it) should be a dar

[sage-devel] Re: bug? float(i^i); TypeError: unable to simplify to float approximation

2010-09-12 Thread mda_
On Sep 12, 5:44 pm, Mitesh Patel wrote: >[...] > This appears to work: > > sage: bool(e^(-pi/2) == i^i) > True Thanks Mitesh. What is the sage convention for returning the object as a result of "==" instead of bool when the result is not False? Is it ad hoc? Would you consider float(i^i) rais

[sage-devel] Re: g95 - can we simply forget it exists? - patches posted!

2010-09-12 Thread Dima Pasechnik
OK, after updating one of the patches I posted (the numpy one), all tests pass for me! (must be testlong for my slow machine :)) I added the update here: http://boxen.math.washington.edu/home/dima/patches/gfortran-macosx.tgz Dima On Sep 12, 4:26 pm, Dima Pasechnik wrote: > OK, here > goes:http

Re: [sage-devel] bug? float(i^i); TypeError: unable to simplify to float approximation

2010-09-12 Thread Mitesh Patel
On 09/12/2010 06:41 PM, mda_ wrote: > sage: float(e^(-pi/2)) > 0.20787957635076193 > > The last digit should be 1, since > i^i = 0.20787957635076190854 You could try, e.g., sage: (e^(-pi/2)).numerical_approx(100) 0.20787957635076190854695561983 sage: (i^i).numerical_approx(100) 0.2078795

[sage-devel] Re: new style for Sage standard documentation

2010-09-12 Thread Rob Beezer
On Sep 12, 3:54 pm, mhampton wrote: > If I understand it correctly, the main changes are to colors and the > logo. I definitely like both of those changes. Nice work. Yes, *strictly* color changes and the logo. No organizational or layout parameters were harmed in the making of this ticket. R

[sage-devel] bug? float(i^i); TypeError: unable to simplify to float approximation

2010-09-12 Thread mda_
Also, sage: float(e^(-pi/2)) 0.20787957635076193 The last digit should be 1, since i^i = 0.20787957635076190854 sage does not recognize this identity: sage: e^(-pi/2) == i^i e^(-1/2*pi) == I^I ("True" expected as output.) What's the best way to ask sage for floating point approximatio

[sage-devel] Re: new style for Sage standard documentation

2010-09-12 Thread mhampton
If I understand it correctly, the main changes are to colors and the logo. I definitely like both of those changes. Nice work. -Marshall On Sep 12, 10:12 am, Minh Nguyen wrote: > Hi folks, > > Ticket #9850 [1] contains some major changes to the HTML style of the > Sage standard documentation.

[sage-devel] new style for Sage standard documentation

2010-09-12 Thread Minh Nguyen
Hi folks, Ticket #9850 [1] contains some major changes to the HTML style of the Sage standard documentation. Among others is the new Sage logo which is the same as the current one, but with a transparent background. Thanks to Niles for much of the original ideas and the transparent background logo

[sage-devel] new pynac version - reviews

2010-09-12 Thread Burcin Erocal
Hi, I uploaded a new pynac version to trac #9901: http://trac.sagemath.org/sage_trac/ticket/9901 As usual, it contains fixes for a few bugs and some goodies such as the ability to disable automatic evaluation of (or to "hold") symbolic expressions. There are several patches, most of them only w

[sage-devel] leave of absence

2010-09-12 Thread Alex Ghitza
Dear Sage-ers, For a number of reasons, mostly personal, I find myself in a situation where I must scale back most of my activities. This includes participating in the Sage community; I will continue to do some things here and there when I get a chance, but I won't be reading the mailing lists f

[sage-devel] Re: g95 - can we simply forget it exists?

2010-09-12 Thread Dima Pasechnik
On Sep 12, 5:14 pm, David Kirkby wrote: > On 12 September 2010 10:03, Dima Pasechnik wrote: > > > Dave, > > this is meant to be MacOSX-specific, for testing of the concept. > > If this flies on 10.x for x!=5, with hardware not necessarily PPC, > > then we are in business > > and can go this way

Re: [sage-devel] Re: g95 - can we simply forget it exists?

2010-09-12 Thread David Kirkby
On 12 September 2010 10:03, Dima Pasechnik wrote: > Dave, > this is meant to be MacOSX-specific, for testing of the concept. > If this flies on 10.x for x!=5, with hardware not necessarily PPC, > then we are in business > and can go this way. > > Dima But the point is the SAGE_FORTRAN variable is

[sage-devel] Re: g95 - can we simply forget it exists?

2010-09-12 Thread Dima Pasechnik
Dave, this is meant to be MacOSX-specific, for testing of the concept. If this flies on 10.x for x!=5, with hardware not necessarily PPC, then we are in business and can go this way. Dima On Sep 12, 4:35 pm, David Kirkby wrote: > On 12 September 2010 08:33, Dima Pasechnik wrote: > > > > > On Se

Re: [sage-devel] Re: g95 - can we simply forget it exists?

2010-09-12 Thread David Kirkby
On 12 September 2010 08:33, Dima Pasechnik wrote: > > > On Sep 12, 2:38 am, Dima Pasechnik wrote: >> I got stuck at scipy: >> > > I have fixed this by making changes in numpy's patch for gnu.py. > The complete build of Sage-4.5.3.has successfully finished now. > I'll post the necessary patched, a

[sage-devel] Re: g95 - can we simply forget it exists? - patches posted!

2010-09-12 Thread Dima Pasechnik
OK, here goes: http://boxen.math.washington.edu/home/dima/patches/gfortran-macosx.tgz Instructions are included. To apply patches, follow instructions on http://sagemath.org/doc/developer/walk_through.html#reviewing-patches-with-queues I tested that is builds Sage 4.5.3 on MacOSX 10.5 ppc (32 bit,

[sage-devel] Re: g95 - can we simply forget it exists?

2010-09-12 Thread Dima Pasechnik
On Sep 12, 2:38 am, Dima Pasechnik wrote: > I got stuck at scipy: > I have fixed this by making changes in numpy's patch for gnu.py. The complete build of Sage-4.5.3.has successfully finished now. I'll post the necessary patched, and the test results, shortly. > In the log below, the line begi