date:20100909

On 09/ 9/10 03:32 AM, Tim Daly wrote:

Some of the questions you have about "why lisp" are answered in:
http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Rich-Hickey-and-Brian-Beckman-Inside-Clojure/

which is about Clojure, a more recent lisp although the ideas are
essentially the same in Common Lisp.

Tim Daly

Thank you Tim.

I think you, RJF and a few others have convinced me Lisp would be the best for
this. I'll revisit this once the 64-bit Solaris ports are done.

If someone wants to make a parser from Python, let them do it. But I'm pretty
convinced it is not the best way to approach it.

However, I've had no success running RJF's code. I would have thought the ANSI
Common Lisp would have covered how commands are loaded, but I am told that is
not so. If Richard could suggest how his code might be modified to run with ECL,
then I'd like to give it a quick try and post my results here.

Dave

David Kirkby wrote:

On 5 September 2010 10:14, Mitesh Patel wrote:

Hi David,

On 09/05/2010 03:52 AM, David Kirkby wrote:

I'm quite happy to be that someone who learns Lisp - I'm serious
thinking of buying a book on it. Unfortunately, they tend to be quite
expensive, as do books on writing compilers.

Some time ago, I found "Practical Common Lisp" by P. Seibel, which is
available for free online:

http://www.gigamonkeys.com/book/

But I have not read it and am not familar with Lisp.

Sincerely,
Mitesh

Thank you for that - it is one of the books on Amazon I was considering.

http://www.amazon.com/Practical-Common-Lisp-Peter-Seibel/dp/1590592395

It's $52.29 on Amazon - to find it free is quite nice.

I also found "Common Lisp: A Gentle Introduction to Symbolic
Computation" - all

http://www.cs.cmu.edu/~dst/LispBook/index.html

I want to finish the Solaris port first, getting it building properly
on 64-bit systems. But then I might take a look trying to parse
Mathematica and do something useful with it.

Dave

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

Re: [sage-devel] Re: New PARI needs testing

2010-09-09 Thread Jeroen Demeyer

On 2010-09-08 22:05, Dr. David Kirkby wrote:
> Could you build it in a number of times in a loop and let us know if it
> ever fails.

I built it 100 times (without SAGE_CHECK) and it was successful every time.

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

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

There's odd bits code scattered around in Sage that do tests for g95, which is
an old Fortran 95 compiler that in any modern Linux or Unix systems.

According to Wikipedia

http://en.wikipedia.org/wiki/G95

gfortran was forked from g95 in 2003 - i.e. 7 years ago.

I'm not sure at what point gfortran became the dominant compiler, but I've not
seen g95 used in the last few years. It might still exist on some systems, but
people tend to use gfortran instead, as that is part of gcc.

Do others, like me, believe we just remove such bits of code as and when we come
across them? i.e. don't make specific tests for gfortran vs g95?

g95 binaries have already been removed from Sage

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

There's a few bits of code in the ATLAS package which make such tests - one of
them uses the "readelf" program to determine if a pre-installed version of ATLAS
was built with g95.

William said here

http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235b738348000/d0f3efda8c0bcf0c?lnk=gst&q=g95+remove#d0f3efda8c0bcf0c

"Probably the only platforms that get g95 are older OS X."

Since ATLAS is not installed on OS X, it seems even less worthwhile having such
a test in the ATLAS package.

But before removing this code, I thought it wise to get the opinion of others.

Dave

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


On 09/ 9/10 10:09 AM, Dr. David Kirkby wrote:

There's odd bits code scattered around in Sage that do tests for g95,
which is an old Fortran 95 compiler that in any modern Linux or Unix
systems.


Oops, I mean its an old compiler that you will not find on any modern system.


Since ATLAS is not installed on OS X, it seems even less worthwhile
having such a test in the ATLAS package.


I mean we don't have install ATLAS on OS X. The "spkg-install-script" has:

if [ `uname` = "Darwin" ]; then
exit 0
fi

Dave

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

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

2010-09-09 Thread François Bissey

> There's odd bits code scattered around in Sage that do tests for g95, which
> is an old Fortran 95 compiler that in any modern Linux or Unix systems.
> 
> According to Wikipedia
> 
> http://en.wikipedia.org/wiki/G95
> 
> gfortran was forked from g95 in 2003 - i.e. 7 years ago.
> 

That doesn't mean that g95 stayed stagnant behind. OK so it is still 
recommended to build it against gcc-4.0.3, but otherwise it is a fine compiler 
and I have only switched to gfortran in the gcc-4.4.x series when it had all 
the features that I needed for my work (outside of sage).

> 
> I'm not sure at what point gfortran became the dominant compiler, but I've
> not seen g95 used in the last few years. It might still exist on some
> systems, but people tend to use gfortran instead, as that is part of gcc.
> 
> Do others, like me, believe we just remove such bits of code as and when we
> come across them? i.e. don't make specific tests for gfortran vs g95?
> 
> g95 binaries have already been removed from Sage
> 
> http://trac.sagemath.org/sage_trac/ticket/7485
> 
> There's a few bits of code in the ATLAS package which make such tests - one
> of them uses the "readelf" program to determine if a pre-installed version
> of ATLAS was built with g95.
> 
> William said here
> 
> http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235b73834
> 8000/d0f3efda8c0bcf0c?lnk=gst&q=g95+remove#d0f3efda8c0bcf0c
> 
> "Probably the only platforms that get g95 are older OS X."
> 
> Since ATLAS is not installed on OS X, it seems even less worthwhile having
> such a test in the ATLAS package.
> 

+1

Francois

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

Re: [sage-devel] Re: New PARI needs testing


On 09/ 9/10 09:53 AM, Jeroen Demeyer wrote:

On 2010-09-08 22:05, Dr. David Kirkby wrote:

Could you build it in a number of times in a loop and let us know if it
ever fails.


I built it 100 times (without SAGE_CHECK) and it was successful every time.



I think given that, and even the person that had the failure now has it working, 
it's best to leave the GSL package unchanged.


Otherwise would disable parallel builds in GSL package.

If a ticket was opened showing the failure, it could be reported to the upstream 
developers to see if they have any comments. Has anyone done that yet? If not, 
I'll open a ticket and report the failure upstream.


