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

Bug in equivalence_decomposition ? #109

Open
swewers opened this issue Feb 18, 2019 · 7 comments
Open

Bug in equivalence_decomposition ? #109

swewers opened this issue Feb 18, 2019 · 7 comments
Labels
bug Something isn't working

Comments

@swewers
Copy link
Contributor

swewers commented Feb 18, 2019

sage: R.<x> = QQ[]
sage: v_7 = QQ.valuation(7)
sage: v0 = GaussValuation(R, v_7)
sage: v1 = v0.augmentation(x, 3/2)
sage: v2 = v1.augmentation(x^2-686, 7/2)
sage: f = x^4 - 8001504*x^2 - 592815428352
sage: v2.equivalence_decomposition(f)

leads to an assertion error:

AssertionError                            Traceback (most recent call last)
ivalence_decomposition(self, f, assume_not_equivalence_unit, coefficients, valuations, compute_unit, degree_
bound)
   1328
   1329         if compute_unit:
-> 1330             assert self.is_equivalent(ret.prod(), f) # this might fail because of leading zeros in i
nexact rings
   1331             assert self.is_equivalence_unit(ret.unit())
   1332
AssertionError:
@swewers swewers added the bug Something isn't working label Feb 18, 2019
@saraedum
Copy link
Member

saraedum commented Sep 5, 2020

Somehow the unit part is wrong in this example. It's determined as 2 but it should have been 1.

I didn't have time to look into this further. Should anybody have a chance to debug this further, I can probably fix it but at the moment I don't see where this wrong unit comes from.

@swewers
Copy link
Contributor Author

swewers commented Sep 11, 2020

I think the problem is that lift_to_key does not guarantee a particular form for the equivalence unit, which makes it incompatibel with _equivalence_reduction.

sage: R.<x> = QQ[]
sage: v_7 = QQ.valuation(7)
sage: v0 = GaussValuation(R, v_7)
sage: v1 = v0.augmentation(x, 3/2)
sage: v2 = v1.augmentation(x^2-686, 7/2)
sage: f = x^4 - 8001504*x^2 - 592815428352
sage: val, phi_divides, F = v2._equivalence_reduction(f)
sage: F = F.factor()
sage: F
(2) * (x^2 + 1)
sage: g = v2.lift_to_key(F[0][0])
sage: g
x^4 - 343/2*x^2 + 1294139
sage: v2.is_equivalent(f, g)
True

I haven't really tried to understand the code for lift_to_key to be able to see what the equivalence unit R implicit in lift_to_key is.

@swewers
Copy link
Contributor Author

swewers commented Sep 12, 2020

Maybe the problem is that equivalence_unit doesn't have the multiplicativity property that is silently assumed?

sage: v2.equivalence_unit(7/2)^2*v2.equivalence_unit(-7)
1/343*x^2
sage: v2.reduce(_)
2

@saraedum
Copy link
Member

saraedum commented Sep 12, 2020

Hm…equivalence_unit does not claim to reduce to 1 so maybe that's rather the problem that the implementation assumes that it does? Now I see what you mean.

@saraedum
Copy link
Member

(I'm on Zulip, if you want to discuss this.)

@saraedum
Copy link
Member

I think I have a fix for this. Is there an upstream ticket already?

@swewers
Copy link
Contributor Author

swewers commented Sep 13, 2020

No, I think there is none yet.

We want to compute u, phi_i and e_i such that f \sim u*\prod_i phi_i^e_i. One could compute u in the last step, by comparing the reduction of Rf and of R\prod_i phi_i^e_i (for an equivalence unit R with the right valuation) and then lifting the missing constant factor to a unit u.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants