Diff for "days53/projects"

Coding sprint projects for Sage Days 53.

• Try out Sage-Git (everybody).

  • - Trac meta-ticket #13015

    - New sage-git developer manual

• Toric fibrations (Jan, Andrey)

• Trac #14880 : p-adic gamma function [DONE]

• Linear algebra mod n -- pari does this. Write a wrapper? (Kiran) Trac #15238

• Kloosterman's paper on deformations of diagonal hypersurfaces -- what are strong, weak equivalence? (Kiran, Adriana, Ursula)

• Create a python object that enumerates the set of points on a toric variety over a finite field (Ursula has code to do this) (David) (useful for checking if these points are on a hypersurface or a complete intersection). See Trac #15224 (needs_review)

• Hypersurfaces - check smoothness, nondegeneracy (where does this fail in families?) (Kiran, Adriana, Ursula, Wouter, Volker) Trac #15239 (needs_review)

• Toric elliptic curves (first, see what's done in Trac #13084 to figure out what is left to do)

• Porting Wouter's Magma code for lattice width, other methods (Wouter, Jen)

• Zeta functions of hyperelliptic curves -- point-counting method in Sage to call David's code, see Trac #15148 (Jan, JP)

• Make quiver algebras and quiver representations work again (Simon)

  • See Trac #12630. The ticket was providing quivers with composition of paths, quiver algebras and the like, but the patch recently broke because of a change in the expected arguments of DiGraph.__init__ in Trac #14806.

• Fix memleak related with quadratic number fields (Jean-Pierre, Simon)

  • See Trac #14711. Quadratic number fields come with an embedding into the complex field. The embedding is stored by strong reference in an attribute of the codomain of the embedding. If the codomain is "immortal" (which is the case for the complex field), then the domain of the embedding becomes immortal, too. Hence, currently, quadratic number fields will stay in memory forever.

• Let the TestSuite test that the construction of a parent returns the parent (Simon, Andrey)

  • See Trac #15223. In a previous version of toric lattice code written by Andrey, the toric lattices inherited the .construction() method from general lattices. Consequence: One could add two elements of different toric lattices so that the result lives in ZZ^2, which is not what Andrey wanted. Underlying problem: When Sage's coercion model applies the pushout() construction to the two toric lattices, it would create ZZ^2, because this is what the construction functors do. Suggestion: There should be a test that if P.construction() does not return None but a pair F,O, then F(O)==P must hold.

    The new test pointed to several problems. One of them is about the way finite rings in Sage are using the category framework. An old discussion on sage-devel provides potential solutions, but, as it turns out, the ideas presented in the discussion are still not all implemented. We want to implement them now.

    A patch is in preparation, but some work needs to be done in the dependencies of this ticket: Trac #15229 aims at using the category framework for integer mod rings more consistently. In particular, there should be a unique quotient ring for any order of integer mod ring, and if Sage finds or the user states that the ring is in fact a field, the instance will be updated. Needs review.

• Undo the category initialisation of a parent Trac #15234 (Simon)

  • Undoing the category initialisation is of course nothing that should be done under normal circumstances, but it may be helpful in debugging. Needs review.

• Implement method to go from q-adics to residue fields and conversly. (JP, David?, Martin?, François?)

  • See Trac #13612 for going up and Trac #13613 for going down.

• Try out p-adic implemention using templates, potentially fix it, extend it! (JP)
  • Sub-tasks:

  • Trac #12555 for the templatig framework,

  • Trac #14304 for a new implementation using FLINT's fmpz_mod_poly module,

  • compare the existing implementation of extensions using NTL's ZZ_pX class together with MulMod function using pre conditioning with a new implementation using the ZZ_pE class,

  • implement something on top of FLINT padic, padic_poly and qadic modules (not in FLINT 2.3, but will be in FLINT 2.4),
  • implement something using PARI's t_PADIC type and Hensel lifting machinery.

• Implement the algorithms in Sperber-Voight: paper and errata