flintlib / antic Goto Github PK

To store a quadratic element only two integers are needed for the numerator. But this is declared as

typedef struct /* element of a quadratic number field */
{
   fmpz num[3];
   fmpz_t den;
} qnf_elem_struct;
typedef qnf_elem_struct qnf_elem_t[1];

It would better be documented what does the third term in the numerator is used for (and if we are free to use it as a temporary variable).

In 2d6a93c antic was adapted to API changes in flint 2.7. In e-antic we would like to support both flint 2.6 and 2.7 to make upgrading easier.

I could add a few #ifdefs to make antic work with flint 2.6 and 2.7. Should I go ahead and create a Pull Request?

Can be causing #74. Hard to know without any tests for the function.

Edit: It would still be nice to know that these work as intended.

Make check fails. Attached You will find more info of failure. Preliminary steps done before running tests:
./configure
make clean
make
make check
antic_make_check_fail.txt

It's not clear which functions are meant to support delayed reduction. For example, nf_elem_add does, but nf_elem_add_fmpq and nf_elem_scalar_mul_fmpq (surprisingly) do not.

It would be great if this was documented, and consistently tested.

In fact, nf_elem_mul_red is not tested at all, which is a bit worrying.

The license file that was just added says LGPL2.1 but most files say GPL2+ in their headers. Would you mind adding something to the readme that clarifies the license situation? Is it LGPL2.1-or-later?

Since I updated flint to 2.9.0 in Debian, antic broke (see the red Regression links):

make: Entering directory '/tmp/autopkgtest-lxc.ahzsw60a/downtmp/autopkgtest_tmp/tests/nf'
cc -I/usr/include/antic    t-init_clear.c  -lantic -lflint -lgmp -o t-init_clear
+-+-+-+ t-init_clear +-+-+-+
init/clear....Segmentation fault

is it a known issue?

Is it really reasonable that nf_elem always initializes its polynomial (in degree >= 3) to hold a full unreduced product? In many circumstances, this will cause needless overallocation.

Worse, the current code is potentially dangerously broken. Some functions (like nf_elem_mul) assume that there is enough space to write an unreduced product without checking this. This is fine if the polynomial has been initialized with the current nf_elem_init. However, there are many functions in the nf_elem module that call non-underscore fmpq_poly methods. Such methods could potentially reallocate the output to a too short length (for instance when swapping the output to handle aliasing). I would feel more comfortable if nf_elems just used the normal dynamic fit_length approach.

As presently implemented nf_elem_set_fmpq_poly only works correctly if the input polynomial is already reduced (which is not checked).

In a general number field, it creates an unreduced nf_elem which is probably not what the user expects. More seriously, in a linear or quadratic field it will just throw away the high coefficients and thus silently produce nonsense.

Some functions are untested, e.g.:

• nf_elem_is_gen
• nf_elem_get_coeff_fmpz

I have just done

./configure --disable-static
make

I get lots of errors. Errors look like this :

undefined reference to `_imp_nf*'

PS: I am on Msys2 MinGWx64 on windows10

I would like to create the FreeBSD package, and it isn't clear what the license is.

Clearly I have fmpz_gcd3.

And by the way, wouldn't it be better to print HAVE_FMPZ_GCD3 into some file instead of the current method of setting it to a C-flag?

Can the NUCOMP algorithm here use forms with a negative discriminant, as in "Solving the
Pell Equation" the NUCOMP given there is for positive discriminate only.

Thank you!

nf_elem_reduce canonicalises its input when the field is quadratic or higher, but doesn't canonicalise when the field is linear.

This should probably be made consistent. Otherwise, users that want to perform reduction + canonicalisation will either have to perform the canonicalisation twice or make a case distinction depending on whether the field is linear.

The current behavior is not documented, in any case.

Log: http://beefy10.nyi.freebsd.org/data/114i386-default/559040/logs/antic-0.2.23.log

get_fmpz_mod_poly.c:32:31: error: too few arguments to function call, expected 2, have 1
        fmpz_mod_poly_zero(pol);
        ~~~~~~~~~~~~~~~~~~    ^
/usr/local/include/flint/fmpz_mod_poly.h:268:1: note: 'fmpz_mod_poly_zero' declared here
FMPZ_MOD_POLY_INLINE 
^
/usr/local/include/flint/fmpz_mod_poly.h:19:30: note: expanded from macro 'FMPZ_MOD_POLY_INLINE'
#define FMPZ_MOD_POLY_INLINE static __inline__
                             ^
get_fmpz_mod_poly.c:38:44: error: too few arguments to function call, expected 3, have 2
            fmpz_mod_poly_fit_length(pol, 1);
            ~~~~~~~~~~~~~~~~~~~~~~~~       ^
/usr/local/include/flint/fmpz_mod_poly.h:124:11: note: 'fmpz_mod_poly_fit_length' declared here
FLINT_DLL void fmpz_mod_poly_fit_length(fmpz_mod_poly_t poly, slong len,
          ^
get_fmpz_mod_poly.c:39:66: error: no member named 'p' in 'fmpz_mod_poly_struct'
            fmpz_mod(pol->coeffs + 0, LNF_ELEM_NUMREF(a), &(pol->p));
                                                            ~~~  ^
get_fmpz_mod_poly.c:46:40: error: too few arguments to function call, expected 3, have 2
        fmpz_mod_poly_fit_length(pol, 3);
        ~~~~~~~~~~~~~~~~~~~~~~~~       ^
/usr/local/include/flint/fmpz_mod_poly.h:124:11: note: 'fmpz_mod_poly_fit_length' declared here
FLINT_DLL void fmpz_mod_poly_fit_length(fmpz_mod_poly_t poly, slong len,
          ^
get_fmpz_mod_poly.c:47:62: error: no member named 'p' in 'fmpz_mod_poly_struct'
        fmpz_mod(pol->coeffs + 0, QNF_ELEM_NUMREF(a), &(pol->p));
                                                        ~~~  ^
get_fmpz_mod_poly.c:48:66: error: no member named 'p' in 'fmpz_mod_poly_struct'
        fmpz_mod(pol->coeffs + 1, QNF_ELEM_NUMREF(a) + 1, &(pol->p));
                                                            ~~~  ^
get_fmpz_mod_poly.c:49:66: error: no member named 'p' in 'fmpz_mod_poly_struct'
        fmpz_mod(pol->coeffs + 2, QNF_ELEM_NUMREF(a) + 2, &(pol->p));
                                                            ~~~  ^
get_fmpz_mod_poly.c:56:42: error: too few arguments to function call, expected 3, have 2
        fmpz_mod_poly_fit_length(pol, len);
        ~~~~~~~~~~~~~~~~~~~~~~~~         ^
/usr/local/include/flint/fmpz_mod_poly.h:124:11: note: 'fmpz_mod_poly_fit_length' declared here
FLINT_DLL void fmpz_mod_poly_fit_length(fmpz_mod_poly_t poly, slong len,
          ^
get_fmpz_mod_poly.c:58:69: error: no member named 'p' in 'fmpz_mod_poly_struct'
            fmpz_mod(pol->coeffs + i, NF_ELEM_NUMREF(a) + i, &(pol->p));
                                                               ~~~  ^
get_fmpz_mod_poly.c:70:71: error: too few arguments to function call, expected 4, have 3
            fmpz_mod_poly_scalar_div_fmpz(pol, pol, LNF_ELEM_DENREF(a));
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                             ^
/usr/local/include/flint/fmpz_mod_poly.h:441:11: note: 'fmpz_mod_poly_scalar_div_fmpz' declared here
FLINT_DLL void fmpz_mod_poly_scalar_div_fmpz(fmpz_mod_poly_t res, 
          ^
get_fmpz_mod_poly.c:72:71: error: too few arguments to function call, expected 4, have 3
            fmpz_mod_poly_scalar_div_fmpz(pol, pol, QNF_ELEM_DENREF(a));
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                             ^
/usr/local/include/flint/fmpz_mod_poly.h:441:11: note: 'fmpz_mod_poly_scalar_div_fmpz' declared here
FLINT_DLL void fmpz_mod_poly_scalar_div_fmpz(fmpz_mod_poly_t res, 
          ^
get_fmpz_mod_poly.c:74:70: error: too few arguments to function call, expected 4, have 3
            fmpz_mod_poly_scalar_div_fmpz(pol, pol, NF_ELEM_DENREF(a));
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                            ^
/usr/local/include/flint/fmpz_mod_poly.h:441:11: note: 'fmpz_mod_poly_scalar_div_fmpz' declared here
FLINT_DLL void fmpz_mod_poly_scalar_div_fmpz(fmpz_mod_poly_t res, 
          ^

Hi,

can you provide a build system outside of FLINT ?

At one point perhaps distributions (Debian, Gentoo, Arch, Sage, etc) will want to package ANTIC, and having it in a self-contained way with just a dep on FLINT will be important.

Thanks,

Snark on #debian-science

It would be great if there was a new antic release with the changes since 0.2, and which depends on Flint 2.6.0

See also #31 and JuliaPackaging/Yggdrasil#1142.

Is there something like __FLINT_RELEASE that can be used to determine the version of ANTIC?

I would like to package ANTIC for conda-forge. Are there any releases (planned) so that packagers could use an official tarball to build from?

fredrik@agm:~/src/antic$ export ANTIC_TEST_MULTIPLIER=10
fredrik@agm:~/src/antic$ make check MOD=nf_elem
make[1]: Entering directory '/home/fredrik/src/antic'
make[1]: Nothing to be done for 'shared'.
make[1]: Leaving directory '/home/fredrik/src/antic'
make[1]: Entering directory '/home/fredrik/src/antic/nf_elem'
get_fmpz_mod_poly....PASS
init/clear....PASS
set_si_ui...PASS
mul....PASS
set_coeff_num_fmpz....PASS
div....PASS
mul_gen....FAIL:
K = Number field with defining polynomial -1/166153499473114484112975882535010304*x-1/23736214210444926301853697505001472
a = -7
b = 47270499
p1 = 110297831/6148914691236517205
p2 = -330893493
../Makefile.subdirs:84: recipe for target '../build/nf_elem/test/t-mul_gen_RUN' failed

Remark: the default ANTIC_TEST_MULTIPLIER=1 is really too low. Some of the tests only run 10 or 100 iterations. I would bump it at least to 10. Maybe manually add more test iterations specifically for low-degree number fields.

Output:

mod_fmpz....FAIL: Reducing without denominator
f = 1/3*x^3+1/3*x-1/3
a = 0
b = 0
c = 0
n = 39613779025677300323867164673

Fails both on FLINT branches trunk and flint-2.8, with Antic being current state of trunk.

README says The only dependency at present is flint2 which is wrong. gmp and mpfr are also dependencies.

Since the recent changes in #18 and #19 I cannot build antic anymore:

.../antic/nf.h:30:25: fatal error: flint/flint.h: No such file or directory

@wbhart I would like to update the antic version of Nemo but this is blocking it.

Is it possible to build antic out-of-tree? (i.e., the equivalent of mkdir build, cd build, ../antic/configure, make)

It seems that ./configure wants to run in the source tree. I could create a PR that autoconfiscates antic if that's helpful.

In the conda-forge distribution, we are seeing errors for programs that were built against antic 0.2.4 when installing 0.2.5.

cling::DynamicLibraryManager::loadLibrary() [/Users/runner/miniforge3/conda-bld/flatsurf_1659591997916/[…]/lib/libexactreal.6.dylib, 9):
Library not loaded: @rpath/libantic-0.2.4.dylib

I don't really understand how library naming works on macOS but could it be that this library should be called libantic.0.dylib instead of libantic-0.2.4.dylib?

The relevant part of the configure script is here:

ANTIC_LIBNAME="libantic.dylib"
ANTIC_LIB="libantic-$ANTIC_MAJOR.$ANTIC_MINOR.$ANTIC_PATCH.dylib"
EXTRA_SHARED_FLAGS="-install_name $PREFIX/lib/$ANTIC_LIB -compatibility_version $ANTIC_MAJOR.$ANTIC_MINOR -current_version $ANTIC_MAJOR.$ANTIC_MINOR.$ANTIC_PATCH";;

According to Apple Docs, we should probably change this. It says:

Listing 3  Generating version 1.0 of the Ratings dynamic library

[Ratings/1.0]% make dylib `clang -dynamiclib -std=gnu99 Ratings.c -current_version 1.0 -compatibility_version 1.0 -fvisibility=hidden -o libRatings.A.dylib`

This list indicates where the major version, minor version, and compatibility version are specified:

• The major version number is specified in the library’s filename as “A” in -o libRatings.A.dylib.

• The minor version number is specified in -current_version 1.0.

• The compatibility version number is specified in -compatibility_version 1.0.