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 -~----------~----~----~----~------~----~------~--~---
