Re: [sage-devel] Building Sage on Cygwin: Possibly Linking Error

2015-08-15 Thread Travis Scrimshaw
I'm using gcc version 4.9.3. On Saturday, August 15, 2015 at 11:15:31 PM UTC-7, François wrote: > > Only thing I can think of that would be useful to know is the version of > gcc used. > > François > > -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] Building Sage on Cygwin: Possibly Linking Error

2015-08-15 Thread Francois Bissey
Only thing I can think of that would be useful to know is the version of gcc used. François > On 16/08/2015, at 18:10, Travis Scrimshaw wrote: > > Okay, now I'm getting this error: > > [ 2/302] gcc -I/usr/include/ncurses -fno-strict-aliasing -g -O2 -DNDEBUG -g > -fwrapv -O3 -Wall -I/home/Tr

[sage-devel] Re: Building Sage on Cygwin: Possibly Linking Error

2015-08-15 Thread Travis Scrimshaw
Okay, now I'm getting this error: [ 2/302] gcc -I/usr/include/ncurses -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -I/home/Travis/sage/local/include -I/home/Travis/sage/ local/include/python2.7 -I/home/Travis/sage/local/lib/python2.7/site- packages/numpy/core/include -I/home/Travis/

[sage-devel] Re: Building Sage on Cygwin: Possibly Linking Error

2015-08-15 Thread Travis Scrimshaw
I explicitly added a link to NTL in module_list.py and this seemed to fix the problem. This is now http://trac.sagemath.org/ticket/19039. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails fro

[sage-devel] Building Sage on Cygwin: Possibly Linking Error

2015-08-15 Thread Travis Scrimshaw
Hey all, Once again I'm trying to get Sage to build on Cygwin, and I'm very pleasantly surprised to see that I got very far in compiling out-of-the-box with #18996 (which is positively reviewed) and #18927. However I get the following error: Executing 383 commands (using 1 thread) [ 1/383]

[sage-devel] question about high memory usage in load/save

2015-08-15 Thread kcrisman
FYI for those who like to answer these things: http://stackoverflow.com/questions/32030633/using-sages-save-and-load-methods-leads-to-high-memory-usage Notice also the question "(is there a better way to look how the sage is using the memory?)" which I believe is quite possible using standard Pyth

Re: [sage-devel] Re: revisions to sandpiles needs review

2015-08-15 Thread David Joyner
On Thu, Jun 11, 2015 at 1:24 PM, David Perkinson wrote: > Yes, I think it will be much more efficient to address these changes all at > once. I would really prefer that, if possible. > I downloaded the code as a tarball and "manually" installed it (as opposed to using git). I didn't find any pr

Re: [sage-devel] Re: Developer manual, some suggestions

2015-08-15 Thread Jori Mäntysalo
On Sat, 15 Aug 2015, Nathann Cohen wrote: For example centrality_degree on graphs return Sage rational, not machine float. Rational version is mostly useless, given that it is way way way slower than the other one - - What about teaching or learning purposes? * * * Not relating only to t

Re: [sage-devel] Re: Developer manual, some suggestions

2015-08-15 Thread Jori Mäntysalo
On Sat, 15 Aug 2015, Nathann Cohen wrote: Or else I haven't understood when exactly we are supposed to return Integer objects. How about "If in doubt, return Integer. Otherwise explain."? I think that the reason for returning a single int or double can be efficiency. In reality it of course

Re: [sage-devel] using cdef to avoid code duplication?

2015-08-15 Thread mmarco
I can see reasons why adding a doctest might not be necessary, but... is there any reason why it would be counter-productive? I mean, if the worst thing that can happen for adding the doctest is that the source code becomes four lines longer just doctest it and be done. -- You received thi

Re: [sage-devel] using cdef to avoid code duplication?

2015-08-15 Thread Volker Braun
On Saturday, August 15, 2015 at 7:27:17 PM UTC+2, Jeroen Demeyer wrote: > > * Do not make a function/method "cdef" unless there is a specific > reason, for example performance or a need of C calling convention. > +1 * In general I don't think that the "100% coverage rule" should be taken > to

Re: [sage-devel] using cdef to avoid code duplication?

2015-08-15 Thread Jeroen Demeyer
Two orthogonal comments: * Do not make a function/method "cdef" unless there is a specific reason, for example performance or a need of C calling convention. * In general I don't think that the "100% coverage rule" should be taken too literal. I think it's more important that code is well tes

Re: [sage-devel] Re: Developer manual, some suggestions

2015-08-15 Thread Nathann Cohen
> You are not fair. You changed the specification of the function from > returning rationals to floats. And then, I complained that rationals are > exact and the function was not taking care of error propagation when doing > floating point operations. O_o It's hardly the place to debate this, but

Re: [sage-devel] Re: Developer manual, some suggestions

2015-08-15 Thread Vincent Delecroix
On 15/08/15 18:45, Nathann Cohen wrote: What functions return for example python double? The MixedIntegerLinearProgram code, for instance. And probably many others. Either way, if you want to prevent functions from returning 'int', I don't get why you would allow float/double. That would be ver

Re: [sage-devel] Re: Developer manual, some suggestions

2015-08-15 Thread Nathann Cohen
> What functions return for example python double? The MixedIntegerLinearProgram code, for instance. And probably many others. Either way, if you want to prevent functions from returning 'int', I don't get why you would allow float/double. That would be very surprising. > For example > centrality

Re: [sage-devel] Re: Developer manual, some suggestions

2015-08-15 Thread Jori Mäntysalo
On Sat, 15 Aug 2015, Nathann Cohen wrote: Are we heading toward a special role of 'int' in Sage? Why aren't all python types like long/float/double considered similarly? How is that justified? What functions return for example python double? For example centrality_degree on graphs return Sag

[sage-devel] Re: Developer manual, some suggestions

2015-08-15 Thread Nathann Cohen
> > 1) We should add some words about int vs. Integer on developer manual. > Are we heading toward a special role of 'int' in Sage? Why aren't all python types like long/float/double considered similarly? How is that justified? I don't understand this apparent obsession with 'int' over all ty

[sage-devel] Developer manual, some suggestions

2015-08-15 Thread Jori Mäntysalo
1) We should add some words about int vs. Integer on developer manual. 2) I suggest NOT explicitly saying that the function has no arguments at all; it should be clear from the function prototype. See http://trac.sagemath.org/ticket/17693 comment 16 which refers to developer manual. And is it

[sage-devel] Re: using cdef to avoid code duplication?

2015-08-15 Thread Dima Pasechnik
On Saturday, 15 August 2015 01:30:18 UTC-7, Volker Braun wrote: > > There isn't really enough data to decide. > > As I tried to explain, pasting the code of helper() into A and into B would lead to two sufficiently doctested functions. The decision to make helper() a separate function is merely

[sage-devel] matrix.subs()

2015-08-15 Thread Vincent Delecroix
Hello, As mentioned by Søren on ask [1] the subs method of matrices behave differently than the subs method on coefficients sage: R. = PolynomialRing(ZZ) sage: m = matrix(R, [[x]]) sage: x.subs(3).parent() # parent *does* change Integer Ring sage: m.subs(3).parent() # parent *doe

[sage-devel] Re: using cdef to avoid code duplication?

2015-08-15 Thread Volker Braun
There isn't really enough data to decide. * Does testing A and B provide full coverage of the helper? * Is the helper performance-critical? * Do you need Cython? * If no, why is the code in that module at all? Source files in Sage are almost always too long to comfortably read, the default sh