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.
