Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prep flint 2.7: resolves #860, resolves #870 #919

Merged
merged 20 commits into from
Dec 21, 2020

Conversation

tthsqe12
Copy link
Contributor

@tthsqe12 tthsqe12 commented Nov 28, 2020

resolves #860, resolves #870
I'll do the nmod_mpoly/gfp_mpoly thing in a later pr.
One thing at a time

@thofma
Copy link
Member

thofma commented Nov 28, 2020

Great, thanks.

src/flint/fq.jl Outdated
Comment on lines 430 to 433
square_root(x::fq)
> Return the square root of $x$ in the finite field. If $x$ is not a square
> an exception is raised.
"""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
square_root(x::fq)
> Return the square root of $x$ in the finite field. If $x$ is not a square
> an exception is raised.
"""
square_root(x::fq)
Return the square root of $x$ in the finite field. If $x$ is not a square
an exception is raised.
"""

src/flint/fq.jl Outdated
Comment on lines 444 to 446
issquare(x::fq)
> Returns `true` if $x$ is a square in the finite field (includes zero).
"""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
issquare(x::fq)
> Returns `true` if $x$ is a square in the finite field (includes zero).
"""
issquare(x::fq)
Return `true` if $x$ is a square in the finite field (includes zero).
"""

dic = Dict{fmpq_mpoly, Int}()
for i in 0:fac.num-1
f = R()
# use get_base instead of swap_base if convert is to preserve input
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rfourquet Is it ok if this function destroys its input? I just didn't want make another useless copy of the polynomials...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you implement a convert method? Or was it there before?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if I implement a convert function, there is less copy+paste and fewer lines of code

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with convert is that it will be called implicitely without the users knowledge (for example in array or dictionary assignments), making the destructive behavior rather unfortunate.

How about implementing (::Factor{fmpq_poly})(::fmpz_poly_factor)? Or convert_and_destroy, something that indicates that the input will be garbage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree with @thofma

src/flint/fq.jl Outdated Show resolved Hide resolved
src/flint/fq.jl Outdated Show resolved Hide resolved
@thofma
Copy link
Member

thofma commented Dec 2, 2020

Sorry, I was a bit sloppy with my comment. The signature I meant was

(::Type{Fac{nmod_mpoly}})(f::nmod_poly_factor)

So that one calls it as Fac{nmod_poly}(f).

I can push those changes if you want.

Project.toml Outdated
@@ -24,7 +24,7 @@ AbstractAlgebra = "^0.11.1"
Antic_jll = "~0.2.2"
Arb_jll = "~2.18.1"
BinaryProvider = "0.4, 0.5"
FLINT_jll = "~2.6.3"
FLINT_jll = "~200.690.0"
LoadFlint = "^0.3.4"

This comment was marked as resolved.

@thofma
Copy link
Member

thofma commented Dec 11, 2020

Sure, there are a few other changes that are necessary.

Project.toml Outdated
@@ -24,7 +24,7 @@ AbstractAlgebra = "^0.11.1"
Antic_jll = "~0.2.2"
Arb_jll = "~2.18.1"
BinaryProvider = "0.4, 0.5"
FLINT_jll = "~2.6.3"
FLINT_jll = "~200.690.0"
LoadFlint = "^0.3.4"

This comment was marked as resolved.

This comment was marked as resolved.

@thofma
Copy link
Member

thofma commented Dec 11, 2020

Good to go from my side.

@thofma
Copy link
Member

thofma commented Dec 11, 2020

The failure on nightly looks scary. Might be due to some bad choices in the random test. I will try to reproduce it locally.

@fingolfin
Copy link
Member

The problem is that fq_ctx_init_modulus expects 4 arguments but gets only 3.

@thofma
Copy link
Member

thofma commented Dec 11, 2020

Thanks. I will fix it. Weird that it passed for the other jobs.

@fingolfin
Copy link
Member

Actually it makes me concerned, I now wonder what other similar issues are hidden there...

@thofma
Copy link
Member

thofma commented Dec 11, 2020

@tthsqe12 please check my fix.

@fingolfin
Copy link
Member

I've submitted PR #923 to enable code coverage tracking. That shows (see https://codecov.io/gh/Nemocas/Nemo.jl/tree/9e9e763d9cb56919ebf94ce81f985c3a6e4a405d/src) that about 80% of the code base is already covered by tests, which is good. But on the downside that means 20% are not yet tested at all.

Of course just because a line of code is executed as part of a test doesn't ensure it is bugfree (as the issue at hand demonstrates), but at least it's slightly less likely than when the code is never tested...

I really wonder if there is a technology that might help with catching these API mismatches: wrong number of arguments, wrong types... I guess it would have to be code that parses C header files to compute the corresponding data. And then somehow match it to our ccalls. Hrm

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tthsqe12 @thofma, this seems to work now

@tthsqe12
Copy link
Contributor Author

@thofma looks fine. I am sorry I missed that one. It would be nice to have some of these errors caught automatically...
If fq_ctx_init_modulus were being tested by the test code, there is no way it would have passed with my buggy omission. What is going on with the test code

@tthsqe12
Copy link
Contributor Author

tthsqe12 commented Dec 12, 2020

@fingolfin I know for a fact that there are other mismatched signatures even from before version 2.6. But, they work currently :) Here are the unpleasant secrets of nemo in order:

  1. We have manually make sure all ccalls are correct
  2. We have to pack (unpack) all of the nested c structs by hand and pray that julia uses the exact same offsets as whatever compiler compiled the c library
  3. Nemo is sneakily relying on ostensibly undefined behaviour No context for destructors of major types flintlib/flint#773

I will go through all of the ccalls soon and remove the nonexistant functions and fix the bad arguments. I didn't want to change too much right now.

@fingolfin
Copy link
Member

There are still a bunch of code change suggestions by @rfourquet which someone with the right permissions could apply

thofma and others added 2 commits December 15, 2020 11:30
Co-authored-by: Rafael Fourquet <fourquet.rafael@gmail.com>
Co-authored-by: Rafael Fourquet <fourquet.rafael@gmail.com>
@fingolfin

This comment has been minimized.

@thofma
Copy link
Member

thofma commented Dec 15, 2020

I don't see square roots for finite fields. Did you add them @tthsqe12?

@tthsqe12
Copy link
Contributor Author

tthsqe12 commented Dec 15, 2020

This only thing missing is issquare_with_square_root in fq.jl and fq_nmod.jl.
By the way, where are the code coverage reports now?

@thofma
Copy link
Member

thofma commented Dec 15, 2020

Would you mind adding it? That would be great.

@fingolfin
Copy link
Member

@tthsqe12 the Codecov comment above is updated whenever this PR is rebuilt. It also contains links to the full report: https://codecov.io/gh/Nemocas/Nemo.jl/pull/919 for this PR.

On https://codecov.io/gh/Nemocas/Nemo.jl/pull/919/diff you can just see the changes introduced by this PR, and whether they are covered or not. They currently have a coverage of 90.75% which is above average! Here's an example of a ccall which is not exercise by the test suite: https://codecov.io/gh/Nemocas/Nemo.jl/pull/919/diff#D2-841

Let me know if you have any questions about Codecov, I am quite familiar with it (including a lot of annoying warts... but hey, it's free)

@fingolfin
Copy link
Member

(Also, while I of course think it'd be useful to increase coverage, getting to 99% is quite ambitious, and perhaps not the best idea to hold up this PR too much just to increase coverage? We can increase it further later, and add corresponding fixes then as well.

@tthsqe12 tthsqe12 changed the title Prep flint 2.7 Prep flint 2.7: resolves #860, resolves #870 Dec 15, 2020
thofma added a commit to thofma/Yggdrasil that referenced this pull request Dec 16, 2020
@fingolfin `200.690` is too old to push Nemocas/Nemo.jl#919 over the finish line.

Did I bump the version correctly? Or should I bump the patch version?
@thofma
Copy link
Member

thofma commented Dec 16, 2020

This is now waiting for a new flint version, see JuliaPackaging/Yggdrasil#2265.

@wbhart
Copy link
Contributor

wbhart commented Dec 16, 2020

The Flint release is waiting on a final PR from @tthsqe12

I think that should be the final issue to deal with and then we can issue a new rc and final release.

giordano pushed a commit to JuliaPackaging/Yggdrasil that referenced this pull request Dec 18, 2020
* [FLINT] new version

@fingolfin `200.690` is too old to push Nemocas/Nemo.jl#919 over the finish line.

Did I bump the version correctly? Or should I bump the patch version?

* Update build_tarballs.jl

* Update build_tarballs.jl

* Update build_tarballs.jl

* Update build_tarballs.jl
@thofma thofma closed this Dec 20, 2020
@thofma thofma reopened this Dec 20, 2020
@fingolfin
Copy link
Member

New Flint and LoadFlint are out. Anything else that needs to be done?

@thofma
Copy link
Member

thofma commented Dec 21, 2020

I pushed the last commit this morning to make everything green. I will do some cleaning up later this day.

@thofma thofma merged commit b2fef8f into Nemocas:master Dec 21, 2020
@tthsqe12
Copy link
Contributor Author

Yay!

@tthsqe12 tthsqe12 deleted the prep_flint2p7 branch December 9, 2021 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants