Multiple zeta algebra

[rws]

Old description:

There is code in Pynac's zeta2_eval allowing lst arguments. Let's check if that can be interfaced to Python. Is there numerics available in mpmath or arb?

​https://en.wikipedia.org/wiki/Multiple_zeta_function

New description:

This ticket is now used to implement the algebra of MZV, using algorithms of Francis Brown.

Sample computation:

sage: Z = Multizeta
sage: M = matrix(2,2,[Z(2),Z(3),Z(4),Z(5)])
sage: M.det()
-10*ζ(1,6) - 5*ζ(2,5) - ζ(3,4) + ζ(4,3) + ζ(5,2)

[chapoton]

see also #18010

[chapoton]

New commits:

​67d78cc

first sketch of MZV function

[git]

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

​4e22cc3

more work on multiple zeta values

[git]

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

​513688c

trying to use precision

[chapoton]

Here is a first advanced sketch for an implementation of the ring of Multiple Zeta values. This in fact implements the motivic MZV, in some sense, following the algorithm given by Francis Brown.

I would appreciate comments and suggestions.

---

New commits:

​63096a3

first sketch for a ring of multiple zeta values

[git]

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

​d825c5a

details

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​47d0d72	first sketch for a ring of multiple zeta values
​b66a693	more doc for MZV

[chapoton]

Do you know anybody that could be interested in this stuff, and would review ?

[tscrim]

Replying to chapoton:

Do you know anybody that could be interested in this stuff, and would review ?

I am not sure. I have cc-ed Dan Bump, who might be willing to or know someone who could. I can do the technical review and would be willing to set a positive review if nobody else is willing to check the mathematics. However, I would rather have a mathematical review.

[vdelecroix]

Actually, I thought about implementing the same thing! I can start the review next week (or maybe even this week-end).

[chapoton]

Cool ! Ca manque sans doute encore un peu de documentation, mais c'est pleinement fonctionnel (je crois).

[vdelecroix]

Major code integration issues

• why in modular?
• It might be useful to distinguish between multizeta values and their algebra
• what is the relation between your code and the already existing

  sage: zeta(3)
  zeta(3)
  

Major design issues

Why are multizeta relations not part of the algebra!?

sage: 4*Multizeta(1,3) == Multizeta(4)
False
sage: Multizeta(2,2,2) == pi**6 / 7.factorial()
False

This is the most interesting part of the story! A lot is (conjecturally) known

• the algebra has a graduation by weight (sum of the composition)
• the algebra has a filtration by length
• a very simple additive basis (Hoffman): multizeta values whith entries 2 and 3 (it is hence very easy to provide additive basis in fixed weight)
• a rather simple multiplicative basis (Broadhurst)

Minor

• You should be more explicit about this comment

  Beware that this conversion involves the sign `(-1)^w` where `w` is the
  length of the composition and the number of `1`in the word in 0 and 1.
  

• the string representation is not informative enough

  sage: m = Multizeta(3,2,2)
  sage: m.parent()
  Algebra of MZV as zeta(n1,...nr) over Rational Field
  

• why do you cache numerical pari evaluation!? Also pari has a much faster evaluation for all multiple zeta values of given weight zetamultall which makes sense in this context.

[git]

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

​a8565cc	Merge branch 'u/chapoton/ticket22713' of ssh://trac.sagemath.org:22/sage into mzv
​76722ca	details in multiple zeta values

[chapoton]

Merci pour les commentaires !

Replying to vdelecroix:

Major code integration issues

• why in modular?

Well, this is the current place of some motivic stuff, for example hypergeometric motives. Any better suggestion ?

• It might be useful to distinguish between multizeta values and their algebra

What do you mean ? change Multizetas to MultizetasAlgebra ?

• what is the relation between your code and the already existing

  sage: zeta(3)
  zeta(3)
  

No relation. Symbolic ring is the root of all evil. I think that conversions are not really possible : from SR to MZV, it would have a very small domain. From MZV to SR, it would fail for lack of a symbolic MZV function. This is not at all what I want to do here.

Major design issues

Why are multizeta relations not part of the algebra!?

