[sage-devel] Re: Doctest failures for Debian SAGE packages

[Timothy G Abbott]

I've Debianized the GAP Guava package and scipy_sandbox packages, so now 
the tests related to those pass.

However, I seem to have one new doctest failure.

sage -t  devel/doc/const/const.tex 
**
File /home/tabbott/test2/const.py, line 3078:
 : list(G.coset_reps())
Expected:
 [[1, 0, 0, 1], [0, -1, 1, 0], [1, 0, 1, 1], [1, 1, 1, 2], [1, 2, 1, 3],
  [1, 3, 1, 4], [1, 4, 1, 5], [1, 5, 1, 6], [1, 6, 1, 7], [1, 7, 1, 8],
  [1, 8, 1, 9], [1, 9, 1, 10]]
Got:
 [[1, 0, 0, 1], [0, -1, 1, 0], [0, -1, 1, 1], [0, -1, 1, 2], [0, -1, 1, 
3], [0, -1, 1, 4], [0, -1, 1, 5], [0, -1, 1, 6], [0, -1, 1, 7], [0, -1, 1, 
8], [0, -1, 1, 9], [0, -1, 1, 10]] 
**

Any ideas?

-Tim Abbott

On Sun, 30 Mar 2008, Timothy G Abbott wrote:


 The set of Debian packages for SAGE 2.10.4 that I just announced do not
 pass all doctests.  Some known problems include:

 - the scipy_sandbox is not installed (so delaunay.py won't load)

 - jmol is not installed

 - a few GAP packages are not available in Debian's GAP.

 - PARI in Debian has the mathnf bug

 - Maxima doctests fail due to the differences between
 -.05837414342758009 and -0.05837414342758 (both roundoff and the 0. at
 the start of numbers less than 1).  I believe this is likely caused by the
 fact that Maxima in Debian uses gsl rather than clisp.

 Below are a bunch of doctest failures whose causes I don't understand,
 summarized as follows:

 - CRT gives the wrong answer
 - modular symbols in ambient.py get wrong answers
 - Many constants are rounded in constants.py
 - Various problems with sympy; perhaps a version mismatch? Debian has 0.5.12
 - the doctests on calculus.py don't terminate (I've not tested anything
 past there yet, but will soon)

 Help debugging these problems will be appreciated.

   -Tim Abbott

 sage -t tut.tex
 **
 File tut.py, line 1150:

 : x = crt(2, 1, 3, 5); x

 Expected:

 11

 Got:

 -4

 **

 sage -t devel/sage-main/sage/modular/modsym/ambient.py
 **
 File ambient.py, line 427:

 sage: M.modular_symbol([2/11, oo])

 Expected:

 -{8/9,1}

 Got:

 -{-1/9,0}

 **
 File ambient.py, line 429:

 sage: M.1

 Expected:

 {7/8,1}

 Got:

 {-1/8,0}

 **
 File ambient.py, line 431:

 sage: M.modular_symbol([-1/8, 0])

 Expected:

 {7/8,1}

 Got:

 {-1/8,0}

 **
 File ambient.py, line 433:

 sage: M.modular_symbol([0, -1/8, 0])

 Expected:

 {7/8,1}

 Got:

 {-1/8,0}

 **

 sage -t devel/sage-main/sage/functions/constants.py
 **
 File constants.py, line 148:

 sage: RQDF(e)

 Expected:

 2.718281828459045235360287471352662497757247093699959574966967630

 Got:

 3.000

 **
 File constants.py, line 150:

 sage: RQDF(pi)

 Expected:

 3.141592653589793238462643383279502884197169399375105820974944590

 Got:

 3.000

 **
 File constants.py, line 152:

 sage: RQDF(e)

 Expected:

 2.718281828459045235360287471352662497757247093699959574966967630

 Got:

 3.000

 **
 File constants.py, line 160:

 sage: RQDF(log2)

 Expected:

 0.693147180559945309417232121458176568075500134360255254120680009

 Got:

 0.700

 **
 File constants.py, line 184:

 sage: RQDF(a)

 Expected:

 13.27134794019724931009881919957581394087110682000307481783297119

 Got:

 13.41832627758846552685865622348547199084119019256775416777037896

 **
 File constants.py, line 733:

 sage: pi._real_rqdf_(RQDF)

 Expected:

 3.141592653589793238462643383279502884197169399375105820974944590

 Got:

 3.000

 **
 File constants.py, line 1032:

 sage: RQDF.e()

 Expected:

 

[sage-devel] Re: 2.11 on Ubuntu Hardy beta; parallel doctesting

[Yi Qiang]

Hey Dan,
The testdoc.py file looks to be right. I just upgraded to Ubuntu 8.04
(32bit) and could not reproduce the problem with the 2.11 binary
posted on sagemath.org.

Has anyone else seen the problem Dan reported in 2.11?

Cheers,
Yi

On Mon, Mar 31, 2008 at 7:00 PM, Dan Drake [EMAIL PROTECTED] wrote:
 On Mon, 31 Mar 2008 at 05:28PM -0700, Yi Qiang wrote:
   Hi Dan,
   the dsage doctest failure you're seeing should not be happening with
   the official 2.11 release.  Can you
  
   1) Verify that you are running the official 2.11 release

  sage: version()
  'SAGE Version 2.11, Release Date: 2008-03-30'

  I also ran an upgrade() and it concluded that it has the most recent
  version.


   2) Provide sage/dsage/tests/testdoc.py from your source tree.

  It's attached.



  Dan

  --
  ---  Dan Drake [EMAIL PROTECTED]
  -  KAIST Department of Mathematical Sciences
  ---  http://math.kaist.ac.kr/~drake

 -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.6 (GNU/Linux)

  iD8DBQFH8Zc6r4V8SljC5LoRAkTIAJ4kGCgHx/o0KCLIhJexXWTgY0SauQCfa98W
  WQC/mIaw5cI9NmJ+Pt5nku4=
  =V0IS
  -END PGP SIGNATURE-



--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: multivariate factoring - use maxima ?

[Timothy G Abbott]

Since the Debian distribution of SAGE uses Maxima with GCL list, I figured 
I'd run the benchmarks Mike posted on my installation.  The SAGE times are 
comparable to those in Mike's test, while the Maxima tests are faster:

sage: load /home/tabbott/fermat_gcd_1var.py
sage: time a = p1.gcd(p2, algorithm='ezgcd')
Wall time: 0.03 s (compare with 0.02)
sage:  mp1 = maxima(p1)
sage: mp2 = maxima(p2)
sage: time a = mp1.gcd(mp2)
Wall time: 0.07 s (compare with 0.20)

sage: load /home/tabbott/fermat_gcd_4var.py
sage: time a = p1.gcd(p2, algorithm='ezgcd')
Wall time: 0.12 s (compare with 0.13)
sage: mp1 = maxima(p1)
sage: mp2 = maxima(p2)
sage:  time a = mp1.gcd(mp2)
Wall time: 0.51 (compare with 1.04)

So, it looks like one's getting a 2-3x speedup by using Maxima with GCL 
lisp on this particular test.

Of course, the fact that I'm running with GCL lisp also means that my SAGE 
fails all the Maxima doctests involving real numbers due to roundoff 
differences.

-Tim Abbott

On Tue, 1 Apr 2008, root wrote:


 William,

 By the way, Richard Fateman pointed out to me offlist that
 Maxima running on top of clisp _might_ be much
 slower than Maxima on gcl.  This could be relevant to
 our benchmarking.

 Not to start an implementation war but GCL compiles to C which
 compiles to machine code whereas clisp is interpreted. Both Axiom
 and Maxima have implementations on top of GCL. GCL includes a
 routine that will output the lisp type declarations and if these
 are loaded into the image with a recompile the resulting code is
 even faster. So if you use Maxima, use the GCL version.

 CMUCL/SBCL are capable of slightly tighter optimizations because
 they grew out of the SPICE Lisp project (under Scott Fahlman)
 and concentrated on code optimizations. Under CMUCL I managed to
 optimize a function down to a single machine instruction so it IS
 possible to get maximal optimizations. But GCL also lays down some
 very tight code since proper declarations can usually eliminate
 type dispatch, which is important in the inner loops.

 You can see the generated code by calling (disassemble )

 On the other hand you're likely to get small factors of improvements
 by changing to compiled lisps (but certainly much faster than python).
 My experience shows that its the algorithm changes that matter most.




 On a related note, I found it odd that someone commented that
 they wish to remove Lisp from Sage. Do you have any idea what
 might motivate that?

 Tim Daly
 Axiom



 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: multivariate factoring - use maxima ?

[Roman Pearce]

On Mar 31, 10:55 pm, William Stein [EMAIL PROTECTED] wrote:
 On Mon, Mar 31, 2008 at 6:48 PM, Roman Pearce [EMAIL PROTECTED] wrote:

   You need Algorithms for Computer Algebra by Geddes, Czapor, and
   Labahn:
   Chapter 5: Chinese Remainder Theorem
   Chapter 6: Newton's Iteration and Hensel Lifting
   Chapter 7: Polynomial GCD
   Chapter 8: Polynomial Factorization
...
   There's about 100 pages of material in that book, when you take out
   the exercises, etc.  You need it all.

 We'll see.  By the way, who did it?
For Maple, I believe Michael Monagan and Laurent Bernadin wrote a lot
of the main routines in use today.  But many other people have
contributed over a long period of time.  A lot of old code has been
replaced, and the full list of contributors would have at least 20
people on it.

 Does *any* program doing
 multivariate polynomial gcd and factorization well except Magma?

Yes, Maple and Mathematica.  It's not just factoring over Z either.
You will eventually want to factor over algebraic number fields and
function fields.  Factoring and GCDs are a huge problem and getting
them implemented is a significant accomplishment.  You will also need
resultants, probably.

 By the way, the book you suggest above was published in 1992.
 Allan Steel implemented all the fast gcd/factoring code in Magma
 many years later. It's perhaps highly likely he made great progress over
 what's in that book.

The book describes the basic core approach which everyone needs to
understand.  People like Allan Steel work on these algorithms over and
over and develop deep insight into them.  That's how you make
fundamental improvements.  Often an improvement will be something
simple, but thinking of it and understanding why it works is the
product of a massive amount of experience and expertise.  People can't
just go and get that out of a book.  You have to be fully immersed in
the problem to understand what is going on.

I am not an expert in this area, but if I had to write this thing I
would start with that book.  You can work through all the algorithms
carefully.  A careful choice of data structures and pre-existing
routines would produce a first version that works.  It wouldn't be
great, but it would get Sage out of a rut.  Then you go back and try
again, with better data structures and better routines and a little
more insight.  By the third version or so, you can make fundamental
improvements.  There are many, many things you can do.  It's a whole
area of computer algebra.  The best strategy is to find a student who
is interested in factorization.  Sage has some nice libraries (fast
GMP, FLINT) and a nice programming language that can be compiled.   So
there is the potential here to write fast code.  But getting the
algorithms right is a big commitment, say 1-2 months for a first
version (using pre-existing routines) and 2-4 months for each version
after that (when you're rewriting things from scratch).  It could be
longer, depending on how it goes.

 I'm curious -- have you actually implemented multivariate gcd and/or
 multivariate factorization?

During (most of) a course in computer algebra, I implemented the
algorithms on top of Maple.  Of course my code was garbage, but I
worked through the algorithms and got an appreciation for them.  It's
not a giant impossible task (unless you insist on beating Magma), but
it can't be done part-time either.  And you have to start by saying
our code might be slower on a lot of examples, but we're going to use
the right algorithms.  That's a difficult pill to swallow.  One big
leg up is that Sage already has good univariate factorization mod p
and over GF(p^q).  I suspect that in terms of code, there is not
really that much to write, but acquiring the necessary experience will
take time and a lot of effort.

One final piece of advice - you can't win by copying your
competitors.  So forget about what Magma does for now.  Magma may be
the fastest system out there, but I doubt it's the fastest system
*possible*.  Allan Steel surely knows there's no such thing as the
fastest code.  This is really true.
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] PolyBoRi Tutorial

[Michael Brickenstein]

Hi!
Suprise, there exists a tutorial for PolyBoRi.

http://polybori.sourceforge.net/doc/tutorial/index.html

It is available in tex-format under
doc/tutorial/tutorial.tex
in our source distribution.
  think it would be nice, to include it in the SAGE documentation in  
some way.
I started this discussion privately with Martin and Burcin and move it  
now to the list,
since it is a general problem about third party documentation.

This tutorial aims to introduce into the efficient use of PolyBoRi.

It is written for PolyBoRi 0.3.1 (using our Boost::python bindings,  
which are very similar).

We have seen two main options until now:
- leave the original documentation as it is and provide a link
- redoing them in a SAGE style

Of course, the first option will provide a good solution now (much  
better not including it for the next months).
However, if we really want to compete with the many M's, then this  
probably won't suffice.

So, what is the best way to include it in SAGE?

Am 31.03.2008 um 16:17 schrieb Burcin Erocal:
 Hello,

 On Mon, 31 Mar 2008 14:45:16 +0100
 Martin Albrecht [EMAIL PROTECTED] wrote:

 The least Sage should do is to explicitly state somewhere that one  
 can use
 PolyBoRi in `PolyBoRi-mode` from within Sage and link to the  
 tutorial.

 Sage does not install the real PolyBoRi wrappers, so the environment
 you get would be a pseudo PolyBoRi-mode. We can add support for
 anything that doesn't exist in Sage easily though.

 Whether the tutorial should be included in the Sage documentation  
 is probably
 something that should be escalated to [sage-devel] since this opens  
 the
 general question about `third-party documentation`. Michael, can  
 you ask on
 [sage-devel]?

 Btw. I don't really know how many people actually use the Sage  
 documentation,
 I wouldn't consider it very good (at least the reference manual is  
 pretty
 bad).

 Another idea could be to re-do the PolyBoRi tutorial in Sage style,  
 i.e.

 sage: B.x,y,z = BooleanPolynomialRing()

 ?

 I think this is what we should do eventually. If ever there is  
 time. :)


Good point.


 About M4RI: I plan to check your modifications and make a new  
 release soon-ish
 and I will probably work on Strassen during dev1, but I cannot  
 promise
 anything, I'm not really familiar with that one yet. Strassen +  
 M4RI should
 beat Magma's dense LA over GF(2).

 Cheers,
 Martin

 PS: If I find time next weekend I want to spend some time updating  
 Sage's
 PolyBoRi to 0.3.1


There is a new version for BoolePolynomial.h, which you should fetch  
from our sourceforge-CVS.


 Michael, maybe you can help with writing the doctests for the new
 functions in the PolyBoRi wrappers. As you know best how those
 functions, especially the nontrivial ones, should behave and as long  
 as
 the interface doesn't change, we'd be checking the correctness of
 PolyBoRi itself with the tests.


I can do so, tell me, where you need help.



Best regards,
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Computing the Weil-Pairing over Elliptic Curves in SAGE

[mabshoff]

On Apr 1, 12:46 pm, John Cremona [EMAIL PROTECTED] wrote:
 Sounds like a good idea, and certainly vastly better than my gp code
 which was really only a toy.

 I CC'ed this so sge-devel.

 John

 On 01/04/2008, Martin Albrecht [EMAIL PROTECTED] wrote:





   Hi there,

   let me (ab)use this opportunity to point to a library for doing these 
  things
   over finite fields (for crypto) I came across by chance.

     http://crypto.stanford.edu/pbc/

   PBC stands for Pairing-Based Cryptography and is a library for ... well ...
   pairings in cryptography (where everybody is pretty crazy about pairings
   these days). The focus seems to be 'industrial' applications rather than
   research (playing around).

   It is
    * GPL v3 (!)

I took a look at the sources and it really is GPL V3. The author made
the switch from 0.4.15 to 0.4.16. Maybe we could ask nicely for GPL V2
or V3. Looking at http://crypto.stanford.edu/pbc/links.html the author
is aware of Sage, so let's give it a try. The code is small, i.e.
0.5MB compressed and even has an MSVC port!

    * well documented: reference manual, tutorial, examples
    * small: 500k
    * used by a couple of applications
    * claimed to be fast: I have no idea how fast 'fast' should be though

   So if you care about pairings, it might be worth a look/wrap etc.

   Cheers,
   Martin

   PS: The PBC website links to Sage btw.

   --
   name: Martin Albrecht
   _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
   _www:http://www.informatik.uni-bremen.de/~malb
   _jab: [EMAIL PROTECTED]

 --
 John Cremona

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Crash in quo_rem

[mabshoff]

On Apr 1, 10:41 am, shreevatsa [EMAIL PROTECTED] wrote:
 Someone else was trying to do something, and I tried something and got
 a crash; mabshoff asked me to post a backtrace. (So if it is very
 long, don't blame me ;-))

 This is probably invalid mathematics that should raise an exception,
 but it causes a crash instead on my OS X 10.4. The other person also
 had this problem on Linux. mabshoff speculated it is a 32-bit/64-bit
 issue, since it raises an exception for him.

 Code:
 K.x=QQ['X']; p=EuclideanDomainElement(K);
 q=EuclideanDomainElement(K); (x^3+p*x+q).quo_rem(3*x^2+p)


SNIP

Note that it doesn't segfault with 2.11 on 64 bit:

sage: (x^3+p*x+q).quo_rem(3*x^2+p)
---
type 'exceptions.NotImplementedError'   Traceback (most recent call
last)

/scratch/mabshoff/release-cycle/sage-3.0.alpha0/ipython console in
module()

/scratch/mabshoff/release-cycle/sage-3.0.alpha0/element.pyx in
sage.structure.element.RingElement.__mul__()

/scratch/mabshoff/release-cycle/sage-3.0.alpha0/coerce.pxi in
sage.structure.element._mul_c()

/scratch/mabshoff/release-cycle/sage-3.0.alpha0/element.pyx in
sage.structure.element.ModuleElement._iadd_c_impl()

/scratch/mabshoff/release-cycle/sage-3.0.alpha0/element.pyx in
sage.structure.element.Element._richcmp_c_impl()

/scratch/mabshoff/release-cycle/sage-3.0.alpha0/element.pyx in
sage.structure.element.Element._cmp_c_impl()

type 'exceptions.NotImplementedError': BUG: sort algorithm for
elements of 'Univariate Polynomial Ring in X over Rational Field' not
implemented
sage:

So if somebody can reproduce this with a 32 bit build (on Linux or OSX
it seems) please open a ticket. Recently there have been a number of
issues that only hit us on 32 bits, so I would guess we need some more
testing on that platform. Maybe I should set up a 32 bit VMWare image
and run the whole doctest suite under valgrind on there. If anybody
wants to help out let me know.

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Crash in quo_rem

[shreevatsa]

Someone else was trying to do something, and I tried something and got
a crash; mabshoff asked me to post a backtrace. (So if it is very
long, don't blame me ;-))

This is probably invalid mathematics that should raise an exception,
but it causes a crash instead on my OS X 10.4. The other person also
had this problem on Linux. mabshoff speculated it is a 32-bit/64-bit
issue, since it raises an exception for him.

Code:
K.x=QQ['X']; p=EuclideanDomainElement(K);
q=EuclideanDomainElement(K); (x^3+p*x+q).quo_rem(3*x^2+p)

Backtrace:
{{{
--
| SAGE Version 2.10.3, Release Date: 2008-03-11  |
| Type notebook() for the GUI, and license() for information.|
--
/Applications/sage/local/bin/sage-gdb-pythonstartup
GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:16:54
GMT 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for
details.
This GDB was configured as i386-apple-darwin...Reading symbols for
shared libraries .. done

Reading symbols for shared libraries . done
[snipped]

--
| SAGE Version 2.10.3, Release Date: 2008-03-11  |
| Type notebook() for the GUI, and license() for information.|
--
sage:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x in ?? ()
(gdb) bt full
#0  0x in ?? ()
No symbol table info available.
#1  0x02b6fe98 in
__pyx_f_4sage_9structure_7element_13ModuleElement__sub_c_impl
(__pyx_v_left=0xb971690, __pyx_v_right=0xa7a1de0) at sage/structure/
element.c:5681
__pyx_r = (struct __pyx_obj_4sage_9structure_7element_ModuleElement
*) 0xb986030
__pyx_1 = (PyObject *) 0xb986030
__pyx_2 = (PyObject *) 0x0
#2  0x02b81fd3 in
__pyx_pf_4sage_9structure_7element_11RingElement___mul__
(__pyx_v_self=0xb971690, __pyx_v_right=0xa7a1de0) at sage/structure/
element.c:16691
__pyx_3 = (PyObject *) 0x0
__pyx_r = (PyObject *) 0x1
__pyx_1 = 1
__pyx_2 = (PyObject *) 0xb971690
#3  0x66cb in PyObject_Call (func=0xb971550, arg=0xb960b70,
kw=0x0) at Objects/abstract.c:1860
result = (PyObject *) 0x43bc71c
call = (ternaryfunc) 0x2bad440
__pyx_vtable_4sage_9structure_7element_Element
func = (PyObject *) 0x43bc720
#4  0x0004d930 in call_maybe (o=0xa7a1de0, name=0xde708 __rmul__,
nameobj=0x11aa20, format=0xe3618 (O)) at Objects/typeobject.c:967
va = 0xbfffc680 ê\026ó\vp\vñ\vp\vñ\v®ó\v‡\035z\n0PP
args = (PyObject *) 0xb960b70
func = (PyObject *) 0xb971550
retval = (PyObject *) 0x43bc71c
nameobj = (PyObject **) 0x43bc71c
#5  0x0004f275 in slot_nb_multiply (self=0xb971690, other=0xa7a1de0)
at Objects/typeobject.c:4312
cache_str = (PyObject *) 0x505080
rcache_str = (PyObject *) 0x5050a0
do_other = 1
#6  0x5fe0 in binary_op1 (v=0xb971690, w=0xa7a1de0, op_slot=8) at
Objects/abstract.c:392
x = (PyObject *) 0x4f1e8
slotv = (binaryfunc) 0x2b81b77
__pyx_pf_4sage_9structure_7element_11RingElement___mul__
slotw = (binaryfunc) 0x4f1e8 slot_nb_multiply
#7  0x8a0b in PyNumber_Multiply (v=0xb971690, w=0xa7a1de0) at
Objects/abstract.c:669
result = (PyObject *) 0xb971690
v = (PyObject *) 0xb971690
w = (PyObject *) 0xa7a1de0
#8  0x0006d410 in PyEval_EvalFrameEx (f=0xba20760, throwflag=0) at
Python/ceval.c:1072
stack_pointer = (PyObject **) 0xba20750
next_instr = (unsigned char *) 0xb91fb32 \027e\a
opcode = 194451088
oparg = 0
why = WHY_NOT
err = 0
x = (PyObject *) 0x1631c80
v = (PyObject *) 0xb971690
w = (PyObject *) 0xb971690
u = (PyObject *) 0xb971690
t = (PyObject *) 0xb971690
stream = (PyObject *) 0x16264b0
fastlocals = (PyObject **) 0xba20898
freevars = (PyObject **) 0xba20898
retval = (PyObject *) 0x0
tstate = (PyThreadState *) 0x600170
co = (PyCodeObject *) 0xb96f140
instr_ub = -1
instr_lb = 0
instr_prev = -1
first_instr = (unsigned char *) 0xb91fae4 e
names = (PyObject *) 0xb9841b0
consts = (PyObject *) 0xb917a80
#9  0x00070b8e in PyEval_EvalCodeEx (co=0xb96f140, globals=0xb965e40,
locals=0xb965e40, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2831
f = (PyFrameObject *) 0xba20760
retval = (PyObject *) 0x0

[sage-devel] Fwd: [Maxima] Maxima 5.15 release branch scheduled for April 5

[David Joyner]

FYI


-- Forwarded message --
From: Robert Dodier [EMAIL PROTECTED]
Date: Tue, Apr 1, 2008 at 12:34 AM
Subject: [Maxima] Maxima 5.15 release branch scheduled for April 5
To: Maxima List [EMAIL PROTECTED]


Hello,

 I am planning to make the 5.15 release branch on April 5
 (probably circa 12h--18h UTC).

 Keeping the world informed

 Robert Dodier
 ___
 Maxima mailing list
 [EMAIL PROTECTED]
 http://www.math.utexas.edu/mailman/listinfo/maxima

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: multivariate factoring - use maxima ?

[mabshoff]

On Apr 1, 8:58 am, root [EMAIL PROTECTED] wrote:
 Michael Abshoff made that comment.  He's motivated by wanting
 to port Sage to a wide range of architectures and keep everything
 maintainable, since he works incredibly hard on that.   He suffers
 a huge amount trying to deal with build issues on various platforms
 such as solaris, Linux PPC, etc.  I'm sure you understand well
 how hard building complicated math software is on a range of platforms!

 I understand. I have ported Axiom from Maclisp/VMLisp on mainframes to
 workstations to PCs under a dozen lisps and a dozen opsys versions,
 including Dos so I understand his pain. In fact, I think that porting
 Sage is going to absorb a very large portion of your available time
 and energy.  The port to the next version of Python should be fun.

To make my comment somewhat clearer: I did not mean the removal of
lisp based code in Sage in general, but from the supported, standard
components. I.e. having interfaces to Maxima, Axiom [or FriCAS or
OpenAxiom] is desirable, but I do not believe those should be in the
core of Sage. If one person is willing to maintain an interface and an
optional spkg for $CAS Sage should support that. But it is quite
different to make it a core component since that requires build
support and also the ability on our end to potentially fix things. So
far there is insufficient expertise to deal with code in Axiom or
Maxima IMHO.

 Trust me, you're underpaying Michael :-)

Thanks. I am aware of that fact. Indeed, I walked away from a
financially potentially much more lucrative project. So: What is my
motivation to work for Sage? It is fun and as long as I can pay my
bills I will always chose the more fun project. Another aspect is also
that decisions are made on technical merit and in the open. One of the
reasons I have walked away from the last two jobs I help was precisely
because my technical recommendations were ignore.

 Tim Daly
 Axiom

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: multivariate factoring - use maxima ?

[Bill Hart]

Roman, I thoroughly agree with you that the multipolygcd and factoring
problem is not going to go away overnight. I'm sure by your comments
that you can guess what we've been doing with FLINT for univariate gcd
and how long even that is taking.

Also, I too get frustrated by some of the simple-minded comments that
get made about this problem. I also get tired of posting about the
information available about what Magma does for GCD and factoring and
about the various papers available on this subject. But, this is
partly my own fault, since Mike Hanson set up a webpage to blog
everything we know about the subject in order to come up with a
strategy for dealing with this problem, and I've been too lazy (or
busy) to put my notes on there.

But let me say from off-list discussions with Joel Mohler that I think
he just might be going to prove us all wrong. There just might be a
simple set of algorithms which give the answer almost all the time
quickly (if you are comparing to Magma) for multipoly factoring. So
I'm not ready to make a call on this one. I'm not saying I'm off to
the local book maker to place money on Joel's approach, but simply
that he's already proved me wrong on a number of points of
established wisdom and his overall plan looks very promising.

But having said that, there is no *single* algorithm which will always
work quickly.

There have also been some recent improvements in algorithms which will
take much of the hard work out of this problem. This is an advantage
that people in the past didn't have. It pains me to admit it, but
possibly doing things properly by going through all the really hard
work that people have done in the past, just may not be necessary any
more. How sad, because I was looking forward to this challenge! But
we'll see.

Regarding probabilistic algorithms, we need to be careful to
distinguish Las Vegas algorithms from Monte Carlo algorithms (you can
check wikipedia for what I am taking as my definitions). Victor Shoup
actually implements both in NTL, but one kind of probabilistic
algorithm is perfectly fine for inclusion in SAGE so long as early
bailout is implemented (something SINGULAR is guilty of not doing).The
other kind of probabilistic algorithm is fine too, if proper checks of
correctness are made and if there is a fallback to another algorithm
if the checks fail. I essentially do this in FLINT for GCD at one
point, due to a comment of Allan Steel on the Magma website and the
result is something like a 100 times speedup in getting the correct
answer. At one point, what I do in FLINT is asymptotically (and
practically much) faster than what Pari does because of this simple
observation.

By the way, it turns out that a single algorithm is sufficient to beat
Magma at univariate GCD over ZZ. But at the very least one can
actually be asymptotically faster (in increasing size of
coefficients), so why stop there! Let's plan to eventually look well
past Magma.

Bill.

On 1 Apr, 07:50, Roman Pearce [EMAIL PROTECTED] wrote:
 On Mar 31, 10:55 pm, William Stein [EMAIL PROTECTED] wrote:

  On Mon, Mar 31, 2008 at 6:48 PM, Roman Pearce [EMAIL PROTECTED] wrote:

    You need Algorithms for Computer Algebra by Geddes, Czapor, and
    Labahn:
    Chapter 5: Chinese Remainder Theorem
    Chapter 6: Newton's Iteration and Hensel Lifting
    Chapter 7: Polynomial GCD
    Chapter 8: Polynomial Factorization
 ...
    There's about 100 pages of material in that book, when you take out
    the exercises, etc.  You need it all.
  We'll see.  By the way, who did it?

 For Maple, I believe Michael Monagan and Laurent Bernadin wrote a lot
 of the main routines in use today.  But many other people have
 contributed over a long period of time.  A lot of old code has been
 replaced, and the full list of contributors would have at least 20
 people on it.

  Does *any* program doing
  multivariate polynomial gcd and factorization well except Magma?

 Yes, Maple and Mathematica.  It's not just factoring over Z either.
 You will eventually want to factor over algebraic number fields and
 function fields.  Factoring and GCDs are a huge problem and getting
 them implemented is a significant accomplishment.  You will also need
 resultants, probably.

  By the way, the book you suggest above was published in 1992.
  Allan Steel implemented all the fast gcd/factoring code in Magma
  many years later. It's perhaps highly likely he made great progress over
  what's in that book.

 The book describes the basic core approach which everyone needs to
 understand.  People like Allan Steel work on these algorithms over and
 over and develop deep insight into them.  That's how you make
 fundamental improvements.  Often an improvement will be something
 simple, but thinking of it and understanding why it works is the
 product of a massive amount of experience and expertise.  People can't
 just go and get that out of a book.  You have to be fully immersed in
 the problem to understand what is going on.

 I am 

[sage-devel] Re: multivariate factoring - use maxima ?

[Bill Hart]

On 1 Apr, 05:21, Mike Hansen [EMAIL PROTECTED] wrote:
 I've posted some benchmarks 
 athttp://wiki.sagemath.org/MultivariateGCDBenchmarks.

 --Mike

I can't do timings for the degree 1000 or 2000 (at least Allan Steel
gives it as degree 2000, whereas your page Mike seems to say it is
degree 1), since FLINT doesn't have the asymptotically fast half
gcd implemented yet for polynomials over Z/pZ, which is a prerequisite
for fast times for these problems.

But for the degree 100 problem I can give a rough preliminary timing.
FLINT computes it in 0.0008949s. Magma currently takes 0.0008300s. So
I guess that is about 24 times faster than ezgcd and 30 times faster
than modular and 200 times faster than Maxima and 2000 times faster
than NTL (or is it Pari? - I don't know what the (univariate) timing
means).

FLINT will be at least 50% faster by the time I'm done with this
function. It's not even properly tuned yet!

Bill.




--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: PolyBoRi Tutorial

[David Joyner]

On Tue, Apr 1, 2008 at 3:39 AM, Michael Brickenstein
[EMAIL PROTECTED] wrote:

  Hi!
  Suprise, there exists a tutorial for PolyBoRi.

  http://polybori.sourceforge.net/doc/tutorial/index.html

  It is available in tex-format under
  doc/tutorial/tutorial.tex
  in our source distribution.
   think it would be nice, to include it in the SAGE documentation in
  some way.
  I started this discussion privately with Martin and Burcin and move it
  now to the list,
  since it is a general problem about third party documentation.

  This tutorial aims to introduce into the efficient use of PolyBoRi.

  It is written for PolyBoRi 0.3.1 (using our Boost::python bindings,
  which are very similar).

  We have seen two main options until now:
  - leave the original documentation as it is and provide a link
  - redoing them in a SAGE style

  Of course, the first option will provide a good solution now (much
  better not including it for the next months).
  However, if we really want to compete with the many M's, then this
  probably won't suffice.

  So, what is the best way to include it in SAGE?

One optionis to include it in the optional package extra_docs-20070208.spkg
available from http://www.sagemath.org/packages/optional/
(To install, just type sage -i extra_docs-20070208, provided you
have an internet connection.) If you make a new package, you have to change
20070208 to the current date of course.



  Am 31.03.2008 um 16:17 schrieb Burcin Erocal:
   Hello,
  
   On Mon, 31 Mar 2008 14:45:16 +0100
   Martin Albrecht [EMAIL PROTECTED] wrote:
  
   The least Sage should do is to explicitly state somewhere that one
   can use
   PolyBoRi in `PolyBoRi-mode` from within Sage and link to the
   tutorial.
  
   Sage does not install the real PolyBoRi wrappers, so the environment
   you get would be a pseudo PolyBoRi-mode. We can add support for
   anything that doesn't exist in Sage easily though.
  
   Whether the tutorial should be included in the Sage documentation
   is probably
   something that should be escalated to [sage-devel] since this opens
   the
   general question about `third-party documentation`. Michael, can
   you ask on
   [sage-devel]?
  
   Btw. I don't really know how many people actually use the Sage
   documentation,
   I wouldn't consider it very good (at least the reference manual is
   pretty
   bad).
  
   Another idea could be to re-do the PolyBoRi tutorial in Sage style,
   i.e.
  
   sage: B.x,y,z = BooleanPolynomialRing()
  
   ?
  
   I think this is what we should do eventually. If ever there is
   time. :)
  

  Good point.


   About M4RI: I plan to check your modifications and make a new
   release soon-ish
   and I will probably work on Strassen during dev1, but I cannot
   promise
   anything, I'm not really familiar with that one yet. Strassen +
   M4RI should
   beat Magma's dense LA over GF(2).
  
   Cheers,
   Martin
  
   PS: If I find time next weekend I want to spend some time updating
   Sage's
   PolyBoRi to 0.3.1
  

  There is a new version for BoolePolynomial.h, which you should fetch
  from our sourceforge-CVS.


   Michael, maybe you can help with writing the doctests for the new
   functions in the PolyBoRi wrappers. As you know best how those
   functions, especially the nontrivial ones, should behave and as long
   as
   the interface doesn't change, we'd be checking the correctness of
   PolyBoRi itself with the tests.
  

  I can do so, tell me, where you need help.

  

  Best regards,
  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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-2.11 is out!