Dave

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

[sage-devel] Re: New PARI needs testing

Builds ok after all on PPC OS X 10.4 (whew!) - to test would overload
things too much for what I need it for now.

However, I noticed something weird:

Dasher-03:~/Desktop/sage-4.6.prealpha4 student$ ./sage
--
| Sage Version 4.6.prealpha4, Release Date: 2010-09-07   |
| Type notebook() for the GUI, and license() for information.|
--
**
**
* Warning: this is a prerelease version, and it may be unstable. *
**
**
sage: 2+2
4
sage:
Exiting Sage (CPU time 0m0.28s, Wall time 0m3.25s).
Exiting spawned GP/PARI interpreter process.

Note the last line.  This is repeatable.  Do we really want this?  We
do get an exit of a spawned GAP process when one moves Sage to a new
location, but that's the only time I can think of that Sage makes such
a message without any other programs being started.  Don't tell me we
started GP/PARI to compute 2+2!  Those aren't really the size of
integers we should need that for :)

- kcrisman

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

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



On Sep 9, 5:09 am, "Dr. David Kirkby"  wrote:
> There's odd bits code scattered around in Sage that do tests for g95, which is
> an old Fortran 95 compiler that in any modern Linux or Unix systems.
>
> According to Wikipedia
>
> http://en.wikipedia.org/wiki/G95
>
> gfortran was forked from g95 in 2003 - i.e. 7 years ago.
>
> I'm not sure at what point gfortran became the dominant compiler, but I've not
> seen g95 used in the last few years. It might still exist on some systems, but
> people tend to use gfortran instead, as that is part of gcc.
>
> Do others, like me, believe we just remove such bits of code as and when we 
> come
> across them? i.e. don't make specific tests for gfortran vs g95?
>
> g95 binaries have already been removed from Sage
>
> http://trac.sagemath.org/sage_trac/ticket/7485
>
> There's a few bits of code in the ATLAS package which make such tests - one of
> them uses the "readelf" program to determine if a pre-installed version of 
> ATLAS
> was built with g95.
>
> William said here
>
> http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235...
>
> "Probably the only platforms that get g95 are older OS X."

It seems like PowerPC gets it.

> Since ATLAS is not installed on OS X, it seems even less worthwhile having 
> such
> a test in the ATLAS package.

True; we use the system one.

Sage also needs fortran for R, at least.  Anywhere else?  If someone
knows how to test for the Sage fortran in a compiled build, I can
quick see which one is installed on my PPC box; the command local/bin/
sage_fortran --version yielded an error (interestingly, a different
error on 10.6 than on 10.4).  Maybe the fortrans get axed after the
build is done?

- kcrisman

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

[sage-devel] Safari and Trac viewing

