-
-
Notifications
You must be signed in to change notification settings - Fork 535
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
bug with power series and/or p-adics #2943
Comments
comment:1
This is strange:
|
comment:2
Here is a much smaller example that triggers the bug:
Interestingly, if we use the vanilla p-adics instead of a ramified extension, we get a different traceback, which seems to indicate a different (possibly related?) bug:
|
comment:3
Even series inversion gives the list index breakage:
|
comment:4
Actually even just squaring something really simple can break:
|
comment:5
ok, the bug is in the polynomial mult instead of the power series mult:
|
comment:6
At least part of this bug is caused by some broken code in p-adic polynomial getslice. Here is the example from the docstring:
but this one dies:
|
comment:7
A smaller example of the original bug (this example involves only multiplication, no division):
|
comment:8
Even simpler (doesn't need the outer PowerSeries ring):
|
comment:9
I just did some more debugging with David Roe and I'm just going to write down our discoveries since I'm exhausted now. The problem is, at some point a Laurent series object is coming into existence whose unit part is a power series whose coefficients are all indistinguishable from zero (but not actually zero). Then when calling valuation on that laurent series, something blows up. It only happens when the base ring is unramified extensions of Qp, since something in the underlying polynomial class hasn't been implemented properly. (Maybe.) The actual exception generated is a bit misleading. It comes up in the last line of this code in
It's entering the loop with p == None, but it should never drop out of the bottom of the loop (it expects to find a nonzero-coefficient). |
comment:10
Getting closer now. Set up some polynomial rings over Qp and an unramified extension of Qp. Notice that the polynomial ring over Qp itself uses a specialised type, whereas over the ramified extension uses the generic polynomial ring:
The specialised type lets you have polynomials whose coefficients are indistinguishable from zero, but it still knows that the whole polynomial is "zero":
But the generic polynomial type just strips them off, since it thinks they are zero:
Now we can try forcing the generic code to let us have coefficients indistinguishable from zero:
And that's basically the problem. The generic polynomial code thinks that the polynomial is nonzero because its coefficient list is non-empty. |
comment:11
After discussion with broune and cwitty on IRC, the proposed solution is as follows:
|
comment:12
Attachment: 2943.patch.gz Attached patch should fix this bug. (Note: this does not fix the "list index" exception issue, which also came up in the above discussion. That is now a separate ticket: #3184) |
comment:13
After this patch, there is still a bug (thanks Kiran Kedlaya for pointing this out). Here is an example:
The output is wrong; there should be s2, s3, s4 terms. Kiran's example was:
which is distinguishable from 1. |
comment:14
Someone else seems to have hit a related bug, see the following thread: http://groups.google.com/group/sage-devel/browse_thread/thread/56a73f331e6b2977 |
comment:15
Any movement here? This ticket seems to have gone stale. Cheers, Michael |
comment:16
I can simplify dmharvey's bad example even further. No need to work over the p-adics at all! (This execution is from 3.2.3.)
So I dare say this is really a bug in power series, specifically in precision management. |
comment:17
I traced through the computation of 1/y in my previous example by hand, and this turned up the following perhaps more telling example.
By contrast, this is correct:
I think multiplication here uses z._mul_karatsuba, so maybe dmharvey needs to look at this again. Karatsuba may cause problems when working over an inexact coefficient ring. |
comment:18
Replying to @kedlaya:
I don't know who wrote the karatsuba code. I think it was there long before I started working on sage. Sure, I agree karatsuba should give inaccurate answers over an inexact coefficient ring, but it shouldn't give wrong answers. I guess the easiest solution is just to disable or remove karatsuba altogether, or first check whether the coefficient ring is exact. david |
comment:19
Replying to @kedlaya: Actually, there's nothing incorrect in your first example, except perhaps the printing:
So it's not printing the "zero" coefficients, and it's losing precision, but the result is correct up to the known precision. |
comment:20
Replying to @sagetrac-dmharvey:
Fair enough, but the behavior of
My previous example is the
I lose the extra So now as I see it, there are actually two different issues.
This is wrong because the 'zero' terms are actually inexact zeroes to certain precisions, which will lead to errors elsewhere if you try to use them. This is a systemic problem with using the generic polynomial module with an inexact ring: it has a habit of truncating leading zeroes after virtually every arithmetic operation. This systemic problem needs a systemic solution: there needs to be a way to check whether an element of an inexact ring is an exact zero or not, so that |
comment:21
I agree, this is the key. I believe it's been discussed several times in the past. Unfortunately the Sage development model seems to be very good at introducing systemic design bugs like this, but doesn't seem to be very good at fixing them (my perennial favourite is #3680). What we need is a hero with lots of time on their hands. david |
comment:22
In order to clarify things for newcomers to this discussion, I created a separate ticket #5075 to deal with the truncation of leading zeroes. Once that gets resolved, we can come back to the Karatsuba issue. |
comment:23
All the examples on this ticket seem to be resolved in 4.0rc0. I'm not sure why, since #5075 is still open, but fixing #3056, #3184, and others may have helped. Especially in light of the existence of #6084 (which should fix #5075 among other things), I propose to call this issue fixed and put this ticket out of its misery. |
comment:24
Attachment: trac_13106.patch.gz I decided this ticket should actually end up with a patch and a review, so I added a patch (mislabeled, sorry) to put another doctest from the above discussion into polynomial_element.pyx. |
Author: kedlaya |
Reviewer: Mike Hansen |
comment:25
Looks good. |
Changed author from kedlaya to Kiran Kedlaya |
Merged: sage-4.3.rc0 |
Can't manipulate certain elements of a power series ring:
CC: @roed314
Component: number theory
Keywords: power series, p-adic extensions
Author: Kiran Kedlaya
Reviewer: Mike Hansen
Merged: sage-4.3.rc0
Issue created by migration from https://trac.sagemath.org/ticket/2943
The text was updated successfully, but these errors were encountered: