Re: [flint-devel] FLINT 1.4 Released!

[Bill H. <goo...@go...>]

Hi Burcin,

Great that everything works. The easiest way to write a test function
is to cut and paste an existing one. It shouldn't be too hard to
convert random poly to zmod_polys then use the evaluate or composition
functions there, then compare the results. In some cases it is hard to
do randomised testing because it is difficult to find a simpler way of
writing the function so that you have a trusted implementation to
compare against. In such cases I tend to look for some algebraic way
of testing the result, e.g. Test addition by subtracting the addend
back off and see if you get the same thing back. I rarely check
individual cases but try to implement the randomised testing in such a
way as to pick up corner cases.

I don't actually have HG, but I can accept patches in git, svn or
standard patch format.

If it would help, I can easily give you svn access, if you have a
sourceforge account.

Bill.

On 27/07/2009, Burcin Erocal <bu...@er...> wrote:
> Hi Bill,
>
> On Thu, 16 Jul 2009 03:52:21 +0100
> Bill Hart <goo...@go...> wrote:
>
>> I've added the functions you supplied, to fmpz_poly.c/h in trunk. At
>> your leisure, could you verify they actually work with your code. I've
>> made some minor changes to them, but I haven't added test code or
>> documentation (feel free to supply it if you feel that the functions
>> could be of more general use).
>>
>> Once you are happy with them, I'll make the release tarball.
>
> I finally found the time to test the new functions. Everything seems to
> work fine, so I'm happy. :)
>
> I can try to write test code, and/or documentation tomorrow. Is there
> any convention or instructions on writing tests in FLINT? Should I just
> pick random polynomials and values, evaluate things using the functions
> and "by hand", then check the results?
>
>
>> I'm sure you have your git repo hooked up to the FLINT svn, but if
>> not, here is the FLINT trunk:
>>
>> http://flint.svn.sourceforge.net/svnroot/flint/trunk
>
> I am not really an advanced git/hg/svn guy. I might try doing this with
> hg tomorrow, or just generate patches the old fashioned way.
>
>
>> One other major improvement would be divide and conquer for
>> zmod_poly_compose. This would actually be asymptotically faster I
>> believe. In the case of zmod_poly_evaluate, I believe Horner's method
>> is asymptotically fast. I don't know if translate would be faster with
>> a divide and conquer strategy.
>
> The paper I referred to earlier,
>
> http://doi.acm.org/10.1145/258726.258745
>
> suggests that method D "Paterson & Stockmeyer's (1973) method" is
> asymptotically faster than divide & conquer or Horner's. I am sure I'll
> have bigger problems elsewhere if I have to translate polynomials of
> degree ~512 though.
>
>
> Many thanks.
>
> Burcin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>