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)?
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?
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.
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
> wst...@uw.edu <javascript:>
>
--
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.
