On May 12, 10:37 am, William Stein <wst...@gmail.com> wrote:
> 2009/5/12 mabshoff <mabsh...@googlemail.com>:
<SNIP>
> I can resolve the failure in gen.pyx easily: Just completely delete
> the finitefield_init function!
Well, nuking functionality is always a solution ;)
> This pari function has always been
> flakie, IMHO, and is used nowhere else in SAge. It used to be used by
> Sage to make finite fields, but I just had a look and it is not used
> anywhere else in Sage (it's commented out). Instead we use some code
> written in Sage itself.
>
> sage: search_src('finitefield_init')
> rings/finite_field_ext_pari.py: #
> self.__pari_modulus = pari.pari.finitefield_init(self.__char,
> self.__degree, self.variable_name())
>
> In that file I write
> # The following is fast/deterministic, but has serious
> problems since
> # it crashes on 64-bit machines, and I can't figure out why:
> # self.__pari_modulus =
> pari.pari.finitefield_init(self.__char, self.__degree,
> self.variable_name())
> # So instead we iterate through random polys until we
> find an irreducible one.
Craig mentioned in IRC late last night that it seemed to be "losing"
the upper 32 bits somehow, i.e. if he "added it back" it made the
doctest pass. I am not sure it this is a pari, a gen.pyx or whatever
problem. It might be worth spending an hour or two on to get this
fixed, especially if it is a pari bug :)
> William
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
