-
-
Notifications
You must be signed in to change notification settings - Fork 514
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
Factoring padic polynomials #12561
Comments
Attachment: 12561.patch.gz |
comment:1
On the wiki page about padic factoring it says that the implementation doesn't work correctly for some examples. Is there only a problem with some specific cases? I just tried a few products of low degree polynomials and the factorizations seemed ok. I want to try to debug the code, so if you know of any simple examples for which it doesn't work, that would be helpful. |
comment:2
Other than the poor state of documentation and polish, I cannot find any faults. I have run the code through all of the previously failed examples with no issue outside of occasionally having insufficient precision. The newton polygon code does not elegantly handle the infinite slope case (the case where the current phi actually divides Phi), but it doesn't have to for factoring since it can be (and is) caught earlier in the loop. |
comment:3
Patch applies correctly on 7.5 and all doctests written so far pass. However: In the doctest from
This is just returning the polynomial unfactored, so demonstrably the factoring isn't working here. We should get:
Also, we should rework this code so that a sage Factorization object is returned, and that pfactortree is called by the |
comment:4
Replying to @haikona:
Note that increasing the precision yields a factorization:
In the case Simon pointed out, adding |
comment:5
The algorithm used in |
comment:6
Oh wait. I looked at the wrong numbers sorry. |
comment:8
Attachment: 12561.2.patch.gz This new patch replaces the first and has a great deal of improvements, bug-fixes, and documentation. The examples should be more sensible now. It should successfully factor monic, square-free, fixed-mod padic polynomials without fail. I am running more tests to ensure its validity as well as implementing the transformations needed to handle non-monic cases, which would leave it only dependant on square-free decomposition. |
comment:9
Nice. I volunteer to review this once it is ready. On a first look, several methods still don't have docstrings (but you are probably aware of this). |
comment:10
Please be aware of #15422 (which fixes some bugs in Sage's factoring of non-squarefree p-adic polynomials). |
Dependencies: #15190 |
Commit: |
Branch: u/roed/ticket/12561 |
Changed branch from u/roed/ticket/12561 to u/bsinclai/ticket/12561 |
Changed branch from u/bsinclai/ticket/12561 to u/roed/ticket/12561 |
Changed branch from u/roed/ticket/12561 to u/bsinclai/ticket/12561 |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Changed branch from u/bsinclai/ticket/12561 to u/roed/ticket/12561 |
Changed branch from u/roed/ticket/12561 to u/bsinclai/ticket/12561 |
Changed branch from u/bsinclai/ticket/12561 to u/roed/ticket/12561 |
Changed branch from u/roed/ticket/12561 to u/bsinclai/ticket/12561 |
New commits:
|
Last 10 new commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:44
I think it would be very nice to come up with a parent for FrameElt and FrameEltTerm and then inherit from Element for these. This would make implementation of arithmetic much easier I think. Isn't FrameElt basically just a sparse polynomial whose coefficients are FrameEltTerm? I actually find it surprising that FrameEltTerm exists. It's just wrapping a FrameElt except in the base case where it is wrapping a constant. I think that a tower of sparse polynomial rings could give you the same much more easily. Not sure if you feel like rewriting this or if we should postpone this. |
Work Issues: add to reference manual, improve arithmetic of FrameElt, FrameEltTerm (i.e., give them a parent) |
comment:46
I think that in the end, finding a parent for FrameElt and FrameEltTerm make sense. FrameElts are sparse polynomials of FrameEltTerms and FrameEltTerms are either representations of p-adic integers as valuation-and-unit or (FrameElt in phii-1)*phiideg. However, there are specialized mechanics to consider and these objects are at the core of most of this code. I think that this would be worthwhile, but might make sense to do as part of a refactor that also collapses segments and residual factors into frames and cleans up the object interface. |
Changed branch from u/saraedum/ticket/12561 to u/bsinclai/ticket/12561 |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Changed branch from u/bsinclai/ticket/12561 to u/roed/ticket/12561 |
New commits:
|
Changed keywords from sd86.5, sd87 to sd86.5, sd87, padicIMA |
Branch pushed to git repo; I updated commit sha1. New commits:
|
OM Tree construction and a native sage implementation of padic polynomial factoring using it. This factorization works for polynomials over Zp as well as over unramified and totally ramified extensions of Zp.
Depends on #15190
Depends on #14825
Depends on #20310
CC: @roed314 @pjbruin
Component: padics
Keywords: sd86.5, sd87, padicIMA
Work Issues: add to reference manual, improve arithmetic of FrameElt, FrameEltTerm (i.e., give them a parent)
Author: Brian Sinclair, Sebastian Pauli
Branch/Commit: u/roed/ticket/12561 @
0e7f566
Reviewer: Julian Rüth
Issue created by migration from https://trac.sagemath.org/ticket/12561
The text was updated successfully, but these errors were encountered: