[sage-devel] Re: VOTE: move Sage development to Github

[Alex J Best]

+1 for github

On Wednesday, September 21, 2022 at 7:23:36 PM UTC+2 David Roe wrote:

> Dear Sage developers,
> Following extensive discussion, both recently 
>  
> (prompted 
> by issues upgrading the trac server) and over 
>  the 
>  last 
>  
> decade 
> , we 
> are calling a vote on switching Sage development from Trac 
>  to Github .  We've 
> created a summary of the pros and cons of each system 
> , a 
> description 
> of the development model to be used on github 
> , 
> and a trac ticket  for 
> coordinating work on the transition.  More work will need to be done to 
> carry out the actual transition once voting is complete.
>
> The voting will last until noon Eastern time (16:00 UTC) on Wednesday, 
> October 5.  Please use this thread only for sending votes, to make it 
> easier to count them afterward; there is a parallel thread where you can 
> make arguments in favor of either system.
>
> Finally, I will close with a plea to be involved in this vote and 
> discussion even if you are not a core Sage developer.  By definition, core 
> Sage developers have become comfortable with trac, and I think that one of 
> the major arguments in favor of github is that it will help bring in new 
> contributors who are not familiar with Sage's development workfow 
> .  Anyone who has 
> ever contributed to the Sage code base or who maintains a Sage user package 
> is welcome to vote.
> David
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c2402862-5a03-41c7-8e0b-06ecdf7a19f9n%40googlegroups.com.

Re: [sage-devel] Re: RFC: zn_poly removal

[Alex J Best]

Right, that seems like a fair benchmark to me, does zn_poly (falling back 
to ntl) run faster than the force ntl = 1 version in enough ranges of 
variables to justify its continued existence?
Knowing whether it failed and fell back (and hence was slower) or just is 
simply slower doesn't seem to matter compared to the end result, knowing 
where its slower.

Yes exactly, I forgot now why we decided to use force ntl=1 for cyclic 
covers, and indeed I forgot that we did force it completely, I really have 
no idea the reasons that went into that decision anymore unfortunately.

On Tuesday, November 9, 2021 at 10:09:38 PM UTC+1 Michael Orlitzky wrote:

> On Tue, 2021-11-09 at 10:54 -0800, Alex J Best wrote:
> > I agree the situation with zn_poly is a mess, but I think it would be 
> good 
> > to do some actual benchmarks to check if the NTL code is faster or 
> > comparable to the zn_poly version, I don't see any data in the ticket 
> but 
> > you do say "The one thing it does is done better by NTL" so maybe you 
> > already did some?
>
> It would be hard to benchmark without knowing where zn_poly fails. The
> only function in sagelib that uses zn_poly is in hypellfrob.cpp, and it
> has a comment at the top:
>
> Note that the zn_poly version occasionally fails; this happens more 
> frequently for smaller p, but is extremely rare for larger p. This 
> wrapper detects this and falls back on the zz_p/ZZ_p versions, which 
> should never fail.
>
> That's what I meant by "NTL does it better," and any benchmark would
> have to take into consideration the attempts that failed and were
> actually made with NTL instead. Certainly those cases are slower than
> if we'd just used NTL the first time.
>
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7062f8ee-226c-41d6-ab95-ad0b0094d908n%40googlegroups.com.

[sage-devel] Re: RFC: zn_poly removal

[Alex J Best]

I must correct myself: the interval products code via NTL is not used for 
cyclic covers as the force NTL flag is set to true there (thanks David Roe!)

On Tuesday, November 9, 2021 at 7:54:44 PM UTC+1 Alex J Best wrote:

> I agree the situation with zn_poly is a mess, but I think it would be good 
> to do some actual benchmarks to check if the NTL code is faster or 
> comparable to the zn_poly version, I don't see any data in the ticket but 
> you do say "The one thing it does is done better by NTL" so maybe you 
> already did some?
> Computing zeta functions of hyperelliptic curves is pretty fundamental 
> thing to do for many applications in arithmetic geometry, and performance 
> is important there, so it would really be a shame if those applications got 
> significantly slower.
> The decision of whether its worth the maintainence burden should be done 
> with full knowledge of what we are losing, if it turns out its nothing, 
> thats great!
> I also this the claim that it's only used in one place undersells it a 
> little bit, the wrapped function `interval_products` is used both in the 
> hyperelliptic_curves and cyclic_covers modules (since 2018) (
> https://github.com/sagemath/sage/search?q=interval_products), though they 
> are admittedly very related applications, there are a range of parameters 
> with which this code may be called.
>
> On Tuesday, November 9, 2021 at 2:25:59 PM UTC+1 Michael Orlitzky wrote:
>
>> Trac: https://trac.sagemath.org/ticket/32841 
>>
>> In short, zn_poly is one of "those" packages. Abandoned in 2008, and 
>> kept on life support by sage developers ever since. Despite our 
>> efforts, the build system remains crazy and it would take a good bit of 
>> time to re-do the whole thing using autotools or cmake or whatever to 
>> make it reliable and easy to package. 
>>
>> And it turns out, the sage library doesn't really need it any more. The 
>> one thing it does is done better by NTL. 
>>
>> I'm posting here because it's a standard SPKG, but I think removal is a 
>> clear win in this case. Smaller tarballs, faster build times, easier on 
>> packagers, and no more time wasted updating zn_poly for new compilers 
>> and operating systems. 
>>
>> But if any number theorists think I've overlooked something, please 
>> speak up. 
>>
>>
>>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f7540468-370c-4145-b4d8-cae831dce64en%40googlegroups.com.

[sage-devel] Re: RFC: zn_poly removal

[Alex J Best]

I agree the situation with zn_poly is a mess, but I think it would be good 
to do some actual benchmarks to check if the NTL code is faster or 
comparable to the zn_poly version, I don't see any data in the ticket but 
you do say "The one thing it does is done better by NTL" so maybe you 
already did some?
Computing zeta functions of hyperelliptic curves is pretty fundamental 
thing to do for many applications in arithmetic geometry, and performance 
is important there, so it would really be a shame if those applications got 
significantly slower.
The decision of whether its worth the maintainence burden should be done 
with full knowledge of what we are losing, if it turns out its nothing, 
thats great!
I also this the claim that it's only used in one place undersells it a 
little bit, the wrapped function `interval_products` is used both in the 
hyperelliptic_curves and cyclic_covers modules (since 2018) 
(https://github.com/sagemath/sage/search?q=interval_products), though they 
are admittedly very related applications, there are a range of parameters 
with which this code may be called.

On Tuesday, November 9, 2021 at 2:25:59 PM UTC+1 Michael Orlitzky wrote:

> Trac: https://trac.sagemath.org/ticket/32841
>
> In short, zn_poly is one of "those" packages. Abandoned in 2008, and
> kept on life support by sage developers ever since. Despite our
> efforts, the build system remains crazy and it would take a good bit of
> time to re-do the whole thing using autotools or cmake or whatever to
> make it reliable and easy to package.
>
> And it turns out, the sage library doesn't really need it any more. The
> one thing it does is done better by NTL.
>
> I'm posting here because it's a standard SPKG, but I think removal is a
> clear win in this case. Smaller tarballs, faster build times, easier on
> packagers, and no more time wasted updating zn_poly for new compilers
> and operating systems.
>
> But if any number theorists think I've overlooked something, please
> speak up.
>
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5e284eb8-8b74-4e4d-bdf4-27d18c4e7b84n%40googlegroups.com.

Re: [sage-devel] Matrix(GF(2^n)) with large n not working on SageMath 9.1

[Alex J Best]

Looks like this is probably fixed by https://trac.sagemath.org/ticket/29818

On Friday, August 14, 2020 at 12:24:00 AM UTC-4 dmo...@deductivepress.ca 
wrote:

> I confirm that the error occurs on CoCalc  (with the 
> 9.1 or Development kernel), so there certainly seems to be a bug somewhere, 
> even though I do not get an error on my own computer (MacOS 10.15.5).
>
> F. = GF(2 ^ 64)
> Matrix(F, 5, 5)
> ---
> OverflowError Traceback (most recent call last)
>  in ()
>   1 F = GF(Integer(2) ** Integer(64), names=('x',)); (x,) = 
> F._first_ngens(1)
> > 2 Matrix(F, Integer(5), Integer(5))
>
> /ext/sage/sage-dev/local/lib/python3.7/site-packages/sage/matrix/constructor.pyx
>  
> in sage.matrix.constructor.matrix 
> (build/cythonized/sage/matrix/constructor.c:2479)()
> 634 """
> 635 immutable = kwds.pop('immutable', False)
> --> 636 M = MatrixArgs(*args, **kwds).matrix()
> 637 if immutable:
> 638 M.set_immutable()
> /ext/sage/sage-dev/local/lib/python3.7/site-packages/sage/matrix/args.pyx 
> in sage.matrix.args.MatrixArgs.matrix 
> (build/cythonized/sage/matrix/args.c:7846)()
> 660 break
> 661 else:
> --> 662 M = self.space(self, coerce=convert)
> 663 
> 664 # Also store the matrix to support multiple calls of 
> matrix()
> /ext/sage/sage-dev/local/lib/python3.7/site-packages/sage/matrix/matrix_space.py
>  
> in __call__(self, entries, coerce, copy)
> 829 [t]
> 830 """
> --> 831 return self.element_class(self, entries, copy, coerce)
> 832 
> 833 def change_ring(self, R):
> /ext/sage/sage-dev/local/lib/python3.7/site-packages/sage/matrix/matrix_gf2e_dense.pyx
>  
> in sage.matrix.matrix_gf2e_dense.Matrix_gf2e_dense.__cinit__ 
> (build/cythonized/sage/matrix/matrix_gf2e_dense.c:3774)()
> 171 
> 172 cdef long i
> --> 173 cdef m4ri_word poly = sum(((c) << i) for (i, c) 
> in enumerate(f))
> 174 
> 175 if alloc and self._nrows and self._ncols:
>
> OverflowError: Python int too large to convert to C unsigned long
>
>
> On Thursday, August 13, 2020 at 3:59:11 PM UTC-6 maxime...@inria.fr wrote:
>
>> On 13/8/20 8:02 pm, Zihan Zheng wrote:
>>
>> Hi developers, 
>>
>> I think I found a bug of SageMath 9.1
>>
>> *F. = GF(2 ^ 64)*
>> *Matrix(F, 5, 5)*
>>
>> This piece of code runs without error on SageMath 8.9 and 9.0, but throws 
>> error on 9.1
>>
>> (reproducible on cocalc.com)
>>
>> *OverflowError: Python int too large to convert to C unsigned long*
>>
>> Best,
>> Zihan
>>
>> -- 
>> 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 sage-devel+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/366187ef-d6bf-4dbf-a55a-9db2a243d9cen%40googlegroups.com
>>  
>> 
>> .
>>
>> Hi, 
>>
>> it works very well for me, even for (much) larger fields.
>>
>> sage: F. = GF(2^16384)
>> sage: Matrix(F, 5, 5)
>> [0 0 0 0 0]
>> [0 0 0 0 0]
>> [0 0 0 0 0]
>> [0 0 0 0 0]
>> [0 0 0 0 0]
>>
>> Can you be more specific ? What version of python are you using ? And on 
>> which OS ?
>>
>> Best,
>>
>> -- 
>> Maxime
>>
>>
>>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/46cd219d-65ba-42fb-9fe6-3f96dc0d5751n%40googlegroups.com.

Re: [sage-devel] Re: Sage 8.0 Build Error on MacOS, [mpir-3.0.0.p0] Error building MPIR.

[Alex J Best]

As the problem is skylake I assume mpn/x86_64/skylake/avx/addmul_1.asm is 
the one to patch out.

On Monday, August 21, 2017 at 11:51:28 AM UTC-4, Dima Pasechnik wrote:
>
>
>
> On Monday, August 21, 2017 at 4:15:29 PM UTC+1, Michael Frey wrote:
>>
>> What is the best way to do this?  The file is extracted from the 
>> mpir-3.0.0.tar.bz2 every time make is run.
>>
>
> the standard way would be to add the patch removing  this file (which one 
> exactly, there are few files named so?)
> build/pkgs/mpir/patches/
>
>
>
>> On Wednesday, August 2, 2017 at 5:41:01 PM UTC-4, Bill Hart wrote:
>>>
>>> The only workaround I'm currently aware of is to remove the offending 
>>> addmul_1.asm file. It is to do with our use of jump tables.
>>>
>>>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: 5.5. release notes

[Alex J Best]

Okay done, yeah you're right this shows a bit more of a trend.
https://docs.google.com/spreadsheet/ccc?key=0AkPdD0Nnsj7BdDBENDRxTVNtR3c2VEVPeWpSN3BvV1E

On Thursday, December 27, 2012 10:17:10 AM UTC, Jeroen Demeyer wrote:

 I think days since last release is not very meaningful. Can you try 
 tickets in this release instead to measure the size of a release? 


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Re: 5.5. release notes

[Alex J Best]

I'm afraid this isn't particularly cool looking but, here is some data and 
a couple of charts:
https://docs.google.com/spreadsheet/ccc?key=0AkPdD0Nnsj7BdDBENDRxTVNtR3c2VEVPeWpSN3BvV1E
I was hoping to see some stronger trends, but I think due to the nature of 
Sage development (Sage days etc.) there isn't any hugely obvious 
correlations in the data (or I'm doing something wrong of course!).

On Wednesday, December 26, 2012 11:34:43 PM UTC, kcrisman wrote:



 On Wednesday, December 26, 2012 3:27:43 PM UTC-5, Harald Schilly wrote:



 On Wednesday, December 26, 2012 8:24:14 PM UTC+1, Jan Groenewald wrote:

 The following 59 people contributed to this release. Of those, 4 made
 their first contribution to Sage:

 Is there a graph of this over time?

  
 Not that I'm aware of. Therefore: the source data for this weeks Sage 
 homework challange is here:

 http://sagemath.org/mirror/src/changelog.txt


 Make your answer as cool as some of those at 
 http://hubwaydatachallenge.org/ and we'll put them on the website, FB, 
 G+, etc.!


-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.