[sage-release] Re: Sage 8.1.beta2 released
Hi! The ticket is #23673. Cheers, Simon On 2017-08-22, Simon King wrote: > Hi Travis, > > On 2017-08-21, tsc...@ucdavis.edu wrote: >> It is in a cython file, but it is not a cpdef method. However, I think >> avoiding dict() (and using .iteritems() instead of items() because it is >> Cython [so it is still Py3 compatible]) for non-sparse polynomials is good. >> Actually, as you suggest, using the specific data structures would likely >> be a lot faster. Do you want to start work on this, which I will happily >> review, or do you want me to? > > I am not so sure whether I will tackle specific polynomial types. However, > I think I can provide a speed up of the generic implementation: Instead > of self.dict().items(), one should work with self.list(copy=False), which > is called by self.dict() anyway, thus avoiding the overhead of constructing > a dict and its items: > >sage: R. = SR[] >sage: p = prod(x+i for i in range(60)) >sage: %timeit R([int(v)%123 for v in p.list(copy=False)]) >100 loops, best of 3: 5.13 ms per loop >sage: %timeit p.map_coefficients(lambda z: int(z)%123) >100 loops, best of 3: 11 ms per loop > > And that's in Python (= Sage command line), not Cython. > > Best regards, > Simon > -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Hi Travis, On 2017-08-21, tsc...@ucdavis.edu wrote: > It is in a cython file, but it is not a cpdef method. However, I think > avoiding dict() (and using .iteritems() instead of items() because it is > Cython [so it is still Py3 compatible]) for non-sparse polynomials is good. > Actually, as you suggest, using the specific data structures would likely > be a lot faster. Do you want to start work on this, which I will happily > review, or do you want me to? I am not so sure whether I will tackle specific polynomial types. However, I think I can provide a speed up of the generic implementation: Instead of self.dict().items(), one should work with self.list(copy=False), which is called by self.dict() anyway, thus avoiding the overhead of constructing a dict and its items: sage: R. = SR[] sage: p = prod(x+i for i in range(60)) sage: %timeit R([int(v)%123 for v in p.list(copy=False)]) 100 loops, best of 3: 5.13 ms per loop sage: %timeit p.map_coefficients(lambda z: int(z)%123) 100 loops, best of 3: 11 ms per loop And that's in Python (= Sage command line), not Cython. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Hey Simon, Sorry for my delay, I was on a transpacific flight and recovering from that. > > On 2017-08-17, tsc...@ucdavis.edu > wrote: > >> What kind of polynomials is involved in that test? libsingular? > > > > I believe they are the generic polynomials: > > > > sage: type(M.some_elements()[3]._x) > > > > 'sage.rings.polynomial.polynomial_ring.PolynomialRing_field_with_category.element_class' > > > > Hm. Then I wonder how one could speed-up the coefficient mapping. > map_coefficients > is cython already. Certainly for things like libsingular polynomials it > would be > a *lot* faster to not use the generic implementation, that's why I was > asking. > > It is in a cython file, but it is not a cpdef method. However, I think avoiding dict() (and using .iteritems() instead of items() because it is Cython [so it is still Py3 compatible]) for non-sparse polynomials is good. Actually, as you suggest, using the specific data structures would likely be a lot faster. Do you want to start work on this, which I will happily review, or do you want me to? Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Hi Travis, On 2017-08-17, tsc...@ucdavis.edu wrote: >> What kind of polynomials is involved in that test? libsingular? > > I believe they are the generic polynomials: > > sage: type(M.some_elements()[3]._x) > 'sage.rings.polynomial.polynomial_ring.PolynomialRing_field_with_category.element_class' Hm. Then I wonder how one could speed-up the coefficient mapping. map_coefficients is cython already. Certainly for things like libsingular polynomials it would be a *lot* faster to not use the generic implementation, that's why I was asking. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Addendum: _.__mro__ (, , , , , , , ... -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Hey Simon,
>
> On 2017-08-17, tsc...@ucdavis.edu > wrote:
> > about half of the time is in
> >
> > {method 'map_coefficients' of
> > 'sage.rings.polynomial.polynomial_element.Polynomial' objects}
> >
> > and subfunction calls. I would say a better solution would include
> > improving Polynomial.map_coefficients(). It probably would benefit from
> > more specialized implementations, specifically sparse and dense
> > implementations, as well as cythonization.
>
> What kind of polynomials is involved in that test? libsingular?
>
> I believe they are the generic polynomials:
sage: type(M.some_elements()[3]._x)
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Hi Travis,
On 2017-08-17, tsc...@ucdavis.edu wrote:
> about half of the time is in
>
> {method 'map_coefficients' of
> 'sage.rings.polynomial.polynomial_element.Polynomial' objects}
>
> and subfunction calls. I would say a better solution would include
> improving Polynomial.map_coefficients(). It probably would benefit from
> more specialized implementations, specifically sparse and dense
> implementations, as well as cythonization.
What kind of polynomials is involved in that test? libsingular?
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
>
>
> Indeed.
>
> sage -t --long --warn-long 75.4 src/sage/rings/function_field/
> function_field.py
> **
> File "src/sage/rings/function_field/function_field.py", line 69, in sage.
> rings.function_field.function_field
> Warning, slow doctest:
> TestSuite(M).run() # long time (52s on sage.math, 2012)
> Test ran for 194.71 s
> [457 tests, 251.53 s]
> --
> All tests passed!
> --
> Total time for all tests: 251.7 seconds
> cpu time: 249.2 seconds
> cumulative wall time: 251.5 seconds
>
> No doctest should take more than 30 seconds, according to the developer
> guide. Hence these long tests should be deleted.
>
Has someone checked to see if there has been a serious performance
regression on that test over the past few beta versions?
However, I do not think we should remove the doctest. From looking at the
TestSuite run, the _test_derivation() took, by far, the longest amount of
time. So a good method going forward would be to skip that test (similar to
the following 2 doctests) and then run that specific test on a smaller set
of elements (some_elements() returns 58 of them, so that is 58^2 = 3364
over , maybe 4 or 5:
sage: %time M._test_derivation(elements=M.some_elements()[:5])
CPU times: user 2.3 s, sys: 24 ms, total: 2.32 s
Wall time: 2.26 s sage: S = M.some_elements()
sage: S = M.some_elements()
sage: %time M._test_derivation(elements=S[:5])
CPU times: user 1.32 s, sys: 12 ms, total: 1.34 s
Wall time: 1.29 s
>From looking at %prun, about 1/3 of the time is spent within the method
maps.py:217(_call_), which is accumulating the C/cython function calls, and
about half of the time is in
{method 'map_coefficients' of
'sage.rings.polynomial.polynomial_element.Polynomial' objects}
and subfunction calls. I would say a better solution would include
improving Polynomial.map_coefficients(). It probably would benefit from
more specialized implementations, specifically sparse and dense
implementations, as well as cythonization.
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-release+unsubscr...@googlegroups.com.
To post to this group, send email to sage-release@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Indeed. sage -t --long --warn-long 75.4 src/sage/rings/function_field/function_field .py ** File "src/sage/rings/function_field/function_field.py", line 69, in sage. rings.function_field.function_field Warning, slow doctest: TestSuite(M).run() # long time (52s on sage.math, 2012) Test ran for 194.71 s [457 tests, 251.53 s] -- All tests passed! -- Total time for all tests: 251.7 seconds cpu time: 249.2 seconds cumulative wall time: 251.5 seconds No doctest should take more than 30 seconds, according to the developer guide. Hence these long tests should be deleted. -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
Re: [sage-release] Re: Sage 8.1.beta2 released
On 2017-08-16 03:07, richar...@lozestech.com wrote: Failed example: E.cremona_label() Expected: Traceback (most recent call last): ... RuntimeError: Cremona label not known for Elliptic Curve defined by y^2 + y = x^3 - 79*x + 342 over Rational Field. Got: '19047851a1' ** This should be fixed by https://trac.sagemath.org/ticket/23609 -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
On Wednesday, August 16, 2017 at 3:15:26 AM UTC+2, rich...@lozestech.com wrote: > > Under openSUSE LEAP 42.2, fresh git-clone + pull develop, all today, got > the following error during ptest (-j4): > Cannot confirm on openSUSE LEAP 42.2 using ten attempts of sage -tp src/sage/schemes/elliptic_curves/ell_rational_field.py -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
Under openSUSE LEAP 42.2, fresh git-clone + pull develop, all today, got the following error during ptest (-j4): ** File "src/sage/schemes/elliptic_curves/ell_rational_field.py", line 3972, in sage.schemes.elliptic_curves.ell_rational_field.EllipticCurve_rational_field.cremona_label Failed example: E.cremona_label() Expected: Traceback (most recent call last): ... RuntimeError: Cremona label not known for Elliptic Curve defined by y^2 + y = x^3 - 79*x + 342 over Rational Field. Got: '19047851a1' ** - Richard -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
On Ubuntu 16.04 x86_64 (Intel Core i7-6700HQ + 16 GB RAM), from a fresh git clone + pull develop, parallel (-j8) build OK and ptestlong passed. Eric. -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-release+unsubscr...@googlegroups.com. To post to this group, send email to sage-release@googlegroups.com. Visit this group at https://groups.google.com/group/sage-release. For more options, visit https://groups.google.com/d/optout.
[sage-release] Re: Sage 8.1.beta2 released
On Debian testing running on Core i7 + 16 GB RAM, ptestlong gives two failures : -- sage -t --long src/sage/rings/function_field/function_field.py # Timed out sage -t --long src/sage/libs/gap/assigned_names.py # 1 doctest failed -- The second one is transient (succeeds when ran standalone). The first one may be genuine : charpent@asus16-ec:/usr/local/sage-8$ sage -t --long src/sage/rings/function_field/function_field.py too many failed tests, not using stored timings Running doctests with ID 2017-08-14-12-17-29-2464ab86. Git branch: develop Using --optional=database_gap,giacpy_sage,git_trac,mpir,python2,sage Doctesting 1 file. sage -t --long src/sage/rings/function_field/function_field.py [458 tests, 677.75 s] -- All tests passed! -- Total time for all tests: 677.8 seconds cpu time: 677.5 seconds cumulative wall time: 677.7 seconds 677 seconds is, indeed, an alarming time, and might well be larger than the (unknown to me) timeout threshold. It might be useful to divide this in subtasks, but is this possible ? HTH, -- Emmanuel Charpentier Le lundi 14 août 2017 00:28:06 UTC+2, Volker Braun a écrit : > > As always, you can get the latest beta version from the "develop" git > branch. Alternatively, the self-contained source tarball is at > http://www.sagemath.org/download-latest.html > > effcedb Updated SageMath version to 8.1.beta2 > 9e9bcc2 Trac #23492: Graph automorphism: Remove a warning block > 49de1ee Trac #23027: Error in conflict resolution documentation > e7bd1ac Trac #13591: Improve padic add_bigoh > c35929e Trac #23597: More use for master bib; order of examples and seealso > 8a6670e Trac #23495: R[x]→S[x] is injective/surjective if R→S is > 5a2a9dc Trac #23456: Compute Gauss sums with Gross-Koblitz formula > f215b82 Trac #23210: immediate dominators and strong articulation points > cb5106c Trac #23611: Fix coercion in polynomial division > 062356f Trac #23607: Matrix.__str__: always show the entries > 0bdf464 Trac #23598: __bool__ for free modules > cd152cc Trac #22400: Transpose text databases of reflexive polytopes for > PALP > d9b1fe8 Trac #21124: Real/Complex number str() method: do not truncate by > default and allow specifying number of digits > 6fdc7c4 Trac #23185: A polynomial ring embeds into its fraction field > 947c2a4 Trac #8423: Add code to plot Julia sets > 59727a3 Trac #23606: Add some abstract methods to Laurent polynomials base > class > 21f9dce Trac #23603: Fix cpdef declaration issues in modular and number > fields > 028ab58 Trac #23592: Faster comparison of manifold points > f8edd55 Trac #23591: py3: more absolute imports in pyx files > 3445b62 Trac #23589: py3: adding absolute imports in many pyx files > 3e1577d Trac #23588: py3 : small changes in unicode art and ascii_art > 0a404b5 Trac #23584: some details in misc/misc.py > cc6f721 Trac #23551: Python 3 print in doctests > 13fe81e Trac #23543: Upgrade PARI to 2.9.3 > c1bc6d3 Trac #23499: Compute conductor of abelian fields > e52d022 Trac #23491: Don't use MethodType to assign methods to a class > 115a65d Trac #23408: py3: richcmp for algebraic closures of finite fields > 6d0d1b3 Trac #23375: Cannot pull back from PBW basis to Lie algebra > 23718e4 Trac #23329: Implement characteristic() for ring of coordinate > functions > a88a6e6 Trac #23227: Add cpdef declarations in pxd files when overwriting > a cdef method > fc058c7 Trac #22951: Integrated curves and geodesics on manifolds > 527e4d3 Trac #22588: Let "make doc" really always work > 886ed8d Trac #20310: change for p-adic rings > 44fba6b Trac #14153: Add Unicode support to the doctesting framework > 8ca3ace Trac #23604: Fix spkg scripts for deformation package > 2e35d4b Trac #23574: Typos of doubled word / part 3 > bb4c2a0 Trac #23485: Ring morphisms should not override __richcmp__ > fb6e3fa7 Trac #23484: Zmod(nm) → Zmod(n) is surjective but not injective > 6b553b5 Trac #23483: ZZ → Zmod is surjective but not injective > d856e57 Trac #23481: Fix typo in is_surjective > df0584c Trac #20300: DirichletGroup should not allow negative modulus > c759d8b Trac #23455: Removing notes directory > c3371e9 Trac #23396: Typos of doubled word / part 2 > 104fd87 Trac #23393: Typos where where a word word is doubled > 09c0e42 Trac #23340: Unify test: vs. tests:: > 46b1023 Trac #23558: More use for PackageNotFoundError > 563d51e Trac #23548: a load of typos > e21c7ef Trac #23532: Update links in Three.js examples > af2799c Trac #23526: bad syntax in trac role and raise > 73f6c84 Trac #23525: implement is_squarefree for p-adic rings > cfca4df Trac #23512: Update Dokchitser's L-function script > 15fce90 Trac #23509: Find all completely split primes in a number field up > to some bound > 6ca4
