[sage-devel] Re: Compilation problems with SAGE-2.8.5.1 released

2007-09-27 Thread David Harvey
>> test-support.o: In function `__gmpz_fits_uint_p': >> test-support.c:(.text+0x0): multiple definition of >> `__gmpz_fits_uint_p' >> Z_mpn-test.o:Z_mpn-test.c:(.text+0x0): first defined here >> test-support.o: In function `__gmpz_fits_ulong_p': >> >> Here is the end of the install.log >> >> ZmodF

[sage-devel] Re: Compilation problems with SAGE-2.8.5.1 released

2007-09-27 Thread William Stein
On 9/27/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > Glad you're enjoying SAGE. > > Flint is a new experimental package that isn't yet used in SAGE (but > will be soon we hope, as soon as the library matures a bit more and > stabilizes). You should be able to proceed by touching sage/spkg/ >

[sage-devel] Re: gmp and mpfr

2007-09-27 Thread Michael
Update- interestingly, using the newer gmp-4.2.2 solved some of the problems I was experiencing, and I got everything to compile without the --with-pic or copying over any header files. The only thing I had to take care of was to add -m64 option as I described earlier when compiling mpfrcpp. I

[sage-devel] Re: Compilation problems with SAGE-2.8.5.1 released

2007-09-27 Thread Robert Bradshaw
Glad you're enjoying SAGE. Flint is a new experimental package that isn't yet used in SAGE (but will be soon we hope, as soon as the library matures a bit more and stabilizes). You should be able to proceed by touching sage/spkg/ installed/flint-0.2.p2 and then running sage -upgrade again, a

[sage-devel] Re: making new infix operators

2007-09-27 Thread Fernando Perez
On 9/27/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > I agree with your caution, but don't see how the examples above mess > anything up. If an object B wants to pretend to be immutable, it > merely has to check that nothing points to it before mutating itself > (and, in mutating itself, don't

[sage-devel] Compilation problems with SAGE-2.8.5.1 released

2007-09-27 Thread Eliz
I first heard about SAGE on UWTV and was very impressed. I finally downloaded the 2.8.5 binary, started on the tutorial and was much further impressed!! I have trouble compiling both SAGE-2.8.5 and SAGE-2.8.5.1 from the source: My computer: Dell 490 My operating system: [EMAIL PROTECTED]:~> u

[sage-devel] Re: making new infix operators

2007-09-27 Thread Chris Chiasson
Well, I don't want to take the thread off topic, but in the standard (documented) way of creating new operators, it is done with an assignment to MakeExpression. This will work in a notebook, where boxes are transformed into expressions before execution, but it will not work in a .m file, because

[sage-devel] Re: making new infix operators

2007-09-27 Thread Robert Bradshaw
On Sep 27, 2007, at 2:47 PM, Fernando Perez wrote: > The problematic issue is that some extensions (numpy first and > foremost, but this buffer API is going into the core of the language > for 2.6/3.0) allow multiple, distinct *python objects* to share the > same (or parts of the same) chunk of r

[sage-devel] Re: making new infix operators

2007-09-27 Thread Jason Grout
Robert Miller wrote: >> The best I've come up with at this point is, given graphs A,B,C,D,E, the >> union is: >> >> A.union(B).union(C).union(D).union(E) >> >> where the union function returns the modified graph each time so I can >> keep chaining union function calls. The union actually modifies

[sage-devel] Re: irange ticket #706 wontfix

2007-09-27 Thread Jaap Spies
Robert Bradshaw wrote: > On Sep 22, 2007, at 12:25 PM, Jaap Spies wrote: > >> Jaap Spies wrote: >> >>> But most of SAGE is still Python, so I stick to the more Pythonic >>> alternative! >>> >>> As a better name for irange I suggest now inrange, maybe that is more >>> intelligible: >>> >>> sage:

[sage-devel] Re: making new infix operators

2007-09-27 Thread Bill Page
On 9/27/07, Fernando Perez wrote: > ... > In [12]: a = N.arange(10) > > In [13]: sys.getrefcount(a) > Out[13]: 2 > > Here the refcount is 2, as expected: the original array and the name > 'a' pointing to it. > > Now, a naked, unassigned slice of the original array has a refcount of 1: > > In [14]:

[sage-devel] Re: making new infix operators

2007-09-27 Thread Fernando Perez
On 9/27/07, Bill Page <[EMAIL PROTECTED]> wrote: > > On 9/27/07, Fernando Perez wrote: > > > > On 9/27/07, Robert Bradshaw wrote: > > > > > You have a good point, though fortunately we're looking for refcounts > > > so low that (essentially) nothing else can be holding onto it but the > > > curren

[sage-devel] Re: making new infix operators

2007-09-27 Thread Bill Page
On 9/27/07, Fernando Perez wrote: > > On 9/27/07, Robert Bradshaw wrote: > > > You have a good point, though fortunately we're looking for refcounts > > so low that (essentially) nothing else can be holding onto it but the > > current stack frame. If b is pointing to a, it doesn't matter how > > m

[sage-devel] Re: making new infix operators

2007-09-27 Thread Robert Miller
> The best I've come up with at this point is, given graphs A,B,C,D,E, the > union is: > > A.union(B).union(C).union(D).union(E) > > where the union function returns the modified graph each time so I can > keep chaining union function calls. The union actually modifies the > graph A, so if you wa

[sage-devel] Re: making new infix operators

2007-09-27 Thread Robert Bradshaw
On Sep 27, 2007, at 1:45 PM, Jason Grout wrote: > Robert Bradshaw wrote: >> On Sep 27, 2007, at 4:43 AM, Jason Grout wrote: > >>> A=A.union(B) >>> >>> to modify A? >> >> Yes. Or even >> >> A.inplace_union(B) >> >> (or some better name than that) which returns nothing. Otherwise, for >> example, e

[sage-devel] Re: making new infix operators

2007-09-27 Thread Jason Grout
Robert Bradshaw wrote: > On Sep 27, 2007, at 4:43 AM, Jason Grout wrote: > >> A=A.union(B) >> >> to modify A? > > Yes. Or even > > A.inplace_union(B) > > (or some better name than that) which returns nothing. Otherwise, for > example, every function that received a graph as an argument wou

[sage-devel] Re: making new infix operators

2007-09-27 Thread Jaap Spies
Jason Grout wrote: > Mike Hansen wrote: >> Of all the code I've read in lots of different languages, I think code >> written for Mathematica has been the least transparent. > > I guess I've always loved functional languages, so the simple core > principles appealed to me right away. See a thread

[sage-devel] Re: making new infix operators

