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 > > > > <[email protected] <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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
