implement fast linear algebra modulo n < 2^31

[malb]

The switch would allow to cover larger primes with the specialised code (and I currently work with primes ~ 2³²).

The switch requires changing all mentions of int to long and probably implementing arith_long.

Depends on #10281

CC: @simon-king-jena @sagetrac-mraum

Component: linear algebra

Issue created by migration from https://trac.sagemath.org/ticket/4968

[sagetrac-mabshoff]

Replying to @malb:

The switch requires changing all mentions of int to long and probably implementing arith_long.

I am not sure using long here is a good idea since on various platforms we want to support sizeof(long) == sizeof (int). You might want to replace it by some typedef so we can make it long long on those platforms.

Cheers,

Michael

[malb]

comment:2

I am not sure using long here is a good idea since on various platforms we want to
support sizeof(long) == sizeof (int). You might want to replace it by some typedef
so we can make it long long on those platforms.

Is your point that the maximum prime for which we use Matrix_modn_dense shouldn't vary across platforms? I didn't think of it before, I can see why this would be desirable. How about "long long" across the board?

[williamstein]

comment:3

How about "long long" across the board?

Won't that have negative implications. For example, on a 32-bit machine all matrices will take twice as much memory to store, and all arithmetic will be an order of magnitude slower. That certainly wouldn't make me happy!

%cython
def foo(n):
    cdef long long i = 10, j = 10093, k
    cdef int z
    for z in range(n):
        k += i*j
    return k
///

%cython
def bar(n):
    cdef int i = 10, j = 10093, k
    cdef int z
    for z in range(n):
        k += i*j
    return k
///

time foo(10^8)
///

587410688573299048L
CPU time: 0.29 s,  Wall time: 0.29 s

time bar(10^8)
///

-171048080
CPU time: 0.04 s,  Wall time: 0.04 s

0.29/0.04
///

7.25000000000000

[sagetrac-mabshoff]

comment:4

Replying to @williamstein:

How about "long long" across the board?

Won't that have negative implications. For example, on a 32-bit machine all matrices will take twice as much memory to store, and all arithmetic will be an order of magnitude slower. That certainly wouldn't make me happy!

Well, assuming we will transparently switch over to another implementation (using gmpz's for example) we should use the "fast" integer type, i.e. 32 bit ints and a 64 bit int type on 64 bit boxen. But my original point remains: On

• 64 bit Solaris
• 64 bit Windows

sizeof(long) == sizeof(int) == 4, so using either a C99 type or some platform dependent typedef is what we need here to get optimum performance on all 64 bit platforms. Since we are already requiring C99 due to FLINT we might as well go for that solution.

Cheers,

Michael

[burcin]

comment:5

I don't know what arith_long is, but the long_extras module of FLINT might help here.

[malb]

comment:7

I'd say this is now a duplicate? of #4260 and should be closed?

[burcin]

comment:8

#4260 doesn't cover your request of modulus > 2³² from the ticket description. Maximum modulus there is 2²³.

We could use the template class from #4260 to provide a matrix class using long longs.

[williamstein]

Dependencies: #10281

[williamstein]

comment:11

Replying to @burcin:

#4260 doesn't cover your request of modulus > 2³² from the ticket description. Maximum modulus there is 2²³.

We could use the template class from #4260 to provide a matrix class using long longs.

I elected not to do this because:

• the template class is very, very heavily tied to linbox, and disentangling that seemed insane. We can't use linbox anyways for primes above 2^23.

• much of the work in writing this patch was spent writing a lot of really good tests that truly exercise the new functionality, and in debugging and properly using the old Strassen code for matrix multiplication and echelon forms. None of that would have been made better by using the template.