2007-09-27 Thread Fernando Perez
On 9/27/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > You have a good point, though fortunately we're looking for refcounts > so low that (essentially) nothing else can be holding onto it but the > current stack frame. If b is pointing to a, it doesn't matter how > many other things are (direc

[sage-devel] Re: making new infix operators

2007-09-27 Thread Robert Bradshaw
On Sep 27, 2007, at 7:36 AM, Fernando Perez wrote: > On 9/27/07, Bill Page <[EMAIL PROTECTED]> wrote: > >> There is another very relevant thread started by Robert Bradshaw on >> this list concerning the safety of in-place modifications: >> >> http://groups.google.com/group/sage-devel/browse_thre

[sage-devel] Re: making new infix operators

2007-09-27 Thread Robert Bradshaw
On Sep 27, 2007, at 4:43 AM, Jason Grout wrote: > Mike Hansen wrote: >>> The best I've come up with at this point is, given graphs >>> A,B,C,D,E, the >>> union is: >>> >>> A.union(B).union(C).union(D).union(E) >>> >>> where the union function returns the modified graph each time so >>> I can

[sage-devel] Re: Introductory SAGE talk in Oslo

2007-09-27 Thread William Stein
On 9/27/07, Jason Grout <[EMAIL PROTECTED]> wrote: > > * FYI: Maple also uses GMP. I don't think Mathematica does (based on > > my limited testing showing it to be slower at integer arithmetic). > > > > The other day I attended a training session on Mathematica and the > Wolfram representative sp

[sage-devel] Useful cross-licensing (BSD/GPL) legal document

2007-09-27 Thread Fernando Perez
Hi all, I know everyone is fed up with licensing discussions, but this will be brief, and meant just to provide a resource, not to stir up any more noise. The Software Freedom Law Center, a legal pro-bono organization, has just released a very useful document providing guidelines for how GPL pro

[sage-devel] Re: Introductory SAGE talk in Oslo

2007-09-27 Thread Jason Grout
William Stein wrote: > On 9/27/07, Georg Muntingh <[EMAIL PROTECTED]> wrote: >> On Monday I will give an introductory talk about SAGE for the algebra >> group in Oslo. The contents of the presentation can be found at >> http://docs.google.com/Doc?id=df56gnzv_15cp38pw , and the slides can >> be fou

[sage-devel] Re: Introductory SAGE talk in Oslo

2007-09-27 Thread Hamptonio
Hi, Nice visuals. I will be giving several intro-to-sage talks in the coming months, so if you don't mind I might recycle some of your presentation ideas. I recommend including a nice 3D screenshot using Tachyon, maybe using graphs. I think tachyon is currently somewhat under-exploited curren

[sage-devel] Re: SAGE conventions for methods

2007-09-27 Thread Bill Page
> > Thoughts or comments? Is there an official convention for these things? > The Axiom library uses the conventions you associate with Lisp of ! and ? name-endings for functions (methods) which modify an object in place and functions which return boolean values, respectively. Personally I don'

[sage-devel] Re: SAGE conventions for methods

2007-09-27 Thread William Stein
On 9/27/07, Jason Grout <[EMAIL PROTECTED]> wrote: > In another thread ("making new infix operators", > http://groups.google.com/group/sage-devel/browse_thread/thread/a27ae5012d3754f5 > ), we evolved into a discussion of conventions for methods in SAGE. > I'll try to summarize and ask questions ab

[sage-devel] Re: SAGE conventions for methods

2007-09-27 Thread David Joyner
Thank you for the summary. GAP also has conventions, though I don't know how official they are. Typically a boolean response starts with "Is" (as is "IsAbelainGroup") and an in-place modification has the work "Mutable" in the command name somewhere. On 9/27/07, Jason Grout <[EMAIL PROTECTED]> wr

[sage-devel] Re: Introductory SAGE talk in Oslo

2007-09-27 Thread William Stein
On 9/27/07, Georg Muntingh <[EMAIL PROTECTED]> wrote: > On Monday I will give an introductory talk about SAGE for the algebra > group in Oslo. The contents of the presentation can be found at > http://docs.google.com/Doc?id=df56gnzv_15cp38pw , and the slides can > be found at http://folk.uio.no/ge

[sage-devel] SAGE conventions for methods

2007-09-27 Thread Jason Grout
In another thread ("making new infix operators", http://groups.google.com/group/sage-devel/browse_thread/thread/a27ae5012d3754f5 ), we evolved into a discussion of conventions for methods in SAGE. I'll try to summarize and ask questions about this general subject here. First, I think it's imp

[sage-devel] Introductory SAGE talk in Oslo

2007-09-27 Thread Georg Muntingh
Hi everybody, On Monday I will give an introductory talk about SAGE for the algebra group in Oslo. The contents of the presentation can be found at http://docs.google.com/Doc?id=df56gnzv_15cp38pw , and the slides can be found at http://folk.uio.no/georgmu/SAGE.pdf . Any feedback would be greatly

[sage-devel] Re: making new infix operators

2007-09-27 Thread Hamptonio
I disagree. Maybe its because I grew up learning BASIC, but in-place modification generally confuses and annoys me. Here's an example that I think illustrates one of my issues: Code version A: a = something b = [a,something_else] c = a.a_method() important_result(b) Code version B: a = somethin

[sage-devel] Re: making new infix operators

2007-09-27 Thread Fernando Perez
On 9/27/07, Bill Page <[EMAIL PROTECTED]> wrote: > There is another very relevant thread started by Robert Bradshaw on > this list concerning the safety of in-place modifications: > > http://groups.google.com/group/sage-devel/browse_thread/thread/806cd958eb28ac3b/46655d7572d11ee6?#46655d7572d11e

[sage-devel] Re: making new infix operators

2007-09-27 Thread Bill Page
On 9/27/07, Jason Grout wrote: > ... > > > >> where the union function returns the modified graph each time so I can > >> keep chaining union function calls. The union actually modifies the > >> graph A, so if you want A left alone and a new graph returned, you do: > >> > >> newgraph=A.copy().uni

[sage-devel] Re: making new infix operators

2007-09-27 Thread Jason Grout
Robert Bradshaw wrote: > On Sep 26, 2007, at 8:59 PM, Jason Grout wrote: > >> As for graphs, there isn't a standard definition for the "+" operation >> that is agreed upon, even for graphs of the same type (e.g., should it >> be disjoint union or union?). That's why I was asking about custom >>

[sage-devel] Re: making new infix operators

2007-09-27 Thread Jason Grout
Chris Chiasson wrote: > It might be worth pointing out that adding "new" syntax in Mathematica > is (usually) done by assignments to the function that transforms > general two dimensional input into source code. That isn't really the > same thing as adding a new operator to the language itself. A

[sage-devel] Re: making new infix operators

2007-09-27 Thread Jason Grout
Craig Citro wrote: >>> The best I've come up with at this point is, given graphs >>> A,B,C,D,E, the >>> union is: >>> >>> A.union(B).union(C).union(D).union(E) >> I actually think that this looks very clear, despite the lack of >> infix operators. >> > > I agree -- especially since it looks like

[sage-devel] Re: making new infix operators

2007-09-27 Thread Jason Grout
Mike Hansen wrote: >> The best I've come up with at this point is, given graphs A,B,C,D,E, the >> union is: >> >> A.union(B).union(C).union(D).union(E) >> >> where the union function returns the modified graph each time so I can >> keep chaining union function calls. The union actually modifies t

[sage-devel] Re: gmp and mpfr

2007-09-27 Thread mabshoff
Hello Michael, On Sep 27, 3:23 am, Michael <[EMAIL PROTECTED]> wrote: > I managed to get gmp, mpfr, and mpfrcpp to compile and link > successfully. > It took a bit of effort to get it working, so I thought I'd record my > settings here in case > other people find them useful > > machine: G5 power