Thoughts on the API

[hasufell]

I am currently using flint for a small fun crypto project which involves a lot of polynomial arithmetic, modulus stuff and euclidean algorithm.

There are a few things in the flint API that confuses me. Please bear with me in case I was just too stupid to figure out something:

• a lot of functions are void without any indication if they succeeded or not... I have to check the parameters I passed or wait for a segfault in order to figure out what just happened
• it seems most functions don't do any checking on the parameters they use... so you get a segfault instead somewhere in the middle of the code, when the function tries to dereference null-pointers
• although the allocation of polynomials is pretty smart, it also makes it extremely difficult to implement some algorithms that expect trailing 0-coefficients (NOT null-pointers!)... this makes me check for both... is it a null pointer? if it is not, is it a null-coefficient?
• It's not clear to me whether it is safe to access some structs directly. E.g. it gets a bit weird if you have to operate a lot on polynomial coefficients and have to use fmpz_poly_get_coeff_ptr() in a hundred places
• the meaning of "get" is confusing in a lot of functions
• for modular reduction I ended up calling fmpz_poly_get_nmod_poly() and fmpz_poly_set_nmod_poly_unsigned() directly after it in most of the cases, maybe a convenience function here would be a thing to consider in case I don't really need the nmod_poly data type?

But what bothers me most is the error handling. Did I miss a section in the manual and there is some sort of global variable I can check? Or is this just a design decision of debugging segfaults instead of functions returning error codes?

Anyway, probably the most advanced library in this field. Pretty awesome.

[wbhart]

On 23 May 2014 18:19, Julian Ospald notifications@github.com wrote:

I am currently using flint for a small fun crypto project which involves a
lot of polynomial arithmetic, modulus stuff and euclidean algorithm.

There are a few things in the flint API that confuses me. Please bear with
me in case I was just too stupid to figure out something:

• a lot of functions are void without any indication if they succeeded
  or not... I have to check the parameters I passed or wait for a segfault in
  order to figure out what just happened

This can't be changed. Some functions need to return values, so it would
be inconsistent to have them return fail/pass. Besides this, if a flint
function fails, it's a bug.

• it seems most functions don't do any checking on the parameters they
  use... so you get a segfault instead somewhere in the middle of the code,
  when the function tries to dereference null-pointers

We intend to add asserts, which will detect invalid input when
--enable-assert is specified at configure. But it's a lot of work. Bear
with us.

• although the allocation of polynomials is pretty smart, it also
  makes it extremely difficult to implement some algorithms that expect
  trailing 0-coefficients (NOT null-pointers!)... this makes me check for
  both... is it a null pointer? if it is not, is it a null-coefficient?

You should not ever have a coefficient that is a null pointer. Are you
using fmpz_poly_get_coeff_ptr or something like that?

Algorithms in flint should be fine with trailing zero coefficients. But we
don't do any special for speed, and we could.

• It's not clear to me whether it is safe to access some structs
  directly. E.g. it gets a bit weird if you have to operate a lot on
  polynomial coefficients and have to use fmpz_poly_get_coeff_ptr() in a
  hundred places

That's C for you.

• the meaning of "get" is confusing in a lot of functions
• for modular reduction I ended up calling fmpz_poly_get_nmod_poly()
  and fmpz_poly_set_nmod_poly_unsigned() directly after it in most of the
  cases, maybe a convenience function here would be a thing to consider in
  case I don't really need the nmod_poly data type?

Yes, we could add a function for reducing coefficients without creating the
intermediate type. This would be easy.

But what bothers me most is the error handling. Did I miss a section in
the manual and there is some sort of global variable I can check? Or is
this just a design decision of debugging segfaults instead of functions
returning error codes?

Welcome to C!

You might investigate the valgrind program. And yes, it is a design
decision, for efficiency reasons. It definitely wont be changed. Sorry
about that.

As I say, things will be easier when we have asserts throughout. But
currently, if you pass valid input according to the documentation, and it
segfaults, please report it as a bug!

Bill.

Anyway, probably the most advanced library in this field. Pretty awesome.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/76
.

[hasufell]

using fmpz_poly_get_coeff_ptr or something like that?

Exactly. One of the polynomials might have a much lesser degree and I need to compare coefficients in both. The comparison now is 2 steps (as in: assume "0"-coefficient if fmpz_poly_get_coeff_ptr() returns a NULL-pointer). The same goes for setting coefficients in the blue, without knowing the whole polynomial yet.

Setting trailing zero-coefficients via the fmpz_poly_set_coeff_* functions will just be ignored, or I did something wrong.

You might investigate the valgrind program.

Already using it :)

[wbhart]

On 23 May 2014 19:32, Julian Ospald notifications@github.com wrote:

using fmpz_poly_get_coeff_ptr or something like that?

Exactly. One of the polynomials might have a much lesser degree and I need
to compare coefficients in both. The comparison now is 2 steps (as in:
assume "0"-coefficient if fmpz_poly_get_coeff_ptr() returns a NULL-pointer).

You have to take the length of the polynomials into account. You can use
FLINT_MIN(len1, len2) to work out the shortest length, then do two for
loops, one up to min, the other for the rest. This is the way I'd do it in
C anyway.

The same goes for setting coefficients in the blue, without knowing the
whole polynomial yet.

Setting trailing zero-coefficients via the fmpz_poly_set_coeff_* functions
will just be ignored, or I did something wrong.

Possibly. The higher the index, the higher the degree of the coefficient.
So setting a coefficient to zero beyond the end of an existing polynomial
will just set the coefficient, then normalise the polynomial, which is
equivalent to doing nothing.

All functions in flint assume polynomials are normalised (unless noted
otherwise).

You might investigate the valgrind program.

Already using it :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/76#issuecomment-44038943
.

[hasufell]

Thanks for the hints.

Another convenience function that I think would be nice to have upstream is:

int fmpz_invmod_ui(fmpz_t f, const fmpz_t g, ulong h);

[wbhart]

On 24 May 2014 22:19, Julian Ospald notifications@github.com wrote:

Thanks for the hints.

Another convenience function that I think would be nice to have upstream
is:

int fmpz_invmod_ui(fmpz_t f, const fmpz_t g, ulong h);

Thanks for the suggestion.

If we look at the interface of GMP for example, there are two situations
where _ui functions are provided:

1. Where it is impractical to provide a multiprecision input, e.g. fib_ui,
   bin_ui, etc.

2. In very simple, low cost, arithmetic functions, such as add_ui, mul_ui,
   set_ui.

We could (and might) add fmpz_invmod_ui. But it doesn't really fit into
either of the above categories, so it isn't high priority for us.

Do you have a specific use case in mind?

Bill.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/76#issuecomment-44098709
.

[hasufell]

Do you have a specific use case in mind?

I guess it is just for convenience. I use it for the NTRUEncrypt algorithms where I operate on the coefficients with the NTRU parameters which are very small. Not sure if it makes sense to convert them to fmpz_t types.