Open
Conversation
On this branch we intend realize a first version of extensions of 'fake' p-adic number fields. This means we have to implement the missing methods in `FakepAdicEmbedding` and `FakepAdicExtension`. In this first commit, these modules are made to comply with pyflake rules.
- added computation of approximation of 1. the generator 2. an element 3. a polynomial - removed obsolete `improve_approximation` - new function `extensions_of_inductive_valuation`: compute all extensions of an inductive valuation v on K[x] to L[x], when a *fake* embedding K->L is given. - helper function `_all_augmentations`: this is a variant of MacLane's algorithm that may be useful in many other places - added a warning in `fake_padic_extensions` about possible error - cosmetic changes to comply with pyflakes
There is a new module, `padic_extensions.approximate_factorizations`. This is now where a weak splitting field of a polynomial can be computed.
There is no plan to actually implement this.
Computing the splitting field of a polynomial over an arbitrary (fake) p-adic number field now essentially works. - for alrge examples, the computation of an embedding into the extension field takes too long - for some error, there is an ad hoc fix
There is a new module `pAdicNumberField` which replaces `FakepAdicCompletion` In principal one can now compute the (weak) splitting field of a polynomial over an arbitrary p-adic number field. However, this is still very unpolished and there are still many bugs.
Only small changes were necessary. It is not clear if semistable reduction works over an arbitrary base field.
an arbitrary base field. The crucial places are in `reduction_trees`, in `lower_components` and `splitting_field`, and in `weak_padic_galois:extensions`
to `padic_embeddings` In addition to changing the name, the new class `pAdicEmbeddings` can only be initialized by specifying an approximation fo the generator which satisfies the condition of Hensels Lemma. Improving the approximation is done with p-adic Newton.
It is now done in a *linear* way.
More of the computation is done module Z/p^N, which makes everything faster. The bottleneck for computing the weak splitting field is now the "base change" of the irreducible components.
We can now compute the splitting field of f = x^8+28*x^2+28 in reasonable time. But this example also reveals a mysterious error in `weak_splitting_field`.
We use systematically `EnhancedValuations` which are inductive valuations together with an equivalence class of key polynomials.
This is preliminary: - it remains to choose the precision in such a way that the computation of the composition is guaranteed to succeed - updated `weak_splitting_field` in an ad hoc manner. These changes should rather be done inside `pAdicExtensions`.
Main points: - `fake_padic_extensions` has been replaced by `padic_extensions` - `pAdicExtension` is a subclass of `pAdicNumberField` - `pAdicExtension` has two subclasses, `ExactpAdicExtension` and `ApproximatepAdicExternsion` - similar for `pAdicEmbeddings` This is not yet working, but an experimental concept.
It remains to: - implement "exact_extension" - use this in `weak_splitting_field` - deal with precision issues - test, test, test
It is now possible to compute the weak splitting field of a polynomial over an arbitrary p-adic number field But htis is a very preliminary version. Obvious problems: - confusion between absolute and relative number fields - inertai and ramification degrees are computed incorrectly; therefore several checks fail
This is only to wrote down where the problem lies at the moment: - if pAdicNumberField is initialized with a relative number field, some things don't work properly. However, the concept of an exact extension uses relative number fields. - in ApproximatepAdicExtension.exact_extension there are many things unclear. In particular, the precison issue - precision issue when initializing ApproximatepAdicEmbedding
Most of the errors of the previous version have been fixed. There remains an error we haven't noticed before, in ApproximatepAdicExtension.exact_extension. The problem occurs if f is not "Krasner separable". Possible solution: an approximate irreducible factor may have extra precision, to distinguish factors of f.
The problems mentioned in the previous commit have been fixed (in a somewhat ad hoc way) by change the algorithm in `approximate_factorization`, so that the resulting factorization is fine enough to distinguish different factors.
- improved some docstrings - experimentally set the initial precision in `SimpleExtension` to 5 - deleted some obselete comments - allow input (K_0, p) for `pAdicNumberField`
- bug in creation of simple extension corrected: there is now a guaranteed choice of a generator - documented an error from Sage in the valuation code, which shows up in `approximate_factorizations` Up to errors due to Sage, everything seems to work now.
By using the option `compute_unit=False` in `equivalence_decomposition` the obnoxious error seems to be avoided. There is also a new comment in the docstring of `weak_splitting_field` on how the speed may be improved.
- `pAdicNumberField` now has its own method to approximate roots - there is also now an inbuild estimate for the precision required to approximate the root of the minimal polynomial of the generator
… field works (in some cases) - corrected error in `weak_splitting_field`, related to the minimal ramification. - corrected an error in `EnhancedValuation.base_change` - implemented the *base change* in reduction tree, in a very ad hoc way
- added `compute_unit=False` in two more places, to avoid a Sage error - added method `required_precision` to `InertialComponent`; this is not used yet - improved computation of integral basis of a p-adic number field; new option `int_basis` when converting field elements to vectors and vice versa
The planned changes include: - implementation of approximate and algebraic elements - new assumption on underlying number field, which results in power integral bases - finite presentation of eleents used more systematically - much more documentation and tests - better detection of subfields - hopefully, better performance.. - etc.etc.
So far, constuction of exact extension completly rewritten. We use the "integral generator" both for the absolute and the relative integral basis. This seems to be faster. Still, computing the exact extension is only feaseable for relatively small degrees.
The main change is a better way to compute the matrix representing the integral generator and the "transition matrix". This gives better performance for computing approximate and exact extensions. Computing the splitting field of f = x^8 + 28*x^2 + 28 over Q_2 now takes 6:15 min.
- extended and clarified documentation for ebeddings - deleteted the subclass ``ApproximatepAdicEmbedding`` - reinstalled the methof `precision` for the simple extensions constructor, which had mysteriously disappreared
but not implemented it yet
Computing the valuation of the value of a polynomial is now done via finite representations. Now we compute the splitting field of f = x^8 + 28*x^2+ 28 in 3:27 min.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On this branch we develop a new version of the functionality for p-adic number fields. The original goal was to overcome the restriction to the base field, which still has to be QQ_p in many places. We took this opportunity to complete rewrite and reorganize the p-adic code.
At the moment, this is only a preliminary version. So far, we have
FakepAdicCompletion,Fake..by new classes, most importantlypAdicNumberField, which is the new base class for p-adic number fields and extensions for p-adic number fields.TODOs:
The plan is to keep this branch separate from the master branch until these issues have been fixed.