[sage-devel] Re: SATURDAY at 10am -- #sage-devel irc.freenode.net
On Aug 16, 7:53 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On 8/15/07, mabshoff <[EMAIL PROTECTED]> wrote: > > > That was a fun way to get work done. I think that it would be great to > > get people on non-Solaris boxen to verify that the modified packages > > still work as expected. > > > Regarding the date: Saturday is better for me, but Sunday is fine, > > too. The time doesn't matter much, I will probably be up anyway. > > Actually I was just talking with Dorian and Alex, and the following > might be a really good strategy for Saturday. > > (1) We all meet on irc. > (2) We view the list of all active tickets here: > http://www.sagemath.org:9002/sage_trac/report/1 This is a list a lot bigger than I thought. Martin is right to suggest a bug squashing day. Maybe it should be a more than a day a month until the backlog gets much smaller. > (3) Starting from the top, for each ticket we either: > (a) completely resolve it, or > (b) decide it isn't a bug *and* explain why, or > (c) fail to fix it and write a comment about why it is hard. > > Basicaly, when we can devastate the bug list on trac, then > SAGE will be ready for prime time. Saturday. 10am Pacific Time. > irc.freenode.net, #sage-devel. >Be there. or be square :-) > william Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Axiom / guess / sage
On 8/15/07, Paul-Olivier Dehaye <[EMAIL PROTECTED]> wrote:
> Hi,
> How do I do some of the more advanced examples given at
> http://wiki.axiom-developer.org/GuessingFormulasForSequences
> under SAGE?
> If tmp is a sequence of SAGE rational functions, I tried:
>
> sage: tmp_axiom = axiom(tmp)
> sage: tmp_axiom.guessRec()
> []
This is just telling you the guess found no answer to the problem you
gave it terms of a recursive formula.
Here is an example that will yield a simple result:
sage: tmp=[1/x^i for i in range(5)]
sage: tmp?
Type: list
Base Class:
String Form:[1, 1/x, 1/x^2, 1/x^3, 1/x^4]
Namespace: Interactive
Length: 5
Docstring:
list() -> new list
list(sequence) -> new list initialized from sequence's items
The more interesting way of interacting with Axiom is by having Sage
automatically convert Sage expressions to Axiom expressions. This is
what happens when you leave out the quotes.
sage: tmp_axiom=axiom(tmp)
sage: tmp_axiom?
Type: AxiomElement
Base Class:
String Form:[1,1/x,1/(x*x),1/x**3,1/x**4]
Namespace: Interactive
Length: 5
Docstring:
[1,1/x,1/(x*x),1/x**3,1/x**4]
So 'tmp' above is a Sage list, but when we pass it to axiom as far as
Sage is concerned it becomes an AxiomElement.
But inside Axiom it a member of a specific Axiom domain (type):
sage: tmp_axiom.type()
List Fraction Polynomial Integer
'List Fraction Polynomial Integer' is the domain of rational functions
with integer coefficients.
Now we can operate on it using guessRec:
sage: tmp_axiom.guessRec()
[[function= [f(n): - x f(n + 1) + f(n)= 0,f(0)= 1],order= 0]]
>
> sage: tmp_axiom.guess([guessRat], [guessSum, guessProduct])
> ---
> Traceback (most recent call last)
>
> /Users/pdehaye/ in ()
>
> : name 'guessRat' is not defined
>
> It s not clear to me how the syntax works...
>
The problem here is to keep track of when you are talking directly to
Axiom and when you are using native Sage syntax. Of course any
expression that is acceptable to Axiom can be passed between quotes
like this:
axiom(' ... ')
The quotes tell Sage not to interpret the contents, but rather just
pass it directly to Axiom. Axiom does some computation and creates a
Sage object which Sage then asks Axiom to display (or saves it a
variable without displaying it).
guessRat, guessSum and guessProduct are names known to Axiom but not
to Sage, so they must appear inside quotes ' ... '. We can define
these names for Sage like this:
sage: guessRat=axiom('guessRat')
sage: guessSum=axiom('guessSum')
sage: guessProduct=axiom('guessProduct')
Now we can call Axiom just as you wrote above:
sage: tmp_guess = tmp_axiom.guess([guessRat], [guessSum, guessProduct])
sage: tmp_guess
- n
[[function= x ,order= 0]]
sage: tmp_guess?
Type: AxiomElement
Base Class:
Namespace: Interactive
Length: 1
sage: tmp_guess.type()
List Record(function: Expression Integer,order: NonNegativeInteger)
sage:
Notice that the result is a rather complex Axiom domain consisting of
a list of records consisting of two fields named, 'function' and
'order'.
Currently there are some limitations in Sage concerning convenient
access to fields within an Axiom Record but this is Python so we can
easily extend the AxiomElement class:
sage: def Record(self,n):
: return axiom('%s.%s'%(self.name(),n))
:
sage: setattr(sage.interfaces.axiom.AxiomElement,'Record', Record)
Then we can write:
sage: tmp_guess[1].Record('function')
- n
x
Or as a property:
sage: sage.interfaces.axiom.AxiomElement.function =
property(fget=lambda self: axiom('%s.function'%self.name()))
which is less generic but perhaps looks nicer:
sage: tmp_guess[1].function
- n
x
As this becomes more clear, I hope that we will be able to write some
documentation about how to use Guess and some of the other packages in
Axiom.
> Also:
> sage: axiom.help('guess')
> AXIOM shell variable has no value. using current directory
> unable to find the file compress.daase
> Help system not available.
>
> but that s on your todo list, right?
>
Yes it is. Axiom has several ways to do this and I am experimenting. I
will have an new update for 'axiom.py' in the next few days that has
something that works.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] SATURDAY at 10am -- #sage-devel irc.freenode.net
On 8/15/07, mabshoff <[EMAIL PROTECTED]> wrote: > That was a fun way to get work done. I think that it would be great to > get people on non-Solaris boxen to verify that the modified packages > still work as expected. > > Regarding the date: Saturday is better for me, but Sunday is fine, > too. The time doesn't matter much, I will probably be up anyway. Actually I was just talking with Dorian and Alex, and the following might be a really good strategy for Saturday. (1) We all meet on irc. (2) We view the list of all active tickets here: http://www.sagemath.org:9002/sage_trac/report/1 (3) Starting from the top, for each ticket we either: (a) completely resolve it, or (b) decide it isn't a bug *and* explain why, or (c) fail to fix it and write a comment about why it is hard. Basicaly, when we can devastate the bug list on trac, then SAGE will be ready for prime time. Saturday. 10am Pacific Time. irc.freenode.net, #sage-devel. Be there. william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
On Aug 16, 3:55 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On 8/15/07, David Harvey <[EMAIL PROTECTED]> wrote: > > > On Aug 15, 2007, at 8:36 PM, William Stein wrote: > > >> at what time? > > > > Good question. How about starting at 9am pacific time (=noon your > > > time)? > > > I suggest this just because I'll likely wake up at 8:30am pacific > > > time. > > > That's okay with me. I might show up a bit later though. > > > I have no idea what bugs I'll work on. Guess I'll just pick up random > > things off trac, or someone can assign them to me, I don't mind too > > much, as long they're things I know roughly how to fix! > > Probably in some cases several people will work on the same bug at once. > We just had a big "porting SAGEf to solaris" sprint and for most > of it Michael Abshoff, Didier Deshommes, and I were all working on > the same problems at once until somebody had an idea. Once we had > a hack to get things going, somebody would go off and "do it right", and > then later we would all test that solution (and see if it really worked, which > wasn't always the case). Perhaps we could try something like that. > It feels like playing a big video game, where you win when you resolve > all the issues; the other people in the sprint are all on your team. > > Thoughts? > That was a fun way to get work done. I think that it would be great to get people on non-Solaris boxen to verify that the modified packages still work as expected. Regarding the date: Saturday is better for me, but Sunday is fine, too. The time doesn't matter much, I will probably be up anyway. > -- William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] RFC: Optional ATLAS SPKG
Hello, at http://sage.math.washington.edu/home/mabshoff/atlas-3.7.37.spkg you can find an ATLAS SPKG. Right now it only builds dynamic and static versions of ATLAS. It takes about 15-20 minutes on a decent Athlon 64. It has been tested by William and me, so if you feel lucky give it a try. We plan to recompile the numerical packages conditinally and link against that version of ATLAS if you install some ATLAS SPKG in the future. If you want to build it on MacOSX you need a g77 or f77 compiler until further notice. William did implement/suggest a solution to use g95 or gfortran for that, but it hasn't been fixed yet. The ATLAS has been tested om Solaris and works there. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage 2.8 build fails on G5 powerpc OS 10.4.10
On 8/15/07, David Harvey <[EMAIL PROTECTED]> wrote: > Well the included binary works at least to this extent: > > ~/sage-2.8/local/bin > george$ ./sage_fortran.bin --version > G95 (GCC 4.0.3 (g95 0.91!) Jun 4 2007) > Copyright (C) 2002-2005 Free Software Foundation, Inc. > > Let me try installing gfortran as you suggest and see if the whole > thing builds properly then. Don't do that yet. Support for using a system-wide fortran was only implemented today (by me). > Has the included fortran binary been tested on other similar systems? Yes, it works fine on fermat.math.harvard.edu, and I think on Justin Walker's G5. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage 2.8 build fails on G5 powerpc OS 10.4.10
On Aug 15, 2007, at 10:08 PM, William Stein wrote: >> Here's another failure which I don't believe is scipy-related, but >> might be a clue: > > That is fortran related. It fails for the same reason that lapack > woulnd't work for you -- the g95 fortran binary we included for > SAGE doesn't work correctly for you for some reason. > In the next SAGE release, one will have the option to specify > an alternative compiler. You could, e.g., install gfortran (easy > to get for Mac os x), and it might work fine for you. Well the included binary works at least to this extent: ~/sage-2.8/local/bin george$ ./sage_fortran.bin --version G95 (GCC 4.0.3 (g95 0.91!) Jun 4 2007) Copyright (C) 2002-2005 Free Software Foundation, Inc. Let me try installing gfortran as you suggest and see if the whole thing builds properly then. Has the included fortran binary been tested on other similar systems? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: fixes need for SAGE 2.8.1 to work on Solaris
On 8/15/07, Martin Albrecht <[EMAIL PROTECTED]> wrote: > just in case you wonder why the channel is empty: The IRC channel is called > #SAGE-dev and not #sage-devel. We should probably change that. OK, henceforth the irc.freenode.net channel is sage-devel. By the way, an easy way to use irc from sage.math (via a text console) is to do the following: 1) type "irssi" at the command line. 2) Type the following into the resulting program: /SERVER add -network IRCnet irc.freenode.net 6667 /SERVER irc.freenode.net /join #sage-dev -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage 2.8 build fails on G5 powerpc OS 10.4.10
On 8/15/07, David Harvey <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 4:03 PM, William Stein wrote: > > > Just for debuging purposes, could you do the following and > > report what happens? > > > > Fake lapack-20070723 for now, e.g., do > > cd SAGE_ROOT > > touch spkg/installed/lapack-20070723 > > Continue the build with "make" and do the same as above > > for whatever else fails. You'll just cut off the connected > > component of scipy, which you don't care about. > > Does the SAGE build complete otherwise? > > Ok, I did that with > > lapack-20070723 > scipy-20070722 > cvxopt-0.8.2.p1 > > and the rest of the build succeeded. SAGE starts up properly and > appears to work. OK, great, that narrows the problem down a lot, and allows you to get back to work. > I'm running doctests now (not finished yet). So far the scipy-related > stuff is failing (not surprising). There shouldn't be much (yet). > Here's another failure which I don't believe is scipy-related, but > might be a clue: That is fortran related. It fails for the same reason that lapack woulnd't work for you -- the g95 fortran binary we included for SAGE doesn't work correctly for you for some reason. In the next SAGE release, one will have the option to specify an alternative compiler. You could, e.g., install gfortran (easy to get for Mac os x), and it might work fine for you. > > sage -t devel/sage-main/sage/misc/inline_fortran.pyerror: > Command "/Users/david/sage-2.8/local/bin/sage-g77_shared /tmp/ > tmp876LSB/tmp/tmp876LSB/src.macosx-10.3-ppc-2.5/ > fortran_module_0module.o /tmp/tmp876LSB/tmp/tmp876LSB/src.macosx-10.3- > ppc-2.5/fortranobject.o /tmp/tmp876LSB/Users/david/.sage/temp/ > George.local/29970/tmp_0.o -lSystemStubs -o ./fortran_module_0.so" > failed with exit status 1 > ** > File "inline_fortran.py", line 27: > sage: test_fortran(s) > Exception raised: > Traceback (most recent call last): >File "/Users/david/sage-2.8/local/lib/python2.5/doctest.py", > line 1212, in __run > compileflags, 1) in test.globs >File "", line 1, in > test_fortran(s)###line 27: > sage: test_fortran(s) >File "/Users/david/sage-2.8/local/lib/python2.5/site-packages/ > sage/misc/inline_fortran.py", line 20, in __call__ > return self.eval(*args, **kwds) >File "/Users/david/sage-2.8/local/lib/python2.5/site-packages/ > sage/misc/inline_fortran.py", line 85, in eval > os.unlink(name + '.so') > OSError: [Errno 2] No such file or directory: 'fortran_module_0.so' > ** > > Everything else is passing okay. > > david > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
On 8/15/07, David Harvey <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 8:36 PM, William Stein wrote: > >> at what time? > > > > Good question. How about starting at 9am pacific time (=noon your > > time)? > > I suggest this just because I'll likely wake up at 8:30am pacific > > time. > > That's okay with me. I might show up a bit later though. > > I have no idea what bugs I'll work on. Guess I'll just pick up random > things off trac, or someone can assign them to me, I don't mind too > much, as long they're things I know roughly how to fix! Probably in some cases several people will work on the same bug at once. We just had a big "porting SAGEf to solaris" sprint and for most of it Michael Abshoff, Didier Deshommes, and I were all working on the same problems at once until somebody had an idea. Once we had a hack to get things going, somebody would go off and "do it right", and then later we would all test that solution (and see if it really worked, which wasn't always the case). Perhaps we could try something like that. It feels like playing a big video game, where you win when you resolve all the issues; the other people in the sprint are all on your team. Thoughts? -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage 2.8 build fails on G5 powerpc OS 10.4.10
On Aug 15, 2007, at 4:03 PM, William Stein wrote: > Just for debuging purposes, could you do the following and > report what happens? > > Fake lapack-20070723 for now, e.g., do > cd SAGE_ROOT > touch spkg/installed/lapack-20070723 > Continue the build with "make" and do the same as above > for whatever else fails. You'll just cut off the connected > component of scipy, which you don't care about. > Does the SAGE build complete otherwise? Ok, I did that with lapack-20070723 scipy-20070722 cvxopt-0.8.2.p1 and the rest of the build succeeded. SAGE starts up properly and appears to work. I'm running doctests now (not finished yet). So far the scipy-related stuff is failing (not surprising). Here's another failure which I don't believe is scipy-related, but might be a clue: sage -t devel/sage-main/sage/misc/inline_fortran.pyerror: Command "/Users/david/sage-2.8/local/bin/sage-g77_shared /tmp/ tmp876LSB/tmp/tmp876LSB/src.macosx-10.3-ppc-2.5/ fortran_module_0module.o /tmp/tmp876LSB/tmp/tmp876LSB/src.macosx-10.3- ppc-2.5/fortranobject.o /tmp/tmp876LSB/Users/david/.sage/temp/ George.local/29970/tmp_0.o -lSystemStubs -o ./fortran_module_0.so" failed with exit status 1 ** File "inline_fortran.py", line 27: sage: test_fortran(s) Exception raised: Traceback (most recent call last): File "/Users/david/sage-2.8/local/lib/python2.5/doctest.py", line 1212, in __run compileflags, 1) in test.globs File "", line 1, in test_fortran(s)###line 27: sage: test_fortran(s) File "/Users/david/sage-2.8/local/lib/python2.5/site-packages/ sage/misc/inline_fortran.py", line 20, in __call__ return self.eval(*args, **kwds) File "/Users/david/sage-2.8/local/lib/python2.5/site-packages/ sage/misc/inline_fortran.py", line 85, in eval os.unlink(name + '.so') OSError: [Errno 2] No such file or directory: 'fortran_module_0.so' ** Everything else is passing okay. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
On Aug 15, 2007, at 8:36 PM, William Stein wrote: >> at what time? > > Good question. How about starting at 9am pacific time (=noon your > time)? > I suggest this just because I'll likely wake up at 8:30am pacific > time. That's okay with me. I might show up a bit later though. I have no idea what bugs I'll work on. Guess I'll just pick up random things off trac, or someone can assign them to me, I don't mind too much, as long they're things I know roughly how to fix! david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sympy and SAGE
> > I would like to avoid this if possible. > > OK, _sage_ and _sympy_ methods are fine with me. We'll try to > implement that soon. > > Ondrej OK, excellent. Let me know when you do, so I can add support for them to some key SAGE classes (e.g., rational numbers, univariate polynomials, etc.) William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
On 8/15/07, Yi Qiang <[EMAIL PROTECTED]> wrote: > Will there be any structure to the bug squashing day? Usually on these > days someone (or many people) will do a triage before the bug hunting > starts to prioritize bugs that need to be fixed. It is very easy for > the process to become randomized unless there is some sort of ordered > list on which bugs are important to tackle. Maybe this is too much > for the first bug squash day, but definitely something to keep in mind > for later ones especially when more people participate. There absolutely will be structure. I have no experience with "bug hunting days", so it would be great if somebody who does -- you? martin? -- would go through the trac and make a wiki page and does what you just described above. Any volunteers? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
Will there be any structure to the bug squashing day? Usually on these days someone (or many people) will do a triage before the bug hunting starts to prioritize bugs that need to be fixed. It is very easy for the process to become randomized unless there is some sort of ordered list on which bugs are important to tackle. Maybe this is too much for the first bug squash day, but definitely something to keep in mind for later ones especially when more people participate. Cheers, Yi -- http://www.yiqiang.org On 8/15/07, William Stein <[EMAIL PROTECTED]> wrote: > > On 8/15/07, Craig Citro <[EMAIL PROTECTED]> wrote: > > So I'd like to be there, but I'll be on a plane. Would there be any > > value to try to get a log of the chat posted, or will all of the > > relevant information get posted on trac? (I have to bet I'm not the > > only one who'd like to be there but can't.) > > Would Saturday be better than Sunday? The only reason I chose > Sunday was that Martin had suggested it in his original email. > Saturday might be better for a lot of people. What do you think? > > > > > -cc > > > > On Aug 15, 2007, at 5:32 PM, William Stein wrote: > > > > > > > > Hi, > > > > > > The first bug squashing day will be this Sunday, August 19. Please > > > email sage-devel if you're interesting in participating, and maybe > > > outline > > > what sort of bugs you'll want to attack. > > > > > > On Sunday we'll coordinate via IRC. > > > > > > -- William > > > > > > -- > > > William Stein > > > Associate Professor of Mathematics > > > University of Washington > > > http://www.williamstein.org > > > > > > > > > > > > > > > > > > > -- > William Stein > Associate Professor of Mathematics > University of Washington > http://www.williamstein.org > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
On 8/15/07, Craig Citro <[EMAIL PROTECTED]> wrote: > So I'd like to be there, but I'll be on a plane. Would there be any > value to try to get a log of the chat posted, or will all of the > relevant information get posted on trac? (I have to bet I'm not the > only one who'd like to be there but can't.) Would Saturday be better than Sunday? The only reason I chose Sunday was that Martin had suggested it in his original email. Saturday might be better for a lot of people. What do you think? > > -cc > > On Aug 15, 2007, at 5:32 PM, William Stein wrote: > > > > > Hi, > > > > The first bug squashing day will be this Sunday, August 19. Please > > email sage-devel if you're interesting in participating, and maybe > > outline > > what sort of bugs you'll want to attack. > > > > On Sunday we'll coordinate via IRC. > > > > -- William > > > > -- > > William Stein > > Associate Professor of Mathematics > > University of Washington > > http://www.williamstein.org > > > > > > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
So I'd like to be there, but I'll be on a plane. Would there be any value to try to get a log of the chat posted, or will all of the relevant information get posted on trac? (I have to bet I'm not the only one who'd like to be there but can't.) -cc On Aug 15, 2007, at 5:32 PM, William Stein wrote: > > Hi, > > The first bug squashing day will be this Sunday, August 19. Please > email sage-devel if you're interesting in participating, and maybe > outline > what sort of bugs you'll want to attack. > > On Sunday we'll coordinate via IRC. > > -- William > > -- > William Stein > Associate Professor of Mathematics > University of Washington > http://www.williamstein.org > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problems building linbox in sage-2.8
On 8/15/07, mabshoff <[EMAIL PROTECTED]> wrote: > On Aug 16, 1:53 am, "Pablo De Napoli" <[EMAIL PROTECTED]> wrote: > > upgrading to sage-2,8 failed on my Gentoo system with the following > > messages: > > (when building linbox-20070812) I've updated the main SAGE repo with the package mentioned in the previous post. It is probably now the case that if you just try sage -upgrade again it will just work. William > > "checking for correct ltmain.sh version... no > > configure: error: > > > > *** [Gentoo] sanity check failed! *** > > *** libtool.m4 and ltmain.sh have a version mismatch! *** > > *** (libtool.m4 = 1.5.23b, ltmain.sh = "1.5.22 Debian 1.5.22-4") *** > > > > Please run: > > > > libtoolize --copy --force > > > > if appropriate, please contact the maintainer of this > > package (or your distribution) for help. > > > > make[1]: *** [config.status] Error 1 > > make[1]: se sale del directorio > > `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox_wrap' > > Error installing linboxwrap > > " > > > > On my system I have > > > > libtool-1.5.23b > > m4-1.4.10 > > gcc-4.1.2 > > > > After running the command > > > > libtoolize --copy --force > > > > in the linbox_wrap directory, however running > > > > ./spkg-install > > > > failed with the follwoing messages: > > > > mkdir .libs/libgmpxx.lax/libgmpxx.a > > (cd .libs/libgmpxx.lax/libgmpxx.a && ar x > > /home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++/.libs/libgmpxx.a) > > ar: > > /home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++/.libs/libgmpxx.a: > > No such file or directory > > make[3]: *** [libgmpxx.la] Error 9 > > make[3]: se sale del directorio > > `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++' > > make[2]: *** [install-recursive] Error 1 > > make[2]: se sale del directorio > > `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util' > > make[1]: *** [install-recursive] Error 1 > > > > Pablo > > See > http://groups.google.com/group/sage-support/browse_thread/thread/2a7bdddf0423591 > for a discussion and an updated linbox.spkg. Let us know if that works > for you. > > Cheers, > > Michael > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
On Aug 16, 2:36 am, "William Stein" <[EMAIL PROTECTED]> wrote: > On 8/15/07, David Harvey <[EMAIL PROTECTED]> wrote: Hello, > > > at what time? > > Good question. How about starting at 9am pacific time (=noon your time)? > I suggest this just because I'll likely wake up at 8:30am pacific time. > > -- William > that makes it rougly 7 pm central European summer time, so I will be there. Workwise I will probably play with the Solaris port, unless it is done by then ;) Cheers, Michael > > > > > > david > > > On Aug 15, 2007, at 8:32 PM, William Stein wrote: > > > > Hi, > > > > The first bug squashing day will be this Sunday, August 19. Please > > > email sage-devel if you're interesting in participating, and maybe > > > outline > > > what sort of bugs you'll want to attack. > > > > On Sunday we'll coordinate via IRC. > > > > -- William > > -- > William Stein > Associate Professor of Mathematics > University of Washingtonhttp://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
On 8/15/07, David Harvey <[EMAIL PROTECTED]> wrote: > at what time? Good question. How about starting at 9am pacific time (=noon your time)? I suggest this just because I'll likely wake up at 8:30am pacific time. -- William > > david > > On Aug 15, 2007, at 8:32 PM, William Stein wrote: > > > > > Hi, > > > > The first bug squashing day will be this Sunday, August 19. Please > > email sage-devel if you're interesting in participating, and maybe > > outline > > what sort of bugs you'll want to attack. > > > > On Sunday we'll coordinate via IRC. > > > > -- William > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: bug squashing Sunday
at what time? david On Aug 15, 2007, at 8:32 PM, William Stein wrote: > > Hi, > > The first bug squashing day will be this Sunday, August 19. Please > email sage-devel if you're interesting in participating, and maybe > outline > what sort of bugs you'll want to attack. > > On Sunday we'll coordinate via IRC. > > -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] bug squashing Sunday
Hi, The first bug squashing day will be this Sunday, August 19. Please email sage-devel if you're interesting in participating, and maybe outline what sort of bugs you'll want to attack. On Sunday we'll coordinate via IRC. -- William -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problems building linbox in sage-2.8
On Aug 16, 1:53 am, "Pablo De Napoli" <[EMAIL PROTECTED]> wrote: > Hi, > > upgrading to sage-2,8 failed on my Gentoo system with the following messages: > (when building linbox-20070812) > > "checking for correct ltmain.sh version... no > configure: error: > > *** [Gentoo] sanity check failed! *** > *** libtool.m4 and ltmain.sh have a version mismatch! *** > *** (libtool.m4 = 1.5.23b, ltmain.sh = "1.5.22 Debian 1.5.22-4") *** > > Please run: > > libtoolize --copy --force > > if appropriate, please contact the maintainer of this > package (or your distribution) for help. > > make[1]: *** [config.status] Error 1 > make[1]: se sale del directorio > `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox_wrap' > Error installing linboxwrap > " > > On my system I have > > libtool-1.5.23b > m4-1.4.10 > gcc-4.1.2 > > After running the command > > libtoolize --copy --force > > in the linbox_wrap directory, however running > > ./spkg-install > > failed with the follwoing messages: > > mkdir .libs/libgmpxx.lax/libgmpxx.a > (cd .libs/libgmpxx.lax/libgmpxx.a && ar x > /home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++/.libs/libgmpxx.a) > ar: > /home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++/.libs/libgmpxx.a: > No such file or directory > make[3]: *** [libgmpxx.la] Error 9 > make[3]: se sale del directorio > `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++' > make[2]: *** [install-recursive] Error 1 > make[2]: se sale del directorio > `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util' > make[1]: *** [install-recursive] Error 1 > > Pablo See http://groups.google.com/group/sage-support/browse_thread/thread/2a7bdddf0423591 for a discussion and an updated linbox.spkg. Let us know if that works for you. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] problems building linbox in sage-2.8
Hi, upgrading to sage-2,8 failed on my Gentoo system with the following messages: (when building linbox-20070812) "checking for correct ltmain.sh version... no configure: error: *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.23b, ltmain.sh = "1.5.22 Debian 1.5.22-4") *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. make[1]: *** [config.status] Error 1 make[1]: se sale del directorio `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox_wrap' Error installing linboxwrap " On my system I have libtool-1.5.23b m4-1.4.10 gcc-4.1.2 After running the command libtoolize --copy --force in the linbox_wrap directory, however running ./spkg-install failed with the follwoing messages: mkdir .libs/libgmpxx.lax/libgmpxx.a (cd .libs/libgmpxx.lax/libgmpxx.a && ar x /home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++/.libs/libgmpxx.a) ar: /home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++/.libs/libgmpxx.a: No such file or directory make[3]: *** [libgmpxx.la] Error 9 make[3]: se sale del directorio `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util/gmp++' make[2]: *** [install-recursive] Error 1 make[2]: se sale del directorio `/home/pablo/sage/sage-2.7.2/spkg/build/linbox-20070812/linbox/linbox/util' make[1]: *** [install-recursive] Error 1 Pablo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sympy and SAGE
> SAGE uses mpfr for arbitrary precision reals and GMP for arbitrary
> precision integers and rationals. This is -- of course -- not the way
> to go for sympy, because of its design goals. Perhaps whatever
> you're doing with arbitrary precision reals might make it back into
> standard Python someday.
Yes, we should do that, but later, when it is well tested.
> My only remark is that the vast majority of SAGE users prefer
> having the mild preparsing as a convenience. Those that don't
> certainly don't have to use it. There are numerous ways to
> turn off using the preparser, Some other remarks:
>
> (1) The preparser is essentially irrelevant to most of the SAGE
> Python library,
> since that library is implemented in 100% standard Python (and Cython),
>
> (2) If one creates a file foo.sage that contains code meant to run through
> the preparser, then run it, e.g., by typing "sage foo.sage", then a file
> foo.py is created, which contains the preparsed version of foo.sage, which
> can then safely be used as standard Python code.
I didn't know (2), in this case I think it is justified to use the
preparsing for SAGE.
> They are well known to Python programers, not to most users of
> SAGE (in my experience most first-time SAGE users have never touched
> Python before). For Sympy, on the other hand, the target audience
> is Python programmers, so again for them preparsing probably isn't
> relevant.
If SAGE could bring more people to Python, then I think a lot of
things could be justified. :)
> It is always very easy in SAGE to go from what you would type in SAGE
> to what you would type in the standard Python environment, as I mentioned
> above. Also, at the command line in SAGE you can type preparse('...') and
> the input string is preparsed and the preparsed version is displayed:
>
> sage: preparse('2^3')
> 'Integer(2)**Integer(3)'
>
> If SAGE users had to type
>
> sage: Integer(2) ** Integer(3)
>
> Just to compute 8 using SAGE integers, the experience of using SAGE would
> simply
> by far too cumbersome.
I understand the point, but I don't know how to solve it without
preparsing. In SymPy, one can use normal python ints and they are
automatically converted to SymPy Integers, like this:
In [2]: a=Rational(2)**3
In [3]: a
Out[3]: 8
In [4]: type(a)
Out[4]:
But at least some part of the expression must be a SymPy instance, so
that the Python integers are converted.
> > _sympy_ could be implemented in SAGE to return SymPy expression, the
> > same way like _maxima_ works. But as I said above, the general Python
> > philosophy is not to check for int, but rather try to use it like int.
> > Thus what we do, is that we try to convert the expression to string
> > (which both Python and SAGE ints can do) and then we parse the string
> > to SymPy expression.
>
> I do not like that as the only choice. Some issues:
>
> (1) String conversions can be very slow. Already converting a number with
> just over 10 digits in Python to a string and back takes a very long time:
>
> In [1]: a = 13 ** 10
> In [2]: time b=eval(str(a))
> CPU times: user 5.61 s, sys: 0.04 s, total: 5.65 s
> Wall time: 8.27
> In [3]: len(str(a))
> Out[3]: 111395
>
> For comparison, converting the same SAGE integer to a Python integer
> is quite fast:
>
> In [1]: from sage.all import Integer
> In [2]: a = Integer(13) ** Integer(10)
> In [3]: time b = int(a)
> CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
> Wall time: 0.00
> In [4]: time c = Integer(b)
> CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
> Wall time: 0.00
>
> It would be much better if you only use strings after checking for a
> _sympy_ method.
>
> (2) What about rational numbers or expressions that involve rationals? E.g.,
>
> In [11]: from sage.all import Rational
> In [12]: a = Rational( (1, 3) )
> In [13]: a
> Out[13]: 1/3
> In [14]: eval(str(a))
> Out[14]: 0
>
> Using strings and eval'ing in Sympy will result in seriously incorrect
> results, because you don't use any sort of preparsing, and SAGE prints
> the rational number 1/3 as "1/3", which is reasonable for SAGE.
> If there were the possibility of a _sympy_ method to do the convertion,
> I could implement it to return
>
> In [17]: sympy.Rational(1,3)
> Out[17]: 1/3
>
> Ahh, notice that even sympy's own rationals will break under the str --> eval
> conversion procedure.
Yes, those are relevant issues. The repr() should return a string,
that, when evaluated using eval(), will return a SymPy/SAGE expression
again. We want to create something like a Python printer, that would
do exactly that (thus returning something like Rational(1)/3).
>
> So, in fact, I would prefer that you do not have the string conversions
> at all. Best would be to raise an error and offer the user the chance
> to define _sympy_. The problem is that if a user defines some sort
> of objects that print with something like "1/3" in them, and you eval
> their string representation, a subtle bug will
[sage-devel] Re: quaddouble in sage, and other floating point issues
On 8/15/07, Jonathan Bober <[EMAIL PROTECTED]> wrote: > > I am willing to rewrite the quad double wrapper for part (2), but it's > possible that it will be at least a little while before it happens. It > shouldn't be too difficult, though, so it might happen soon. > > Part (1) probably requires dealing with autotools stuff (unless it can > be wrapped with distutils somehow) and I don't know how to do it right > now. (But maybe it's a good time to learn.) Excellent. Can you put something in the trac that describes the issues, solutions, and that you're going to work on it? http://www.sagemath.org:9002/sage_trac If you need a trac login email me. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: quaddouble in sage, and other floating point issues
On Wed, 2007-08-15 at 09:13 -0700, William Stein wrote: > On 8/14/07, William Stein <[EMAIL PROTECTED]> wrote: > > On 8/14/07, cwitty <[EMAIL PROTECTED]> wrote: > > > On Aug 14, 12:59 am, Jonathan Bober <[EMAIL PROTECTED]> wrote: > > > > This is exactly what NTL does in its quad float class. Just about every > > > > function starts and ends with a macro to adjust the fpu, resulting in > > > > around 7 extra assembly instructions. In the following code, the > > > > overhead is quite significant - it takes around 21 seconds to execute on > > > > my machine, but only about 4 seconds without the START_FIX and END_FIX. > > > > Of course, this is not necessarily any sort of accurate test, but it > > > > does indicate that this can be an expensive operation. > > > > > > Yes, changing the floating-point modes is very slow on many (all?) x86 > > > processors. I believe it flushes the floating-point pipeline, which > > > takes many clock cycles. > > > > OK, how about this plan: > > > > (1) On systems with sse2, we do the option 3a (which is "If a > > processor supports sse2, > > then passing gcc -march=whatever -msse2 -mfpmath=sse (maybe the -march > > isn't needed) will cause gcc to use sse registers and instructions for > > doubles, and these have the proper precision.") > > > > (2) On systems without sse2 (old slow pentium 3's) we do the START_FIX > > and END_FIX. These computers are very slow anyways, so let them suffer > > (and the suffering is *only* for code that uses quaddouble, which is very > > little > > code anyways). > I am willing to rewrite the quad double wrapper for part (2), but it's possible that it will be at least a little while before it happens. It shouldn't be too difficult, though, so it might happen soon. Part (1) probably requires dealing with autotools stuff (unless it can be wrapped with distutils somehow) and I don't know how to do it right now. (But maybe it's a good time to learn.) > Since nobody objected, can somebody volunteer to implement this? :-) > > William > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage 2.8 build fails on G5 powerpc OS 10.4.10
David, Just for debuging purposes, could you do the following and report what happens? Fake lapack-20070723 for now, e.g., do cd SAGE_ROOT touch spkg/installed/lapack-20070723 Continue the build with "make" and do the same as above for whatever else fails. You'll just cut off the connected component of scipy, which you don't care about. Does the SAGE build complete otherwise? -- William On 8/14/07, David Harvey <[EMAIL PROTECTED]> wrote: > > Something goes wrong in LAPACK build: > > sage-spkg installed/lapack-20070723 2>&1 > lapack-20070723 > Machine: > Darwin George.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 > 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh > powerpc > Deleting directories from past builds of previous/current versions of > lapack-20070723 > Extracting package /Users/david/sage-2.8/spkg/standard/ > lapack-20070723.spkg ... > -rw-r--r-- 1 david david 3442036 Jul 23 16:27 /Users/david/ > sage-2.8/spkg/standard/lapack-20070723.spkg > lapack-20070723/ > lapack-20070723/.hg/ > lapack-20070723/.hg/00changelog.i > lapack-20070723/.hg/dirstate > lapack-20070723/.hg/requires > lapack-20070723/.hg/store/ > > . > > lapack-20070723/src/TESTING/zec.in > lapack-20070723/src/TESTING/zed.in > lapack-20070723/src/TESTING/zgbak.in > lapack-20070723/src/TESTING/zgbal.in > lapack-20070723/src/TESTING/zgd.in > lapack-20070723/src/TESTING/zgg.in > lapack-20070723/src/TESTING/zsb.in > lapack-20070723/src/TESTING/zsg.in > lapack-20070723/src/TESTING/ztest.in > Finished extraction > > Host system > uname -a: > Darwin George.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 > 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh > powerpc > > > GCC Version > gcc -v > Using built-in specs. > Target: powerpc-apple-darwin8 > Configured with: /private/var/tmp/gcc/gcc-5247.obj~4/src/configure -- > disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- > enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] > [^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- > build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- > target=powerpc-apple-darwin8 > Thread model: posix > gcc version 4.0.1 (Apple Computer, Inc. build 5247) > > ( cd INSTALL; make; ./testlsame; ./testslamch; \ >./testdlamch; ./testsecond; ./testdsecnd; ./testversion ) > sage_fortran -fPIC -c lsame.f -o lsame.o > sage_fortran -fPIC -c lsametst.f -o lsametst.o > sage_fortran -o testlsame lsame.o lsametst.o > ld: table of contents for archive: /Users/david/sage-2.8/local/bin/../ > lib/gcc-lib/powerpc-apple-darwin6.8/4.0.3//libf95.a is out of date; > rerun ranlib(1) (can't load from it) > ld: table of contents for archive: /Users/david/sage-2.8/local/bin/../ > lib/gcc-lib/powerpc-apple-darwin6.8/4.0.3//libgcc.a is out of date; > rerun ranlib(1) (can't load from it) > ld: table of contents for archive: /Users/david/sage-2.8/local/bin/../ > lib/gcc-lib/powerpc-apple-darwin6.8/4.0.3//libgcc_eh.a is out of > date; rerun ranlib(1) (can't load from it) > make[3]: *** [testlsame] Error 1 > /bin/sh: line 1: ./testlsame: cannot execute binary file > /bin/sh: line 1: ./testslamch: cannot execute binary file > /bin/sh: line 1: ./testdlamch: cannot execute binary file > /bin/sh: line 1: ./testsecond: No such file or directory > /bin/sh: line 1: ./testdsecnd: cannot execute binary file > /bin/sh: line 1: ./testversion: cannot execute binary file > make[2]: *** [lapack_install] Error 126 > Error compiling lapack. > > real0m0.419s > user0m0.149s > sys 0m0.163s > sage: An error occured while installing lapack-20070723 > Please email sage-devel http://groups.google.com/group/sage-devel > explaining the problem and send the relevant part of > of /Users/david/sage-2.8/install.log. Describe your computer, > operating system, etc. > If you want to try to fix the problem, yourself *don't* just cd to > /Users/david/sage-2.8/spkg/build/lapack-20070723 and type 'make'. > Instead (using bash) type "source local/bin/sage-env" from the directory > /Users/david/sage-2.8 > in order to set all environment variables correctly, then cd to > /Users/david/sage-2.8/spkg/build/lapack-20070723 > make[1]: *** [installed/lapack-20070723] Error 1 > > real60m26.672s > user26m56.349s > sys 17m18.560s > > > > david > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math
[sage-devel] Re: New Axiom package
On 8/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > The package is not available where you linked to, Sorry, the file was on the wrong machine. I have moved it so this link should now work: http://sage.math.washington.edu/home/page/axiom.py-0.3.1.patch > but I applied the change you said manually and both your example and > mine work now. Excellent. > Thanks! Now off to play with GUESS on some neat polynomials... You are welcome. Have fun. I am sure that Martin Rubey would be happy to discuss the program with you if you have any questions. Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: New Axiom package
The package is not available where you linked to, but I applied the change you said manually and both your example and mine work now. Thanks! Now off to play with GUESS on some neat polynomials... Paul On Aug 15, 7:39 pm, "Bill Page" <[EMAIL PROTECTED]> wrote: > Paul, > > If you have a moment to spare, could you please try this *additional( > patch for axiom.py in sage-2.8: > > http://sage.math.washington.edu/home/page/axiom.py-0.3.1.patch > > -- > bsd:~/sage-2.8/devel page$ diff -au > ./sage-main/sage/interfaces/axiom.py > ./sage-test/sage/interfaces/axiom.py > --- ./sage-main/sage/interfaces/axiom.py2007-08-15 > 11:27:03.0 -0700 > +++ ./sage-test/sage/interfaces/axiom.py2007-08-15 > 11:30:33.0 -0700 > @@ -159,7 +159,7 @@ > Expect.__init__(self, > name = 'axiom', > prompt = '\([0-9]+\) -> ', > -command = "axiom -nox -noclef", > +command = "sh -c 'cat|axiom -nox -noclef'", > maxread = 10, > script_subdirectory = script_subdirectory, > restart_on_ctrlc = False, > bsd:~/sage-2.8/devel page$ diff -au > ./sage-main/sage/interfaces/axiom.py > ./sage-test/sage/interfaces/axiom.py > ~/axiom.py-0.3.1.patch > bsd:~/sage-2.8/devel page$ > -- > > This second patch should be applied after the earlier one: > > http://sage.math.washington.edu/home/page/axiom.py-0.3.patch > > One the MAC OSX system that I am using for test, this change cures the > problems that you reported. The excuse for this funny construction: > >sh -c 'cat|axiom -nox -noclef' > > is that it causes Clisp to disable readline. > > Please let me know if it works for you. > > Regards, > Bill Page. > > On 8/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > no, the problem is most definitely still there, in both your and my > > example, even after installing the patch. it does produce interesting > > errors... > > > -- > > | SAGE Version 2.8, Release Date: 2007-08-12 | > > | Type notebook() for the GUI, and license() for information.| > > -- > > > sage: sage: r=[0,3,32,375,5184,84035] > > sage: sage: r=[0,3,32,375,5184,84035] > > sage: sage: R=axiom(r).guessExpRat(); R > > >n > > [[function= n (n + 2) ,order= 0]] > > sage: sage: R=axiom(r).guessExpRat(); R > > [0,3,32,375,5184,84035] > > ... --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: New Axiom package
Paul, If you have a moment to spare, could you please try this *additional( patch for axiom.py in sage-2.8: http://sage.math.washington.edu/home/page/axiom.py-0.3.1.patch -- bsd:~/sage-2.8/devel page$ diff -au ./sage-main/sage/interfaces/axiom.py ./sage-test/sage/interfaces/axiom.py --- ./sage-main/sage/interfaces/axiom.py2007-08-15 11:27:03.0 -0700 +++ ./sage-test/sage/interfaces/axiom.py2007-08-15 11:30:33.0 -0700 @@ -159,7 +159,7 @@ Expect.__init__(self, name = 'axiom', prompt = '\([0-9]+\) -> ', -command = "axiom -nox -noclef", +command = "sh -c 'cat|axiom -nox -noclef'", maxread = 10, script_subdirectory = script_subdirectory, restart_on_ctrlc = False, bsd:~/sage-2.8/devel page$ diff -au ./sage-main/sage/interfaces/axiom.py ./sage-test/sage/interfaces/axiom.py > ~/axiom.py-0.3.1.patch bsd:~/sage-2.8/devel page$ -- This second patch should be applied after the earlier one: http://sage.math.washington.edu/home/page/axiom.py-0.3.patch One the MAC OSX system that I am using for test, this change cures the problems that you reported. The excuse for this funny construction: sh -c 'cat|axiom -nox -noclef' is that it causes Clisp to disable readline. Please let me know if it works for you. Regards, Bill Page. On 8/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > no, the problem is most definitely still there, in both your and my > example, even after installing the patch. it does produce interesting > errors... > > -- > | SAGE Version 2.8, Release Date: 2007-08-12 | > | Type notebook() for the GUI, and license() for information.| > -- > > sage: sage: r=[0,3,32,375,5184,84035] > sage: sage: r=[0,3,32,375,5184,84035] > sage: sage: R=axiom(r).guessExpRat(); R > >n > [[function= n (n + 2) ,order= 0]] > sage: sage: R=axiom(r).guessExpRat(); R > [0,3,32,375,5184,84035] > ... --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: New Axiom package
On 8/15/07, Bill Page <[EMAIL PROTECTED]> wrote: > > Wonderful. > > > It just took a lot of work refining how the maxima interface works -- > > it resynchronizes itself before every interaction by putting > > "random number + 1" in the input and waits for the result of that > > arithmetic, etc. I'm sure the axiom interface could do something > > similar. > > Yes, I saw your new resynchronization code in 'maxima.py' and I was > **amazed** ! :-) It seems to me that you have gone to heroic lengths > to ensure that there is a way to recover from these sort of > communications problems. (At least Axiom never tries to ask the > console user a question!) I would be very interested to know how > often communications with Maxima have to be resynchronized during an > intensive interaction. If the need for resynchronization is occurring > often even when Maxima is not asking questions, and *if* this is due > to readline/pexpect interactioin - as I am now sure it is in the case > of Axiom - then it seems to me that preventing communications problems > in the first place and eliminating the (possible) spurious need for > resynchronization might make things more efficient. No. It will make the communications overhead maybe 50% better, but it would be far far less robust. And robustness is critically important. Also, random things can happen to mess up certain interfaces, e.g., the user hits control-C. If you want a rock solid interface, synchronizing (or dividing things up into clear transactions) is necessary. > I was thinking about how to do this resynchronization in 'axiom.py' > but then I realized that in my tests this was actually happening > because pexpect was (sometimes) returning a matched prompt string in > 'expect.after' even though the contents of 'expect.before' did not > contain the complete output that leads up to that prompt and then it > would return the same buffer a second (and sometimes third) time, each > time a little more complete before. As a result the communications get > out of sync. This problem entirely disappears when I rebuild with > readline disabled. Maybe it is a bug in pexpect. But as you implied, > these problems seem to be exceeding difficult to debug. It is easier > to work around them. I think that to really do this right we need > better syntactical markup in the Axiom output like is possible in > Maxima. Better markup would be very nice indeed. Best of luck with all this. Do consider synchronization. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: quaddouble in sage, and other floating point issues
On 8/14/07, William Stein <[EMAIL PROTECTED]> wrote: > On 8/14/07, cwitty <[EMAIL PROTECTED]> wrote: > > On Aug 14, 12:59 am, Jonathan Bober <[EMAIL PROTECTED]> wrote: > > > This is exactly what NTL does in its quad float class. Just about every > > > function starts and ends with a macro to adjust the fpu, resulting in > > > around 7 extra assembly instructions. In the following code, the > > > overhead is quite significant - it takes around 21 seconds to execute on > > > my machine, but only about 4 seconds without the START_FIX and END_FIX. > > > Of course, this is not necessarily any sort of accurate test, but it > > > does indicate that this can be an expensive operation. > > > > Yes, changing the floating-point modes is very slow on many (all?) x86 > > processors. I believe it flushes the floating-point pipeline, which > > takes many clock cycles. > > OK, how about this plan: > > (1) On systems with sse2, we do the option 3a (which is "If a > processor supports sse2, > then passing gcc -march=whatever -msse2 -mfpmath=sse (maybe the -march > isn't needed) will cause gcc to use sse registers and instructions for > doubles, and these have the proper precision.") > > (2) On systems without sse2 (old slow pentium 3's) we do the START_FIX > and END_FIX. These computers are very slow anyways, so let them suffer > (and the suffering is *only* for code that uses quaddouble, which is very > little > code anyways). Since nobody objected, can somebody volunteer to implement this? :-) William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: New Axiom package
On 8/15/07, William Stein <[EMAIL PROTECTED]> wrote: > ... > Maxima should never ever fail due to communication between SAGE and > Maxima. I spent a lot of time making sure of that a few months ago, when > we were rolling out the calculus functionality, which uses the maxima > interface > very very heavily. > When you doctest the SAGE_ROOT/devel/sage/sage/calculus directory, there > are literally hundreds of different and subtle interactions between SAGE and > maxima via the interface -- some involving expecting interactive questions > about input, etc., and it all happens very very quickly, but it works > perfectly > every time now. Wonderful. > It just took a lot of work refining how the maxima interface works -- > it resynchronizes itself before every interaction by putting > "random number + 1" in the input and waits for the result of that > arithmetic, etc. I'm sure the axiom interface could do something > similar. Yes, I saw your new resynchronization code in 'maxima.py' and I was **amazed** ! :-) It seems to me that you have gone to heroic lengths to ensure that there is a way to recover from these sort of communications problems. (At least Axiom never tries to ask the console user a question!) I would be very interested to know how often communications with Maxima have to be resynchronized during an intensive interaction. If the need for resynchronization is occurring often even when Maxima is not asking questions, and *if* this is due to readline/pexpect interactioin - as I am now sure it is in the case of Axiom - then it seems to me that preventing communications problems in the first place and eliminating the (possible) spurious need for resynchronization might make things more efficient. I was thinking about how to do this resynchronization in 'axiom.py' but then I realized that in my tests this was actually happening because pexpect was (sometimes) returning a matched prompt string in 'expect.after' even though the contents of 'expect.before' did not contain the complete output that leads up to that prompt and then it would return the same buffer a second (and sometimes third) time, each time a little more complete before. As a result the communications get out of sync. This problem entirely disappears when I rebuild with readline disabled. Maybe it is a bug in pexpect. But as you implied, these problems seem to be exceeding difficult to debug. It is easier to work around them. I think that to really do this right we need better syntactical markup in the Axiom output like is possible in Maxima. Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: New Axiom package
On 8/15/07, Bill Page <[EMAIL PROTECTED]> wrote: > > Yes, I could/will easily do this. I have no reason to believe that any > tests would fail, but of course it is good to check. The main > difference would be felt by those people who use -clisp, -maxima, or > -axiom in console-mode. These users would no longer have line-editing > support. This is the main reason why I would hesitate to suggest this > option. Exactly. This is not an option. > After looking into the Maxima code a little more, I doubt what I said > about --readline-off is true. It seems that this option only applies > to Maxima built using GCL. And now checking the code in maxima.py > again too, it seems that recent versions definitely don't use this > option. But maxima.py does use the > > (setf *general-display-prefix* "") > > option to help implement a general "resynchronization" protocol which > perhaps prevents this from happening so often when using Maxima from > Sage. So it seems to me that even the reliability of Maxima on > different hardware is likely to be improved by the use of Clisp built > --without-readline. Does anyone no of any test cases now for Maxima > that seem to fail due to the communication between Maxima and Sage? Maxima should never ever fail due to communication between SAGE and Maxima. I spent a lot of time making sure of that a few months ago, when we were rolling out the calculus functionality, which uses the maxima interface very very heavily. When you doctest the SAGE_ROOT/devel/sage/sage/calculus directory, there are literally hundreds of different and subtle interactions between SAGE and maxima via the interface -- some involving expecting interactive questions about input, etc., and it all happens very very quickly, but it works perfectly every time now. It just took a lot of work refining how the maxima interface works -- it resynchronizes itself before every interaction by putting "random number + 1" in the input and waits for the result of that arithmetic, etc. I'm sure the axiom interface could do something similar. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: New Axiom package
On 8/15/07, David Joyner wrote: > > Maybe this is more work than you want to get into but here's > an idea: > (1) try building SAGE using Clisp without readline support, > check for warnings etc, > (2) run sage -testall, check for broken tests. > (3) report problems to the lists. > Would that add useful information? > Yes, I could/will easily do this. I have no reason to believe that any tests would fail, but of course it is good to check. The main difference would be felt by those people who use -clisp, -maxima, or -axiom in console-mode. These users would no longer have line-editing support. This is the main reason why I would hesitate to suggest this option. Being able to dynamically disable it for use with pexpect would be much nicer. After looking into the Maxima code a little more, I doubt what I said about --readline-off is true. It seems that this option only applies to Maxima built using GCL. And now checking the code in maxima.py again too, it seems that recent versions definitely don't use this option. But maxima.py does use the (setf *general-display-prefix* "") option to help implement a general "resynchronization" protocol which perhaps prevents this from happening so often when using Maxima from Sage. So it seems to me that even the reliability of Maxima on different hardware is likely to be improved by the use of Clisp built --without-readline. Does anyone no of any test cases now for Maxima that seem to fail due to the communication between Maxima and Sage? Regards. Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: New Axiom package
On 8/15/07, David Joyner <[EMAIL PROTECTED]> wrote: > Maybe this is more work than you want to get into but here's > an idea: > (1) try building SAGE using Clisp without readline support, > check for warnings etc, > (2) run sage -testall, check for broken tests. > (3) report problems to the lists. > Would that add useful information? The SAGE clisp *must* be built with readline support. If you don't do that, then, e.g., maxima_console() would not have readline support, which would be a very miserable experience. It's almost certainly possible to program around the readline problem in axiom.py by using some more complicated code there to synchronize things. That's probably the way to go. And, of course, figuring out how maxima can disable readline at startup is well worth doing. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: New Axiom package
Maybe this is more work than you want to get into but here's an idea: (1) try building SAGE using Clisp without readline support, check for warnings etc, (2) run sage -testall, check for broken tests. (3) report problems to the lists. Would that add useful information? On 8/15/07, Bill Page <[EMAIL PROTECTED]> wrote: > > On 8/15/07, Bill Page I wrote: > > ... > > How much objection would there be to building Clisp in Sage without > > readline support? > > ... > > Alternatively assuming no dynamic method of disabling readline for > Clisp is found, I guess I could use the clisp*.spkg source to build a > local copy of clisp without readline support during the axiom4sage > spkg-install. This would make the Axiom install significantly longer, > but otherwise would be transparent to the rest of Sage. > > Regards, > Bill Page. > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: New Axiom package
On 8/15/07, Bill Page I wrote: > ... > How much objection would there be to building Clisp in Sage without > readline support? > ... Alternatively assuming no dynamic method of disabling readline for Clisp is found, I guess I could use the clisp*.spkg source to build a local copy of clisp without readline support during the axiom4sage spkg-install. This would make the Axiom install significantly longer, but otherwise would be transparent to the rest of Sage. Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: ticket #59 (optimize elliptic curve arithmetic)
On Aug 15, 2007, at 2:37 AM, Michel wrote: > I think repeated squaring is not more efficient in all cases. For > example over Z it is only > more efficient if your multiplication algorithm is faster than the > naive one (which is O(n^2) in the number of bits). > > So in the case of elliptic curves it really depends on the efficiency > of the addition steps and on how fast > the numerators/denominators grow. I am sure the elliptic curve experts > on this forum can say more about this. Ah yes I had hadn't thought through that. SAGE uses GMP for the multiplications, which is quasi-linear time; on the other hand, the integer GCD code in GMP is still quadratic (as of GMP 4.2.1), so in effect what you're saying is still relevant since it is really doing arithmetic over Q. If you take a non-torsion point P on E(Q), then the bitsize of the numerators/denominators of kP grow like k^2. So bitsize of 2^m P is about 4^m. Say we compute 2^m P by repeated doubling. If the arithmetic is quadratic time then computing 2^m P costs about 1 + 4^2 + 16^2 + ... + (4^m)^2 which is about 4^(2m) = 16^m. If the arithmetic is linear time (including the GCDs) then computing 2^m P costs about 1 + 4 + 16 + ... + 4^m which is about 4^m (ignoring log factors). Now say we compute 2^m P as (P + (P + (P + ( ... (P + P))...))). Well I'm not sure exactly what happens here, it's a bit more complicated since at each stage you're adding something "small" to something "big". I guess to keep it simple we can pretend the small thing is a constant, since we're assuming P is fixed. In the linear-time arithmetic case, at step N you have to do at least N^2 work, so it's 1 + 2^2 + 3^2 + ... + (2^m)^2 = about 8^m, so definitely loses to repeated doubling. In the quadratic time arithmetic case, it's more complicated. I'm looking at the formula for elliptic curve addition, and it looks like to compute P+Q you have to multiply coordinates of Q by coordinates of Q. Maybe there's a way of rewriting it, I don't know. If this is true, it means step N needs at least N^4 work, so it's 1 + 2^4 + 3^4 + ... + (2^m)^4 = about 32^m, so this still loses out to repeated doubling. If on the other hand, you can get away with multiplying coordinates of Q by coordinates of P (which is assumed to be constant), then it's still 8^m, so it beats repeated doubling. So if my analysis is wrong, we need an elliptic curve expert; and if it's right, we need an elliptic curve expert! (and in all cases it would be great if someone could address this ticket: http://www.sagemath.org:9002/sage_trac/ticket/424) david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: fixes need for SAGE 2.8.1 to work on Solaris
Hi, just in case you wonder why the channel is empty: The IRC channel is called #SAGE-dev and not #sage-devel. We should probably change that. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] fixes need for SAGE 2.8.1 to work on Solaris
Hello,
I guess it isn't a secret that William want Sage 2.8.1 to work on
Solaris "out of the box". Didie, William and I spend most of yesterday
in the IRC channel #sage-devel to cooridnate the hacking and got quite
far. We are done yet, but here are some notes on things to be done:
sage -br fixes/suggestions for Solaris
libsingular builds with the right headers. Make install target needs
fixing. The current singular.spkg expects install-sh in very odd
places and therefore fails easily. One of them is $SAGE_LOCAL/bin -
very naughty.
real_rqdf: INFINITY and NAN are undefined on Solaris. That can be
accompilished by the slightly changed cygwinfix.h (which is no
misnamed :))
// cygwinfix.h
// defines NAN and INFINITY on Solaris. The same applies to *BSD if
anybody cares.
#if defined(__sun)
#define NAN (0.0/0.0)
#define INFINITY (__builtin_huge_valf())
#endif
It isn't worth to provide this as a patch, but I am sure William will
give me credit :)
Later on in the code for real_rqdf.pyx we have another two problems:
#if isinf(d[0]):
#d[0] = INFINITY
#return qd_from_double(d[0])
#if not finite(d[0]):
#d[0] = NAN
#return qd_from_double(d[0])
The problem with isinf can be resolved via an explicit cast. The
symbol finite is missing and might no longer exist after the update
to quad_double 2.3pre5.
coerce:
The following took quite a while to figure our: coerce doesn't
compile:
building 'sage.structure.coerce' extension
gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -
fPIC -I/extra/home/mabshoff/SAGE-build/sage-2.8/local//include -I/
extra/home/mabshoff/SAGE-build/sage-2.8/local//include/python -I/extra/
home/mabshoff/SAGE-build/sage-2.8/devel//sage/sage/ext -I/extra/home/
mabshoff/SAGE-build/sage-2.8/local/include/python2.5 -c sage/structure/
coerce.c -o build/temp.solaris-2.9-sun4u-2.5/sage/structure/coerce.o -
w
sage/structure/coerce.c:824: error: expected identifier or '(' before
numeric constant
sage/structure/coerce.c:825: error: expected ';' before 'int'
error: command 'gcc' failed with exit status 1
sage: There was an error installing modified sage library code.
If you look around line 300 in coerce.pyx you will find the following
code:
def coercion_maps(self, R, S):
return self.coercion_maps_c(R, S)
cdef coercion_maps_c(self, R, S):
try:
return self._coercion_maps[R,S]
except KeyError:
homs = self.discover_coercion_c(R, S)
if homs is not None:
self._coercion_maps[R,S] = homs
self._coercion_maps[S,R] = (homs[1], homs[0])
else:
self._coercion_maps[R,S] = self._coercion_maps[S,R] =
None
return homs
def get_action(self, R, S, op):
return self.get_action_c(R, S, op)
Now cython turns this into C code. All the variables named R in cython
are named _R in C, analog for S which turns into _S. This is a
problem in Solaris because at least one of those is defined as a
numercial constant and therefore makes gcc barf. In LinBox the same
happended in lb-solve.C where a template member is called _B. It would
be very nice if somebody familiar with the coercion code could change
the variable names to something longer and submit a patch to William.
That way he migth wake up to a bunch of bugs squashed. If you know of
any other places in the cython code now might be a good idea to speak
up.
There have been many changes already to the 2.8 packages in order to
make them build on Solaris. If you want to help out check out #sage-
devel in a couple hours. I am getting some sleep now, it has been a
long night.
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: New Axiom package
On 8/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> no, the problem is most definitely still there, in both your and my
> example, even after installing the patch. it does produce interesting
> errors...
>
I can not reproduce these errors on the sage.math server (Linux) but
careful testing on MAC OSX of *exactly* the same code including the
axiom.py-0.3.patch, I find that it does *randomly* produce the kind of
errors you describe.
There followed a long night of debugging... I have finally determined
that the problem is caused by readline in Clisp. The use of readline
in the pexpect interface seems to cause problems on some systems but
not on others. I noticed that this problem does not occur in Maxima
even though Maxima is built using Clisp because Maxima itself is run
in the maxima.py interface with readline disabled. Unfortunately, so
far as I can tell there is no similar way to dynamically disable
readline in Axiom if it is built using Clisp. How this might be done
depends on the version of Lisp. I can find a method of GCL but not for
Clisp. If anyone knows how to do this (or even how Maxima does this
internally), please let me know.
So as a last resort I modified the Clisp spkg-install script to call
./configure --without-readline ...
and re-built Clisp without readline linked in. Then I recompiled
axiom4sage-0.3.1 and now everything is working properly on both Linux
and MAC OSX!
How much objection would there be to building Clisp in Sage without
readline support?
Regards,
Bill Page.
Test results:
Using my original script
copy -
r=[0,3,32,375,5184,84035]
R=axiom(r).guessExpRat(); R
f=axiom('%s.1.function'%R.name()); f
f.type()
f.eval(axiom('n=5'))
f.eval(axiom('n=6'))
paste -
I get the following when pasting it into a Sage console session:
[EMAIL PROTECTED]:~/sage-2.8$ ./sage
--
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information.|
--
Loading SAGE library. Current Mercurial branch is: test
sage: r=[0,3,32,375,5184,84035]
sage: R=axiom(r).guessExpRat(); R
n
[[function= n (n + 2) ,order= 0]]
sage: f=axiom('%s.1.function'%R.name()); f
n
n (n + 2)
sage: f.type()
Expression Integer
sage: f.eval(axiom('n=5'))
84035
sage: f.eval(axiom('n=6'))
1572864
sage: exit
Exiting SAGE (CPU time 0m0.05s, Wall time 0m24.78s).
Exiting spawned Axiom process.
And with Paul's script:
- copy ---
k = var('k')
tmp = [rising_factorial(x,k)/falling_factorial(x,k) for k in range(5)]
pol1 = axiom(tmp[1])
pol1
pol1
pol1
pol4 = axiom(tmp[4])
pol4
pol4
pol4
pol4
pol4
pol4
pol4
pol4
pol1 = axiom(tmp[1])
pol1
pol1
pol1
pol1
pol1
pol1
pol1
pol1
paste
I get the result:
[EMAIL PROTECTED]:~/sage-2.8$ ./sage
--
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information.|
--
Loading SAGE library. Current Mercurial branch is: test
sage: k = var('k')
sage: tmp = [rising_factorial(x,k)/falling_factorial(x,k) for k in range(5)]
sage:
sage: pol1 = axiom(tmp[1])
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol4 = axiom(tmp[4])
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
--
3 2
x - 6x + 11x - 6
sage: pol1 = axiom(tmp[1])
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: exit
Exiting SAGE (CPU time 0m0.09s, Wall time 0m11.02s).
Exiting spawned Axiom process.
[EMAIL PROTECTED]:~/sage-2.8$
---
This now looks ok to me on both sage.math and on the MAC OSX test system.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~-
[sage-devel] Re: New Axiom package
no, the problem is most definitely still there, in both your and my example, even after installing the patch. it does produce interesting errors... -- | SAGE Version 2.8, Release Date: 2007-08-12 | | Type notebook() for the GUI, and license() for information.| -- sage: sage: r=[0,3,32,375,5184,84035] sage: sage: r=[0,3,32,375,5184,84035] sage: sage: R=axiom(r).guessExpRat(); R n [[function= n (n + 2) ,order= 0]] sage: sage: R=axiom(r).guessExpRat(); R [0,3,32,375,5184,84035] sage: sage: R=axiom(r).guessExpRat(); R sage: sage: R=axiom(r).guessExpRat(); R 84035 sage: sage: R=axiom(r).guessExpRat(); R = [sage0,sage1,sage2,sage3,sage4,sage5] := guessExpRat(sage6) = 5184 5184 sage: sage: R=axiom(r).guessExpRat(); R 375 sage: sage: R=axiom(r).guessExpRat(); R 32 sage: sage: R=axiom(r).guessExpRat(); R 3 On Aug 15, 7:57 am, "Bill Page" <[EMAIL PROTECTED]> wrote: > On 8/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > It build fine but the I/O is seriously bugged for me, at least for the > > displaying of rational functions (but probably wrapping too)... > > ... > > Oops, for the full axiom interface to work reliably you need > sage-2.8.1 or the following patch: > > http://sage.math.washington.edu/home/page/axiom.py-0.3.patch > > (Not required just to run 'sage -axiom'.) > > On 8/13/07, William Stein <[EMAIL PROTECTED]> wrote: > > > > > Thanks. I've applied this for sage-2.8.1. > > > On 8/13/07, Bill Page <[EMAIL PROTECTED]> wrote: > > > On 8/13/07, William Stein <[EMAIL PROTECTED]> wrote: > > > > Please resend your patch as an email attachment or post it somewhere > > > > and send me a link. Your emailing + my email client mangled it. > > > > Sorry. Here's a link: > > > >http://sage.math.washington.edu/home/page/axiom.py-0.3.patch > > > -- > > William Stein > > Associate Professor of Mathematics > > University of Washington > >http://www.williamstein.org > > Regards, > Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
