Thanks for looking into that David and Martin. It certainly saved a whole load of headache for me!!
Bill. On 31 May, 06:46, David Harvey <dmhar...@cims.nyu.edu> wrote: > This is nowhttp://sagetrac.org/sage_trac/ticket/6168. > > david > > On May 30, 12:03 pm, Bill Hart <goodwillh...@googlemail.com> wrote: > > > Regarding compilation with debug, zn_poly is passed the flag -DNEBUG > > for a couple of files, instead of -DNDEBUG. This is a sloppy typo on > > my part. Originally I think I took the output from the zn_poly > > configure script, but in the latest version there were some new files, > > and I guess I added the targets by hand to the FLINT makefile. > > > At any rate, that is not the cause of our problems, and I will fix it > > in the next version of FLINT. > > > As for something not being reduced before being passed to zn_poly, it > > is likely that someone assumed FLINT reduces coefficients mod p before > > doing anything with them, which it does not. I met at least one such > > person. It would be a performance issue to do this at any level. > > Instead, FLINT assumes all polynomials it is passed have reduced > > coefficients and it guarantees too return polynomials which respect > > this, except for I think one function (zmod_poly_add_nored I think) > > which would be specifically documented as not doing so. > > > Sorry none of this actually helps find the bug. It is still possible > > of course that zn_poly is actually being passed garbage by FLINT, and > > that garbage just happens to not be reduced. > > > At some point in Martin's wrapper of zmod_poly in Sage, there was an > > option you could switch on to compare the output from FLINT with that > > of Pari. Thus helped us track down the specific polynomial computation > > which caused the issue last time. > > > Bill. > > > On 30 May, 06:11, David Harvey <dmhar...@cims.nyu.edu> wrote: > > > > On May 29, 10:54 pm, David Harvey <dmhar...@cims.nyu.edu> wrote: > > > > > Hmmm let me try again. Would appreciate help from people familiar with > > > > FLINT wrapper and/or coercion system. > > > > > sage: R.<x> = PolynomialRing(Integers(121)) > > > > sage: S.<y> = PolynomialRing(Integers(11)) > > > > sage: S(50*x) > > > > 6*y > > > > sage: R(S(50*x)) > > > > 50*x # !!!!!! > > > > > I think what's actually happening is that the underlying FLINT > > > > zmod_poly object is not getting coefficients reduced into [0, 10]. > > > > This causes other problems indirectly (e.g. #5817). I can't quite > > > > trace why this is happening. Any ideas? > > > > There is a also a performance issue. The following is in sage 3.4.2: > > > > sage: R.<x> = PolynomialRing(Integers(11^6)) > > > sage: S.<y> = PolynomialRing(Integers(11^3)) > > > sage: f = R([ZZ.random_element(11^6) for _ in range(1000000)]) > > > sage: time g = f * f > > > CPU times: user 0.96 s, sys: 0.01 s, total: 0.97 s > > > Wall time: 0.96 s > > > sage: f = S(f) > > > sage: time g = f * f > > > CPU times: user 0.93 s, sys: 0.00 s, total: 0.93 s > > > Wall time: 0.93 s > > > sage: f = S([ZZ.random_element(11^3) for _ in range(1000000)]) > > > sage: time g = f * f > > > CPU times: user 0.55 s, sys: 0.00 s, total: 0.55 s > > > Wall time: 0.55 s > > > > What appears to be happening is that FLINT is using kronecker > > > substitution for the multiplication (packing polynomials into an > > > integer and then multiplying the integers), but in the second > > > multiplication above it is *not* reducing mod 11^3 before doing this. > > > > Even better evidence is the following: if I install flint 1.2.5 (as > > > per trac #5817) I get: > > > > sage: R.<x> = PolynomialRing(Integers(11^6)) > > > sage: S.<y> = PolynomialRing(Integers(11^3)) > > > sage: f = R([ZZ.random_element(11^6) for _ in range(1000000)]) > > > sage: f = S(f) > > > sage: time g = f * f > > > sage.bin: zn_poly/src/zn_poly.h:185: zn_mod_add_slim: Assertion `x < > > > mod->m && y < mod->m' failed. > > > /home/dmharvey/5817/sage-3.4.2-new/local/bin/sage-sage: line 198: > > > 16421 Aborted (core dumped) sage-ipython "$@" -i > > > > This means two things: (1) zn_poly is getting compiled with debug > > > assertions, which it shouldn't, since this is a major performance > > > loss, and (2) some zn_poly routine is getting called on a polynomial > > > with non-normalised coefficients. > > > > But I still don't know exactly where the non-normalisation is > > > happening. > > > > david --~--~---------~--~----~------------~-------~--~----~ 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 For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