[bill.p]

On Apr 1, 9:54 am, bill purvis [EMAIL PROTECTED] wrote:
 On Mar 30, 2008, at 19:37 , William Stein wrote: Hello folks,

  Sage 2.11 has been released on March 30th, 2008. It is available at

   http://sagemath.org/download.html

 Built on my poor little laptop. Toshiba - 2.9GHz Celeron, 512MB RAM.
 Still having some problems with the evaluate link in notebook.
 Works more reliably than 2.10, but still hangs when I first open the
 worksheet. So far I've not had it fail until I closed and re-opened
 the worksheet.

Have now run make test and only the dsage problem reported:

   The following tests failed:


sage -t  devel/sage-main/sage/dsage/tests/testdoc.py
   Total time for all tests: 5784.5 seconds
   grep: .test-dsage.log: No such file or directory

This Ubuntu 7.10(Gutsy) on a Toshiba laptop, with Celeron 2.9GHz cpu.

Bill
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-2.11 is out!

[bill purvis]

On Mar 30, 2008, at 19:37 , William Stein wrote:
 Hello folks,

 Sage 2.11 has been released on March 30th, 2008. It is available at

   http://sagemath.org/download.html

Built on my poor little laptop. Toshiba - 2.9GHz Celeron, 512MB RAM.
Still having some problems with the evaluate link in notebook.
Works more reliably than 2.10, but still hangs when I first open the 
worksheet. So far I've not had it fail until I closed and re-opened
the worksheet.

Bill
-- 
+---+
| Bill Purvis, Amateur Mathematician|
|  email: [EMAIL PROTECTED]  |
|  http://bil.members.beeb.net  |
+---+

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Fighting Spam in the wiki

[mabshoff]

Hi,

if you look at

http://wiki.sagemath.org/RecentChanges?max_days=14

you will see once again some idiot spammers creating crap pages in the
wiki. While we aren't too badly effected by Spam I think it has gotten
worst over time. So what should we do?

a) The wiki has a Spam detection system, but currently we cannot
declare pages as Spam (I think only robertwb and wstein, i.e. people
with admin power can). So I would suggest to add various people who
watch the wiki (mhansen, tclemans, mhampton, mabshoff and others who
would like to) to the  admin group.

b) install a Captcha. This can be done together with (a)

c) Just like trac hand out account to the wiki only on demand and
delete the old spammer accounts. moin moin wiki doesn't really have an
elegant way to disable account creation without poking around in the
internals, so if you know a elegant way please enlighten me.

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fighting Spam in the wiki

[mabshoff]

On Apr 1, 2:57 pm, Harald Schilly [EMAIL PROTECTED] wrote:
  b) install a Captcha.

 +1

 this one is good and usefulhttp://recaptcha.net/



  c) Just like trac hand out account[s] ...

 -1

Yeah. I forgot to mention that I consider this as a last resort type
of solution after (a) and (b) have failed.

 I think that's not a good idea, because you are cutting off the long
 tail of random but useful contributions. e.g. things for the
 interact example page or similar. having to mail others about small
 errors or additions is a high barrier and would hinder them to
 contribute.

 harald

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Crash in quo_rem

[David Harvey]

