Hi,
Just to mention that fflas-ffpack and LinBox have been improving recently, wrt
computation speed of
most basic routines, and in particular with addition and improvement of kernels
for efficient matmul
over Z and large Z/pZ.
Benchmarketing is in progress, but matmul seems to compare favorably wrt FLINT
especially with large
bitsizes and dimensions.
The instance given in ticket #16803 (n=1000 range(10^6)) runs in 469ms on one
i5-3320M core of my
laptop.
While there's still more work in progress, the code has been released in
fflas-ffpack-2.0 10 days
ago and will soon be exposed in LinBox and our next step is of course to update
the sage spkg's,
which will definitely happen this coming year.
Well all this rant and marketing is just to advocate that sage keeps its
ability to link against
various libraries and be able to select the best code available at the moment.
Best
Clément
Le 13/08/2014 15:32, Martin Albrecht a écrit :
> On Wednesday 13 Aug 2014 04:27:54 Marc Masdeu wrote:
>> Alright, so the data available with the new implementation is different,
>> since everything is encapsulated into flint types. What would be the right
>> approach? Should I keep the old types and provide conversion functions, or
>> should the different functions decide on other algorithms depending on some
>> heuristics (which should be re-done)?
>
> I would suggest to write conversion functions from fmpz_mat_t to pari,
> linbox,
> iml, NTL and back. Then use those to to convert to, run the computation, and
> convert back.
>
> As for the heuristics, I would start with FLINT being the default but would
> check if alternative implementations beat it for the values suggested by the
> old heuristics.
>
>> Also, do you think it is worth keeping the native code (the one written by
>> William) -- especially for the basic functionality --, or this should be
>> considered superseded by the FLINT functionality?
>
> I would consider it superseded once all missing features are ported over. I
> would not keep it around, that's a maintenance nightmare.
>
>> For now, and as an intermediate step, I will reincorporate the calls to
>> other packages but set the defaults to using flint whenever possible.
>>
>> Thanks for the feedback!
>>
>> Marc.
>>
>> On Tuesday, August 12, 2014 7:00:38 PM UTC+1, wstein wrote:
>>> On Tue, Aug 12, 2014 at 10:52 AM, Martin Albrecht
>>>
>>> <martinr...@googlemail.com <javascript:>> wrote:
>>>> Hi, I like the proposal to move some types over to FLINT. However, you
>>>
>>> removed
>>>
>>>> some options, e.g. calling Pari, LinBox or IML for solving certain
>>>
>>> problems
>>>
>>>> (charpoly, kernel, …). I'd prefer these options to be preserved as it is
>>>
>>> not
>>>
>>>> clear to me a priori that FLINT will in all cases be fastest. Also,
>>>
>>> having
>>>
>>>> choices allows to compare results.
>>>
>>> +1. In my experience, having implemented Matrix_integer_dense in the
>>> first place, most systems that we call are full of bugs. It's almost
>>> never the case that any of the claimed functions, e.g., charpoly,
>>> kernel, etc. aren't buggy. It's critical (and disturbing) to run test
>>> code comparing the various systems with various random (and not)
>>> inputs.
>>> Also, there are some systems like linbox that have proof=False
>>> options, which can be faster, but will in fact be very wrong,
>>> especially in corner cases.
>>>
>>> I also noticed your patch removes a bunch of verbose output. Why?
>>> Having the potential for logging when running code is very useful:
>>>
>>> - t = verbose('hermite mod %s'%D, caller_name='matrix_integer_dense')
>>> cdef Matrix_integer_dense res =
>>> self._new_uninitialized_matrix(self._nrows, self._ncols)
>>> self._hnf_modn(res, D)
>>> - verbose('finished hnf mod', t, caller_name='matrix_integer_dense')
>>>
>>> william
>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On Tuesday 12 Aug 2014 10:12:04 Marc Masdeu wrote:
>>>>> Hi,
>>>>>
>>>>> Recently I noticed that Sage was not using fmpz_mat_t for matrices
>>>>> (probably when FLINT was incorporated in Sage it didn't yet have this).
>>>
>>> I
>>>
>>>>> have opened a ticket (http://trac.sagemath.org/ticket/16803 --thanks
>>>>> pbruin!--) with a patch that reimplements matrix_integer_dense with
>>>
>>> FLINT,
>>>
>>>>> and it would probably be a good idea to do a similar thing for
>>>
>>> fmpq_mat_t.
>>>
>>>>> In any case, I am new to FLINT so I might not be doing the right
>>>
>>> things, if
>>>
>>>>> any expert is willing to review the ticket it would be great!
>>>>>
>>>>> Best,
>>>>>
>>>>> Marc.
>
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
