Opened 4 years ago

Closed 6 months ago

#22713 closed enhancement (fixed)

Multiple zeta algebra

Reported by: rws Owned by:
Priority: major Milestone: sage-9.2
Component: number theory Keywords: motives
Cc: vdelecroix, tscrim, kedlaya, bump, cremona Merged in:
Authors: Frédéric Chapoton Reviewers: Vincent Delecroix
Report Upstream: N/A Work issues:
Branch: c9e3b4c (Commits) Commit: c9e3b4cf905f5bb81821e8a078eb1dd1424930dd
Dependencies: Stopgaps:

Description (last modified by chapoton)

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)

Change History (101)

comment:1 Changed 12 months ago by chapoton

see also #18010

comment:2 Changed 11 months ago by chapoton

  • Branch set to u/chapoton/27713
  • Cc vdelecroix added
  • Commit set to 67d78cca1ccbf8fa1bf04c4ab4382c8e8f529cb2

New commits:

67d78ccfirst sketch of MZV function

comment:3 Changed 11 months ago by git

  • Commit changed from 67d78cca1ccbf8fa1bf04c4ab4382c8e8f529cb2 to 4e22cc35ea55d3a7558e5834401ee5483c7fcf9b

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

4e22cc3more work on multiple zeta values

comment:4 Changed 11 months ago by chapoton

  • Milestone changed from sage-8.0 to sage-9.1

comment:5 Changed 11 months ago by git

  • Commit changed from 4e22cc35ea55d3a7558e5834401ee5483c7fcf9b to 513688c2476548af90e3718cf9e7b4eaff270b77

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

513688ctrying to use precision

comment:6 Changed 8 months ago by chapoton

  • Branch changed from u/chapoton/27713 to u/chapoton/ticket22713
  • Cc tscrim kedlaya added
  • Commit changed from 513688c2476548af90e3718cf9e7b4eaff270b77 to 63096a3fbc406bcc9f636d8fa590a7458eae6322
  • Status changed from new to needs_info

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:

63096a3first sketch for a ring of multiple zeta values

comment:7 Changed 8 months ago by chapoton

  • Description modified (diff)

comment:8 Changed 8 months ago by git

  • Commit changed from 63096a3fbc406bcc9f636d8fa590a7458eae6322 to d825c5a2a010d01284e716d498985c192ce95da4

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

d825c5adetails

comment:9 Changed 8 months ago by git

  • Commit changed from d825c5a2a010d01284e716d498985c192ce95da4 to b66a6937ea595293f1ccae70683324de2bc9749e

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

47d0d72first sketch for a ring of multiple zeta values
b66a693more doc for MZV

comment:10 follow-up: Changed 8 months ago by chapoton

  • Description modified (diff)
  • Status changed from needs_info to needs_review
  • Summary changed from Multiple zeta function to Multiple zeta algebra

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

comment:11 in reply to: ↑ 10 Changed 8 months ago by tscrim

  • Cc bump added

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.

comment:12 Changed 8 months ago by vdelecroix

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

comment:13 Changed 8 months ago by chapoton

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

comment:14 follow-up: Changed 8 months ago by vdelecroix

  • Reviewers set to Vincent Delecroix
  • Status changed from needs_review to needs_info

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.

comment:15 Changed 8 months ago by git

  • Commit changed from b66a6937ea595293f1ccae70683324de2bc9749e to 76722ca236e02362b13aee07d8048bf51a8c7906

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

a8565ccMerge branch 'u/chapoton/ticket22713' of ssh://trac.sagemath.org:22/sage into mzv
76722cadetails in multiple zeta values

comment:16 in reply to: ↑ 14 ; follow-up: Changed 8 months ago by 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.

comment:17 in reply to: ↑ 16 Changed 8 months ago by 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).

comment:18 Changed 8 months ago by 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).

comment:19 Changed 8 months ago by 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.

comment:20 Changed 8 months ago by 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.

comment:21 Changed 8 months ago by 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.

comment:22 follow-up: Changed 8 months ago by 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.

comment:23 Changed 8 months ago by git

  • Commit changed from 76722ca236e02362b13aee07d8048bf51a8c7906 to c83419a40722c0225d5cdeb2d564d88c4035235c

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

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

comment:24 Changed 8 months ago by 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.

Last edited 8 months ago by vdelecroix (previous) (diff)

comment:25 Changed 8 months ago by vdelecroix

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

comment:26 Changed 8 months ago by 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.

comment:27 Changed 8 months ago by git

  • Commit changed from c83419a40722c0225d5cdeb2d564d88c4035235c to 9670c981242a153a7d8e9ecec8e07c3ae76a548f

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

9670c98some details in doc of MZV

comment:28 Changed 8 months ago by git

  • Commit changed from 9670c981242a153a7d8e9ecec8e07c3ae76a548f to 2849ea6d7ad22121bb65a54e3602e6b65cbcd8db

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

2849ea6one more reference

comment:29 Changed 8 months ago by 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))

comment:30 follow-up: Changed 8 months ago by 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'

comment:31 in reply to: ↑ 30 Changed 8 months ago by 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)

Last edited 8 months ago by vdelecroix (previous) (diff)

comment:32 Changed 8 months ago by 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"

comment:33 Changed 8 months ago by git

  • Commit changed from 2849ea6d7ad22121bb65a54e3602e6b65cbcd8db to 8d56f7008746cda2086284e245157278994eea73

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

8d56f70add category of integral domain to both MZV algebras

comment:34 in reply to: ↑ 22 Changed 8 months ago by 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.

comment:35 Changed 8 months ago by git

  • Commit changed from 8d56f7008746cda2086284e245157278994eea73 to 5d638ae085f5508299108f61e4ff63ac6407fe96

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

5d638aemake phi map also available on the main algebra and its elements

comment:36 follow-up: Changed 8 months ago by chapoton

  • Cc cremona added

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

comment:37 in reply to: ↑ 36 Changed 8 months ago by 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

comment:38 Changed 8 months ago by chapoton

  • Authors set to Frédéric Chapoton

comment:39 Changed 8 months ago by chapoton

May I set back to needs review ?

comment:40 Changed 8 months ago by 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?

comment:41 Changed 8 months ago by 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

comment:42 follow-up: Changed 8 months ago by 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.

comment:43 Changed 8 months ago by git

  • Commit changed from 5d638ae085f5508299108f61e4ff63ac6407fe96 to 827f1236159616e268cb028f219df3af097c4d31

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

827f123adding a warning about weight <= 17

comment:44 Changed 8 months ago by vdelecroix

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

comment:45 in reply to: ↑ 42 Changed 8 months ago by 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

comment:46 Changed 8 months ago by git

  • Commit changed from 827f1236159616e268cb028f219df3af097c4d31 to b990defc470327ea6bc1abf349361423b298c00b

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

b990deftrac #22713 fix one little bug

comment:47 Changed 8 months ago by mkoeppe

  • Milestone changed from sage-9.1 to sage-9.2

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.

comment:48 Changed 7 months ago by git

  • Commit changed from b990defc470327ea6bc1abf349361423b298c00b to 540a57582d63af4aa5c27d16bcd77369a32c9a3e

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

540a575first sketch for a ring of multiple zeta values

comment:49 Changed 7 months ago by git

  • Commit changed from 540a57582d63af4aa5c27d16bcd77369a32c9a3e to ade05bd88a2e36d0cde691c15dc86f602eb0662a

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

ade05bdtrac 22713 adding an example : looking for relations

comment:50 Changed 7 months ago by chapoton

  • Status changed from needs_info to needs_review

comment:51 follow-up: Changed 7 months ago by 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?

comment:52 Changed 7 months ago by git

  • Commit changed from ade05bd88a2e36d0cde691c15dc86f602eb0662a to a05056e39c84f3d8a596c39f5f12f82f87b7a787

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

a05056etrac 22713 some simplifications

comment:53 Changed 7 months ago by git

  • Commit changed from a05056e39c84f3d8a596c39f5f12f82f87b7a787 to bf1583a0f566399dc0889df30c44d2316c1db99c

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

bf1583atrac 22713 further simplifications

comment:54 in reply to: ↑ 51 Changed 7 months ago by 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.

comment:55 Changed 7 months ago by git

  • Commit changed from bf1583a0f566399dc0889df30c44d2316c1db99c to f8834ba4d070ae72d14f1f299a9a646a0ac5a0d6

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

f8834batrac 22713 more doc and made base a method

comment:56 Changed 7 months ago by chapoton

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

comment:57 follow-up: Changed 7 months ago by chapoton

Maybe I should also remove "base_multi" ?

comment:58 Changed 7 months ago by vdelecroix

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

Last edited 7 months ago by vdelecroix (previous) (diff)

comment:59 Changed 7 months ago by 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.

comment:60 in reply to: ↑ 57 ; follow-up: Changed 7 months ago by vdelecroix

Replying to chapoton:

Maybe I should also remove "base_multi" ?

Yes. Moving both as methods make sense.

comment:61 in reply to: ↑ 60 Changed 7 months ago by 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?

comment:62 Changed 7 months ago by git

  • Commit changed from f8834ba4d070ae72d14f1f299a9a646a0ac5a0d6 to b9971fa991bd5599d7220fc3961c1ba2ec8c7923

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

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

comment:63 Changed 7 months ago by git

  • Commit changed from b9971fa991bd5599d7220fc3961c1ba2ec8c7923 to 9ea7fbd79baf6abddac3f7478ce3ee07ce91d5f2

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

9ea7fbdtrac 22713 changing base_ to basis_

comment:64 Changed 7 months ago by git

  • Commit changed from 9ea7fbd79baf6abddac3f7478ce3ee07ce91d5f2 to 0ca039da94535c49e2a02dfd2f3a31aefce5487d

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

0ca039dfix

comment:65 Changed 7 months ago by 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

comment:66 Changed 7 months ago by git

  • Commit changed from 0ca039da94535c49e2a02dfd2f3a31aefce5487d to e5349fb29f904741fab99983c4e93578268ed805

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

e5349fbtrac 22713 more fixes in handling general base rings

comment:67 Changed 7 months ago by git

  • Commit changed from e5349fb29f904741fab99983c4e93578268ed805 to 54570b018b89af08d3b5d8329d3df6dc86efdabb

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

54570b0minor details in doc

comment:68 Changed 7 months ago by git

  • Commit changed from 54570b018b89af08d3b5d8329d3df6dc86efdabb to f8db52738bc25917cd789dee92d96df1f672005a

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

f8db527trac 22713 trying to use zetamultall

comment:69 Changed 7 months ago by 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.

comment:70 Changed 7 months ago by 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

comment:71 Changed 7 months ago by git

  • Commit changed from f8db52738bc25917cd789dee92d96df1f672005a to 389bd58b4b40bd632509d434c850bb56dd7f3914

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

389bd58introduce phi_as_vector, and fix some details in doc

comment:72 Changed 7 months ago by 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.

comment:73 Changed 7 months ago by chapoton

  • Component changed from symbolics to number theory
  • Keywords motives added

comment:74 Changed 7 months ago by 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.

comment:75 Changed 7 months ago by 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)

comment:76 Changed 7 months ago by git

  • Commit changed from 389bd58b4b40bd632509d434c850bb56dd7f3914 to 6e14709c36085e0d3e0b01b24f4b370bc08b7668

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

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

comment:77 Changed 7 months ago by 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.

comment:78 Changed 7 months ago by git

  • Commit changed from 6e14709c36085e0d3e0b01b24f4b370bc08b7668 to a60c6888825e9f601814cf4bb931af45fd5820f8

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

a60c688trac 22713 adding a simplify procedure using duality

