Opened 4 years ago
Closed 8 months ago
#22713 closed enhancement (fixed)
Multiple zeta algebra
Reported by:  rws  Owned by:  

Priority:  major  Milestone:  sage9.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 )
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 14 months ago by
comment:2 Changed 13 months ago by
 Branch set to u/chapoton/27713
 Cc vdelecroix added
 Commit set to 67d78cca1ccbf8fa1bf04c4ab4382c8e8f529cb2
New commits:
67d78cc  first sketch of MZV function

comment:3 Changed 13 months ago by
 Commit changed from 67d78cca1ccbf8fa1bf04c4ab4382c8e8f529cb2 to 4e22cc35ea55d3a7558e5834401ee5483c7fcf9b
Branch pushed to git repo; I updated commit sha1. New commits:
4e22cc3  more work on multiple zeta values

comment:4 Changed 13 months ago by
 Milestone changed from sage8.0 to sage9.1
comment:5 Changed 13 months ago by
 Commit changed from 4e22cc35ea55d3a7558e5834401ee5483c7fcf9b to 513688c2476548af90e3718cf9e7b4eaff270b77
Branch pushed to git repo; I updated commit sha1. New commits:
513688c  trying to use precision

comment:6 Changed 10 months ago by
 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:
63096a3  first sketch for a ring of multiple zeta values

comment:7 Changed 10 months ago by
 Description modified (diff)
comment:8 Changed 10 months ago by
 Commit changed from 63096a3fbc406bcc9f636d8fa590a7458eae6322 to d825c5a2a010d01284e716d498985c192ce95da4
Branch pushed to git repo; I updated commit sha1. New commits:
d825c5a  details

comment:9 Changed 10 months ago by
 Commit changed from d825c5a2a010d01284e716d498985c192ce95da4 to b66a6937ea595293f1ccae70683324de2bc9749e
comment:10 followup: ↓ 11 Changed 10 months ago by
 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 10 months ago by
 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 cced 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 10 months ago by
Actually, I thought about implementing the same thing! I can start the review next week (or maybe even this weekend).
comment:13 Changed 10 months ago by
Cool ! Ca manque sans doute encore un peu de documentation, mais c'est pleinement fonctionnel (je crois).
comment:14 followup: ↓ 16 Changed 10 months ago by
 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 10 months ago by
 Commit changed from b66a6937ea595293f1ccae70683324de2bc9749e to 76722ca236e02362b13aee07d8048bf51a8c7906
comment:16 in reply to: ↑ 14 ; followup: ↓ 17 Changed 10 months ago by
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 10 months ago by
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 10 months ago by
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
toMultizetasAlgebra
?
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() FalseI 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 sayM
and doM.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 FieldI changed the repr to be more verbose.
Please use "motivic zeta values" here (unless I misunderstood something).
comment:19 Changed 10 months ago by
 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 10 months ago by
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 10 months ago by
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 followup: ↓ 34 Changed 10 months ago by
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 noninteger, 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 10 months ago by
 Commit changed from 76722ca236e02362b13aee07d8048bf51a8c7906 to c83419a40722c0225d5cdeb2d564d88c4035235c
Branch pushed to git repo; I updated commit sha1. New commits:
c83419a  more doc, motivic names, one more doctest for a fix

comment:24 Changed 10 months ago by
What is your rule about lower case/upper case in mathematic terms such as motivic Multiple Zeta Values
?
comment:25 Changed 10 months ago by
What do you mean by Although this set of relations is not explicit
?
comment:26 Changed 10 months ago by
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 10 months ago by
 Commit changed from c83419a40722c0225d5cdeb2d564d88c4035235c to 9670c981242a153a7d8e9ecec8e07c3ae76a548f
Branch pushed to git repo; I updated commit sha1. New commits:
9670c98  some details in doc of MZV

comment:28 Changed 10 months ago by
 Commit changed from 9670c981242a153a7d8e9ecec8e07c3ae76a548f to 2849ea6d7ad22121bb65a54e3602e6b65cbcd8db
Branch pushed to git repo; I updated commit sha1. New commits:
2849ea6  one more reference