On Apr 1, 2008, at 4:53 AM, mabshoff wrote:

 On Apr 1, 10:41 am, shreevatsa [EMAIL PROTECTED] wrote:
 Someone else was trying to do something, and I tried something and  
 got
 a crash; mabshoff asked me to post a backtrace. (So if it is very
 long, don't blame me ;-))

 This is probably invalid mathematics that should raise an exception,
 but it causes a crash instead on my OS X 10.4. The other person also
 had this problem on Linux. mabshoff speculated it is a 32-bit/64-bit
 issue, since it raises an exception for him.

 Code:
 K.x=QQ['X']; p=EuclideanDomainElement(K);
 q=EuclideanDomainElement(K); (x^3+p*x+q).quo_rem(3*x^2+p)

Wait a second

if I type

sage: K.x = QQ['X']
sage: p = EuclideanDomainElement(K)

what is this supposed to even mean? What is p supposed to be here? I get

sage: p
  Generic element of a structure

I think the __init__ call gets redirected to Element.__init__, which  
just sets the parent. In my opinion, this constructor call should be  
disallowed somehow. Unless there's something about the new coercion  
model that I don't know.

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-2.11 is out!

[philt]

Hi,

I downloaded sage-2.11.tar and did make on 2 machines, both 64-bit
Debian.
One went fine, make test is still running but seems ok.

The other make failed

install log: http://www.yobi.be/files/install.log.bz2 (300k)

tail:

config.status: creating Makefile
config.status: executing depfiles commands
make[2]: Entering directory `/opt/sage-2.11/spkg/build/
linbox-1.1.5rc2.p6/linbox_wrap'
/bin/sh ./libtool --tag=CXX   --mode=compile g++ -DPACKAGE_NAME=
\liblinboxwrap\ -DPACKAGE_TARNAME=\liblinboxwrap\ -
DPACKAGE_VERSION=\0.0.1\ -DPACKAGE_STRING=\liblinboxwrap\ 0.0.1\ -
DPACKAGE_BUGREPORT=\\ -DPACKAGE=\liblinboxwrap\ -DVERSION=
\0.0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -
DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -
DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I.   -g -I/opt/
sage-2.11/local/include/linbox -I/opt/sage-2.11/local/include  -g -
fPIC -I/opt/sage-2.11/local/include -I/opt/sage-2.11/local/include/
linbox  -L/opt/sage-2.11/local/lib -MT linbox_wrap.lo -MD -MP -
MF .deps/linbox_wrap.Tpo -c -o linbox_wrap.lo `test -f 'src/
linbox_wrap.cpp' || echo './'`src/linbox_wrap.cpp
mkdir .libs
 g++ -DPACKAGE_NAME=\liblinboxwrap\ -DPACKAGE_TARNAME=\liblinboxwrap
\ -DPACKAGE_VERSION=\0.0.1\ -DPACKAGE_STRING=\liblinboxwrap
0.0.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\liblinboxwrap\ -
DVERSION=\0.0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -
I. -g -I/opt/sage-2.11/local/include/linbox -I/opt/sage-2.11/local/
include -g -fPIC -I/opt/sage-2.11/local/include -I/opt/sage-2.11/local/
include/linbox -L/opt/sage-2.11/local/lib -MT linbox_wrap.lo -MD -MP -
MF .deps/linbox_wrap.Tpo -c src/linbox_wrap.cpp  -fPIC -DPIC -o .libs/
linbox_wrap.o
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
URL:file:///usr/share/doc/gcc-4.1/README.Bugs.

make[2]: *** [linbox_wrap.lo] Error 1
make[2]: Leaving directory `/opt/sage-2.11/spkg/build/
linbox-1.1.5rc2.p6/linbox_wrap'
Error building linboxwrap
make[2]: Entering directory `/opt/sage-2.11/spkg/build/
linbox-1.1.5rc2.p6/linbox_wrap'
/bin/sh ./libtool --tag=CXX   --mode=compile g++ -DPACKAGE_NAME=
\liblinboxwrap\ -DPACKAGE_TARNAME=\liblinboxwrap\ -
DPACKAGE_VERSION=\0.0.1\ -DPACKAGE_STRING=\liblinboxwrap\ 0.0.1\ -
DPACKAGE_BUGREPORT=\\ -DPACKAGE=\liblinboxwrap\ -DVERSION=
\0.0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -
DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -
DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -I.   -g -I/opt/
sage-2.11/local/include/linbox -I/opt/sage-2.11/local/include  -g -
fPIC -I/opt/sage-2.11/local/include -I/opt/sage-2.11/local/include/
linbox  -L/opt/sage-2.11/local/lib -MT linbox_wrap.lo -MD -MP -
MF .deps/linbox_wrap.Tpo -c -o linbox_wrap.lo `test -f 'src/
linbox_wrap.cpp' || echo './'`src/linbox_wrap.cpp
 g++ -DPACKAGE_NAME=\liblinboxwrap\ -DPACKAGE_TARNAME=\liblinboxwrap
\ -DPACKAGE_VERSION=\0.0.1\ -DPACKAGE_STRING=\liblinboxwrap
0.0.1\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\liblinboxwrap\ -
DVERSION=\0.0.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -
DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -
I. -g -I/opt/sage-2.11/local/include/linbox -I/opt/sage-2.11/local/
include -g -fPIC -I/opt/sage-2.11/local/include -I/opt/sage-2.11/local/
include/linbox -L/opt/sage-2.11/local/lib -MT linbox_wrap.lo -MD -MP -
MF .deps/linbox_wrap.Tpo -c src/linbox_wrap.cpp  -fPIC -DPIC -o .libs/
linbox_wrap.o
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
URL:file:///usr/share/doc/gcc-4.1/README.Bugs.

make[2]: *** [linbox_wrap.lo] Error 1
make[2]: Leaving directory `/opt/sage-2.11/spkg/build/
linbox-1.1.5rc2.p6/linbox_wrap'
Error installing linboxwrap

real1m21.351s
user0m57.540s
sys 0m18.281s
sage: An error occurred while installing linbox-1.1.5rc2.p6
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /opt/sage-2.11/install.log.  Describe your computer, operating
system, etc.
If you want to try to fix the problem, yourself *don't* just cd to
/opt/sage-2.11/spkg/build/linbox-1.1.5rc2.p6 and type 'make'.
Instead type /opt/sage-2.11/sage -sh
in order to set all environment variables correctly, then cd to
/opt/sage-2.11/spkg/build/linbox-1.1.5rc2.p6
(When you are done debugging, you can type exit to leave the

[sage-devel] Re: sage-2.11 is out!

[mabshoff]

On Apr 1, 5:42 pm, philt [EMAIL PROTECTED] wrote:
 Hi,

 I downloaded sage-2.11.tar and did make on 2 machines, both 64-bit
 Debian.
 One went fine, make test is still running but seems ok.

 The other make failed

 install log:http://www.yobi.be/files/install.log.bz2(300k)


SNIP

You g++ decided it didn't like LinBox: g++: Internal error: Killed.
This is somewhat surprising since we are using the exact [and I mean
identical to the last bit] same gcc release as you do.

Thoughts?

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-2.11 is out!

[William Stein]

On Tue, Apr 1, 2008 at 8:52 AM, mabshoff
[EMAIL PROTECTED] wrote:



  On Apr 1, 5:42 pm, philt [EMAIL PROTECTED] wrote:
   Hi,
  
   I downloaded sage-2.11.tar and did make on 2 machines, both 64-bit
   Debian.
   One went fine, make test is still running but seems ok.
  
   The other make failed
  
   install log:http://www.yobi.be/files/install.log.bz2(300k)


  SNIP

  You g++ decided it didn't like LinBox: g++: Internal error: Killed.
  This is somewhat surprising since we are using the exact [and I mean
  identical to the last bit] same gcc release as you do.

  Thoughts?

I wonder if he has enough RAM?   Maybe gcc does dumb things
when there isn't enough ram sometimes.

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] sage lite

[Ondrej Certik]

Hi,

Sage motivation is to create a viable alternative to Ma*.

There are also people, who don't need an alternative to Ma*, but
rather a good library, read for example this email from Gael:

http://groups.google.com/group/sympy/msg/f8f497d1d32fab30

who works on Mayavi2 (yet we have paraview3, that imho is more mature,
but it's a beast).

What are your opinions - can Sage become (in a year, or two) in
something like Gael (and me) want?

Basically, I think we need a modular calculus package, that interacts
well with other python scientific packages.

Ondrej

P.S. I am looking forward to Garry's calculus patch. :)

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-2.11 is out!

[mabshoff]

On Apr 1, 5:57 pm, William Stein [EMAIL PROTECTED] wrote:
 On Tue, Apr 1, 2008 at 8:52 AM, mabshoff



 [EMAIL PROTECTED] wrote:

   On Apr 1, 5:42 pm, philt [EMAIL PROTECTED] wrote:
    Hi,

    I downloaded sage-2.11.tar and did make on 2 machines, both 64-bit
    Debian.
    One went fine, make test is still running but seems ok.

    The other make failed

    install log:http://www.yobi.be/files/install.log.bz2(300k)

   SNIP

   You g++ decided it didn't like LinBox: g++: Internal error: Killed.
   This is somewhat surprising since we are using the exact [and I mean
   identical to the last bit] same gcc release as you do.

   Thoughts?

 I wonder if he has enough RAM?   Maybe gcc does dumb things
 when there isn't enough ram sometimes.

Well, I would assume that the OOM killer might do something stupid. If
malloc fails inside gcc I would expect it to die gracefully. Maybe
Phil should check /var/log/messages for any signs of the OOM killer.

 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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage-2.11 is out!

[philt]

  I wonder if he has enough RAM?   Maybe gcc does dumb things
  when there isn't enough ram sometimes.

 Well, I would assume that the OOM killer might do something stupid. If
 malloc fails inside gcc I would expect it to die gracefully. Maybe
 Phil should check /var/log/messages for any signs of the OOM killer.

Indeed, thanks for the tips.
Both machines were vservers with 1Gb RAM and both were running the
Sage 2.10.3 notebook during the compilation, so apparently one of the
notebook was more hungry.
I stopped the notebook and now it seems to compile fine (but still
running for probably a couple of hours...).

BTW the make test finished on the first machine with an all
passed, good job! ;-)

Phil
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Gary Furnish]

Right now pulling in group theory may end up pulling in calculus.  There are
similar issues all over with really tight coupling between subsystems.  It
ought to be possible to use group theory (maybe without a feature or two)
without calculus and vice versa.

On Tue, Apr 1, 2008 at 11:33 AM, Nick Alexander [EMAIL PROTECTED]
wrote:



 On 1-Apr-08, at 10:21 AM, Gary Furnish wrote:

  Maybe.  I see two real issues.
  1) Sage right now has really bad global namespace pollution issues
  that make it very hard to import just one or two files.  I don't
  see why this shouldn't be fixable, it just needs someone to work on
  it.  This would not be that hard, and would probably catch some
  subtle import bugs in the process.

 Warning: I'm not expert in this area.  AFAICT, the Sage library
 itself exports nothing globally -- it's all in a startup line similar
 to from sage.all_cmdline import *.  You might be talking about
 another scenario, though.

 Nick

 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Gary Furnish]

Maybe.  I see two real issues.
1) Sage right now has really bad global namespace pollution issues that make
it very hard to import just one or two files.  I don't see why this
shouldn't be fixable, it just needs someone to work on it.  This would not
be that hard, and would probably catch some subtle import bugs in the
process.

2) Every cython file compiles to an separate dll, dramatically increasing
used space.  This would require a change to cython to fix, but ought to be
doable.  Maybe space is not as big of an issue as ease of use though.

The main dependency of the calculus package right now is on ZZ and RR.  If
an alternate integer and real ring was provided with no external
dependencies, it could be easily modified to use them.  Maybe including gmp
isn't an issue for you, however.  This is not something I am opposed to
doing (as it is simple to implement) but I don't want to do the work (to
create dependency free rings) myself.  If I was provided such rings, I would
have no problem adding an option for my calculus system to use them.

In short, if there was real interest and this, and someone (you?) wanted to
help with it, I'd get behind the idea very quickly.  I would very much like
to see the sage.symbolics package useable without importing all of Sage.

On Tue, Apr 1, 2008 at 10:30 AM, Ondrej Certik [EMAIL PROTECTED] wrote:


 Hi,

 Sage motivation is to create a viable alternative to Ma*.

 There are also people, who don't need an alternative to Ma*, but
 rather a good library, read for example this email from Gael:

 http://groups.google.com/group/sympy/msg/f8f497d1d32fab30

 who works on Mayavi2 (yet we have paraview3, that imho is more mature,
 but it's a beast).

 What are your opinions - can Sage become (in a year, or two) in
 something like Gael (and me) want?

 Basically, I think we need a modular calculus package, that interacts
 well with other python scientific packages.

 Ondrej

 P.S. I am looking forward to Garry's calculus patch. :)

 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Nick Alexander]

On 1-Apr-08, at 10:36 AM, Gary Furnish wrote:

 Right now pulling in group theory may end up pulling in calculus.   
 There are similar issues all over with really tight coupling  
 between subsystems.  It ought to be possible to use group theory  
 (maybe without a feature or two) without calculus and vice versa.

This isn't really a global namespace pollution issue, but it is a  
concern.  One way to deal with this is to make (more) imports  
function or class local.  I'm not sure if there are performance  
penalties for this, especially in Cython.  Can anyone say?

Nick

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Nick Alexander]

On 1-Apr-08, at 10:21 AM, Gary Furnish wrote:

 Maybe.  I see two real issues.
 1) Sage right now has really bad global namespace pollution issues  
 that make it very hard to import just one or two files.  I don't  
 see why this shouldn't be fixable, it just needs someone to work on  
 it.  This would not be that hard, and would probably catch some  
 subtle import bugs in the process.

Warning: I'm not expert in this area.  AFAICT, the Sage library  
itself exports nothing globally -- it's all in a startup line similar  
to from sage.all_cmdline import *.  You might be talking about  
another scenario, though.

Nick

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[William Stein]

On Tue, Apr 1, 2008 at 9:30 AM, Ondrej Certik [EMAIL PROTECTED] wrote:

  Hi,

  Sage motivation is to create a viable alternative to Ma*.

  There are also people, who don't need an alternative to Ma*, but
  rather a good library, read for example this email from Gael:

  http://groups.google.com/group/sympy/msg/f8f497d1d32fab30

  who works on Mayavi2 (yet we have paraview3, that imho is more mature,
  but it's a beast).

  What are your opinions - can Sage become (in a year, or two) in
  something like Gael (and me) want?

I very much hope and strongly encourage that technology
developed in the context of Sage will turn into the sorts of thing you
want, even if that isn't the current stated aim of the Sage project.
For example, the great work Tim Abbot has done on debianization
of Sage helps a huge amount and I'm extremely supportive of that.
And I strongly agree with Gary Furnish's answer to your email above.

William


  Basically, I think we need a modular calculus package, that interacts
  well with other python scientific packages.

  Ondrej

  P.S. I am looking forward to Garry's calculus patch. :)

  




-- 
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fighting Spam in the wiki

[Robert Bradshaw]

On Apr 1, 2008, at 5:43 AM, mabshoff wrote:

 Hi,

 if you look at

 http://wiki.sagemath.org/RecentChanges?max_days=14

 you will see once again some idiot spammers creating crap pages in the
 wiki. While we aren't too badly effected by Spam I think it has gotten
 worst over time. So what should we do?

 a) The wiki has a Spam detection system, but currently we cannot
 declare pages as Spam (I think only robertwb and wstein, i.e. people
 with admin power can). So I would suggest to add various people who
 watch the wiki (mhansen, tclemans, mhampton, mabshoff and others who
 would like to) to the  admin group.

This seems like a good idea.

 b) install a Captcha. This can be done together with (a)

 c) Just like trac hand out account to the wiki only on demand and
 delete the old spammer accounts. moin moin wiki doesn't really have an
 elegant way to disable account creation without poking around in the
 internals, so if you know a elegant way please enlighten me.

(b) and especially (c) discourage content, and I don't think we have  
enough of a problem to worry about that right now, but we could go  
with (b) if things get works.

I added some words to http://wiki.sagemath.org/LocalBadContent . Now  
one can't talk about gold in the wiki, but it seems the vast majority  
of MoinMoin spammers (at least this was the case for the Cython wiki)  
are chinese gold farmers, so that alone cut a huge amount down.

What I would really like is a way to moderate new pages, i.e. if  
someone creates a *new* page it must be approved before getting  
accepted. This is by far the majority of spam.

- Robert


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Robert Bradshaw]

On Apr 1, 2008, at 10:45 AM, Nick Alexander wrote:

 On 1-Apr-08, at 10:36 AM, Gary Furnish wrote:

 Right now pulling in group theory may end up pulling in calculus.
 There are similar issues all over with really tight coupling
 between subsystems.  It ought to be possible to use group theory
 (maybe without a feature or two) without calculus and vice versa.

 This isn't really a global namespace pollution issue, but it is a
 concern.  One way to deal with this is to make (more) imports
 function or class local.  I'm not sure if there are performance
 penalties for this, especially in Cython.  Can anyone say?

Importing locally takes time, even if just to discover the cached  
import if it has already been done once. This is independent of  
whether or not the file is in Cython (though the relative overhead  
may be much greater for a Cythonized function).

The order in which things are imported is really, really crazy right  
now, as anyone trying to hunt down an (easy to trigger) circular  
references can attest to. It would be great if this could be cleaned  
up, both for developing Sage and for making things more modular so  
other projects can benefit from them.

- Robert


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Crash in quo_rem

[Robert Bradshaw]

On Apr 1, 2008, at 6:15 AM, David Harvey wrote:

 On Apr 1, 2008, at 4:53 AM, mabshoff wrote:

 On Apr 1, 10:41 am, shreevatsa [EMAIL PROTECTED] wrote:
 Someone else was trying to do something, and I tried something and
 got
 a crash; mabshoff asked me to post a backtrace. (So if it is very
 long, don't blame me ;-))

 This is probably invalid mathematics that should raise an exception,
 but it causes a crash instead on my OS X 10.4. The other person also
 had this problem on Linux. mabshoff speculated it is a 32-bit/64-bit
 issue, since it raises an exception for him.

 Code:
 K.x=QQ['X']; p=EuclideanDomainElement(K);
 q=EuclideanDomainElement(K); (x^3+p*x+q).quo_rem(3*x^2+p)

 Wait a second

 if I type

 sage: K.x = QQ['X']
 sage: p = EuclideanDomainElement(K)

 what is this supposed to even mean? What is p supposed to be here?  
 I get

 sage: p
   Generic element of a structure

 I think the __init__ call gets redirected to Element.__init__, which
 just sets the parent. In my opinion, this constructor call should be
 disallowed somehow. Unless there's something about the new coercion
 model that I don't know.

Yeah, this is totally nonsensical--no idea what it's trying to do  
here, but as a general principle we shouldn't crash on nonsense.

In the new coercion model all the empty classes like  
EuclideanDomainElement will go away (why is this in the global  
namespace) because categories will play a much larger role (and not  
be determined by inheritance). This is where abstract classes are good.

- Robert


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Carl Witty]

On Apr 1, 11:23 am, Robert Bradshaw [EMAIL PROTECTED]
wrote:
 On Apr 1, 2008, at 10:45 AM, Nick Alexander wrote:

  On 1-Apr-08, at 10:36 AM, Gary Furnish wrote:

  Right now pulling in group theory may end up pulling in calculus.
  There are similar issues all over with really tight coupling
  between subsystems.  It ought to be possible to use group theory
  (maybe without a feature or two) without calculus and vice versa.

  This isn't really a global namespace pollution issue, but it is a
  concern.  One way to deal with this is to make (more) imports
  function or class local.  I'm not sure if there are performance
  penalties for this, especially in Cython.  Can anyone say?

 Importing locally takes time, even if just to discover the cached
 import if it has already been done once. This is independent of
 whether or not the file is in Cython (though the relative overhead
 may be much greater for a Cythonized function).

For instance, see https://bugs.launchpad.net/cython/+bug/155076, where
I measure the cost of a local import as around 2 microseconds.

 The order in which things are imported is really, really crazy right
 now, as anyone trying to hunt down an (easy to trigger) circular
 references can attest to. It would be great if this could be cleaned
 up, both for developing Sage and for making things more modular so
 other projects can benefit from them.

Yes, this would be great!

It seems like it would be very difficult to fix, though.

Carl
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Crash in quo_rem

[John Cremona]

Is it safe for me to wait until 3.0 before learning what the new
coercion model actually is, or should I do that now if I want any new
functionality to be merged into 3.0?

John

On 01/04/2008, Robert Bradshaw [EMAIL PROTECTED] wrote:

  On Apr 1, 2008, at 6:15 AM, David Harvey wrote:

   On Apr 1, 2008, at 4:53 AM, mabshoff wrote:
  
   On Apr 1, 10:41 am, shreevatsa [EMAIL PROTECTED] wrote:
   Someone else was trying to do something, and I tried something and
   got
   a crash; mabshoff asked me to post a backtrace. (So if it is very
   long, don't blame me ;-))
  
   This is probably invalid mathematics that should raise an exception,
   but it causes a crash instead on my OS X 10.4. The other person also
   had this problem on Linux. mabshoff speculated it is a 32-bit/64-bit
   issue, since it raises an exception for him.
  
   Code:
   K.x=QQ['X']; p=EuclideanDomainElement(K);
   q=EuclideanDomainElement(K); (x^3+p*x+q).quo_rem(3*x^2+p)
  
   Wait a second
  
   if I type
  
   sage: K.x = QQ['X']
   sage: p = EuclideanDomainElement(K)
  
   what is this supposed to even mean? What is p supposed to be here?
   I get
  
   sage: p
 Generic element of a structure
  
   I think the __init__ call gets redirected to Element.__init__, which
   just sets the parent. In my opinion, this constructor call should be
   disallowed somehow. Unless there's something about the new coercion
   model that I don't know.


 Yeah, this is totally nonsensical--no idea what it's trying to do
  here, but as a general principle we shouldn't crash on nonsense.

  In the new coercion model all the empty classes like
  EuclideanDomainElement will go away (why is this in the global
  namespace) because categories will play a much larger role (and not
  be determined by inheritance). This is where abstract classes are good.


  - Robert



  


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Crash in quo_rem

[William Stein]

On Tue, Apr 1, 2008 at 12:46 PM, John Cremona [EMAIL PROTECTED] wrote:

  Is it safe for me to wait until 3.0 before learning what the new
  coercion model actually is, or should I do that now if I want any new
  functionality to be merged into 3.0?

Sage 3.0 will be released soon -- hopefully within two weeks.  It
will have *none* of the new coercion model code in it.Sage 3.0
will be a solid stable release that we will make when we meet
the following goals (which we have been pushing for for months):

* (nearly done) DOCTESTS: Raise the doctest coverage of the Sage
library to 50%.
* (done) INTERACT: Interactive versions of functions in the
notebook; kind of like Mathematica's Manipulate command.
* (nearly done) R: a pexpect R interface
* (status??) TIMING/BENCHMARK: Making it so doctesting Sage also
saves complete timing and profiling information. Start using and
publishing the results of this.
* (nearly done?) PORTING: OSX 10.5 64 bit , FreeBSD, PPC 64 bit
build support out of the box. Experimental 32 bit Solaris 10 build
support
* (nearly done) MODULAR ABELIAN VARIETIES: Implement Stein's
algorithms for computing with modular abelian varieties. This is very
*symbolic*, because Stein started the Sage project in the first place
specifically to implement these algorithms.

So Sage 3.0 is definitely not some sort of nebulous release off
in the distance.

 -- 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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Crash in quo_rem

[Robert Bradshaw]

On Apr 1, 2008, at 12:51 PM, William Stein wrote:

 On Tue, Apr 1, 2008 at 12:46 PM, John Cremona  
 [EMAIL PROTECTED] wrote:

  Is it safe for me to wait until 3.0 before learning what the new
  coercion model actually is, or should I do that now if I want  
 any new
  functionality to be merged into 3.0?

 Sage 3.0 will be released soon -- hopefully within two weeks.  It
 will have *none* of the new coercion model code in it.Sage 3.0
 will be a solid stable release that we will make when we meet
 the following goals (which we have been pushing for for months):

 * (nearly done) DOCTESTS: Raise the doctest coverage of the Sage
 library to 50%.
 * (done) INTERACT: Interactive versions of functions in the
 notebook; kind of like Mathematica's Manipulate command.
 * (nearly done) R: a pexpect R interface
 * (status??) TIMING/BENCHMARK: Making it so doctesting Sage also
 saves complete timing and profiling information. Start using and
 publishing the results of this.
 * (nearly done?) PORTING: OSX 10.5 64 bit , FreeBSD, PPC 64 bit
 build support out of the box. Experimental 32 bit Solaris 10 build
 support
 * (nearly done) MODULAR ABELIAN VARIETIES: Implement Stein's
 algorithms for computing with modular abelian varieties. This is very
 *symbolic*, because Stein started the Sage project in the first place
 specifically to implement these algorithms.

 So Sage 3.0 is definitely not some sort of nebulous release off
 in the distance.

Yes. We're making good progress on the new coercion model (David Roe  
and I were working on it last night, he finished Rings), but it is  
not 3.0 material (both for timing and stability reasons).

To find out what the new coercion model is see http:// 
wiki.sagemath.org/days7/coercion . It is orthogonal to most  
development but I think you in particular keep hearing a lot about it  
because it was created to address exactly the kinds of concerns and  
annoyances with Sage that you so often bring up :). Also, if someone  
proposes doing something that is a complete reduplication of work  
that either has been done (or is rendered unnecessary) by the  
coercion fixes I try and point that out.

- Robert


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Output Form versus Internal Structure

[root]

Robert,

I briefly looked over your coercion model.

_repr_ This is the easiest way to define how your object prints
   It should take a string representing your object
   I takes one argument, do_latex


I might comment that Axiom uses an output domain that exports functions
for constructing the print representation of its objects. This design
has made it possible for an object to print itself in various ways.

Over time Axiom has implemented many different output forms, such as
script (an IBM internal scripting language), algebra (the default 2D
ascii output), LaTeX, FORTRAN, and most recently MathML, used in the
new Firefox front end.

You might consider a design that allows the end user the option of
specifying the desired output form as decoupled from the object
structure.

Tim Daly
Axiom

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Gary Furnish]

Wierd circular import issues can (should) be solved with circular cdef
imports.  I think the easiest fix to crazy deps (group theory on calculus)
might be to do something alone the lines of
foo = None
def importcrazydeps():
import sage.foo as localfoo
foo = localfoo
Then have sage.x.package import all package modules and sage.x.all import
sage.package and then run importcrazydeps() on any function.
Perhaps another approach would be in Cython with an import optional foo
(does not throw an exception on failure).

On Tue, Apr 1, 2008 at 1:41 PM, Carl Witty [EMAIL PROTECTED] wrote:


 On Apr 1, 11:23 am, Robert Bradshaw [EMAIL PROTECTED]
 wrote:
  On Apr 1, 2008, at 10:45 AM, Nick Alexander wrote:
 
   On 1-Apr-08, at 10:36 AM, Gary Furnish wrote:
 
   Right now pulling in group theory may end up pulling in calculus.
   There are similar issues all over with really tight coupling
   between subsystems.  It ought to be possible to use group theory
   (maybe without a feature or two) without calculus and vice versa.
 
   This isn't really a global namespace pollution issue, but it is a
   concern.  One way to deal with this is to make (more) imports
   function or class local.  I'm not sure if there are performance
   penalties for this, especially in Cython.  Can anyone say?
 
  Importing locally takes time, even if just to discover the cached
  import if it has already been done once. This is independent of
  whether or not the file is in Cython (though the relative overhead
  may be much greater for a Cythonized function).

 For instance, see https://bugs.launchpad.net/cython/+bug/155076, where
 I measure the cost of a local import as around 2 microseconds.

  The order in which things are imported is really, really crazy right
  now, as anyone trying to hunt down an (easy to trigger) circular
  references can attest to. It would be great if this could be cleaned
  up, both for developing Sage and for making things more modular so
  other projects can benefit from them.

 Yes, this would be great!

 It seems like it would be very difficult to fix, though.

 Carl
 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Output Form versus Internal Structure

[Robert Bradshaw]

On Apr 1, 2008, at 2:33 PM, root wrote:

 Robert,

 I briefly looked over your coercion model.

 _repr_ This is the easiest way to define how your object prints
It should take a string representing your object
I takes one argument, do_latex


 I might comment that Axiom uses an output domain that exports  
 functions
 for constructing the print representation of its objects. This design
 has made it possible for an object to print itself in various ways.

 Over time Axiom has implemented many different output forms, such as
 script (an IBM internal scripting language), algebra (the default 2D
 ascii output), LaTeX, FORTRAN, and most recently MathML, used in the
 new Firefox front end.

 You might consider a design that allows the end user the option of
 specifying the desired output form as decoupled from the object
 structure.

Thanks for your input. We are considering a more advanced model  
(David Roe has lots of ideas on this front), but this falls outside  
of the central focus coercion scheme. (This is one reason to use  
_repr_ rather than the Python __repr__ so that the base object's  
__repr__ can do more sophisticated things (although now it just calls  
_repr_).

- Robert


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Output Form versus Internal Structure

[David Roe]

Separate from the coercion model, I have some ideas for changing where
printing code lives (see the section on printers at the bottom of
http://www.sagemath.org:9001/days7/coercion).  I agree that it should
be easy to implement output into other formats, and I'll keep that in
mind when I actually sit down to implement printer objects.
David

On Tue, Apr 1, 2008 at 2:33 PM, root [EMAIL PROTECTED] wrote:

  Robert,

  I briefly looked over your coercion model.

  _repr_ This is the easiest way to define how your object prints
It should take a string representing your object
I takes one argument, do_latex


  I might comment that Axiom uses an output domain that exports functions
  for constructing the print representation of its objects. This design
  has made it possible for an object to print itself in various ways.

  Over time Axiom has implemented many different output forms, such as
  script (an IBM internal scripting language), algebra (the default 2D
  ascii output), LaTeX, FORTRAN, and most recently MathML, used in the
  new Firefox front end.

  You might consider a design that allows the end user the option of
  specifying the desired output form as decoupled from the object
  structure.

  Tim Daly
  Axiom

  


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Robert Bradshaw]

On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote:
 Wierd circular import issues can (should) be solved with circular  
 cdef imports.  I think the easiest fix to crazy deps (group theory  
 on calculus) might be to do something alone the lines of
 foo = None
 def importcrazydeps():
 global foo
 import sage.foo as localfoo
 foo = localfoo
 Then have sage.x.package import all package modules and sage.x.all  
 import sage.package and then run importcrazydeps() on any function.

Yep, I think such things should be handled manually rather than  
adding special behavior and caching to import functions in Cython.  
Note that of you do cdef foo then accessing foo in the global  
namespace will be a C lookup.

One problem is that then we will have all kinds of  
importcrazydepsfor_x() functions at the end of sage.x.all, which will  
get longer and longer, until we have circular dependancies among  
these, etc.

 Perhaps another approach would be in Cython with an import optional  
 foo (does not throw an exception on failure).

-1. Then it throws an error later on? It has to check every time?

I think the longterm solution is to reduce the number of from foo  
import blah (if you just do import foo and don't use foo, it will  
handle it just fine), reduce the number of unneeded imports (e.g.  
from sage.rings.all import ZZ which needlessly imports lots of  
other stuff than ZZ), and perhaps set up a hierarchy (e.g. decide  
which of groups or calculus should be imported first, and then if you  
need to go the other way do it via late imports of without the  
from keyword.

Sometimes it amazes me that the whole library manages to load at all.

 On Tue, Apr 1, 2008 at 1:41 PM, Carl Witty [EMAIL PROTECTED]  
 wrote:

 On Apr 1, 11:23 am, Robert Bradshaw [EMAIL PROTECTED]
 wrote:
  On Apr 1, 2008, at 10:45 AM, Nick Alexander wrote:
 
   On 1-Apr-08, at 10:36 AM, Gary Furnish wrote:
 
   Right now pulling in group theory may end up pulling in calculus.
   There are similar issues all over with really tight coupling
   between subsystems.  It ought to be possible to use group theory
   (maybe without a feature or two) without calculus and vice versa.
 
   This isn't really a global namespace pollution issue, but it is a
   concern.  One way to deal with this is to make (more) imports
   function or class local.  I'm not sure if there are performance
   penalties for this, especially in Cython.  Can anyone say?
 
  Importing locally takes time, even if just to discover the cached
  import if it has already been done once. This is independent of
  whether or not the file is in Cython (though the relative overhead
  may be much greater for a Cythonized function).

 For instance, see https://bugs.launchpad.net/cython/+bug/155076, where
 I measure the cost of a local import as around 2 microseconds.

  The order in which things are imported is really, really crazy right
  now, as anyone trying to hunt down an (easy to trigger) circular
  references can attest to. It would be great if this could be cleaned
  up, both for developing Sage and for making things more modular so
  other projects can benefit from them.

 Yes, this would be great!

 It seems like it would be very difficult to fix, though.

 Carl



 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[William Stein]

On Tue, Apr 1, 2008 at 1:36 PM, Robert Bradshaw
[EMAIL PROTECTED] wrote:

  On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote:
   Wierd circular import issues can (should) be solved with circular
   cdef imports.  I think the easiest fix to crazy deps (group theory
   on calculus) might be to do something alone the lines of
   foo = None
   def importcrazydeps():
   global foo

  import sage.foo as localfoo
   foo = localfoo
   Then have sage.x.package import all package modules and sage.x.all
   import sage.package and then run importcrazydeps() on any function.

  Yep, I think such things should be handled manually rather than
  adding special behavior and caching to import functions in Cython.
  Note that of you do cdef foo then accessing foo in the global
  namespace will be a C lookup.

  One problem is that then we will have all kinds of
  importcrazydepsfor_x() functions at the end of sage.x.all, which will
  get longer and longer, until we have circular dependancies among
  these, etc.


   Perhaps another approach would be in Cython with an import optional
   foo (does not throw an exception on failure).

  -1. Then it throws an error later on? It has to check every time?

  I think the longterm solution is to reduce the number of from foo
  import blah (if you just do import foo and don't use foo, it will
  handle it just fine), reduce the number of unneeded imports (e.g.
  from sage.rings.all import ZZ which needlessly imports lots of
  other stuff than ZZ), and perhaps set up a hierarchy (e.g. decide
  which of groups or calculus should be imported first, and then if you
  need to go the other way do it via late imports of without the
  from keyword.

I'm not disagreeing but want to point out a potential drawback
to the above suggestion.  Let's say I'm writing my modular abelian
varieties package (which I am right now).  If I type

from sage.rings.integer_ring import ZZ

instead of

from sage.rings.all import ZZ

then my code will break if the rings directory is reorganized
(and it does get reorganized sometimes, e.g., moving code
into the polynomial subdirectory...).   Thus typing

from sage.rings.all import ZZ

results in my modabvar package being more robust against
changes in Sage.

I am not claiming that is enough of a reason to not do
from sage.rings.integer_ring import ZZ
just that there are pros and cons to both approaches.


  Sometimes it amazes me that the whole library manages to load at all.

It's even more amazing that it correctly runs 52 thousand
lines of doctest input on a bunch of different platforms:

was$ sage -grep sage: |wc -l
   52637

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Robert Bradshaw]

On Apr 1, 2008, at 1:50 PM, William Stein wrote:

 On Tue, Apr 1, 2008 at 1:36 PM, Robert Bradshaw
 [EMAIL PROTECTED] wrote:

  On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote:
 Wierd circular import issues can (should) be solved with circular
 cdef imports.  I think the easiest fix to crazy deps (group theory
 on calculus) might be to do something alone the lines of
 foo = None
 def importcrazydeps():
 global foo

 import sage.foo as localfoo
 foo = localfoo
 Then have sage.x.package import all package modules and sage.x.all
 import sage.package and then run importcrazydeps() on any function.

  Yep, I think such things should be handled manually rather than
  adding special behavior and caching to import functions in Cython.
  Note that of you do cdef foo then accessing foo in the global
  namespace will be a C lookup.

  One problem is that then we will have all kinds of
  importcrazydepsfor_x() functions at the end of sage.x.all, which  
 will
  get longer and longer, until we have circular dependancies among
  these, etc.


 Perhaps another approach would be in Cython with an import optional
 foo (does not throw an exception on failure).

  -1. Then it throws an error later on? It has to check every time?

  I think the longterm solution is to reduce the number of from foo
  import blah (if you just do import foo and don't use foo, it will
  handle it just fine), reduce the number of unneeded imports (e.g.
  from sage.rings.all import ZZ which needlessly imports lots of
  other stuff than ZZ), and perhaps set up a hierarchy (e.g. decide
  which of groups or calculus should be imported first, and then if  
 you
  need to go the other way do it via late imports of without the
  from keyword.

 I'm not disagreeing but want to point out a potential drawback
 to the above suggestion.  Let's say I'm writing my modular abelian
 varieties package (which I am right now).  If I type

 from sage.rings.integer_ring import ZZ

 instead of

 from sage.rings.all import ZZ

 then my code will break if the rings directory is reorganized
 (and it does get reorganized sometimes, e.g., moving code
 into the polynomial subdirectory...).   Thus typing

 from sage.rings.all import ZZ

 results in my modabvar package being more robust against
 changes in Sage.

 I am not claiming that is enough of a reason to not do
 from sage.rings.integer_ring import ZZ
 just that there are pros and cons to both approaches.

This is a very good point. It's kind of related to the hierarchy  
idea--one would hope that rings are all loaded before one starts  
loading the modular forms stuff.

Actually, this very statement has caused me many headaches in places  
(not in the modular directory) where importing ZZ from rings.all  
imports a whole bunch of other stuff (e.g. algebraic reals) that in  
turn imports the thing I'm trying to work on. rings.all is so huge it  
might be worth having a rings.basic or something that just imports  
ZZ, QQ, and maybe a couple of others.

  Sometimes it amazes me that the whole library manages to load at  
 all.

 It's even more amazing that it correctly runs 52 thousand
 lines of doctest input on a bunch of different platforms:

 was$ sage -grep sage: |wc -l
52637

:)

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Crash in quo_rem

[John Cremona]

On 01/04/2008, Robert Bradshaw [EMAIL PROTECTED] wrote:



 Yes. We're making good progress on the new coercion model (David Roe
  and I were working on it last night, he finished Rings), but it is
  not 3.0 material (both for timing and stability reasons).

Thanks for the explanation.

  To find out what the new coercion model is see http://
  wiki.sagemath.org/days7/coercion . It is orthogonal to most
  development but I think you in particular keep hearing a lot about it
  because it was created to address exactly the kinds of concerns and
  annoyances with Sage that you so often bring up :).

Who, me?

Also, if someone
  proposes doing something that is a complete reduplication of work
  that either has been done (or is rendered unnecessary) by the
  coercion fixes I try and point that out.

That is useful.  I have some code almost ready to go which might well
fit into that category.

John



  - Robert



  


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Gary Furnish]

Why not use import sage.rings.integer_ring as module_integer_ring.  If the
location changes, just change what it is imported as.
On Tue, Apr 1, 2008 at 3:01 PM, Robert Bradshaw 
[EMAIL PROTECTED] wrote:


 On Apr 1, 2008, at 1:50 PM, William Stein wrote:
 
  On Tue, Apr 1, 2008 at 1:36 PM, Robert Bradshaw
  [EMAIL PROTECTED] wrote:
 
   On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote:
  Wierd circular import issues can (should) be solved with circular
  cdef imports.  I think the easiest fix to crazy deps (group theory
  on calculus) might be to do something alone the lines of
  foo = None
  def importcrazydeps():
  global foo
 
  import sage.foo as localfoo
  foo = localfoo
  Then have sage.x.package import all package modules and sage.x.all
  import sage.package and then run importcrazydeps() on any function.
 
   Yep, I think such things should be handled manually rather than
   adding special behavior and caching to import functions in Cython.
   Note that of you do cdef foo then accessing foo in the global
   namespace will be a C lookup.
 
   One problem is that then we will have all kinds of
   importcrazydepsfor_x() functions at the end of sage.x.all, which
  will
   get longer and longer, until we have circular dependancies among
   these, etc.
 
 
  Perhaps another approach would be in Cython with an import optional
  foo (does not throw an exception on failure).
 
   -1. Then it throws an error later on? It has to check every time?
 
   I think the longterm solution is to reduce the number of from foo
   import blah (if you just do import foo and don't use foo, it will
   handle it just fine), reduce the number of unneeded imports (e.g.
   from sage.rings.all import ZZ which needlessly imports lots of
   other stuff than ZZ), and perhaps set up a hierarchy (e.g. decide
   which of groups or calculus should be imported first, and then if
  you
   need to go the other way do it via late imports of without the
   from keyword.
 
  I'm not disagreeing but want to point out a potential drawback
  to the above suggestion.  Let's say I'm writing my modular abelian
  varieties package (which I am right now).  If I type
 
  from sage.rings.integer_ring import ZZ
 
  instead of
 
  from sage.rings.all import ZZ
 
  then my code will break if the rings directory is reorganized
  (and it does get reorganized sometimes, e.g., moving code
  into the polynomial subdirectory...).   Thus typing
 
  from sage.rings.all import ZZ
 
  results in my modabvar package being more robust against
  changes in Sage.
 
  I am not claiming that is enough of a reason to not do
  from sage.rings.integer_ring import ZZ
  just that there are pros and cons to both approaches.

 This is a very good point. It's kind of related to the hierarchy
 idea--one would hope that rings are all loaded before one starts
 loading the modular forms stuff.

 Actually, this very statement has caused me many headaches in places
 (not in the modular directory) where importing ZZ from rings.all
 imports a whole bunch of other stuff (e.g. algebraic reals) that in
 turn imports the thing I'm trying to work on. rings.all is so huge it
 might be worth having a rings.basic or something that just imports
 ZZ, QQ, and maybe a couple of others.

   Sometimes it amazes me that the whole library manages to load at
  all.
 
  It's even more amazing that it correctly runs 52 thousand
  lines of doctest input on a bunch of different platforms:
 
  was$ sage -grep sage: |wc -l
 52637

 :)

 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] trivial but common typos in tutorial

[Minh Nguyen]

--- doc-main-2.11.0/tut/tutworks.tex2008-03-31 13:11:51.0 +1000
+++ doc-main-2.11.1/tut/tutworks.tex2008-04-02 08:00:46.0 +1000
@@ -2777,7 +2777,7 @@
 We can also compute the above power in some of the computer
 algebra systems that \sage includes.  In each case we execute
 a trivial command in the system, in order to start up the
-server for that program.  The most relavant time is the wall time.
+server for that program.  The most relevant time is the wall time.
 However, if there is a significant difference between the
 wall time and the CPU time then this may indicate
 a performance issue worth looking into.
@@ -3388,7 +3388,7 @@
 sage: pari('znprimroot(10007)')
 Mod(5, 10007)
 \end{verbatim}
-In the first case a separate copy of the GP interepreter is
+In the first case a separate copy of the GP interpreter is
 started as a server, and the string \code{'znprimroot(10007)'}
 is sent to it, evaluated by GP, and the result is assigned
 to a variable in GP (which takes up space in the child GP
@@ -3756,7 +3756,7 @@
 simultaneously similar to both Python and C.  Most Python
 constructions, including list comprehensions, conditional expressions,
 code like \code{+=} are allowed; you can also import code that you
-have written in other Python modules.  Morever, one can declare
+have written in other Python modules.  Moreover, one can declare
 arbitrary C variables and arbitrary C library calls can be made
 directly.  The resulting code is converted to C and compiled using a C
 compiler.
@@ -4177,7 +4177,7 @@


 \section{Iterators}
-Iterators are a recent addition to Python that are particulary useful
+Iterators are a recent addition to Python that are particularly useful
 in mathematics applications.Here are several examples; see
 \cite{PyT} for more details.
 We make an iterator over the squares of the nonnegative integers up
to $1000$.



Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Robert Bradshaw]

On Apr 1, 2008, at 2:08 PM, Gary Furnish wrote:
 Why not use import sage.rings.integer_ring as module_integer_ring.   
 If the location changes, just change what it is imported as.

I think the point is that re-arranging the rings directory should  
have minimal impact outside of it. This is one of the big benifits of  
an .all file.


 On Tue, Apr 1, 2008 at 3:01 PM, Robert Bradshaw  
 [EMAIL PROTECTED] wrote:

 On Apr 1, 2008, at 1:50 PM, William Stein wrote:
 
  On Tue, Apr 1, 2008 at 1:36 PM, Robert Bradshaw
  [EMAIL PROTECTED] wrote:
 
   On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote:
  Wierd circular import issues can (should) be solved with circular
  cdef imports.  I think the easiest fix to crazy deps (group theory
  on calculus) might be to do something alone the lines of
  foo = None
  def importcrazydeps():
  global foo
 
  import sage.foo as localfoo
  foo = localfoo
  Then have sage.x.package import all package modules and sage.x.all
  import sage.package and then run importcrazydeps() on any  
 function.
 
   Yep, I think such things should be handled manually rather than
   adding special behavior and caching to import functions in Cython.
   Note that of you do cdef foo then accessing foo in the global
   namespace will be a C lookup.
 
   One problem is that then we will have all kinds of
   importcrazydepsfor_x() functions at the end of sage.x.all, which
  will
   get longer and longer, until we have circular dependancies among
   these, etc.
 
 
  Perhaps another approach would be in Cython with an import  
 optional
  foo (does not throw an exception on failure).
 
   -1. Then it throws an error later on? It has to check every time?
 
   I think the longterm solution is to reduce the number of from foo
   import blah (if you just do import foo and don't use foo, it  
 will
   handle it just fine), reduce the number of unneeded imports (e.g.
   from sage.rings.all import ZZ which needlessly imports lots of
   other stuff than ZZ), and perhaps set up a hierarchy (e.g. decide
   which of groups or calculus should be imported first, and then if
  you
   need to go the other way do it via late imports of without the
   from keyword.
 
  I'm not disagreeing but want to point out a potential drawback
  to the above suggestion.  Let's say I'm writing my modular abelian
  varieties package (which I am right now).  If I type
 
  from sage.rings.integer_ring import ZZ
 
  instead of
 
  from sage.rings.all import ZZ
 
  then my code will break if the rings directory is reorganized
  (and it does get reorganized sometimes, e.g., moving code
  into the polynomial subdirectory...).   Thus typing
 
  from sage.rings.all import ZZ
 
  results in my modabvar package being more robust against
  changes in Sage.
 
  I am not claiming that is enough of a reason to not do
  from sage.rings.integer_ring import ZZ
  just that there are pros and cons to both approaches.

 This is a very good point. It's kind of related to the hierarchy
 idea--one would hope that rings are all loaded before one starts
 loading the modular forms stuff.

 Actually, this very statement has caused me many headaches in places
 (not in the modular directory) where importing ZZ from rings.all
 imports a whole bunch of other stuff (e.g. algebraic reals) that in
 turn imports the thing I'm trying to work on. rings.all is so huge it
 might be worth having a rings.basic or something that just imports
 ZZ, QQ, and maybe a couple of others.

   Sometimes it amazes me that the whole library manages to load at
  all.
 
  It's even more amazing that it correctly runs 52 thousand
  lines of doctest input on a bunch of different platforms:
 
  was$ sage -grep sage: |wc -l
 52637

 :)




 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sage lite

[Gary Furnish]

I think it is entirely possible that fixing import problems may have to come
at the expense of ease of use.  I don't see rings.basic helping much.  I
envision grand discussions about what constitutes a basic ring and what
should and should not be included.  What happens if we still have issues
after a rings.basic... do we move to a rings.basic and rings.basic2 system?

On Tue, Apr 1, 2008 at 3:14 PM, Robert Bradshaw 
[EMAIL PROTECTED] wrote:


 On Apr 1, 2008, at 2:08 PM, Gary Furnish wrote:
  Why not use import sage.rings.integer_ring as module_integer_ring.
  If the location changes, just change what it is imported as.

 I think the point is that re-arranging the rings directory should
 have minimal impact outside of it. This is one of the big benifits of
 an .all file.

 
  On Tue, Apr 1, 2008 at 3:01 PM, Robert Bradshaw
  [EMAIL PROTECTED] wrote:
 
  On Apr 1, 2008, at 1:50 PM, William Stein wrote:
  
   On Tue, Apr 1, 2008 at 1:36 PM, Robert Bradshaw
   [EMAIL PROTECTED] wrote:
  
On Apr 1, 2008, at 1:23 PM, Gary Furnish wrote:
   Wierd circular import issues can (should) be solved with circular
   cdef imports.  I think the easiest fix to crazy deps (group theory
   on calculus) might be to do something alone the lines of
   foo = None
   def importcrazydeps():
   global foo
  
   import sage.foo as localfoo
   foo = localfoo
   Then have sage.x.package import all package modules and sage.x.all
   import sage.package and then run importcrazydeps() on any
  function.
  
Yep, I think such things should be handled manually rather than
adding special behavior and caching to import functions in Cython.
Note that of you do cdef foo then accessing foo in the global
namespace will be a C lookup.
  
One problem is that then we will have all kinds of
importcrazydepsfor_x() functions at the end of sage.x.all, which
   will
get longer and longer, until we have circular dependancies among
these, etc.
  
  
   Perhaps another approach would be in Cython with an import
  optional
   foo (does not throw an exception on failure).
  
-1. Then it throws an error later on? It has to check every time?
  
I think the longterm solution is to reduce the number of from foo
import blah (if you just do import foo and don't use foo, it
  will
handle it just fine), reduce the number of unneeded imports (e.g.
from sage.rings.all import ZZ which needlessly imports lots of
other stuff than ZZ), and perhaps set up a hierarchy (e.g. decide
which of groups or calculus should be imported first, and then if
   you
need to go the other way do it via late imports of without the
from keyword.
  
   I'm not disagreeing but want to point out a potential drawback
   to the above suggestion.  Let's say I'm writing my modular abelian
   varieties package (which I am right now).  If I type
  
   from sage.rings.integer_ring import ZZ
  
   instead of
  
   from sage.rings.all import ZZ
  
   then my code will break if the rings directory is reorganized
   (and it does get reorganized sometimes, e.g., moving code
   into the polynomial subdirectory...).   Thus typing
  
   from sage.rings.all import ZZ
  
   results in my modabvar package being more robust against
   changes in Sage.
  
   I am not claiming that is enough of a reason to not do
   from sage.rings.integer_ring import ZZ
   just that there are pros and cons to both approaches.
 
  This is a very good point. It's kind of related to the hierarchy
  idea--one would hope that rings are all loaded before one starts
  loading the modular forms stuff.
 
  Actually, this very statement has caused me many headaches in places
  (not in the modular directory) where importing ZZ from rings.all
  imports a whole bunch of other stuff (e.g. algebraic reals) that in
  turn imports the thing I'm trying to work on. rings.all is so huge it
  might be worth having a rings.basic or something that just imports
  ZZ, QQ, and maybe a couple of others.
 
Sometimes it amazes me that the whole library manages to load at
   all.
  
   It's even more amazing that it correctly runs 52 thousand
   lines of doctest input on a bunch of different platforms:
  
   was$ sage -grep sage: |wc -l
  52637
 
  :)
 
 
 
 
  


 


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] trivial typo in reference manual

[Minh Nguyen]

--- doc-main-2.11.0/ref/libs.tex2008-03-31 13:11:51.0 +1000
+++ doc-main-2.11.1/ref/libs.tex2008-04-02 08:23:12.0 +1000
@@ -8,7 +8,7 @@
 The interfaces are implemented via shared libraries and data is moved
 between systems purely in memory.  In particular, there is no
 interprocess interpreter parsing (e.g., \code{expect}), since
-everthing is linked together and run as a single process.  This is
+everything is linked together and run as a single process.  This is
 much more robust and efficient than using \code{expect}.

 Each of these interfaces is used by other parts of SAGE.  For example,



Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: trivial typo in reference manual

[Minh Nguyen]

--- doc-main-2.11.0/ref/networking.tex  2008-03-31 13:11:51.0 +1000
+++ doc-main-2.11.1/ref/networking.tex  2008-04-02 08:24:06.0 +1000
@@ -14,7 +14,7 @@
 mature, fast, and offers a vast range of networking functionality.

 The SAGE Notebook (see Chapter~\ref{ch:notebook})
-is another networking application icluded with SAGE.
+is another networking application included with SAGE.

 \input{sage/sage.server.wiki.moin}



Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] trivial typos in doc.tex

[Minh Nguyen]

--- doc-main-2.11.0/doc/doc.tex 2008-03-31 13:11:51.0 +1000
+++ doc-main-2.11.1/doc/doc.tex 2008-04-02 08:43:35.0 +1000
@@ -471,7 +471,7 @@

 \LaTeX{} provides a variety of environments even without the
 additional markup provided by the Python-specific document classes
-introducted in the next section.  The following environments are
+introduced in the next section.  The following environments are
 provided as part of standard \LaTeX{} and are being used in the
 standard Python documentation; descriptions will be added here as
 time allows.
@@ -830,7 +830,7 @@
   with release \var{version}.  The text given as \var{what to do}
   should recommend something to use instead.  It should be
   complete sentences.  The entire deprecation notice will be
-  presented as a separate paragraph; it should either preceed or
+  presented as a separate paragraph; it should either precede or
   succeed the description of the deprecated feature.
 \end{macrodesc}

@@ -1122,7 +1122,7 @@

   \begin{envdesc}{notice}{\op{type}}
 Label some paragraphs as being worthy of additional attention from
-the reader.  What sort of attention is warrented can be indicated
+the reader.  What sort of attention is warranted can be indicated
 by specifying the \var{type} of the notice.  The only values
 defined for \var{type} are \code{note} and \code{warning}; these
 are equivalent in intent to the inline markup of the same name.
@@ -1349,7 +1349,7 @@

 Here is a small example of a table given in the documentation for
 the \module{warnings} module; markup inside the table cells is
-minimal so the markup for the table itself is readily discernable.
+minimal so the markup for the table itself is readily discernible.
 Here is the markup for the table:

 \begin{verbatim}
@@ -1660,7 +1660,7 @@
 \begin{envdesc}{productionlist}{\op{language}}
   This environment is used to enclose a group of productions.  The
   two macros are only defined within this environment.  If a
-  document descibes more than one language, the optional parameter
+  document describes more than one language, the optional parameter
   \var{language} should be used to distinguish productions between
   languages.  The value of the parameter should be a short name
   that can be used as part of a filename; colons or other
@@ -2080,7 +2080,7 @@
 fairly rough.

 The timeframe for the conversion is not clear since there doesn't
-seem to be much time available to work on this, but the appearant
+seem to be much time available to work on this, but the apparent
 benefits are growing more substantial at a moderately rapid pace.


Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] trivial typo in inst.tex

[Minh Nguyen]

--- doc-main-2.11.0/inst/inst.tex   2008-03-31 13:11:51.0 +1000
+++ doc-main-2.11.1/inst/inst.tex   2008-04-02 08:51:30.0 +1000
@@ -169,7 +169,7 @@
   Complete compilation of \SAGE is currently not supported on Solaris
   or *BSD.  It is possible to compile most of \SAGE on Solaris
   machines and to fill in the extra parts using standard packages;
-  please email sage-devel if you desparately need to run
+  please email sage-devel if you desperately need to run
   \SAGE on Solaris.  We do plan to fully support Solaris -- it's
 a very important platform. Work is ongoing.


Regards
Minh Van Nguyen

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: PolyBoRi Tutorial

[William Stein]

On Tue, Apr 1, 2008 at 12:39 AM, Michael Brickenstein
[EMAIL PROTECTED] wrote:

  Hi!
  Suprise, there exists a tutorial for PolyBoRi.

  http://polybori.sourceforge.net/doc/tutorial/index.html

  It is available in tex-format under
  doc/tutorial/tutorial.tex
  in our source distribution.
   think it would be nice, to include it in the SAGE documentation in
  some way.
  I started this discussion privately with Martin and Burcin and move it
  now to the list,
  since it is a general problem about third party documentation.

  This tutorial aims to introduce into the efficient use of PolyBoRi.

  It is written for PolyBoRi 0.3.1 (using our Boost::python bindings,
  which are very similar).

  We have seen two main options until now:
  - leave the original documentation as it is and provide a link
  - redoing them in a SAGE style

  Of course, the first option will provide a good solution now (much
  better not including it for the next months).
  However, if we really want to compete with the many M's, then this
  probably won't suffice.

  So, what is the best way to include it in SAGE?

Is it written in LaTeX?   If so, we can include it directly
in the Sage reference manual as a patch, and you can
update that every once in a while.  The sage reference
manual is just a large latex document.

 -- 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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] sdmp - closed-source library for sparse multivariate polynomial arithmetic

[Mike Hansen]

Hello,

On sci.math.symbolic, I saw that Roman Pearce posted some benchmarks
from his closed source library for performing sparse multivariate
polynomial arithmetic, which can be found at
http://www.cecm.sfu.ca/~rpearcea/ .  The benchmarks (
http://www.cecm.sfu.ca/~rpearcea/sdmp/2008_04_01/benchmarks.txt ) are
pretty impressive.

--Mike

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: video from lecture one of my Sage course

[Michael]

Excellent stuff!   Please post videos of all of the lectures.

But, Will, if that is you giving the lecture you need to increase your
lean body mass!  More muscle = more math.
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Y axis range

[Jason Grout]

Jason Grout wrote:
 CCing sage-devel since this has turned into a devel discussion.  The 
 original thread is on sage-support.
 
 Joel B. Mohler wrote:
 On Tuesday 01 April 2008 05:20:47 pm Joel B. Mohler wrote:
 On Tuesday 01 April 2008 04:45:16 pm alex clemesha wrote:
 With respect to the 'goal' of Sage's plotting (follow Mma),
 I would say this is definitley a bug.

 People with 'violent' feelings about this apsect of the plotting
 might want to change certain features of the plot code once and for all
 :)
 Well, as I mentioned in my earlier post on this thread, I wasn't sure what
 was intentional design.

 This thread
 http://groups.google.com/group/sage-devel/browse_thread/thread/c7445f921c8f
 0e85/1c7420b369bc7baa left me quite confused when I complained the first
 time.

 I do have a patch which I apply everytime I have a critical output quality
 plotting session.  Actually, that patch is in the mentioned thread.  It's
 quick and dirty, but it removes all extra margins (I think it has to touch
 3 places in the code -- i.e. 3 extra margin padding code-points -- really
 quite grotesque, and, I couldn't believe it was all by accident.)
 Perhaps I should add here that I'm happy to produce a patch for this, but I 
 didn't really feel like my ideals were the design goals of this plotting 
 code.  That's why I didn't submit any patches earlier.  The patch in that 
 other thread really is not intended to be applied -- I wrote it to do what 
 *I* wanted with no regards for any other flexible functionality.

 If I feel like we have a consensus on design, I will enshrine that design in 
 a 
 patch -- although, I'd be happy if someone beat me to it.  I don't know that 
 I myself have any specific design goals for this particular point aside from 
 making the margins exactly what I say the margins are supposed to be -- It 
 could be that exactly what I say is a bit more nebulous than I'm aware of.
 
 
 I played around with it for a bit this afternoon.  I figured out one 
 place to change, but the frame messed things up and I didn't see where 
 to fix the margins added by the frame in the short time I looked at it.
 
 I was thinking of setting an explicit_ymin and explicit_ymax and if 
 those existed, no auto-tuning would be done, or something like that. 
 You've already worked on this, so no doubt you'd beat me to a patch :).
 
 While we're on the issue, it seems very clunky to have the parameter 
 names called ymin and ymax; what if my variable isn't y?  I'd like 
 plot_range=(-0.5, 0.5) instead (or even vertical_range, if we wanted 
 to be extremely explicit).  Again, for reference, in Mma it is 
 PlotRange.  The Mma PlotRange parameter is quite a bit more flexible, 
 though:
 
 http://reference.wolfram.com/mathematica/ref/PlotRange.html?q=PlotRangelang=en
 


Also, Mma has a PlotRangePadding option, which seems to address the 
issue that is noted above.

http://reference.wolfram.com/mathematica/ref/PlotRangePadding.html

Jason


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: video from lecture one of my Sage course

[Dan Drake]

On Mon, 31 Mar 2008 at 06:04PM -0700, William Stein wrote:
 This is video from lecture one of my Sage course
 
 http://video.google.com/videoplay?docid=-826792746508034hl=en

Check out the related videos that show up:

http://math.kaist.ac.kr/~drake/img/videos-related-to-sage.png

It must have been a very exciting lecture! 

Dan

-- 
---  Dan Drake [EMAIL PROTECTED]
-  KAIST Department of Mathematical Sciences
---  http://math.kaist.ac.kr/~drake


signature.asc
Description: Digital signature

[sage-devel] Re: Y axis range

[William Stein]

On Tue, Apr 1, 2008 at 5:11 PM, Jason Grout [EMAIL PROTECTED] wrote:


  Jason Grout wrote:
   CCing sage-devel since this has turned into a devel discussion.  The
   original thread is on sage-support.
  
   Joel B. Mohler wrote:
   On Tuesday 01 April 2008 05:20:47 pm Joel B. Mohler wrote:
   On Tuesday 01 April 2008 04:45:16 pm alex clemesha wrote:
   With respect to the 'goal' of Sage's plotting (follow Mma),
   I would say this is definitley a bug.
  
   People with 'violent' feelings about this apsect of the plotting
   might want to change certain features of the plot code once and for all
   :)
   Well, as I mentioned in my earlier post on this thread, I wasn't sure 
 what
   was intentional design.
  
   This thread
   
 http://groups.google.com/group/sage-devel/browse_thread/thread/c7445f921c8f
   0e85/1c7420b369bc7baa left me quite confused when I complained the first
   time.
  
   I do have a patch which I apply everytime I have a critical output 
 quality
   plotting session.  Actually, that patch is in the mentioned thread.  It's
   quick and dirty, but it removes all extra margins (I think it has to 
 touch
   3 places in the code -- i.e. 3 extra margin padding code-points -- really
   quite grotesque, and, I couldn't believe it was all by accident.)
   Perhaps I should add here that I'm happy to produce a patch for this, but 
 I
   didn't really feel like my ideals were the design goals of this plotting
   code.  That's why I didn't submit any patches earlier.  The patch in that
   other thread really is not intended to be applied -- I wrote it to do what
   *I* wanted with no regards for any other flexible functionality.
  
   If I feel like we have a consensus on design, I will enshrine that design 
 in a
   patch -- although, I'd be happy if someone beat me to it.  I don't know 
 that
   I myself have any specific design goals for this particular point aside 
 from
   making the margins exactly what I say the margins are supposed to be -- It
   could be that exactly what I say is a bit more nebulous than I'm aware 
 of.
  
  
   I played around with it for a bit this afternoon.  I figured out one
   place to change, but the frame messed things up and I didn't see where
   to fix the margins added by the frame in the short time I looked at it.
  
   I was thinking of setting an explicit_ymin and explicit_ymax and if
   those existed, no auto-tuning would be done, or something like that.
   You've already worked on this, so no doubt you'd beat me to a patch :).
  
   While we're on the issue, it seems very clunky to have the parameter
   names called ymin and ymax; what if my variable isn't y?  I'd like
   plot_range=(-0.5, 0.5) instead (or even vertical_range, if we wanted
   to be extremely explicit).  Again, for reference, in Mma it is
   PlotRange.  The Mma PlotRange parameter is quite a bit more flexible,
   though:
  
   
 http://reference.wolfram.com/mathematica/ref/PlotRange.html?q=PlotRangelang=en
  


  Also, Mma has a PlotRangePadding option, which seems to address the
  issue that is noted above.

  http://reference.wolfram.com/mathematica/ref/PlotRangePadding.html

  Jason

Jason,  It is my strong desire that we follow the mathematica naming
conventions and feature set for 2d plotting whenever this isn't totally
wacky.  Thus I'm all for any of your suggestions above about changing
plotting to work more like in mathematica.

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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Output Form versus Internal Structure

[Dan Drake]

Robert Bradshaw wrote:
 Thanks for your input. We are considering a more advanced model
 (David Roe has lots of ideas on this front), but this falls outside  
 of the central focus coercion scheme. (This is one reason to use  
 _repr_ rather than the Python __repr__ so that the base object's  
 __repr__ can do more sophisticated things (although now it just calls  
 _repr_).

I would really like something like this. For example, take Young
tableaux: when working in the Sage interpreter, I might want a tableau
to print out like this:

   7532
   642
   632
   1

but in the notebook interface, or for including into a LaTeX document, I
might want the tableau to print out a TikZ picture environment:

  \begin{tikzpicture}
\draw ...
  \end{tikzpicture}

Also, Francophones will want those same things printed upside down. :)
So more flexibility, and multiple printed representations, would be very
nice.

Dan

-- 
---  Dan Drake [EMAIL PROTECTED]
-  KAIST Department of Mathematical Sciences
---  http://math.kaist.ac.kr/~drake


signature.asc
Description: Digital signature

[sage-devel] Re: Crash in quo_rem

[Robert Bradshaw]

On Apr 1, 2008, at 2:03 PM, John Cremona wrote:

 On 01/04/2008, Robert Bradshaw [EMAIL PROTECTED] wrote:

 Yes. We're making good progress on the new coercion model (David Roe
  and I were working on it last night, he finished Rings), but it is
  not 3.0 material (both for timing and stability reasons).

 Thanks for the explanation.

  To find out what the new coercion model is see http://
  wiki.sagemath.org/days7/coercion . It is orthogonal to most
  development but I think you in particular keep hearing a lot  
 about it
  because it was created to address exactly the kinds of concerns and
  annoyances with Sage that you so often bring up :).

 Who, me?

Yes. Finding and reporting bugs is a good thing :). Thanks.

 Also, if someone
  proposes doing something that is a complete reduplication of work
  that either has been done (or is rendered unnecessary) by the
  coercion fixes I try and point that out.

 That is useful.  I have some code almost ready to go which might well
 fit into that category.

Well, I'm not trying to stop people from writing good code, and lots  
of times it will be useful even if it has to be re-factored to fit  
into the still-not-ready-for-prime-time system.

- Robert

--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] _fast_float_ for symbolic equalities/inequalities

[Jason Grout]

I'm trying to add _fast_float_ functionality to SymbolicEquation 
objects.  However, a perusal of the sage.ext.fast_eval.pyx file seems to 
indicate that the operations , =, ==, =, , and != are not supported 
by the fast_float machinery.  Is that correct?  If so, how do I add 
these operations?  If not, then how do I construct a FastDoubleFunc 
object appropriately?

Or, should I just use the python operators and call fast_float on each side?

Thanks,

Jason


--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: PolyBoRi Tutorial

[Michael Brickenstein]

Hi William!
It is pure latex (I have chosen this format, as I wanted to reuse it
at some day for SAGE).

Michael

On 1 Apr., 23:53, William Stein [EMAIL PROTECTED] wrote:
 On Tue, Apr 1, 2008 at 12:39 AM, Michael Brickenstein



 [EMAIL PROTECTED] wrote:

   Hi!
   Suprise, there exists a tutorial for PolyBoRi.

   http://polybori.sourceforge.net/doc/tutorial/index.html

   It is available in tex-format under
   doc/tutorial/tutorial.tex
   in our source distribution.
    think it would be nice, to include it in the SAGE documentation in
   some way.
   I started this discussion privately with Martin and Burcin and move it
   now to the list,
   since it is a general problem about third party documentation.

   This tutorial aims to introduce into the efficient use of PolyBoRi.

   It is written for PolyBoRi 0.3.1 (using our Boost::python bindings,
   which are very similar).

   We have seen two main options until now:
   - leave the original documentation as it is and provide a link
   - redoing them in a SAGE style

   Of course, the first option will provide a good solution now (much
   better not including it for the next months).
   However, if we really want to compete with the many M's, then this
   probably won't suffice.

   So, what is the best way to include it in SAGE?

 Is it written in LaTeX?   If so, we can include it directly
 in the Sage reference manual as a patch, and you can
 update that every once in a while.  The sage reference
 manual is just a large latex document.

  -- 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://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: sdmp - closed-source library for sparse multivariate polynomial arithmetic

[Michael Brickenstein]

Hi!

Without saying anything about the quality of Romans work (I can't
judge that without a deeper look):

I don't find it very impressive, posting some benchmark for just one
example.
Note, that the example is dense.
If he is using fast (Strassen-like) algorithms, then it is quite
natural, to achieve
good results in these problems.

I tried the same in Singular and stopped at the point, where
I was able to have quite similar results (compared to the normal
Singular multiplication)
in the dense case, but naturally very slow in the sparse case.
Fast methods are not constructed for sparse arithmetic.

Speeding up a polynomial arithmetic library consists of two parts:
-Implement the algorithms
-choosing at run time, which algorithm to call
At the moment the multiplication in Singular uses two different
function (with and without Geobuckets).

If you would like to have this functionality in SAGE, I can help you,
implementing it in libSingular.
On the other hand (since I did these experiments), you might notice,
that it only improves the quite rare case of quite dense, huge
polynomials  (of similar size) in a few variables.
Best regards,
Michael

On 2 Apr., 00:53, Mike Hansen [EMAIL PROTECTED] wrote:
 Hello,

 On sci.math.symbolic, I saw that Roman Pearce posted some benchmarks
 from his closed source library for performing sparse multivariate
 polynomial arithmetic, which can be found 
 athttp://www.cecm.sfu.ca/~rpearcea/.  The benchmarks 
 (http://www.cecm.sfu.ca/~rpearcea/sdmp/2008_04_01/benchmarks.txt) are
 pretty impressive.

 --Mike
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---