Feedback needed on Vertex algebra implementation

[Reimundo Heluani]

Dear all, this e-mail is mostly advertising ticket

https://trac.sagemath.org/ticket/29610

and asking for help. It is my hope that eventually some version of that ticket
would make it to SageMath.

I've implemented Vertex algebras, Lie Conformal Algebras and Poisson Vertex
Algebras. Some of the description is in the ticket itself and most examples
are in the manuals that are compiled mainly in the pages:

http://potuz.net/reference/algebras/sage/algebras/vertex_algebras/vertex_algebra.html
http://potuz.net/reference/algebras/vertex_algebras/vertex_algebras.html
http://potuz.net/reference/algebras/lie_conformal_algebras/lie_conformal_algebras.html
http://potuz.net/reference/algebras/poisson_vertex_algebras/poisson_vertex_algebras.html

The patch is not small and is bound to have tons of mistakes/bugs. I'd love to
hear any feedback you may have.

I understand that reviewing this may be an ungratifying pain. It was suggested
by Frédéric Chapoton and Travis Scrimshaw that I should break this patch in
smaller pieces in order to get it reviewed.

I am happy to do so, but before doing so I wanted to ask opinions here. In
principle I could remove all examples of these algebras and leave one to
doctest, then break into Lie conformal algebras + vertex algebras + poisson
vertex algebras and try to remove the overlap between these classes: like
lifting from a Lie conformal algebra to its universal enveloping algebra, or
taking classical limits from a vertex algebra to a poisson vertex algebra, or
the fact that Poisson vertex algebras are Lie conformal algebras and inherit
some of the methods from that category, etc.

Now that I am writing this e-mail I realize that it may be a harder task than
I thought. But the point I wanted to make/ask is whether or not this is worth
it or even if it is a good model? It looks to me that it will put an
unnecessary burden on my part with no gain for the reviewer (besides having
less code to read). Maintaining it would be much harder, and the set of
examples that the documentation would have would be much smaller. It also
looks to me that is actually more error-prone to have bits an pieces of code
carefully divided to not break something that was already working as a whole,
and to finally have it assembled again.

Please take a look at the above pages and you'll see quite a variety of
examples, most, if not all, would be gone if I were to divide this into
smaller pieces. I get the impression that this does a disservice to someone
that wants to read the code.

Anyway,

I hope someone can take this up. As it stands now it is already useful to me
and to my collaborators to have one repository from where they can clone that
branch.

Best,

R.

[Sébastien Labbé]

Bonjour,

When writing new modules containing thousands of lines of code, I think it is important to know that there are more than one way to share this code to the SageMath Community:

1) Post a patch bomb on trac, hoping that people will review it and hoping the code follows the Sage conventions and hoping it works for oneself but also different kind of usages by others and hoping the code is mature enough (the interface must be stable afterwards which puts lot of pressure on the reviewers to make sure everything is okay in the patch bomb)

2) Create a pip optional SageMath package containing the code allowing anyone on earth to easily install it by doing `sage -pip install yourpackage` and allowing yourself to update the package as you wish including changes in the API.

Personnally, in the last years, I like the idea of first using 2), and then, when I am confident on the API for my own usage but also for more diverse usage, I go to 1). But maybe going to 1) is not the goal anymore. Indeed, note that Sage development directions is now to split its core into independent modules. So, I am now wandering myself if the goal is really to get patch bomb into sage anymore? By definition of a patch bomb, nothing depends on the patch bomb. So it seems to be easy to modularize... I would be curious to get the opinion of Matthias Koeppe on that.

Sincerely,

Sébastien Labbé

[Travis Scrimshaw]

When writing new modules containing thousands of lines of code, I think it is important to know that there are more than one way to share this code to the SageMath Community:

1) Post a patch bomb on trac, hoping that people will review it and hoping the code follows the Sage conventions and hoping it works for oneself but also different kind of usages by others and hoping the code is mature enough (the interface must be stable afterwards which puts lot of pressure on the reviewers to make sure everything is okay in the patch bomb)

2) Create a pip optional SageMath package containing the code allowing anyone on earth to easily install it by doing `sage -pip install yourpackage` and allowing yourself to update the package as you wish including changes in the API.

Personnally, in the last years, I like the idea of first using 2), and then, when I am confident on the API for my own usage but also for more diverse usage, I go to 1). But maybe going to 1) is not the goal anymore. Indeed, note that Sage development directions is now to split its core into independent modules.

I am opposed to 2. We have no mechanism for easy user access and testing such code. It is too easy for it to break when it relies on code already in Sage and is meant to be integrated in. Modularization is good, but fragmentation is not. It is also difficult to get diverse usage without exposure and integration.

I am going to be reviewing (albeit slowly) the ticket; although I would like to have a few smaller tickets if it can be done reasonably.

 

So, I am now wandering myself if the goal is really to get patch bomb into sage anymore? By definition of a patch bomb, nothing depends on the patch bomb.

That is not true: categories, coercion rewrite, new-style parents, Python3 transition, to name a few. All of these included some form of a patch bomb with efforts being made to make it more incremental to lessen the work to actually get it in.

 

So it seems to be easy to modularize... I would be curious to get the opinion of Matthias Koeppe on that.

Best,

Travis