Does anyone sometimes get weird behavior on Safari when viewing Trac
tickets?  None of the formatting comes through at times (now is such a
time, but it's happened for me for months, never long enough to
complain until now).  Firefox works fine, as do Chrome and Opera
(didn't try IE).  Any ideas?

- kcrisman

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

[sage-devel] Re: Safari and Trac viewing



On Sep 9, 9:19 pm, kcrisman  wrote:
> Does anyone sometimes get weird behavior on Safari when viewing Trac
> tickets?

yes, on my old PowerBook G4 I get this with Safari once in a while.

> None of the formatting comes through at times (now is such a
> time, but it's happened for me for months, never long enough to
> complain until now).  Firefox works fine, as do Chrome and Opera
> (didn't try IE).  Any ideas?
>
> - kcrisman

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

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



On Sep 9, 9:05 pm, kcrisman  wrote:
> On Sep 9, 5:09 am, "Dr. David Kirkby"  wrote:
>
>
>
>
>
> > There's odd bits code scattered around in Sage that do tests for g95, which 
> > is
> > an old Fortran 95 compiler that in any modern Linux or Unix systems.
>
> > According to Wikipedia
>
> >http://en.wikipedia.org/wiki/G95
>
> > gfortran was forked from g95 in 2003 - i.e. 7 years ago.
>
> > I'm not sure at what point gfortran became the dominant compiler, but I've 
> > not
> > seen g95 used in the last few years. It might still exist on some systems, 
> > but
> > people tend to use gfortran instead, as that is part of gcc.
>
> > Do others, like me, believe we just remove such bits of code as and when we 
> > come
> > across them? i.e. don't make specific tests for gfortran vs g95?
>
> > g95 binaries have already been removed from Sage
>
> >http://trac.sagemath.org/sage_trac/ticket/7485
>
> > There's a few bits of code in the ATLAS package which make such tests - one 
> > of
> > them uses the "readelf" program to determine if a pre-installed version of 
> > ATLAS
> > was built with g95.
>
> > William said here
>
> >http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235...
>
> > "Probably the only platforms that get g95 are older OS X."
>
> It seems like PowerPC gets it.

Well, I run MacOSX 10.5 on my PPC (G4), and I have gfortran.

I would propose dropping support for g95...
E.g. it only causes a headache when updating packages that are
supposed to
depend on it, e.g. cvxopt. I have no idea how and where to test my new
cvxopt-1.1.2 spkg with g95...

>
> > Since ATLAS is not installed on OS X, it seems even less worthwhile having 
> > such
> > a test in the ATLAS package.
>
> True; we use the system one.
>
> Sage also needs fortran for R, at least.  Anywhere else?  If someone
> knows how to test for the Sage fortran in a compiled build, I can
> quick see which one is installed on my PPC box; the command local/bin/
> sage_fortran --version yielded an error (interestingly, a different
> error on 10.6 than on 10.4).  Maybe the fortrans get axed after the
> build is done?
>
> - kcrisman

Dima

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

[sage-devel] Re: How to deal with GAP's machine dependent random generator?



On Sep 9, 3:12 am, Peter Jeremy  wrote:
> On 2010-Sep-06 21:29:35 +0100, "Dr. David Kirkby"  
> wrote:
>
> >I would be very weary of any random number generator that claims to be a good
> >source of random numbers if the output differs by platform or compilation 
> >mode.
>
> It depends what you mean by "differs".  For "real" random numbers, you
> can only discuss different statistical properties of the sequences
> because the actual sequencee of numbers cannot be predicted or repeated.
>
> For pseudo-random sequences, you can additionally talk about the
> actual sequence of numbers returned by the rng.  The documentation for
> most rng's talks about sequences being repeatable by calling an
> initialisation function with the same seed but generally does not
> state the scope of the repeatability - so actual sequences generated
> by a specific seed could potentially vary on different platforms.
>
> I would suggest that the bigger problem is that the GAP doctest relies
> on a specific sequence of random numbers being used by GAP but does
> not control or test the actual sequence of random numbers.
>
I don't quite see what you mean by the latter.
GAP, without the patch I proposed in the spkg in this thread (trac
#9867), uses a random seed in an endianness-dependent way.
The said patch fixes this.
Nobody seems to be willing to review the ticket, however, as if the
problem got resolved in a way that escapes me.

Best,
Dima



> --
> Peter Jeremy
>
>  application_pgp-signature_part
> < 1KViewDownload

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

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

2010-09-09 Thread David Kirkby

On 9 September 2010 10:23, François Bissey  wrote:
>> There's odd bits code scattered around in Sage that do tests for g95, which
>> is an old Fortran 95 compiler that in any modern Linux or Unix systems.
>>
>> According to Wikipedia
>>
>> http://en.wikipedia.org/wiki/G95
>>
>> gfortran was forked from g95 in 2003 - i.e. 7 years ago.
>>
>
> That doesn't mean that g95 stayed stagnant behind. OK so it is still
> recommended to build it against gcc-4.0.3, but otherwise it is a fine compiler
> and I have only switched to gfortran in the gcc-4.4.x series when it had all
> the features that I needed for my work (outside of sage).


I realise that.

>> William said here
>>
>> http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235b73834
>> 8000/d0f3efda8c0bcf0c?lnk=gst&q=g95+remove#d0f3efda8c0bcf0c
>>
>> "Probably the only platforms that get g95 are older OS X."
>>
>> Since ATLAS is not installed on OS X, it seems even less worthwhile having
>> such a test in the ATLAS package.
>>
>
> +1
>
> Francois

Glad you and other agree.

It just seems a pain.

There's odd bits of code related to g95 dotted around in Sage -
several bits are written in perl. They just make maintenance harder to
me.

I've never liked the idea of using the variable SAGE_FORTRAN - I don't
know why we can't use FC like all autoconf packages do. We don't have
a SAGE_CC or a SAGE_CXX - we use the standard variables. Why should
Fortran be any different?

But SAGE_FORTRAN aside, having specific tests for g95 seem a bit pointless.


Dave

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

Re: [sage-devel] Re: Safari and Trac viewing

2010-09-09 Thread Ivan Andrus

On Sep 9, 2010, at 3:33 PM, Dima Pasechnik wrote:
> On Sep 9, 9:19 pm, kcrisman  wrote:
>> Does anyone sometimes get weird behavior on Safari when viewing Trac
>> tickets?
> 
> yes, on my old PowerBook G4 I get this with Safari once in a while.

I saw this just the other day on Omniweb (which probably gets identified as 
Safari) on 10.6.  It was exceedingly weird.

>>  None of the formatting comes through at times (now is such a
>> time, but it's happened for me for months, never long enough to
>> complain until now).  Firefox works fine, as do Chrome and Opera
>> (didn't try IE).  Any ideas?
>> 
>> - kcrisman

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

[sage-devel] Re: How to deal with GAP's machine dependent random generator?

2010-09-09 Thread Simon King

Hi Dima!

On Sep 9, 2:44 pm, Dima Pasechnik  wrote:
>...
> Nobody seems to be willing to review the ticket, however, as if the
> problem got resolved in a way that escapes me.

The problem for my package did indeed resolve, due to
current_randstate().set_seed_gap(). But of course it should better be
solved directly in GAP (resp. the GAP spkg).

However, at the moment, I spend all my energy in (1) finalising the
next version of my cohomology package, and (2) the relocation of my
family (without the help of my wife, who is very sick). After (1) I'll
probably need a break from development. So, I'd appreciate if someone
else could review the ticket.

Best regards,
Simon

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

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

> > > William said here
>
> > >http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235...
>
> > > "Probably the only platforms that get g95 are older OS X."
>
> > It seems like PowerPC gets it.
>
> Well, I run MacOSX 10.5 on my PPC (G4), and I have gfortran.

Can you give me a command to check this on my own (G4, but running
10.4) machine?  As noted above, I can't get the command which should
work to work.  local/bin/which_fortran is one of those Perl scripts
looking for G95, by the way.

> I would propose dropping support for g95...

If it doesn't break 10.4 support, I would agree.
http://gcc.gnu.org/wiki/GFortranBinaries#MacOS seems to indicate that
PPC binaries are only available for Leopard, not Tiger.
Unsurprisingly, the R project has a site (http://r.research.att.com/
tools/) with links to lots of Fortran compilers, including apparently
one gfortran one which would work on 10.4 (?).

- kcrisman

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

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


> Unsurprisingly, the R project has a site (http://r.research.att.com/
> tools/) with links to lots of Fortran compilers, including apparently
> one gfortran one which would work on 10.4 (?).

Though apparently one then also needs to download a newer-built Xcode
- a custom one which has gcc 4.2 (as opposed to 4.0.1, which is
usually the last supported one on Tiger), SDK, and gfortran.  Then one
has to create symlinks... yuck.  Or we could just provide gcc for PPC
Tiger along with gfortran... this seems weird.

- kcrisman

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

[sage-devel] Re: A Mathematica parser for Sage.

2010-09-09 Thread rjf


>
> However, I've had no success running RJF's code. I would have thought the ANSI
> Common Lisp would have covered how commands are loaded, but I am told that is
> not so. If Richard could suggest how his code might be modified to run with 
> ECL,
> then I'd like to give it a quick try and post my results here.

Reading this thread, it seems that tkosan installed my code. Did you
follow his suggestions?
If you have it running on ABCL,
there should be no modification to run on ECL, but frankly, I have no
copy of ECL and do not intend to get one.

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

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

Okay, I finally figured out how to check this - I had to run the
binary directly, the scripts didn't work because of the way they're
used (since gfortran isn't in my PATH, of course):

G95 (GCC 4.0.3 (g95 0.91!) Jun 4 2007)

Dima, can you look at your $SAGE_LOCAL/bin/sage_fortran and tell us
what it says?  If it has sage_fortran.bin, run

$SAGE_LOCAL/bin/sage_fortran.bin --version

which will almost certainly be G95, otherwise it's probably

$SAGE_LOCAL/bin/gfortran-xx --version

which will be gfortran.

I would be open to building a custom gfortran binary against GCC 4.0.1
for distribution with Sage in this edge case, but would need a lot of
hand-holding.

Then again, 
http://www.macresearch.org/xcode_gfortran_contest_winner_damien_bobillot
seems to indicate there is a plugin for Xcode 2.4 (the default Tiger
one), and http://gcc.gnu.org/wiki/GFortranBinariesMacOS would
apparently work with Xcode 2.5...

Sorry for all the activity on this.  My interest on this is not
related to drkirkby's (legitimate) concerns, but is related to #9808.

- kcrisman

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

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

2010-09-09 Thread David Kirkby

On 9 September 2010 15:33, kcrisman  wrote:
>> > > William said here
>>
>> > >http://groups.google.com/group/sage-devel/browse_thread/thread/1b6235...
>>
>> > > "Probably the only platforms that get g95 are older OS X."
>>
>> > It seems like PowerPC gets it.
>>
>> Well, I run MacOSX 10.5 on my PPC (G4), and I have gfortran.

> Can you give me a command to check this on my own (G4, but running
> 10.4) machine?  As noted above, I can't get the command which should
> work to work.  local/bin/which_fortran is one of those Perl scripts
> looking for G95, by the way.
>
>> I would propose dropping support for g95...

> If it doesn't break 10.4 support, I would agree.

I think its appropiate if I split my question into two.

1) Can we remove code just in *ATLAS* that checks to see if a previous
installation of ATLAS was built with g95 or not?
2) Can we remove all code in the whole of Sage that worries about g95.

Let's consider both cases - first ATLAS, then the more general one.

1) ATLAS

Given we do not install ATLAS on OS X at all, we can discount issues
related to OS X.

The *only* justification I can see for keeping the code below in ATLAS
is that someone could have a very old Linux system with a
pre-installed version of ATLAS that has a shared library built with
g95. If they then try to build Sage with gfortran on that very old
system, it could break.

The code below, which is in the ATLAS package  *may* detect that and
exit with an error message. I say *may* since the shared library that
is tested (ibf77blas.so) is not reliably built on Linux.

This code generates a harmless error on Solaris, as there is no
"readelf" command. But it does not cause any problems. It's just a bit
annoying to have code generating error messages, when IMHO the problem
this attempts to solve is not worth worrying about in 2010.

##
##
   s_gfortran = os.popen2('readelf -s '
+ATLAS_LIB+'/lib/libf77blas.so | grep gfortran')[1].read()
s_g95 = os.popen2('readelf -s ' + ATLAS_LIB +
'/lib/libf77blas.so | grep g95')[1].read()

if s_gfortran !='' and not fortran.startswith('gfortran'):
print "Symbols in lib77blas indicate it was build with
gfortran \n"
print "However SAGE is using a different fortran compiler \n"
print "If you wish to use this blas library, make sure
SAGE_FORTRAN points \n"
print "to a fortran compiler compatible with this library. \n"
sys.exit(2)

if s_g95 !='' and not fortran.startswith('g95'):
print "Symbols in lib77blas indicate it was build with g95 \n"
print "However SAGE is using a different fortran compiler \n"
print "If you wish to use this blas library, make sure
SAGE_FORTRAN points \n"
print "to a fortran compiler compatible with this library. \n"
sys.exit(2)
##
##

2) The next question is whether we should remove *all* code in Sage
that make a distinction between g95 and gfortran. I propose that Sage
still allows one to specify a Fortran compiler with SAGE_FORTRAN, but
if that's not set, it just uses gfortran and does not consider g95.

Note, Sage used to ship with g95 binaries, but they have since been removed. See

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

So Sage is definitely moving away from g95.

I'm *NOT* proposing we stop someone building Sage with g95 if they
really want to. Let them try, and set

$ export SAGE_FORTRAN=/path/to/g95

in much the same was I would do on Solaris with

$ export SAGE_FORTRAN=/opt/sunstudio12.1/bin/f95

(note f95, not g95)

I just think we should remove the odd code (much of it rather ugly,
often written in perl), which makes a distinction between gfortran and
g95.

Dave

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

[sage-devel] Sage is embarrassingly slow

2010-09-09 Thread David Harvey


Dear sage-devel,

Sage is very slow. I discovered this (again) while trying to write a  
prototype of an algorithm for computing zeta functions of projective  
varieties. I need to multiply lots of polynomials and matrices over  
finite rings, and frequently move coefficients between polynomials  
and matrices. The arithmetic is actually not too bad; it's the boring  
data movement stuff that really sucks. I made a bunch of tickets:


http://trac.sagemath.org/sage_trac/ticket/9882
http://trac.sagemath.org/sage_trac/ticket/9883
http://trac.sagemath.org/sage_trac/ticket/9884
http://trac.sagemath.org/sage_trac/ticket/9885
http://trac.sagemath.org/sage_trac/ticket/9886
http://trac.sagemath.org/sage_trac/ticket/9887
http://trac.sagemath.org/sage_trac/ticket/9888

Maybe I can be the first to #1 if I keep going!

david

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

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

###
>
> 2) The next question is whether we should remove *all* code in Sage
> that make a distinction between g95 and gfortran. I propose that Sage
> still allows one to specify a Fortran compiler with SAGE_FORTRAN, but
> if that's not set, it just uses gfortran and does not consider g95.
>
> Note, Sage used to ship with g95 binaries, but they have since been removed. 
> See
>
> http://trac.sagemath.org/sage_trac/ticket/7485

If you look carefully at that ticket, though, you'll see that on OS X
10.4 PPC we do supply G95.  I ran

$SAGE_LOCAL/bin/sage_fortran.bin --version

to get the output in my previous email, and I definitely would not
install Fortran (or anything else like it!) anywhere but via Sage.
Even thinking about this taxes my CS background, which is virtually
nil.  But Sage does supply it.

> So Sage is definitely moving away from g95.

True.

> I just think we should remove the odd code (much of it rather ugly,
> often written in perl), which makes a distinction between gfortran and
> g95.

It would be nice if we could find a binary for gfortran for the
particular situation I reference above.

- kcrisman

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

Re: [sage-devel] Sage is embarrassingly slow

2010-09-09 Thread Robert Bradshaw

On Thu, Sep 9, 2010 at 9:24 AM, David Harvey  wrote:
> Dear sage-devel,
>
> Sage is very slow. I discovered this (again) while trying to write a
> prototype of an algorithm for computing zeta functions of projective
> varieties. I need to multiply lots of polynomials and matrices over finite
> rings, and frequently move coefficients between polynomials and matrices.
> The arithmetic is actually not too bad; it's the boring data movement stuff
> that really sucks. I made a bunch of tickets:
>
> http://trac.sagemath.org/sage_trac/ticket/9882
> http://trac.sagemath.org/sage_trac/ticket/9883
> http://trac.sagemath.org/sage_trac/ticket/9884
> http://trac.sagemath.org/sage_trac/ticket/9885
> http://trac.sagemath.org/sage_trac/ticket/9886
> http://trac.sagemath.org/sage_trac/ticket/9887
> http://trac.sagemath.org/sage_trac/ticket/9888
>
> Maybe I can be the first to #1 if I keep going!

Ugh. I don't think anyone's done anything optimization for
non-word-sized IntegerMod.

- Robert

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

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

I didn't build sage on my G4 since 4.3.4, and there gfortran points to
something I got from fink.
So I must have built Sage using fink's gfortran, built against
gcc-4.3.4 ? Hmm.
OK, let me try the current release and see if I get anywhere.
(It will take a while...)

Dima

On Sep 9, 11:20 pm, kcrisman  wrote:
> Okay, I finally figured out how to check this - I had to run the
> binary directly, the scripts didn't work because of the way they're
> used (since gfortran isn't in my PATH, of course):
>
> G95 (GCC 4.0.3 (g95 0.91!) Jun 4 2007)
>
> Dima, can you look at your $SAGE_LOCAL/bin/sage_fortran and tell us
> what it says?  If it has sage_fortran.bin, run
>
> $SAGE_LOCAL/bin/sage_fortran.bin --version
>
> which will almost certainly be G95, otherwise it's probably
>
> $SAGE_LOCAL/bin/gfortran-xx --version
>
> which will be gfortran.
>
> I would be open to building a custom gfortran binary against GCC 4.0.1
> for distribution with Sage in this edge case, but would need a lot of
> hand-holding.
>
> Then 
> again,http://www.macresearch.org/xcode_gfortran_contest_winner_damien_bobillot
> seems to indicate there is a plugin for Xcode 2.4 (the default Tiger
> one), andhttp://gcc.gnu.org/wiki/GFortranBinariesMacOSwould
> apparently work with Xcode 2.5...
>
> Sorry for all the activity on this.  My interest on this is not
> related to drkirkby's (legitimate) concerns, but is related to #9808.
>
> - kcrisman

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

Re: [sage-devel] Re: New PARI needs testing

2010-09-09 Thread Jeroen Demeyer

On 2010-09-09 14:48, kcrisman wrote:
> sage:
> Exiting Sage (CPU time 0m0.28s, Wall time 0m3.25s).
> Exiting spawned GP/PARI interpreter process.
> 
> Note the last line.  This is repeatable.  Do we really want this?  We
> do get an exit of a spawned GAP process when one moves Sage to a new
> location, but that's the only time I can think of that Sage makes such
> a message without any other programs being started.  Don't tell me we
> started GP/PARI to compute 2+2!  Those aren't really the size of
> integers we should need that for :)
The "2+2" has nothing do with it.  Even exiting Sage immediately gives
that message.  This HAS changed w.r.t. sage-4.5.3 but I don't know
exactly what the reason is.

Jeroen.

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

[sage-devel] Re: Sage is embarrassingly slow

2010-09-09 Thread Jason Grout


On 9/9/10 11:24 AM, David Harvey wrote:



Maybe I can be the first to #1 if I keep going!



+1 to you opening up 118 tickets and posting patches to them!

Jason

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

[sage-devel] Re: New PARI needs testing



On Sep 9, 12:40 pm, Jeroen Demeyer  wrote:
> On 2010-09-09 14:48, kcrisman wrote:> sage:
> > Exiting Sage (CPU time 0m0.28s, Wall time 0m3.25s).
> > Exiting spawned GP/PARI interpreter process.
>
> > Note the last line.  This is repeatable.  Do we really want this?  We
> > do get an exit of a spawned GAP process when one moves Sage to a new
> > location, but that's the only time I can think of that Sage makes such
> > a message without any other programs being started.  Don't tell me we
> > started GP/PARI to compute 2+2!  Those aren't really the size of
> > integers we should need that for :)
>
> The "2+2" has nothing do with it.  

Well, I figured ;)  Hopefully it won't be hard to track down.

- kcrisman

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

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

On Sep 9, 12:31 pm, Dima Pasechnik  wrote:
> I didn't build sage on my G4 since 4.3.4, and there gfortran points to
> something I got from fink.
> So I must have built Sage using fink's gfortran, built against
> gcc-4.3.4 ? Hmm.
> OK, let me try the current release and see if I get anywhere.
> (It will take a while...)

That should be ok, though.  The point is that you used something in
fink, and you didn't use Xcode's GCC.  This is a useful data point
too, but somewhat orthogonal to my point (just standard build on OS
X).  But useful to know that's why you don't have G95 showing up,
since you didn't use Sage's provided binary to start with.

- kcrisman

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

[sage-devel] Re: New PARI needs testing

2010-09-09 Thread ggrafendorfer

Hi,

built successful and almost all test passed (ptestlong) on AMD Phenom
X4 II, Fedora 13

one test failed, this is related to

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


Georg



On Sep 7, 12:09 pm, Jeroen Demeyer  wrote:
> Hello sage-devel,
>
> As far as we know, there are no more remaining issues for the PARI
> update (#9343).  We haven't had any doctest failures for a while now.
> The main issues recently have been with PARI not compiling properly on
> various machines, but all those seem to be fixed now.
>
> I have made a complete Sage distribution sage-4.6.prealpha4, based on
> sage-4.5.3.rc0 with the new PARI and some more updates.  You can
> download it 
> fromhttp://sage.math.washington.edu/home/jdemeyer/dist/sage-4.6.prealpha4...
>
> In order to test this thoroughly, extract the tarball and then:
>   cd sage-4.6.prealpha4
>   make
>   env SAGE_CHECK=yes SAGE_TUNE_pari=yes ./sage -f
> pari-2.4.3.svn-12577.p5.spkg
>   make ptestlong
>
> On sage.math.washington.edu, this worked without problems (apart from a
> sometimes-reproducible error in devel/sage/sage/tests/startup.py)
>
> The following tickets have been merged in sage-4.6.prealpha4 (w.r.t.
> sage-4.5.3.rc0):
> #9343: PARI upgrade
> #9860: Port changes in PARI 2.3.5.p4 (#9722) to current 2.4.3
> #9591: Upgrade genus2reduction due to Pari upgrade to svn snapshot 12577
> - a pre-release of Pari 2.4.3
> #9592: Upgrade lcalc to work with Pari svn snapshot 12577 - a
> pre-release of Pari 2.4.3
> #9845: lcalc doesn't build on cygwin due to missing time.h include
> #9750: Document that PARI no longer assumes more than GRH.
> #9636: Catch output from PARI in Sage.
> #9400: Modify the NumberField constructor to pass in optional integer B
> such that all the internal PARI routines will replace the discriminant
> by its gcd with B, making some things massively faster.
>
> Jeroen.

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

[sage-devel] Re: New PARI needs testing

2010-09-09 Thread John Cremona

On Sep 9, 7:00 pm, kcrisman  wrote:
> On Sep 9, 12:40 pm, Jeroen Demeyer  wrote:
>
> > On 2010-09-09 14:48, kcrisman wrote:> sage:
> > > Exiting Sage (CPU time 0m0.28s, Wall time 0m3.25s).
> > > Exiting spawned GP/PARI interpreter process.
>
> > > Note the last line.  This is repeatable.  Do we really want this?  We
> > > do get an exit of a spawned GAP process when one moves Sage to a new
> > > location, but that's the only time I can think of that Sage makes such
> > > a message without any other programs being started.  Don't tell me we
> > > started GP/PARI to compute 2+2!  Those aren't really the size of
> > > integers we should need that for :)
>
> > The "2+2" has nothing do with it.  
>
> Well, I figured ;)  Hopefully it won't be hard to track down.

This may be a side effect of having to send a gp command on startup of
the gp interpreter (to turn off the default debugging mode), which may
mean that the interpreter is really started up on creation of the
interpreter object, every time, instead of only being started when a
"real" gp command is needed.

That's a non-trivial fix in something I had to work out how to change
in the first place;  not impossible though.  But I will not be able to
do this before Saturday... so someone else is welcome to take a look.

>
> - kcrisman

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

[sage-devel] reviewing sage-location patch

2010-09-09 Thread Jason Grout

Currently, installing packages on a Sage that has been moved from its
original build location is seriously broken. The problem is that the
pkgconfig files (which many spkgs use to set up the include paths) are
not updated to the new location.

There is a patch at #9210 that fixes this. It needs to be reviewed,
though. The review instructions are a bit touchy, since the patch needs
to be applied before the sage is moved.

Can someone please review this patch? It would make reviewing and
installing spkgs a lot easier, as they actually build and refer to the
correct paths. It may also fix some longstanding bugs where sage picks
up system packages when it should pick up sage-specific packages.

To review, this should be sufficient:

1. Download and build Sage (important; it must be a fresh build from
source).

2. Apply the patch at the ticket to the scripts repository (in
SAGE_ROOT/local/bin):

http://trac.sagemath.org/sage_trac/raw-attachment/ticket/9210/trac-9210-rewrite-sage-location.patch

3. Delete the file SAGE_ROOT/local/lib/sage-current-location.txt, if it
exists

4. Now run Sage, then exit (this updates the sage-current-location and
pkgconfig files appropriately).

5. Move the sage directory and run Sage again. The
SAGE_ROOT/local/lib/sage-current-location.txt should be updated, and the
pkgconfig files in SAGE_ROOT/local/lib/pkgconfig/ should also be updated
to the new path (you can check the freetype2.pc file, for example, to
see the new sage directory is listed there in the SAGE_ROOT variable).

Many thanks to whoever reviews this!

Thanks,

Jason

Re: [sage-devel] reviewing sage-location patch


On 09/ 9/10 09:07 PM, Jason Grout wrote:

Currently, installing packages on a Sage that has been moved from its
original build location is seriously broken. The problem is that the
pkgconfig files (which many spkgs use to set up the include paths) are
not updated to the new location.

There is a patch at #9210 that fixes this. It needs to be reviewed,





Many thanks to whoever reviews this!

Thanks,

Jason



I have done - it simply does not work for me.

As I note on the trac ticket, I think 'sed' may be the best tool for this, not 
Python.


Dave

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

[sage-devel] Re: reviewing sage-location patch

2010-09-09 Thread Jason Grout


On 9/9/10 5:51 PM, Dr. David Kirkby wrote:

On 09/ 9/10 09:07 PM, Jason Grout wrote:

Currently, installing packages on a Sage that has been moved from its
original build location is seriously broken. The problem is that the
pkgconfig files (which many spkgs use to set up the include paths) are
not updated to the new location.

There is a patch at #9210 that fixes this. It needs to be reviewed,





Many thanks to whoever reviews this!

Thanks,

Jason



I have done - it simply does not work for me.



I noted on the trac ticket that you skipped step 4 (running Sage before 
moving the directory).  Could you please try it again?




As I note on the trac ticket, I think 'sed' may be the best tool for
this, not Python.


That may be.  There is more that goes on in this sage-location script, 
so python may be better-suited over all.  And I'm more confident in 
python than in sed.  And I'm pretty confident that the current patch 
works (if the instructions are followed for reviewing it).


That sed, if someone wants to go ahead and write a sed script, we'll 
just go with whatever they seys. :).


Jason

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

[sage-devel] Re: Sage is embarrassingly slow

2010-09-09 Thread cousteau

On 9 sep, 18:24, David Harvey  wrote:
> Sage is very slow. I discovered this (again) while trying to write a  
> prototype of an algorithm for computing zeta functions of projective  
> varieties. I need to multiply lots of polynomials and matrices over  
> finite rings, and frequently move coefficients between polynomials  
> and matrices. The arithmetic is actually not too bad; it's the boring  
> data movement stuff that really sucks.

Well, it's nothing new that Python is slower for low-level, highly
iterative functions (tight loops) than other languages such as C.
That's why part of the Sage source code is written in Cython rather
than Python.

Sage can load (using load()) 3 file types:
- Sage (*.sage), a slightly modified version of the Python languages;
- Python (*.py);
- Cython (*.pyx), a sort of Python with some C declarations.

Cython is way faster than Python, so if your code can be rewritten to
use Cython on the most CPU-intensive parts, it will be very fast.

Example:
- py_iter.py -
def pyIter(n=2000):
x = 1e-80
for i in xrange(n):
x *= 1.17
print x
--- (time: 4.47 s) ---

- cpy_iter.pyx -
cdef double _cpyIter_(long n): # C declaration
cdef double x = 1e-80
cdef long i
for i in xrange(n):
x *= 1.17
return x

def cpyIter(n=2000): # Python declaration
return _cpyIter_(n)
--- (time: 0.06 s) ---

You can find some documentation here: http://docs.cython.org/
(Oh, and here http://docs.cython.org/src/quickstart/build.html you may
find something familiar)

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

[sage-devel] Re: Sage is embarrassingly slow

2010-09-09 Thread dmharvey

On Sep 9, 7:44 pm, cousteau  wrote:
> On 9 sep, 18:24, David Harvey  wrote:
>
> > Sage is very slow. I discovered this (again) while trying to write a  
> > prototype of an algorithm for computing zeta functions of projective  
> > varieties. I need to multiply lots of polynomials and matrices over  
> > finite rings, and frequently move coefficients between polynomials  
> > and matrices. The arithmetic is actually not too bad; it's the boring  
> > data movement stuff that really sucks.
>
> Well, it's nothing new that Python is slower for low-level, highly
> iterative functions (tight loops) than other languages such as C.
> That's why part of the Sage source code is written in Cython rather
> than Python.
>
> Sage can load (using load()) 3 file types:
> - Sage (*.sage), a slightly modified version of the Python languages;
> - Python (*.py);
> - Cython (*.pyx), a sort of Python with some C declarations.
>
> Cython is way faster than Python, so if your code can be rewritten to
> use Cython on the most CPU-intensive parts, it will be very fast.
>
> Example:
> - py_iter.py -
> def pyIter(n=2000):
>     x = 1e-80
>     for i in xrange(n):
>         x *= 1.17
>     print x
> --- (time: 4.47 s) ---
>
> - cpy_iter.pyx -
> cdef double _cpyIter_(long n): # C declaration
>     cdef double x = 1e-80
>     cdef long i
>     for i in xrange(n):
>         x *= 1.17
>     return x
>
> def cpyIter(n=2000): # Python declaration
>     return _cpyIter_(n)
> --- (time: 0.06 s) ---
>
> You can find some documentation here:http://docs.cython.org/
> (Oh, and herehttp://docs.cython.org/src/quickstart/build.htmlyou may
> find something familiar)

I am aware of all this. In fact I wrote a lot of the early Cython code
in Sage (back when it was still Pyrex).

The examples of slow things I gave are things that should be fast,
even in the Sage interpreter. All of these things are fast in Magma
for example, which is also an interpreted language, and this is the
main reason that Magma is so popular in my research area (and clearly
a reason that people would use Magma rather than Sage). I am using
Sage to prototype my algorithm. I eventually intend to write a C++
version, once I have used the Sage version to experiment with the
algorithm and understand it better. If the only way to write it in
Sage is to work at a lower level then it completely defeats the
purpose of using Sage to develop the prototype in the first place; I
want to use Sage to hide the lower-level details so I can concentrate
on the high level stuff. I don't care if it's a reasonable constant
factor slower than what my fast implementation will eventually be. But
a factor of 100x is unacceptable for these sorts of things, and makes
it impossible to do experiments.

david

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

Re: [sage-devel] Sage is embarrassingly slow

2010-09-09 Thread David Roe

There are some implemented coercion maps already (see
sage.rings.finite_rings.integer_mod.Integer_to_IntegerMod).  Many of these
tickets can be solved by writing optimized coercion and conversion morphisms
and including appropriate section() functions on some of them.  See the
patch at #9814, though that still needs a bit of work.

I can probably do this fairly easily, but not tonight.  :-)
David

On Thu, Sep 9, 2010 at 12:24, David Harvey  wrote:

> Dear sage-devel,
>
> Sage is very slow. I discovered this (again) while trying to write a
> prototype of an algorithm for computing zeta functions of projective
> varieties. I need to multiply lots of polynomials and matrices over finite
> rings, and frequently move coefficients between polynomials and matrices.
> The arithmetic is actually not too bad; it's the boring data movement stuff
> that really sucks. I made a bunch of tickets:
>
> http://trac.sagemath.org/sage_trac/ticket/9882
> http://trac.sagemath.org/sage_trac/ticket/9883
> http://trac.sagemath.org/sage_trac/ticket/9884
> http://trac.sagemath.org/sage_trac/ticket/9885
> http://trac.sagemath.org/sage_trac/ticket/9886
> http://trac.sagemath.org/sage_trac/ticket/9887
> http://trac.sagemath.org/sage_trac/ticket/9888
>
> Maybe I can be the first to #1 if I keep going!
>
> david
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

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

Re: [sage-devel] Disappearing notebook

2010-09-09 Thread Tim Joseph Dumol

Hi,

It seems you have a permission problem. Please try running:

$ sudo chown :users ~/sage/sage-4.5.2 -R
$ chmod ug+rwX ~/sage/sage-4.5.2 -R

And see if that fixes things.

