Sign of hypergeometric motives is sometimes wrong

[kedlaya]

The sign method of HypergeometricData sometimes returns answers that do not agree with Magma:

sage: from sage.modular.hypergeometric_motive import HypergeometricData as Hyp
sage: H = Hyp(cyclotomic=([6,2],[1,1,1]))
sage: [H.sign(1/4,p) for p in [5,7,11,13,17,19]] #correct
[1, 1, -1, -1, 1, 1]
sage: H = Hyp(cyclotomic=([1,1,1],[6,2]))
sage: [H.sign(4,p) for p in [5,7,11,13,17,19]] #should agree but doesn't
[-1, -1, -1, -1, -1, -1]

I believe this is because Magma's formula is not valid when 0 in alpha. Note that this does not affect the padic_H_value or euler_factor methods because these do an alpha-beta swap to avoid this case (just as in Magma).

I have a fix for this coded up locally. Will post a patch shortly.

[chapoton]

Maybe we should instead always switch when creating the object (in the __init__) when 0 in alpha ?

---

New commits:

​61f3c25	Fix sign of hypergeometric motives
​8bbce1f	Docstring edit

EDIT:

But maybe this is not a good idea, because the user will not get what he wants..

[kedlaya]

Right, it is probably a bad idea to not return what is asked for. I understand that Magma originally did this and it caused all sorts of headaches.

A better idea might be, at creation time, if 0 in alpha, instantiate the swapped data and save it in H._swap. Then one can access this attribute when sign is called (or for that matter padic_H_value or H_value or euler_factor).

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​68eeea1

Add _swap attribute to HypergeometricData

[kedlaya]

While implementing this last suggestion, I discovered I was getting strange irreproducible errors if I didn't perform

t = QQ(t)

before doing the swap (the value of t was sometimes getting cast to 0).

[chapoton]

I have changed a few details. I am setting to positive.

---

New commits:

​37fda46

trac 28404 fix details

[kedlaya]

Looks good, thanks.