comment:29 Changed 10 months ago by
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 followup: ↓ 31 Changed 10 months ago by
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/sitepackages/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) <ipythoninput17e649f42fa12> 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/sitepackages/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/sitepackages/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/sitepackages/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/sitepackages/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/sitepackages/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 10 months ago by
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)
comment:32 Changed 10 months ago by
 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 Fring and do linear algebra there.
 One could probably add "integral domain" to the category of "Multizetas"
comment:33 Changed 10 months ago by
 Commit changed from 2849ea6d7ad22121bb65a54e3602e6b65cbcd8db to 8d56f7008746cda2086284e245157278994eea73
Branch pushed to git repo; I updated commit sha1. New commits:
8d56f70  add category of integral domain to both MZV algebras

comment:34 in reply to: ↑ 22 Changed 10 months ago by
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 10 months ago by
 Commit changed from 8d56f7008746cda2086284e245157278994eea73 to 5d638ae085f5508299108f61e4ff63ac6407fe96
Branch pushed to git repo; I updated commit sha1. New commits:
5d638ae  make phi map also available on the main algebra and its elements

comment:36 followup: ↓ 37 Changed 10 months ago by
 Cc cremona added
@cremona : John, would you please put a message in sagent, so that interested people can have a look at this ticket ?
comment:37 in reply to: ↑ 36 Changed 10 months ago by
Replying to chapoton:
@cremona : John, would you please put a message in sagent, so that interested people can have a look at this ticket ?
OK, will do
comment:38 Changed 10 months ago by
comment:39 Changed 10 months ago by
May I set back to needs review ?
comment:40 Changed 10 months ago by
Bien sur tu peux. Mais je croyais que tu allais refactoriser en utilisant #29434 et te débarasser de F_ring
. Que comptestu faire?
comment:41 Changed 9 months ago by
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 followup: ↓ 45 Changed 9 months ago by
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 9 months ago by
 Commit changed from 5d638ae085f5508299108f61e4ff63ac6407fe96 to 827f1236159616e268cb028f219df3af097c4d31
Branch pushed to git repo; I updated commit sha1. New commits:
827f123  adding a warning about weight <= 17

comment:44 Changed 9 months ago by
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 9 months ago by
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 9 months ago by
 Commit changed from 827f1236159616e268cb028f219df3af097c4d31 to b990defc470327ea6bc1abf349361423b298c00b
Branch pushed to git repo; I updated commit sha1. New commits:
b990def  trac #22713 fix one little bug

comment:47 Changed 9 months ago by
 Milestone changed from sage9.1 to sage9.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 9 months ago by
 Commit changed from b990defc470327ea6bc1abf349361423b298c00b to 540a57582d63af4aa5c27d16bcd77369a32c9a3e
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

comment:49 Changed 9 months ago by
 Commit changed from 540a57582d63af4aa5c27d16bcd77369a32c9a3e to ade05bd88a2e36d0cde691c15dc86f602eb0662a
Branch pushed to git repo; I updated commit sha1. New commits:
ade05bd  trac 22713 adding an example : looking for relations

comment:50 Changed 9 months ago by
 Status changed from needs_info to needs_review
comment:51 followup: ↓ 54 Changed 9 months ago by
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 9 months ago by
 Commit changed from ade05bd88a2e36d0cde691c15dc86f602eb0662a to a05056e39c84f3d8a596c39f5f12f82f87b7a787
Branch pushed to git repo; I updated commit sha1. New commits:
a05056e  trac 22713 some simplifications

comment:53 Changed 9 months ago by
 Commit changed from a05056e39c84f3d8a596c39f5f12f82f87b7a787 to bf1583a0f566399dc0889df30c44d2316c1db99c
Branch pushed to git repo; I updated commit sha1. New commits:
bf1583a  trac 22713 further simplifications

comment:54 in reply to: ↑ 51 Changed 9 months ago by
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 ofMultizetas
. Moreover, here the right terminology here is I believebase
and notbasis
.
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
orvector_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 thephi 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(); Kbut not very nice from a user perspective. Whouldn't it be possible to have
Zc.phi().vector()
(or even betterZc.vector()
)?
Clearly, this only makes sense for homogeneous elements. One could have a method "phi_vector" that would raise error for nonhomogeneous elements. I am not sure if it makes sense to add a method "vector" to the Fring, 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 whatrelation
is and runrelation.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 = Multizetaused 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 9 months ago by
 Commit changed from bf1583a0f566399dc0889df30c44d2316c1db99c to f8834ba4d070ae72d14f1f299a9a646a0ac5a0d6