On Thu, Sep 9, 2010 at 2:43 PM, Enrico  wrote:
> Hi sage-devel, I'm having a problem with sagenb and it told me to post
> here.
> I'm running:
> Ubuntu 10.04LTS on
> hp DualCore6300 w/ 2Gb RAM
> sage-4.5.2 binary install in my home with
> $SAGE_ROOT:$SAGE_ROOT/local/bin added to my path in .bash_profile
> in /usr/local/bin there's also a copy of sage file with 4th line
> edited
> SAGE_ROOT="/home/me/sage/sage-4.5.2"
> ===/
> $sage -n
> Please wait while the Sage Notebook server starts...
> File ...
> ImportError: No module named sage.server.notebook.all
> =
> Last time I took a punt on
> $sage -i sagenb
> and it rebuilt the notebook and it worked again.
> ===
> $sage -i sagenb
> Extracting package from /home/me
> -rw-r--r--  ... spkg/standard/sagenb-0.8.2.spkg
> tar: This does not look like a tar archive...
>
> so then I think it goes looking on the internet and finds sagenb-0.8.2
> and rebuilds the whole thing.
>
> But now I've got a whole lot of permission denied errors on the
> rebuild this time and
> sage: An error occurred while installing sagenb-0.8.2
> Please email sage-devel
> 
> excerpt of log follows
> ===
> tar: Exiting with failure status due to previous errors
> Finished extraction
> sage: After decompressing the directory sagenb does not exist
> This means that the corresponding .spkg needs to be downloaded
> again.
> Searching for latest version of sagenb
> Found package sagenb-0.8.2
> http://www.sagemath.org//packages/optional/sagenb-0.8.2.spkg -->
> sagenb-0.8.2.spkg
> [ ]
> http://www.sagemath.org//packages/standard/sagenb-0.8.2.spkg -->
> sagenb-0.8.2.spkg
> [..]
> /home/bee/sage/sage-4.5.2/spkg/build
> tar: Record size = 8 blocks
> sagenb-0.8.2/
> sagenb-0.8.2/src/
> sagenb-0.8.2/src/sagenb/
> 
> ...
> downloading...
> copying...
> ===
> changing mode of build/bdist.linux-i686/egg/EGG-INFO/scripts/jmol to
> 755
> changing mode of build/bdist.linux-i686/egg/EGG-INFO/scripts/sage3d to
> 755
> copying sagenb.egg-info/PKG-INFO -> build/bdist.linux-i686/egg/EGG-
> INFO
> copying sagenb.egg-info/SOURCES.txt -> build/bdist.linux-i686/egg/EGG-
> INFO
> copying sagenb.egg-info/dependency_links.txt -> build/bdist.linux-i686/
> egg/EGG-INFO
> copying sagenb.egg-info/requires.txt -> build/bdist.linux-i686/egg/EGG-
> INFO
> copying sagenb.egg-info/top_level.txt -> build/bdist.linux-i686/egg/
> EGG-INFO
> zip_safe flag not set; analyzing archive contents...
> sagenb.misc.sageinspect: module MAY be using inspect.getabsfile
> creating dist
> creating 'dist/sagenb-0.8.2-py2.6.egg' and adding 'build/bdist.linux-
> i686/egg' to it
> removing 'build/bdist.linux-i686/egg' (and everything under it)
> Processing sagenb-0.8.2-py2.6.egg
> removing '/home/bee/sage/sage-4.5.2/local/lib/python2.6/site-packages/
> sagenb-0.8.2-py2.6.egg' (and everything under it)
> error removing /home/bee/sage/sage-4.5.2/local/lib/python2.6/site-
> packages/sagenb-0.8.2-py2.6.egg: /home/bee/sage/sage-4.5.2/local/lib/
> python2.6/site-packages/sagenb-0.8.2-py2.6.egg/EGG-INFO/PKG-INFO:
> Permission denied
> ...
> Permission denied...
> error removing...
> error removing /home/bee/sage/sage-4.5.2/local/lib/python2.6/site-
> packages/sagenb-0.8.2-py2.6.egg: /home/bee/sage/sage-4.5.2/local/lib/
> python2.6/site-packages/sagenb-0.8.2-py2.6.egg: Directory not empty
> Extracting sagenb-0.8.2-py2.6.egg to /home/bee/sage/sage-4.5.2/local/
> lib/python2.6/site-packages
> error: /home/bee/sage/sage-4.5.2/local/lib/python2.6/site-packages/
> sagenb-0.8.2-py2.6.egg/EGG-INFO/PKG-INFO: Permission denied
>
> real    0m22.212s
> user    0m7.724s
> sys     0m2.088s
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>



-- 
Tim Joseph Dumol 
http://timdumol.com

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

[sage-devel] Re: Disappearing notebook

2010-09-09 Thread Enrico

Thanks Tim, I tried that but I still get the import error. However if
I use this shell:
cd '/home/me/sage/sage-4.5.2/spkg/build/sagenb-0.8.2' && '/home/me/
sage/sage-4.5.2/sage' -sh
then I get a working notebook.

I made a .bash_profile:
SAGE_ROOT="/home/me/sage/sage-4.5.2"
PATH="$PATH:$SAGE_ROOT:$SAGE_ROOT/local/bin"
export SAGE_ROOT
export PATH

So what is the shell giving me that my profile isn't?

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

Re: [sage-devel] Re: Disappearing notebook

2010-09-09 Thread Tim Joseph Dumol

You don't need to set those environment variables in your profile. The
sage binary sets those automatically.

On Fri, Sep 10, 2010 at 10:36 AM, Enrico  wrote:
> Thanks Tim, I tried that but I still get the import error. However if
> I use this shell:
> cd '/home/me/sage/sage-4.5.2/spkg/build/sagenb-0.8.2' && '/home/me/
> sage/sage-4.5.2/sage' -sh
> then I get a working notebook.
>
> I made a .bash_profile:
> SAGE_ROOT="/home/me/sage/sage-4.5.2"
> PATH="$PATH:$SAGE_ROOT:$SAGE_ROOT/local/bin"
> export SAGE_ROOT
> export PATH
>
> So what is the shell giving me that my profile isn't?
>
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to 
> sage-devel+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>



-- 
Tim Joseph Dumol 
http://timdumol.com

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

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