sage: 4*Multizeta(1,3) == Multizeta(4)
False
sage: Multizeta(2,2,2) == pi**6 / 7.factorial()
False

I just forgot to implement equality for one of the two classes. Done now.

This is the most interesting part of the story! A lot is (conjecturally) known

• the algebra has a graduation by weight (sum of the composition)
• the algebra has a filtration by length
• a very simple additive basis (Hoffman): multizeta values whith entries 2 and 3 (it is hence very easy to provide additive basis in fixed weight)
• a rather simple multiplicative basis (Broadhurst)

Yes, sure. Because the implemented algebra is the "motivic algebra of MZV", these statements are not conjectural, but theorems. We already have the grading (see M.category()), in fact. There is room for a lot more work. It would be more fun to do this in a collaborative way. I spent a lot of time already just to make the "motivic" equality work correctly.

Minor

• You should be more explicit about this comment

  Beware that this conversion involves the sign `(-1)^w` where `w` is the
  length of the composition and the number of `1`in the word in 0 and 1.
  

I hav expanded the comment.

• the string representation is not informative enough

  sage: m = Multizeta(3,2,2)
  sage: m.parent()
  Algebra of MZV as zeta(n1,...nr) over Rational Field
  

I changed the repr to be more verbose.

• why do you cache numerical pari evaluation!? Also pari has a much faster evaluation for all multiple zeta values of given weight zetamultall which makes sense in this context.

I cache that because I need a lot of them. But maybe this is not a good idea, given that their number is a power of 2. And of course, using the faster pari method to copmpute them all may be a good idea. But this depends on how the algebra is used.

[vdelecroix]

Replying to chapoton:

There is room for a lot more work. It would be more fun to do this in a collaborative way. I spent a lot of time already just to make the "motivic" equality work correctly.

Consider my comments not as "do this in this ticket" but rather as

• how does Vincent can make this useful for him (or at least understandable)? Given the fact that you spent a lot of time on this you know the code much better than I do.
• Make sure that all what I suggest can be done in the future without changing the design.

Once I am convinced by the design, I can go through the documentation and suggest/change/expand (inside a commit).

[vdelecroix]

Replying to chapoton:

Merci pour les commentaires !

Replying to vdelecroix:

Major code integration issues

• why in modular?

Well, this is the current place of some motivic stuff, for example hypergeometric motives. Any better suggestion ?

arith? motives?

I do not see the link with modular form (which does not mean that there is not one).

• It might be useful to distinguish between multizeta values and their algebra

What do you mean ? change Multizetas to MultizetasAlgebra ?

Not exactly. (s1, s2, s3) -> zeta(s1, s2, s3) is a function. zeta(3, 5, 2) is a special value of this function which is a real number. But the Multizeta you designed lives in a different world. It has an evaluation to the reals. But this is not clearly stated in the module documentation to my mind.

• what is the relation between your code and the already existing

  sage: zeta(3)
  zeta(3)
  

No relation. Symbolic ring is the root of all evil. I think that conversions are not really possible : from SR to MZV, it would have a very small domain. From MZV to SR, it would fail for lack of a symbolic MZV function. This is not at all what I want to do here.

But pi and zeta(2) are (when considered as real numbers) part of the (image in the real numbers of the) algebra you are trying to design. This is confusing, unless everything becomes "motivic".

Major design issues

Why are multizeta relations not part of the algebra!?

sage: 4*Multizeta(1,3) == Multizeta(4)
False
sage: Multizeta(2,2,2) == pi**6 / 7.factorial()
False

I just forgot to implement equality for one of the two classes. Done now.

Wunderbar!

This is the most interesting part of the story! A lot is (conjecturally) known

• the algebra has a graduation by weight (sum of the composition)
• the algebra has a filtration by length
• a very simple additive basis (Hoffman): multizeta values whith entries 2 and 3 (it is hence very easy to provide additive basis in fixed weight)
• a rather simple multiplicative basis (Broadhurst)

Yes, sure. Because the implemented algebra is the "motivic algebra of MZV", these statements are not conjectural, but theorems.

As I said, it would help if there were a clearer distinction between this motivic version and its image in the set of real numbers.

Also, if the algebra of motivic MZV is "just" a special case of FreeZinbielAlgebra why do you hide it under this F_ring function? I have hard time understanding the logic of your proposal. If FreeZinbielAlgebra lacks support for infinite basis, shouldn't it be the purpose of this ticket (or a dependency of this one)?

We already have the grading (see M.category()), in fact.

What I want to be able to do (maybe this is already possible)

• access a graded component (as a finite dimensional Q-vector space), let say M and do M.basis(), M.dimension(), ... And more generally, perform linear algebra there.

• the string representation is not informative enough

  sage: m = Multizeta(3,2,2)
  sage: m.parent()
  Algebra of MZV as zeta(n1,...nr) over Rational Field
  

I changed the repr to be more verbose.

Please use "motivic zeta values" here (unless I misunderstood something).

[vdelecroix]

• why do you cache numerical pari evaluation!? Also pari has a much faster evaluation for all multiple zeta values of given weight zetamultall which makes sense in this context.

I cache that because I need a lot of them. But maybe this is not a good idea, given that their number is a power of 2. And of course, using the faster pari method to copmpute them all may be a good idea. But this depends on how the algebra is used.

That you need a lot of them is not a good enough reason! But this is a very minor issue for sure.

[tscrim]

It should be easy to extend the FreeZinbielAlgebra to support infinite bases. From looking at the code, it just requires a little bit of changing around of the __classcall_private__ and __init__ methods to allow for infinite generating set, along with a slight tweaks to the construction functor to check this cases. This might be of independent interest.

[chapoton]

Hello Travis,

I would like very much to have that, but did not feel able to do that. It was already hard to allow numbered variables such as "z2" as generator names. What we need here is the free Zinbiel algebra on the set of odd integers greater than 3.

[tscrim]

