I suspect some of the changes to matrix construction recently merged might
need some fine tuning.
With the code on
https://trac.sagemath.org/ticket/15113
I ran the following example:
load("picard_group.sage")
n=4
k.=GF(41)
R.=k[]
F=x^3*y+x^3*z+x^2*y^2+x^2*y*z+x^2*z^2+x*y^2*z+x*y*z^2+y^3*z+y*z^
Please try it with https://trac.sagemath.org/ticket/25476; the specialized
_echbelon_in_place_classical code might not have been getting called. (Note
also that it has also become a cpdef method, and IIRC, those don't get
separated as a separate function call by %prun when called from within a
On Monday, June 4, 2018 at 5:30:50 PM UTC-7, Travis Scrimshaw wrote:
>
> Please try it with https://trac.sagemath.org/ticket/25476; the
> specialized _echbelon_in_place_classical code might not have been getting
> called. (Note also that it has also become a cpdef method, and IIRC, those
> don't
On Monday, June 4, 2018 at 5:30:50 PM UTC-7, Travis Scrimshaw wrote:
>
> However, is there an overall speed regression in the test? Can you try it
> on the same machine against 8.3.beta2 and post the total time?
>
>
OK, luckily it's not THAT bad. This is 8.2 vs. 8.3b4 on the same machine.
Runnin
It would be useful to have a concrete MatrixSpace.__call__() call
showing the regression.
--
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...@g
On Monday, June 4, 2018 at 11:10:34 PM UTC-7, Jeroen Demeyer wrote:
>
> It would be useful to have a concrete MatrixSpace.__call__() call
> showing the regression.
>
I suspect that the main slowdowns I am observing are due to the reduced
performance in examples like
M=matrix(GF(37),9,9,range
