Hi all, Let me give an update on the adèles/idèles project. The project viewed as my Master's thesis project at Leiden University is completely finished: the thesis is final and it (together with the software package) has been given a high grade.
As far as I know the software package is also finished now. In the last few weeks some poeple rose some questions which sometimes lead to small changes in the code. For example those given by Justin Walker and Matthias : thank you guys! If you have any questions/suggestions/bug reports: I am still open to all of those! Please send me an email or start an issue on the GithHub repository <https://github.com/mathehertogh/adeles>. The package is now pip-installable using "sage -pip install adeles" (as suggested by Tomer and others; thank you!). The documentation is hosted online using GitHub Pages; it can be viewed at https://mathehertogh.github.io/adeles (also suggested by Tomer). The package is listed on https://wiki.sagemath.org/SageMathExternalPackages, thanks to Vincent. @Peter: thank you for the praising words, I really appreciate it. At this point I think I would like to make my package an optional SageMath package. I still have to figure out how to do this precisely. I think I will follow packaging developer guide <https://doc.sagemath.org/html/en/developer/packaging.html>. I will also take a look at Trac #31164 <https://trac.sagemath.org/ticket/31164> as suggested by Matthias. If you have more tips, let me know! But I think I'll manage. If the package where to be used frequently, it may be nice to really add it to SageMath in the future. But I will leave that for now (unless people have other opinions). Regards, Mathé Hertogh Op zaterdag 11 september 2021 om 13:29:07 UTC+2 schreef vdelecroix: > And also, list it on the page > > https://wiki.sagemath.org/SageMathExternalPackages > > Le 27/08/2021 à 04:07, Matthias Koeppe a écrit : > > I took a quick look at the packaging metadata of your package. It all > looks > > great, but in setup.cfg you will want to make a change to the > > "install_requires", which currently say "sage >= 9.2". As of Sage 9.4, > > there is no longer a distribution package called "sage". Instead we have > > "sagemath-standard". > > > > Like other have said, the way to advertise your package to Sage users is > to > > add it as an optional "pip" package to Sage. We have done this with > several > > user packages in the recent past, see > https://trac.sagemath.org/ticket/31164 > > These packages then appear in the package index at > > https://doc.sagemath.org/html/en/reference/spkg/index.html > > > > On Thursday, August 26, 2021 at 6:26:12 PM UTC-7 Travis Scrimshaw wrote: > > > >> One additional point about including it into Sage (as a sort of > >> counterpoint to Nils' point about discoverability). If it is included, > then > >> it will be documented within Sage, which means it will be very likely to > >> appear at the top of Google searches for "SageMath adéles" and we do not > >> (currently) have some clear list of other pip installable packages that > can > >> be used in Sage. The current thing to do is to have it as an optional > Sage > >> package that takes the best of both worlds: clearly linked with Sage but > >> being a separate package (which can remain pip installable). > >> > >> I believe also sage_sample is a bit out of date on our packaging > practices > >> (this was mentioned on another thread recently). > >> > >> Best, > >> Travis > >> > >> > >> On Saturday, August 21, 2021 at 12:16:13 AM UTC+10 m.c.h...@gmail.com > >> wrote: > >> > >>> Dear Tomer, > >>> > >>> Thank you for the tips and advice. I will definitely (try to) do both! > >>> > >>> Regards, > >>> Mathé > >>> > >>> On Thu, 19 Aug 2021 at 22:06, TB <math...@gmail.com> wrote: > >>> > >>>> Dear Mathé, > >>>> > >>>> From a quick skim of https://github.com/mathehertogh/adeles it looks > >>>> very impressive. I do not know if it is better to incorporate the > code into > >>>> Sage or leave it as a stand-alone package, but in case the code does > live > >>>> in its own repository, I would make two suggestions: > >>>> > >>>> 1. Upload the package into PyPI, so users can install it with a > command > >>>> like: > >>>> $ sage --pip install package-name > >>>> and developers will still use `git clone` for the latest development > >>>> version. This should make it easier for users to try out the code. > >>>> The Sage Sample Package [1] have the basic structure for Sage > packages, > >>>> but in a recent thread [2] it was noted that some of the packaging > advice > >>>> there is somewhat outdated. Your code is only (or mostly?) in Python, > so > >>>> consulting the Python Packaging User Guide [3] can be more useful. > >>>> > >>>> 2. Have the compiled HTML docs hosted somewhere (e.g. Read the Docs, > >>>> GitHub Pages, personal website, etc.). Your repository seems to have > >>>> extensive docs, and similar to the first point, it would make it > easier for > >>>> users to see what this package provides. This should also make the > docs > >>>> easier to find for a search engine. > >>>> > >>>> Regards, > >>>> Tomer > >>>> > >>>> [1] https://github.com/sagemath/sage_sample > >>>> [2] https://groups.google.com/g/sage-devel/c/wvhXWMwd0i8 > >>>> [3] https://packaging.python.org/ > >>>> > >>>> On 18/08/2021 19:00, Mathe Hertogh wrote: > >>>> > >>>> Dear Nils and others, > >>>> > >>>> I would put my contribution in category B: creating infrastructure for > >>>> computing with adèles and idèles. > >>>> > >>>> Currently completions of number fields at finite primes are not yet > >>>> implemented in sagemath and hence the bundling of such computations > into an > >>>> adèle ring is not possible at this point. My design is different, as > you > >>>> noted: I implement rings of profinite integers as projective limits of > >>>> rings of integers. And based on that implementation I implemented the > >>>> finite adèle ring. > >>>> As for the idèles: there I do compute at different completions of a > >>>> number field explicitly. For this I implemented the unit groups of > such > >>>> completions at finite primes seperately. > >>>> Indeed Part 3 is an algorithmic contribution. > >>>> > >>>> As for the link to function fields and their Picard groups: I did nog > >>>> take this into consideration during the design. So I would not know > how > >>>> easy it would to extend my code to such circumstances. > >>>> > >>>> As for the killer applications: the motivating application of these > >>>> rings/groups was the computation of Part 4. Outside of that, I do not > know > >>>> of any applications that would benefit from this code. But as this is > the > >>>> first implementation of adèles/idèles in a computer algebra package > (as for > >>>> as I know), this is not supprising I guess. > >>>> You could view the following as an “application” as well though: > letting > >>>> students learning about adèles and idèles for the first time by > letting > >>>> them compute with them in practice using sage, just like some > undergraduate > >>>> courses use sage to teach about groups. > >>>> > >>>> You make a valid point about leaving the repository on its own for a > >>>> while. If this is how you think about it and there are no other > poeple with > >>>> (different) opinions, then I will let go of the plan to include the > code > >>>> into sagemath for now. > >>>> But I know of at least one person that is currently trying out the > code, > >>>> and maybe there are also others that are still checking it out. If > they > >>>> have something to say about the package, I would love to hear! > >>>> > >>>> Kind regards, > >>>> Mathé > >>>> > >>>> On Sat, 14 Aug 2021 at 19:46, Nils Bruin <nbr...@sfu.ca> wrote: > >>>> > >>>>> Dear Mathé, > >>>>> > >>>>> Congratulations on almost finishing your thesis. I trust it will just > >>>>> take a short stretch of time until you succeed in fully finishing > your > >>>>> thesis (code from an unfinished thesis would be a bit of a red > flag). I'll > >>>>> give a bit of a general view of what the pros and cons of including > code in > >>>>> sagemath are. > >>>>> > >>>>> Useful new contributions to computer algebra packages come in many > >>>>> forms. I think two main categories are: > >>>>> A) Algorithmic contributions -- an implementation of some non-trivial > >>>>> algorithm (or suite of them) that allow certain computations that > would be > >>>>> hard to do without them. > >>>>> B) Infrastructure/interface contributions - parts of the system that > >>>>> allow convenient and easy access to algorithms, or sometimes allow > for > >>>>> expressing computations in a way that is closer to mathematics than > what > >>>>> "raw" access to algorithms would allow. > >>>>> > >>>>> For A), a valuable contribution could be a new algorithm, or an > >>>>> implementation of an existing algorithm. The value can come from the > >>>>> implementation being much faster/more efficient than other existing > >>>>> implementations or simply from an implementation now being available > from > >>>>> sagemath where it first wasn't. Packaging and interfacing with > existing > >>>>> libraries can fall in this category too, It helps if there are some > "killer > >>>>> applications": things that a lot of people agree on that are > valuable to > >>>>> compute, that can be done with the new contribution. > >>>>> > >>>>> For B) I would think of things like implementing a new ring type, or > >>>>> for instance scheme morphisms (the underlying algorithm for most of > the > >>>>> questions there is a groebner basis algorithm), where a lot of the > value > >>>>> can come from being able to represent the morphism and the system > checking > >>>>> that the data is consistent. Here too, the value comes from providing > >>>>> infrastructure that actually gets used. So relevance for some "killer > >>>>> application" comes in handy here too. There's a meta-level to B: > >>>>> infrastructure for implementing such systems (that's where sage's > coercion > >>>>> framework and category framework come in) > >>>>> > >>>>> For A) you can already make a useful contribution by providing "raw" > >>>>> access to the algorithm: an API that allows you to pass in the > parameters > >>>>> exactly as the implementation requires it. The icing on the cake is > then a > >>>>> small wrapper/translation layer that allows the input to be > specified in > >>>>> flexible forms that are convenient to the user. Generally you want > both: > >>>>> the convenience layer costs overhead, so it's good if there's an > option to > >>>>> strip it out. > >>>>> > >>>>> I would generally not recommend B) to a novice contributor. It's > where > >>>>> "good design" is of utmost importance and where compatibility with > other > >>>>> design decisions in sage (themselves not necessarily optimal) is > important. > >>>>> Design that combines room for growth as well as the room for fast > code > >>>>> paths is also important. These are particularly things where > experience of > >>>>> a non-mathematical nature is invaluable. > >>>>> > >>>>> From what you describe, it sounds like your contribution has an > >>>>> important B) component to it: interface for ring of adeles. One way > of > >>>>> implementing those is by doing all computations in complete local > fields, > >>>>> and then the "adele ring" is mainly a tool for administrating those > >>>>> computations. Are you doing something different (it looks like you > might, > >>>>> if you're actually providing Zhat as a projective limit on its own)? > Any > >>>>> significant algorithmic components there? Part 3 sounds like it, > possibly. > >>>>> > >>>>> One thing I'd be worried about for the B) design of adelic rings is > >>>>> their close link to, in the geometric case, function fields and the > >>>>> computation of their Picard groups (and in the number field case > too) It > >>>>> doesn't need to be there in the first iteration, but it's worth > paying > >>>>> attention to the design so that no big roadblocks are created. > >>>>> > >>>>> Finally, what are your "killer applications"? > >>>>> > >>>>> An option other than immediate incorporation into sage would be to > >>>>> first let it live for a while as a separate repository. You'll be > more > >>>>> nimble in redesigning the interface if it's necessary. Then, with > more > >>>>> maturity and proven audience interest, incorporation in sage is an > easy > >>>>> decision to make. It also establishes a consistency record on your > side, so > >>>>> that more regular sagemath contributors aren't worried that this is a > >>>>> commit-and-run, where someone checks in a piece of code with just > the right > >>>>> amount of work to get it past review and then isn't around anymore > to fix > >>>>> the little things that slipped through review. > >>>>> > >>>>> While it might seem that incorporation into sage is a good way of > >>>>> protecting the package from withering away in its own little > repository, I > >>>>> think that doesn't actually help too much: discoverability in sage > is only > >>>>> there if people know to look for it, and if it doesn't get used, > >>>>> incorporation into sage only adds to the maintenance burden. For you > >>>>> getting credit for the work: sure "code accepted into SageMath" is > an OK > >>>>> CV-item, but a separate repo may actually provide better visibility > of the > >>>>> code. > >>>>> > >>>>> > >>>>> -- > >>>>> You received this message because you are subscribed to a topic in > the > >>>>> Google Groups "sage-devel" group. > >>>>> To unsubscribe from this topic, visit > >>>>> https://groups.google.com/d/topic/sage-devel/15ALIvGHqYs/unsubscribe > . > >>>>> To unsubscribe from this group and all its topics, send an email to > >>>>> sage-devel+...@googlegroups.com. > >>>>> To view this discussion on the web visit > >>>>> > https://groups.google.com/d/msgid/sage-devel/67b380ee-aa2e-492f-b740-495fc91abe6dn%40googlegroups.com > >>>>> < > https://groups.google.com/d/msgid/sage-devel/67b380ee-aa2e-492f-b740-495fc91abe6dn%40googlegroups.com?utm_medium=email&utm_source=footer > > > >>>>> . > >>>>> > >>>> -- > >>>> > >>>> You received this message because you are subscribed to the Google > >>>> Groups "sage-devel" group. > >>>> To unsubscribe from this group and stop receiving emails from it, send > >>>> an email to sage-devel+...@googlegroups.com. > >>>> To view this discussion on the web visit > >>>> > https://groups.google.com/d/msgid/sage-devel/CAPxwVi_J-aT%3DDZUb%3D%2BzO_LXZ3KyCnCLXuVCD5OD%2BFWi_g1eanQ%40mail.gmail.com > >>>> < > https://groups.google.com/d/msgid/sage-devel/CAPxwVi_J-aT%3DDZUb%3D%2BzO_LXZ3KyCnCLXuVCD5OD%2BFWi_g1eanQ%40mail.gmail.com?utm_medium=email&utm_source=footer > > > >>>> . > >>>> > >>>> > >>>> -- > >>>> You received this message because you are subscribed to a topic in the > >>>> Google Groups "sage-devel" group. > >>>> To unsubscribe from this topic, visit > >>>> https://groups.google.com/d/topic/sage-devel/15ALIvGHqYs/unsubscribe. > >>>> To unsubscribe from this group and all its topics, send an email to > >>>> sage-devel+...@googlegroups.com. > >>>> > >>> To view this discussion on the web visit > >>>> > https://groups.google.com/d/msgid/sage-devel/8807e325-2414-537f-cbf6-d0a44b7bd95c%40gmail.com > >>>> < > https://groups.google.com/d/msgid/sage-devel/8807e325-2414-537f-cbf6-d0a44b7bd95c%40gmail.com?utm_medium=email&utm_source=footer > > > >>>> . > >>>> > >>> > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4385d193-8f7a-4279-974d-7e1100d49b0bn%40googlegroups.com.