Branch pushed to git repo; I updated commit sha1. New commits:
f8834ba  trac 22713 more doc and made base a method

comment:56 Changed 9 months ago by
I have added a little more doc to phi, and move base_brown to a method.
comment:57 followup: ↓ 60 Changed 9 months ago by
Maybe I should also remove "base_multi" ?
comment:58 Changed 9 months ago by
Fact: singular is basis
and plural is bases
. No base
(unless when used as an adjective as in base ring
).
comment:59 Changed 9 months ago by
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(); Kbut not very nice from a user perspective. Whouldn't it be possible to have
Zc.phi().vector()
(or even betterZc.vector()
)?Clearly, this only makes sense for homogeneous elements. One could have a method "phi_vector" that would raise error for nonhomogeneous elements. I am not sure if it makes sense to add a method "vector" to the Fring, with the similar restrictions.
But then one would expect Zc.homogeneous_component().vector()
to work. An alternative is to consider the semisparse infinite dimensional vector space whose elements are dictionaries d > phi_vector in degree d
.
comment:60 in reply to: ↑ 57 ; followup: ↓ 61 Changed 9 months ago by
Replying to chapoton:
Maybe I should also remove "base_multi" ?
Yes. Moving both as methods make sense.
comment:61 in reply to: ↑ 60 Changed 9 months ago by
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 9 months ago by
 Commit changed from f8834ba4d070ae72d14f1f299a9a646a0ac5a0d6 to b9971fa991bd5599d7220fc3961c1ba2ec8c7923
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

comment:63 Changed 9 months ago by
 Commit changed from b9971fa991bd5599d7220fc3961c1ba2ec8c7923 to 9ea7fbd79baf6abddac3f7478ce3ee07ce91d5f2
Branch pushed to git repo; I updated commit sha1. New commits:
9ea7fbd  trac 22713 changing base_ to basis_

comment:64 Changed 9 months ago by
 Commit changed from 9ea7fbd79baf6abddac3f7478ce3ee07ce91d5f2 to 0ca039da94535c49e2a02dfd2f3a31aefce5487d
Branch pushed to git repo; I updated commit sha1. New commits:
0ca039d  fix

comment:65 Changed 9 months ago by
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 9 months ago by
 Commit changed from 0ca039da94535c49e2a02dfd2f3a31aefce5487d to e5349fb29f904741fab99983c4e93578268ed805
Branch pushed to git repo; I updated commit sha1. New commits:
e5349fb  trac 22713 more fixes in handling general base rings

comment:67 Changed 9 months ago by
 Commit changed from e5349fb29f904741fab99983c4e93578268ed805 to 54570b018b89af08d3b5d8329d3df6dc86efdabb
Branch pushed to git repo; I updated commit sha1. New commits:
54570b0  minor details in doc

comment:68 Changed 9 months ago by
 Commit changed from 54570b018b89af08d3b5d8329d3df6dc86efdabb to f8db52738bc25917cd789dee92d96df1f672005a
Branch pushed to git repo; I updated commit sha1. New commits:
f8db527  trac 22713 trying to use zetamultall

comment:69 Changed 9 months ago by
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 9 months ago by
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 9 months ago by
 Commit changed from f8db52738bc25917cd789dee92d96df1f672005a to 389bd58b4b40bd632509d434c850bb56dd7f3914
Branch pushed to git repo; I updated commit sha1. New commits:
389bd58  introduce phi_as_vector, and fix some details in doc

comment:72 Changed 9 months ago by
Je viens de rajouter une methode phi_as_vector, qui simplifie la recherche de relations.
La question du précalcul, du stockage et du recalcul des valeurs numeriques si nécessaire me pose probleme. Estce 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 9 months ago by
 Component changed from symbolics to number theory
 Keywords motives added
comment:74 Changed 9 months ago by
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 pensestu 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 9 months ago by
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 9 months ago by
 Commit changed from 389bd58b4b40bd632509d434c850bb56dd7f3914 to 6e14709c36085e0d3e0b01b24f4b370bc08b7668
comment:77 Changed 9 months ago by
Salut,
voilà une tentative minimale de cache faitmaison, 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 Fanneau, 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 9 months ago by
 Commit changed from 6e14709c36085e0d3e0b01b24f4b370bc08b7668 to a60c6888825e9f601814cf4bb931af45fd5820f8
Branch pushed to git repo; I updated commit sha1. New commits:
a60c688  trac 22713 adding a simplify procedure using duality

comment:79 Changed 9 months ago by
 Commit changed from a60c6888825e9f601814cf4bb931af45fd5820f8 to 37a5667e305f82ceec5a26546a149eaf1544e8dc
Branch pushed to git repo; I updated commit sha1. New commits:
37a5667  remove automatic simplification

comment:80 Changed 9 months ago by
 Commit changed from 37a5667e305f82ceec5a26546a149eaf1544e8dc to 7887eb2e20c536493cf0bd0c47c10c8a31eb3efb
Branch pushed to git repo; I updated commit sha1. New commits:
7887eb2  have .simplify available

comment:81 Changed 9 months ago by
Sur la branch public/22713
j'ai nettoyé l'approximation numérique.
comment:82 Changed 9 months ago by
(j'espère qu'il n'y a pas de conflit avec tes trois derniers commits)
comment:83 Changed 9 months ago by
 Commit changed from 7887eb2e20c536493cf0bd0c47c10c8a31eb3efb to d9ce5ae0f664b1ef021a25846f284d5eeffe499f
comment:84 Changed 9 months ago by
Y'a un petit bug dans pari_eval
. Je vais rajouter un commit...
comment:85 Changed 9 months ago by
See 4c2cf94267
still on public/22713
(rebased on your d9ce5ae
).
comment:86 Changed 9 months ago by
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?
comment:87 Changed 9 months ago by
 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 9 months ago by
 Commit changed from be3691c00bbe12180427880795aea559d54139fb to 1203ebf5f05a8a9d5dd29ec0efbd28c95f5881c1
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

comment:89 Changed 9 months ago by
 Commit changed from 1203ebf5f05a8a9d5dd29ec0efbd28c95f5881c1 to b295b274c34c47d6b076ea075fb85f412bdcd20f
Branch pushed to git repo; I updated commit sha1. New commits:
b295b27  trac 22713, tiny details, one more reference

comment:90 Changed 9 months ago by
Coverage is ok.
So, what remains to be done ?
comment:91 Changed 9 months ago by
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 9 months ago by
 Commit changed from b295b274c34c47d6b076ea075fb85f412bdcd20f to 08c2b81633e89f430b1df6baa169808dad232c99
comment:93 followup: ↓ 94 Changed 9 months ago by
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 9 months ago by
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 9 months ago by
 Commit changed from 08c2b81633e89f430b1df6baa169808dad232c99 to c9e3b4cf905f5bb81821e8a078eb1dd1424930dd
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

comment:96 followup: ↓ 97 Changed 9 months ago by
all commits squashed, and the patchbot is green
comment:97 in reply to: ↑ 96 Changed 9 months ago by
 Status changed from needs_review to positive_review
Replying to chapoton:
all commits squashed, and the patchbot is green
Let us get that in!
Estce que tu es dispo mardi 05.05 14h17h? 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 followup: ↓ 99 Changed 9 months ago by
 Status changed from positive_review to needs_work
Not python2compatible
comment:99 in reply to: ↑ 98 Changed 9 months ago by
 Status changed from needs_work to positive_review
Replying to vbraun:
Not python2compatible
Why is that a problem? The milestone is set to 9.2 which is supposed to be Python3 only. Or did I misunderstand something?
comment:100 Changed 9 months ago by
Probably the merging tools do not respect the milestone..
comment:101 Changed 8 months ago by
 Branch changed from public/22713 to c9e3b4cf905f5bb81821e8a078eb1dd1424930dd
 Resolution set to fixed
 Status changed from positive_review to closed
see also #18010