comment:79 Changed 7 months ago by git

  • Commit changed from a60c6888825e9f601814cf4bb931af45fd5820f8 to 37a5667e305f82ceec5a26546a149eaf1544e8dc

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

37a5667remove automatic simplification

comment:80 Changed 7 months ago by git

  • Commit changed from 37a5667e305f82ceec5a26546a149eaf1544e8dc to 7887eb2e20c536493cf0bd0c47c10c8a31eb3efb

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

7887eb2have .simplify available

comment:81 Changed 7 months ago by vdelecroix

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

comment:82 Changed 7 months ago by vdelecroix

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

comment:83 Changed 7 months ago by git

  • Commit changed from 7887eb2e20c536493cf0bd0c47c10c8a31eb3efb to d9ce5ae0f664b1ef021a25846f284d5eeffe499f

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

be3691cclean numerical approximation
d9ce5aeMerge branch 'public/22713' of ssh://trac.sagemath.org:22/sage into mzv

comment:84 Changed 7 months ago by vdelecroix

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

comment:85 Changed 7 months ago by vdelecroix

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

comment:86 Changed 7 months ago by 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?

Last edited 7 months ago by vdelecroix (previous) (diff)

comment:87 Changed 7 months ago by chapoton

  • Branch changed from u/chapoton/ticket22713 to public/22713
  • Commit changed from d9ce5ae0f664b1ef021a25846f284d5eeffe499f to be3691c00bbe12180427880795aea559d54139fb

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.

comment:88 Changed 7 months ago by git

  • Commit changed from be3691c00bbe12180427880795aea559d54139fb to 1203ebf5f05a8a9d5dd29ec0efbd28c95f5881c1

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

a60c688trac 22713 adding a simplify procedure using duality
37a5667remove automatic simplification
7887eb2have .simplify available
d9ce5aeMerge branch 'public/22713' of ssh://trac.sagemath.org:22/sage into mzv
4c2cf94some fixes and documentation to numerical MZV
1203ebf100% doctest coverage

comment:89 Changed 7 months ago by git

  • Commit changed from 1203ebf5f05a8a9d5dd29ec0efbd28c95f5881c1 to b295b274c34c47d6b076ea075fb85f412bdcd20f

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

b295b27trac 22713, tiny details, one more reference

comment:90 Changed 7 months ago by chapoton

Coverage is ok.

So, what remains to be done ?

comment:91 Changed 7 months ago by 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.

comment:92 Changed 7 months ago by git

  • Commit changed from b295b274c34c47d6b076ea075fb85f412bdcd20f to 08c2b81633e89f430b1df6baa169808dad232c99

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

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

comment:93 follow-up: Changed 7 months ago by 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 ?

comment:94 in reply to: ↑ 93 Changed 7 months ago by vdelecroix

Replying to chapoton:

I have added a little more doc about numerical approximation.

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

Sure

comment:95 Changed 7 months ago by git

  • Commit changed from 08c2b81633e89f430b1df6baa169808dad232c99 to c9e3b4cf905f5bb81821e8a078eb1dd1424930dd

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

c9e3b4cimplementation of the ring of motivic multiple zeta values

comment:96 follow-up: Changed 7 months ago by chapoton

all commits squashed, and the patchbot is green

comment:97 in reply to: ↑ 96 Changed 7 months ago by vdelecroix

  • Status changed from needs_review to positive_review

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.

comment:98 follow-up: Changed 7 months ago by vbraun

  • Status changed from positive_review to needs_work

Not python2-compatible

comment:99 in reply to: ↑ 98 Changed 7 months ago by vdelecroix

  • Status changed from needs_work to positive_review

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?

Last edited 7 months ago by vdelecroix (previous) (diff)

comment:100 Changed 7 months ago by chapoton

Probably the merging tools do not respect the milestone..

comment:101 Changed 6 months ago by vbraun

  • Branch changed from public/22713 to c9e3b4cf905f5bb81821e8a078eb1dd1424930dd
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.