I will do this tomorrow (it is quite late here and I don't think I have the energy to do it today). To sketch what I will do to FreeZinbielAlgebra:

In the __classcall_private__ allow n to be a non-integer, in which case names should be None and just pass that to the __init__. There n, in this case, will get fed to Alphabet. Then algebra_generators will need a case when self.variable_names() is not None. Then there will also be some slight cases when checking stuff in the construction functor with disabling those features as checking trivial intersection of infinite sets is not computable.

[git]

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

​c83419a

more doc, motivic names, one more doctest for a fix

[vdelecroix]

What is your rule about lower case/upper case in mathematic terms such as motivic Multiple Zeta Values?

EDIT: for example it appears in the doc as motivic multiple zeta values.

[vdelecroix]

What do you mean by Although this set of relations is not explicit?

[chapoton]

Salut Vincent. Je crois qu'il faut lire l'article de Brown pour comprendre un peu ce que fait le programme.

Concernant les majuscules/minuscules : il est d'usage de parler de MZV, c'est pour ca que j'ai garder les majuscules à Multiple Zeta Values. Mais d'un autre coté, je propose les fonctions Multizeta et Multizetas, ce qui n'est pas tres coherent.

Concernant les relations non explicites : l'ideal des relations n'est pas explicite, mais defini grosso modo comme "l'ensemble des relations induites par les changements de variables en geometrie algebrique". Et malgré tout, les gens comme F. Brown parviennent à décrire le quotient, à en donner des bases, etc. Mais on ne connait pas d'ensemble de generateurs de l'ideal des relations, sauf de facon conjecturale.

[git]

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

​9670c98

some details in doc of MZV

[git]

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

​2849ea6

one more reference

[vdelecroix]

Testing relations from ​wikipedia (which has the opposite convention for the order of entries)

sage: assert Multizeta(2,2) == 3/4 * Multizeta(4)
sage: assert Multizeta(2,3) == 3*Multizeta(2)*Multizeta(3) - 11/2*Multizeta(5)
sage: assert Multizeta(2,4) == Multizeta(3)**2 - 4/3*Multizeta(6)
sage: assert Multizeta(2,5) == 5*Multizeta(2)*Multizeta(5) + 2*Multizeta(3)*Multizeta(4) - 11*Multizeta(7)
sage: assert Multizeta(3,2) == 9/2*Multizeta(5) - 2*Multizeta(2)*Multizeta(3)
sage: assert Multizeta(3,3) == 1/2 * (Multizeta(3)**2 - Multizeta(6))
sage: assert Multizeta(3,4) == 17*Multizeta(7) - 10*Multizeta(2)*Multizeta(5)
sage: assert Multizeta(3,5) == 5*Multizeta(3)*Multizeta(5) - 147/24*Multizeta(8) - 5/2*Multizeta(2,6)
sage: assert Multizeta(4,2) == 25/12*Multizeta(6) - Multizeta(3)**2
sage: assert Multizeta(4,3) == 10*Multizeta(2)*Multizeta(5) + Multizeta(3)*Multizeta(4) - 18*Multizeta(7)
sage: assert Multizeta(4,4) == 1/2*(Multizeta(4)**2 - Multizeta(8))

[vdelecroix]

I thought about getting linear relations using

sage: matrix([Multizeta(2,2), Multizeta(1,3), Multizeta(4)]).right_kernel()

But this badly fails

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
/opt/sage/local/lib/python3.7/site-packages/sage/structure/category_object.pyx in sage.structure.category_object.CategoryObject.getattr_from_category (build/cythonized/sage/structure/category_object.c:6958)()
    837         try:
--> 838             return self.__cached_methods[name]
    839         except KeyError:

KeyError: 'is_integral_domain'

During handling of the above exception, another exception occurred:

AttributeError                            Traceback (most recent call last)
<ipython-input-1-7e649f42fa12> in <module>()
----> 1 matrix([Multizeta(Integer(2),Integer(2)), Multizeta(Integer(1),Integer(3)), Multizeta(Integer(4))]).right_kernel()

/opt/sage/local/lib/python3.7/site-packages/sage/matrix/matrix2.pyx in sage.matrix.matrix2.Matrix.right_kernel (build/cythonized/sage/matrix/matrix2.c:29512)()
   4239 
   4240         # Go get the kernel matrix, this is where it all happens
-> 4241         M = self.right_kernel_matrix(*args, **kwds)
   4242 
   4243         ambient = R**self.ncols()

/opt/sage/local/lib/python3.7/site-packages/sage/matrix/matrix2.pyx in sage.matrix.matrix2.Matrix.right_kernel_matrix (build/cythonized/sage/matrix/matrix2.c:28514)()
   3850             format, M = self._right_kernel_matrix_over_field()
   3851 
-> 3852         if M is None and R.is_integral_domain():
   3853             format, M = self._right_kernel_matrix_over_domain()
   3854 

/opt/sage/local/lib/python3.7/site-packages/sage/structure/category_object.pyx in sage.structure.category_object.CategoryObject.__getattr__ (build/cythonized/sage/structure/category_object.c:6880)()
    830             AttributeError: 'PrimeNumbers_with_category' object has no attribute 'sadfasdf'
    831         """
--> 832         return self.getattr_from_category(name)
    833 
    834     cdef getattr_from_category(self, name):

/opt/sage/local/lib/python3.7/site-packages/sage/structure/category_object.pyx in sage.structure.category_object.CategoryObject.getattr_from_category (build/cythonized/sage/structure/category_object.c:7043)()
    845                 cls = self._category.parent_class
    846 
--> 847             attr = getattr_from_other_class(self, cls, name)
    848             self.__cached_methods[name] = attr
    849             return attr

/opt/sage/local/lib/python3.7/site-packages/sage/cpython/getattr.pyx in sage.cpython.getattr.getattr_from_other_class (build/cythonized/sage/cpython/getattr.c:2547)()
    387         dummy_error_message.cls = type(self)
    388         dummy_error_message.name = name
--> 389         raise AttributeError(dummy_error_message)
    390     cdef PyObject* attr = instance_getattr(cls, name)
    391     if attr is NULL:

AttributeError: 'Multizetas_with_category' object has no attribute 'is_integral_domain'

[vdelecroix]

Replying to vdelecroix:

I thought about getting linear relations using

sage: matrix([Multizeta(2,2), Multizeta(1,3), Multizeta(4)]).right_kernel()

Alternatively

sage: pari.lindep([pari.zetamult([2,2]), pari.zetamult([3,1]), pari.zetamult([4])])
[-1, -1, 1]~

(wher you can notice that PARI/GP also has the other convention for the order)

[chapoton]

• Concerning the order convention, it is unfortunate that here is no unique prefered one. I sticked with Brown's convention, which I like because the conversion to iterated integral is more simple.

• Concerning the question of finding relations between a given set of MZV, the simplest way is to convert them all to the F-ring and do linear algebra there.

• One could probably add "integral domain" to the category of "Multizetas"

[git]

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

​8d56f70

add category of integral domain to both MZV algebras

[tscrim]

Replying to tscrim:

I will do this tomorrow (it is quite late here and I don't think I have the energy to do it today). To sketch what I will do to FreeZinbielAlgebra:

This is now #29434. For your application here, I would just use the larger algebra with generators indexed by ZZ and just use the generators you need for simplicity.

[git]

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

​5d638ae

make phi map also available on the main algebra and its elements

[chapoton]

@cremona : John, would you please put a message in sage-nt, so that interested people can have a look at this ticket ?

[cremona]

Replying to chapoton:

@cremona : John, would you please put a message in sage-nt, so that interested people can have a look at this ticket ?

OK, will do

[chapoton]

May I set back to needs review ?

[vdelecroix]

Bien sur tu peux. Mais je croyais que tu allais refactoriser en utilisant #29434 et te débarasser de F_ring. Que comptes-tu faire?

[chapoton]

Salut,

il n'est pas question de se débarrasser du F_ring, qui joue un role crucial.

on peut modifier le F_ring pour qu'il ait un nombre infini de generateurs, mais de toutes facons, le code devient lent a partir de n=12 ou 13, et il est limité par la table des générateurs des zetas comme algèbres, qui est codée en dur jusqu'a n=17.

Je devrais sans doute mettre un gros avertissement : ne fonctionne qu'en poids <= 17

[chapoton]

Question to Travis, @tscrim. How to make this work:

sage: Z = Multizeta
sage: Z(3)/Z(2,1)

I have declared the algebra to be an integral domain, but this does not trigger the fraction field.

[git]

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

​827f123

adding a warning about weight <= 17

[vdelecroix]

Instead of giving wrong answers, the code would better crash with errors. I thought you disliked the symbolic ring :-)

[tscrim]

Replying to chapoton:

Question to Travis, @tscrim. How to make this work:

sage: Z = Multizeta
sage: Z(3)/Z(2,1)

I have declared the algebra to be an integral domain, but this does not trigger the fraction field.

So the code that actually implements the fraction field stuff is in sage.rings.ring.Ring. I am not sure how I feel about inheriting from that since it is a subclass of ParentWithGens. I would probably just implement the following modified form of fraction_field in the IntegralDomains category:

    @cached_method
    def fraction_field(self):
        """
        Return the fraction field of ``self``.

        EXAMPLES::
        """
        from sage.rings.fraction_field import FractionField_generic
        return FractionField_generic(self)

(Note that FractionField_generic is not a UniqueRepresentation, so this is not a memory leak.)

Pardon ma réponse n'est pas en Français. I can mostly understand because I also know Spanish, but not really respond without some Google help. ;P

[git]

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

​b990def

trac #22713 fix one little bug

[mkoeppe]

Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​540a575

first sketch for a ring of multiple zeta values

[git]

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

​ade05bd

trac 22713 adding an example : looking for relations

[vdelecroix]

Why do you have so many functions as opposed to methods? In particular, I don't understand why base_brown is not a method of Multizetas. Moreover, here the right terminology here is I believe base and not basis.

Why do you have trivial functions such as compositions_23, numerical_MZV or vector_to_multizeta. These functions have code 10x shorter than their documentation.

The following piece of documentation is very cryptic.

        Return the morphism ``phi``.

        This sends multiple zeta values to the algebra :func:`F_ring`.

Where are the F ring and the phi morphism actually defined? There is not even a reference to where to look for a definition.

This is really nice (as a feature)

Then one can compute the space of relations::

    sage: from sage.modular.multiple_zeta import f_to_vector
    sage: M = matrix([f_to_vector(Zc.phi()) for Zc in L])
    sage: K = M.kernel(); K

but not very nice from a user perspective. Whouldn't it be possible to have Zc.phi().vector() (or even better Zc.vector())?

The doctest coming just after is kind of weird

    sage: relation.phi()
    0
    sage: relation.n()
    0.000000000000...

Why do you numerically evaluate 0? It would be nice to also print what relation is and run relation.is_zero().

Is this global definition

MZV = Multizeta

used anywhere?

Now, a more concrete mathematical questions: I have a prefered basis, let say basis_brown, how do I decompose a multizeta on this basis?

[git]

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

​a05056e

trac 22713 some simplifications

[git]

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

​bf1583a

trac 22713 further simplifications

[chapoton]

Replying to vdelecroix:

Why do you have so many functions as opposed to methods? In particular, I don't understand why base_brown is not a method of Multizetas. Moreover, here the right terminology here is I believe base and not basis.

This could be turned into a method, yes. I have not done that yet.

Why do you have trivial functions such as compositions_23, numerical_MZV or vector_to_multizeta. These functions have code 10x shorter than their documentation.

Got rid of them three.

The following piece of documentation is very cryptic.

        Return the morphism ``phi``.

        This sends multiple zeta values to the algebra :func:`F_ring`.

Where are the F ring and the phi morphism actually defined? There is not even a reference to where to look for a definition.

Well, everything is based on Brown's article [Brown2012]. But one could add more explanations, for sure.

This is really nice (as a feature)

Then one can compute the space of relations::

    sage: from sage.modular.multiple_zeta import f_to_vector
    sage: M = matrix([f_to_vector(Zc.phi()) for Zc in L])
    sage: K = M.kernel(); K

but not very nice from a user perspective. Whouldn't it be possible to have Zc.phi().vector() (or even better Zc.vector())?

Clearly, this only makes sense for homogeneous elements. One could have a method "phi_vector" that would raise error for non-homogeneous elements. I am not sure if it makes sense to add a method "vector" to the F-ring, with the similar restrictions.

The doctest coming just after is kind of weird

    sage: relation.phi()
    0
    sage: relation.n()
    0.000000000000...

Why do you numerically evaluate 0? It would be nice to also print what relation is and run relation.is_zero().

This is because the relation, now displayed, is not the zero linear combination. It is only equal to the zero element. Of course, we know that the period map sends this to zero, because phi sends this to zero.

Is this global definition

MZV = Multizeta

used anywhere?

No, removed.

Now, a more concrete mathematical questions: I have a prefered basis, let say basis_brown, how do I decompose a multizeta on this basis?

Just compute phi or rather "phi_vector" on every element of your basis, compute phi or rather "phi_vector" on your element, make a matrix and take the kernel of the obtained matrix.

[git]

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

​f8834ba

trac 22713 more doc and made base a method

[chapoton]

I have added a little more doc to phi, and move base_brown to a method.

[chapoton]

Maybe I should also remove "base_multi" ?

[vdelecroix]

Fact: singular is basis and plural is bases. No base (unless when used as an adjective as in base ring).

[vdelecroix]

Replying to chapoton:

Replying to vdelecroix:

This is really nice (as a feature)

Then one can compute the space of relations::

    sage: from sage.modular.multiple_zeta import f_to_vector
    sage: M = matrix([f_to_vector(Zc.phi()) for Zc in L])
    sage: K = M.kernel(); K

but not very nice from a user perspective. Whouldn't it be possible to have Zc.phi().vector() (or even better Zc.vector())?

Clearly, this only makes sense for homogeneous elements. One could have a method "phi_vector" that would raise error for non-homogeneous elements. I am not sure if it makes sense to add a method "vector" to the F-ring, with the similar restrictions.

But then one would expect Zc.homogeneous_component().vector() to work. An alternative is to consider the semi-sparse infinite dimensional vector space whose elements are dictionaries d -> phi_vector in degree d.

[vdelecroix]

Replying to chapoton:

Maybe I should also remove "base_multi" ?

Yes. Moving both as methods make sense.

[vdelecroix]

Replying to vdelecroix:

Replying to chapoton:

Maybe I should also remove "base_multi" ?

Yes. Moving both as methods make sense.

Actually, here I would not call it a basis. Shouldn't it rather be algebra_generators?

[git]

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

​b9971fa

trac 22713 various fixes about base ring, and moving one function to method

[git]

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

​9ea7fbd

trac 22713 changing base_ to basis_

[git]

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

​0ca039d

fix

[vdelecroix]

Please don't cache pari.zetamult. It does not make sense to use this function with repeated calls while there is zetamultall that compute all values up to a given weight. For weight <= 15 there is a 100x time difference

sage: %time Z = pari.zetamultall(15)
CPU times: user 156 ms, sys: 26.7 ms, total: 183 ms
Wall time: 183 ms
sage: %time Z = [pari.zetamult(pari.zetamultconvert(i)) for i in range(1, 16384)]
CPU times: user 9.99 s, sys: 1.43 ms, total: 9.99 s
Wall time: 10 s

[git]

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

​e5349fb

trac 22713 more fixes in handling general base rings

[git]

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

​54570b0

minor details in doc

[git]

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

​f8db527

trac 22713 trying to use zetamultall

[chapoton]

voila une tentative avec zetamultall. Je ne sais pas trop comment gérer le stockage, et le ré-emploi éventuel de ces calculs pour des poids et des précisions différentes.

[vdelecroix]

Je ne pense pas qu'il faille utiliser le cache de @cached_function. Quand une demande en poids plus grand est faite il faut juste écraser les valeurs précédentes. Qui peut le plus peut le moins. En plus ici le résultat de zetamultall est toujours ordonné par poids croissant.

Ce serait bien d'avoir un algo qui réutilise le travail fait en poids w pour calculer le poids w+1. Mais je ne suis pas sur que l'algorithme d'Akilesh permette ça. (en tout cas PARI/GP ne le fait pas)

Puisque de toute façon l'algèbre ne "marche pas" en poids > 17, le seul truc qui compte est le poids 17, non? Et ça ne fait pas tant de valeurs que ça

sage: len(pari.zetamultall(17)) == 2**16 - 1
True

[git]

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

​389bd58

introduce phi_as_vector, and fix some details in doc

[chapoton]

Je viens de rajouter une methode phi_as_vector, qui simplifie la recherche de relations.

La question du pré-calcul, du stockage et du re-calcul des valeurs numeriques si nécessaire me pose probleme. Est-ce que je dois utiliser une variable globale ?

Par ailleurs, la seule chose qui va ne pas marcher en poids > 17 est le test d'égalité (et le morphisme phi). On peut très bien faire quand meme des produits, et vouloir calculer une valeur numerique sur une composition de taille plus grande.

[vdelecroix]

Si tu prévois d'aller plus loin que poids 17 pour zetamult, ça va commencer à coûter cher en temps et mémoire. Aussi, si le calcul a été fait en précision 10 * prec ce n'est pas la peine de le refaire pour prec. Que penses-tu d'avoir une classe MultizetaValues(cache_max_weight, prec) qui stocke les valeurs en poids jusqu'à cache_max_weight (avec précision prec fixé) via des appels à zetamultall. Si la précision demandée est en dessous de la précision ou le poids en dessous de cache_max_weight on utilise le cache, sinon on fait un appel à zetamult. Il est tout à fait possible de faire en sorte que la cache_max_weight et prec soit modifiable à la volée de manière à ce qu'un utilisateur puisse ajuster à son besoin.

[vdelecroix]

Question: Comment Brown a construit sa base? Ce n'est pas possible d'écrire un algo pour faire ça? (et en particulier aller plus loin que poids 17)

[git]

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

​de3b9d5	Merge branch 'u/chapoton/ticket22713' of ssh://trac.sagemath.org:22/sage into mzv
​6e14709	trac 22713 first tentative of smarter caching for MZV

[chapoton]

Salut,

voilà une tentative minimale de cache fait-maison, mais je ne sais pas trop si c'est la bonne manière.

Il a 4 tests qui foirent pour cause de précision trop grande. J'aurais besoin de dégrader la précision d'un nombre en pari, et je ne sais pas comment faire.

Concernant la base multiplicative de Brown, il me semble que ça relève un peu de l'artisanat. On calcule l'application phi avec un candidat pour la base, et si ça donne bien une base de la composante homogène du F-anneau, alors on avait fait un bon choix. Il y a peut-être une autre base multiplicative proposée par Broadhurst (du style mots de Lyndon), mais je ne sais pas si elle est conjecturale ou pas.

Je suis moins pré-occupé par aller au delà de 17 que par réussir à être efficace jusqu'au poids 13, y compris en présence de coefficients polynomiaux. J'ai échoué hier (sur mon vieux portable, interrompu au bout de quelques heures à chauffer fort) à faire un calcul qui m’intéresse en poids 11.

[git]

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

​a60c688

trac 22713 adding a simplify procedure using duality

[git]

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

​37a5667

remove automatic simplification

[git]

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

​7887eb2

have .simplify available

[vdelecroix]

Sur la branch public/22713 j'ai nettoyé l'approximation numérique.

[vdelecroix]

(j'espère qu'il n'y a pas de conflit avec tes trois derniers commits)

[git]

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

​be3691c	clean numerical approximation
​d9ce5ae	Merge branch 'public/22713' of ssh://trac.sagemath.org:22/sage into mzv

[vdelecroix]

Y'a un petit bug dans pari_eval. Je vais rajouter un commit...

[vdelecroix]

See 4c2cf94267 still on public/22713 (rebased on your d9ce5ae).

[vdelecroix]

Si tu veux faire du poids 13, il faut absolument faire avant

sage: from sage.modular.multiple_zeta import MultizetaValues
sage: M = MultizetaValues()
sage: M.update(max_weight=13, prec=1024)

(j'imagine que precision 1024 est suffisant ici?)

Mais ce n'est peut-être pas la partie numérique qui rame... t'as fait du profiling?

[chapoton]

Basculons sur la branche public/ pour nous simplifier la vie.

Concernant mon calcul perso en poids 11, je crois que je vais devoir faire un algo plus subtil.

TODO ici : s'occuper du coverage.

[git]

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

​a60c688	trac 22713 adding a simplify procedure using duality
​37a5667	remove automatic simplification
​7887eb2	have .simplify available
​d9ce5ae	Merge branch 'public/22713' of ssh://trac.sagemath.org:22/sage into mzv
​4c2cf94	some fixes and documentation to numerical MZV
​1203ebf	100% doctest coverage

[git]

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

​b295b27

trac 22713, tiny details, one more reference

[chapoton]

Coverage is ok.

So, what remains to be done ?

[vdelecroix]

One feature which is not advertized in the main docstring of the module is the numerical approximation. I think it deserves a mention.

Otherwise I believe it is ready for inclusion.

[git]

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

​f6e69bf	Merge branch 'public/22713' of ssh://trac.sagemath.org:22/sage into mzv
​08c2b81	trac 22713 adding more doc about numerical approximation aka period map

[chapoton]

I have added a little more doc about numerical approximation.

• Should I move references to master ref file ?

• I am tempted to squash all commits. May I ?

• Anything else ?

[vdelecroix]

Replying to chapoton:

I have added a little more doc about numerical approximation.

• I am tempted to squash all commits. May I ?

Sure

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​c9e3b4c

implementation of the ring of motivic multiple zeta values

[chapoton]

all commits squashed, and the patchbot is green

[vdelecroix]

Replying to chapoton:

all commits squashed, and the patchbot is green

Let us get that in!

Est-ce que tu es dispo mardi 05.05 14h-17h? Bill (Allombert) organise une hacking session PARI/GP et j'aimerais travailler sur les multizeta colorés (évaluation des polylogarithmes aux racines de l'unité). Henri (Cohen) a déjà programmé quelques trucs numériques. Si jamais ça t'intéresse.

[vbraun]

Not python2-compatible

[vdelecroix]

Replying to vbraun:

Not python2-compatible

Why is that a problem? The milestone is set to 9.2 which is supposed to be Python3 only. Or did I misunderstand something?

[chapoton]

Probably the merging tools do not respect the milestone..