[sage-devel] another sage talk...

2007-11-14 Thread William Stein

http://sagemath.org/talks/20071114-sage_bristol/

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

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [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: [SAGEdev] Error building sage in Solaris 10 with gcc 4.0.2

2007-11-14 Thread David Joyner

Klas:
Thanks for your report but it was sent to the wrong list.
(The sf list is closed. I'm forwarding this to the correct list.)
- David Joyner

On Nov 14, 2007 8:19 AM, Klas Heggemann [EMAIL PROTECTED] wrote:

  This fails in the building of one of the libraries:

  SunOS sgray.nada.kth.se 5.10 Generic_127111-02 sun4u sparc
 SUNW,Sun-Fire-280R
  
  
  GCC Version
  gcc -v
  Using built-in specs.
  Target: sparc-sun-solaris2.10
  Configured with: ../gcc-4.0.2/configure --prefix=/pkg/gcc/4.0.2/os
  Thread model: posix
  gcc version 4.0.2
  
  make[2]: Entering directory
 `/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/spkg/build/flint-0.2.p4/src'
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c mpn_extras.c -o
 mpn_extras.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c Z.c -o Z.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c memory-manager.c -o
 memory-manager.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c Z_mpn.c -o Z_mpn.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF.c -o ZmodF.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF_mul.c -o
 ZmodF_mul.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF_mul-tuning.c
 -o ZmodF_mul-tuning.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c fmpz.c -o fmpz.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c fmpz_poly.c -o
 fmpz_poly.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c mpz_poly-tuning.c
 -o mpz_poly-tuning.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c mpz_poly.c -o
 mpz_poly.o
  gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
 -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF_poly.c -o
 ZmodF_poly.o
  ZmodF_poly.c: In function 'ZmodF_poly_bit_pack_mpn':
  ZmodF_poly.c:217: error: 'u_int16_t' undeclared (first use in this
 function)
  ZmodF_poly.c:217: error: (Each undeclared identifier is reported only once
  ZmodF_poly.c:217: error: for each function it appears in.)
  ZmodF_poly.c:217: error: syntax error before 'lower'
  ZmodF_poly.c:269: error: 'lower' undeclared (first use in this function)
  ZmodF_poly.c:269: error: syntax error before 'temp'
  make[2]: *** [ZmodF_poly.o] Error 1
  make[2]: Leaving directory
 `/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/spkg/build/flint-0.2.p4/src'


  This is due to the fact that there is no typedef for u_int_t in include
 files.

  Adding this definition in some file makes sage build OK.




 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 sage-devel mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/sage-devel



--~--~-~--~~~---~--~~
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 

[sage-devel] Re: Error building sage in Solaris 10 with gcc 4.0.2

2007-11-14 Thread mabshoff



On Nov 14, 3:59 pm, David Joyner [EMAIL PROTECTED] wrote:
 Klas:
 Thanks for your report but it was sent to the wrong list.
 (The sf list is closed. I'm forwarding this to the correct list.)

:)

 - David Joyner

 On Nov 14, 2007 8:19 AM, Klas Heggemann [EMAIL PROTECTED] wrote:



   This fails in the building of one of the libraries:

   SunOS sgray.nada.kth.se 5.10 Generic_127111-02 sun4u sparc
  SUNW,Sun-Fire-280R
   
   
   GCC Version
   gcc -v
   Using built-in specs.
   Target: sparc-sun-solaris2.10
   Configured with: ../gcc-4.0.2/configure --prefix=/pkg/gcc/4.0.2/os
   Thread model: posix
   gcc version 4.0.2
   
   make[2]: Entering directory
  `/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/spkg/build/flint-0.2.p4/src'
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c mpn_extras.c -o
  mpn_extras.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c Z.c -o Z.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c memory-manager.c -o
  memory-manager.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c Z_mpn.c -o Z_mpn.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF.c -o ZmodF.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF_mul.c -o
  ZmodF_mul.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF_mul-tuning.c
  -o ZmodF_mul-tuning.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c fmpz.c -o fmpz.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c fmpz_poly.c -o
  fmpz_poly.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c mpz_poly-tuning.c
  -o mpz_poly-tuning.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c mpz_poly.c -o
  mpz_poly.o
   gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/
  -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include
  -fexpensive-optimizations  -fPIC -funroll-loops   -O3 -c ZmodF_poly.c -o
  ZmodF_poly.o
   ZmodF_poly.c: In function 'ZmodF_poly_bit_pack_mpn':
   ZmodF_poly.c:217: error: 'u_int16_t' undeclared (first use in this
  function)
   ZmodF_poly.c:217: error: (Each undeclared identifier is reported only once
   ZmodF_poly.c:217: error: for each function it appears in.)
   ZmodF_poly.c:217: error: syntax error before 'lower'
   ZmodF_poly.c:269: error: 'lower' undeclared (first use in this function)
   ZmodF_poly.c:269: error: syntax error before 'temp'
   make[2]: *** [ZmodF_poly.o] Error 1
   make[2]: Leaving directory
  `/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/spkg/build/flint-0.2.p4/src'

   This is due to the fact that there is no typedef for u_int_t in include
  files.

mmh, I remember fixing that. Maybe it snuck back in or Bill has fixed
it upstream only.

Either way I will check this out on my Sun 10 box. Last time I checked
I got everything to build except cvxopt (due to missing complex.h, but
that might be fixed now, too), but some of the doctests failed upon
startup.

Klas, if you have the time: Could you run ./sage -testall and report
back please? Apologies if I got the wrong Klas Heggemann :)

Cheers,

Michael


   Adding this definition in some file makes sage build OK.

  -
  This SF.net email is sponsored by: Splunk Inc.
  Still grepping through log files to find problems?  Stop.
  Now Search log 

[sage-devel] Re: another sage talk...

2007-11-14 Thread mabshoff



On Nov 14, 2:59 pm, William Stein [EMAIL PROTECTED] wrote:
 http://sagemath.org/talks/20071114-sage_bristol/

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

And a direct link to the inquirer story:

http://www.theinquirer.net/articles/flameAuthor/gb/inquirer/news/2007/10/24/mathematics-rediscovers-scientific

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: Question about Error in IntegerMod_gmp_power_of_2

2007-11-14 Thread Robert Bradshaw

Sorry I haven't had a chance to look into this yet, but I'm probably  
not going to have internet access for a while so I figured I'd send a  
quick reply now.

On Nov 14, 2007, at 2:03 AM, Jonathan Hanke wrote:

 Hi Robert,

 I have been playing around with it, and there seems to be a problem  
 with the way I'm trying to call any C-level IntegerMod since I can  
 also generate errors and segfaults when I try to use the more  
 stable IntegerMod_gmp.

Can you use hg_sage.diff() to see what changed?


 I think that the real issue is I don't know how to properly call  
 cython functions.

 1) I can declare variables and do some basic operations with:

 R = 5
 cdef IntegerMod_gmp one
 one = IntegerMod_gmp(IntegerModRing(R), 1)
 print one + one

 However bad things happen when I try to multiply

 print one * one

 and this is where some of my problems are.


 2) I can create lists by repeated use of the .append() method, but  
 I don't know a cythonic way of creating lists (or if this is even  
 desirable).

