Re: [sage-devel] Re: docstring and lazyimport

So, the INPUT section should be at class level? Maybe that would indeed be better because there is __init__ and __call__ and _element_constructor_,... Martin Am Freitag, 22. September 2017 01:56:07 UTC+2 schrieb Travis Scrimshaw: > > IMO, __init__ should not be included in the docstring

Re: [sage-devel] Re: docstring and lazyimport

IMO, __init__ should not be included in the docstring anytime there is something at the class level. Moreover, there should always be documentation at the class level to describe the class. The __init__ docstring should be stuff that is special to the initialization that should not appear at

[sage-devel] Should parent(x) call x.parent()?

After cleaning up some code related to homsets in #23905, I noticed that the new code was about 20% to 30% slower in some cases. I traced this difference to a call R = parent(x) where x was a Python function (so, not a Sage Element). It turns out that parent(x) tries to call x.parent(). If

Re: [sage-devel] Re: ecm failed to build

Hi On 21 September 2017 at 09:21, Jan Groenewald wrote: > Hi > > This is possibly gcc 6.2 related: ​https://mail.coreboot.org/ > pipermail/coreboot/2016-December/082739.html > > And a possible solution is Build GMP --with-pic, (only) if GCC defaults > to -pie (preferred

Re: [sage-devel] Re: docstring and lazyimport

On 2017-09-21 15:34, 'Martin R' via sage-devel wrote: It turns out that this has been noticed before: https://trac.sagemath.org/ticket/20626#comment:2 And there is even a rejected fix! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Sort ambient spaces by inner product as well?

Note that there is no distinction between the FreeModule with inner_product_matrix=matrix.identity(1)*2 and FreeQuadraticModusince the sage object created in both ways is the same object. Not just equal, but literally the same object in memory, so any change will automatically affect both.

[sage-devel] docstring and lazyimport

I just discovered something puzzling with lazyimport: if I import the classes below with from test_doc import * I have the following (desirable) behaviour: * Instance1? gives me the "Generic" class docstring together with the __init__ docstring of Instance1 * Instance2? gives me the

Re: [sage-devel] Should parent(x) call x.parent()?

IMHO, I don't see the point of calling `x.parent()`. This whole machinery is intended for Sage coercion model where you should properly inherit from Element. So +1 for type(x) on non Element. On 21/09/2017 15:07, Jeroen Demeyer wrote: After cleaning up some code related to homsets in #23905,

[sage-devel] Re: docstring and lazyimport

It turns out that this has been noticed before: https://trac.sagemath.org/ticket/20626#comment:2 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [sage-devel] Re: ecm failed to build

Hi This is possibly gcc 6.2 related: ​ https://mail.coreboot.org/pipermail/coreboot/2016-December/082739.html And a possible solution is Build GMP --with-pic, (only) if GCC defaults to -pie (preferred solution from reading the rest of above thread to the end). Regards, Jan On 21 September

Re: [sage-devel] Re: ecm failed to build

Hi On 20 September 2017 at 13:32, Dima Pasechnik wrote: > > > On Wednesday, September 20, 2017 at 8:19:48 AM UTC+1, Jan Groenewald wrote: >> >> Hi >> >> On 20 September 2017 at 08:56, Jan Groenewald wrote: >> >>> Hi >>> >>> On 19 September 2017 at 19:25,

Re: [sage-devel] Re: docstring and lazyimport

So, to try it, is it enough to (rebase and) apply #22752? Am Donnerstag, 21. September 2017 15:46:53 UTC+2 schrieb Jeroen Demeyer: > > On 2017-09-21 15:34, 'Martin R' via sage-devel wrote: > > It turns out that this has been noticed before: > > > >

[sage-devel] Re: Including 64-bit-only code in Sage

On Wednesday, September 20, 2017 at 10:40:39 PM UTC+1, Volker Braun wrote: > > On Wednesday, September 20, 2017 at 12:12:33 PM UTC+2, Dima Pasechnik > wrote: >> >> Still, why don't we start by including this code as an experimental >> package? >> > > > Thats fine, but the way I understood

Re: [sage-devel] Including 64-bit-only code in Sage

On 2017-09-20 02:28, Kiran Kedlaya wrote: Currently, some code is unable to be included in Sage (except as an optional package) because it is not 32-bit safe. One example close to my heart is Drew Sutherland's smalljac package for computing L-series of hyperelliptic curves; Drew's position is

[sage-devel] Sort ambient spaces by inner product as well?

Currently, comparison of free_module_generic (and free_quadratic_modules) ignores the inner product matrix sage: FreeModule(ZZ,1)==FreeModule(ZZ,1,inner_product_matrix=matrix.identity(1)*2) True sage: FreeQuadraticModule(ZZ,1,matrix.identity(1))==FreeQuadraticModule(ZZ,1,matrix.identity(1)*2)