List comprehensions for now, or use native c arrays.


 3) I read in the programming guide that we need to have cdef'ed  
 methods declared as public before we can use them, and  
 IntegerMod_gmp is not public.  Is this a problem?  Why or why not?

cef'd attributes need to be public to use them from python, nothing  
you do to cdef functions makes them accessable. (But cpdef can be.)

The programming guide is so out of date in terms of using Pyrex/ 
Cython, and IIRC lots of it is misleading or just plain false.  
Everything but the C++ section needs a major rewrite. Use the stuff  
on http://wiki.cython.org/ And update it too, lots of people have  
similar questions.

Also, I've been working on http://sage.math.washington.edu/home/ 
robertwb/cython/polynomial_element.pyx.html

 4) How do I know when to coerce a variable with ...?  If I do,  
 how does it do the coercion?  Can I coerce an IntegerMod to an  
 IntegerMod_gmp?  What about the other way?

Never, ever, coerce variables with ... That is C casting, and is  
used to tell Cython when you have an object that you know is a more  
specific type and you want to use it as such.

This is probably where your segfaults are coming from.

 5) How would I find functions like PyList_New and PyInt_FromLong  
 from the following example when I need them (or even decide what  
 they do when I see them)?

 def f4(int n):
 cdef int i
 v = PyList_New(n)
 for i from 0 = i  n:
 PyList_SET_ITEM(v, i, objectPyInt_FromLong(i))
 #WARNING -- maybe I need to incref the ref to the long?!
 return v

The answer is, don't do stuff like this, do [i for i from 0 = i  n]

which will be just as fast, easier to read, and won't cause a  
segfault if you mess up.

 6) How do I know when I need to allocate/release memory?  I don't  
 need to for a long, but I do for an mpz_t.
 What about for an instance of Python/Cython class?  How do I do this?

Typically, you obey the c semantics of allocating/releasing memory  
for stuff like mpz_t, int*, etc. If you allocate, somewhere you have  
to figure out where to dealloc. But see below.

As for Python/Cython classes, they are all taken care of by the  
python garbage collector, so you have no need to alloc or free them.

Every cython (cdef) class has a __new__ (or __cinit__*) method which  
gets called exactly once at object creation. This is the best place  
to allocate class members (such as mpz_t's). When a class is about to  
be free'd (as determined by the Python garbage collector), the  
__dealloc__ method is called and this is the spot to free anything  
you allocated in __new__. This makes most memory handling very easy.

* Greg recently changed the name of __new__ to __cinit__ to not  
conflict with Python's version of __new__. Both coexist for the  
moment and are aliases. Someday I'll do a s/__new__/__cinit__/g  
throughout all sage cython files.

 That's about all I can think of.  I looked at the cython section of  
 the Programming Guide, but it would be really helpful to have  
 several small worked hacking projects to see how design decisions  
 are made, and how everything fits together.  I'd be happy to try to  
 contribute such information once I learn it.

That would be great.


 Thanks a lot,

 -Jon
  =)

 P.S.  Feel free to post your response to the sage-devel list as  
 well if you think it's appropriate.

If the past is any indication, I'm sure lots of other people have  
similar questions.


--~--~-~--~~~---~--~~
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] More potential GPL issues with Singular

2007-11-14 Thread mabshoff

Searching some debian mailing lists I came across:

Re: Advice on packaging SAGE - see 
http://lists.debian.org/debian-mentors/2007/06/threads.html

Specifically from http://lists.debian.org/debian-mentors/2007/06/msg00020.html
***
  IIRC Singular has licensing restrictions (requires citing the
authors) so I
  don't think it can go in main.

I don't think that is part of the license. After the license there is
first a request to send in comments and bugs to a specific address,
then a request to register yourself as user, then this
request:

If you use Singular or parts thereof in a project and/or publish
results that were partly obtained using SINGULAR, we ask you to cite
SINGULAR and inform us thereof - see
`http://www.singular.uni-kl.de/how_to_cite.html', for information on
how to cite Singular.

I'm no native english speaker, and I think those who have written this
are neither. But this looks much like it is a request and no condition
on use (or copying/modifying).

There are licencse problems with the omalloc library included, but it
looks like its author already relicenced it, so it will most likely
be fixed in the next version.

Hochachtungsvoll,
Bernhard R. Link
***

This might actually explain why Singular isn't in Debian.

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/
-~--~~~~--~~--~--~---