*intpart module?@ 2018-05-31 19:01 Tito Sacchi2018-05-31 19:16 ` Patrick Alken 0 siblings, 1 reply; 5+ messages in thread From: Tito Sacchi @ 2018-05-31 19:01 UTC (permalink / raw) To: gsl-discuss;+Cc:Massimiliano Sacchi Greetings, I’d like to start working on some code on integer partitions, combinatorics, and related algorithms (Young tableaux, hook lengths...) in a new module that I’d call “intpart” (or “intparts”, tell me). I have already read the GSL Homepage which says that “any new functionality is encouraged as packages”, but such module isn’t very specific, and creating a package would signify creating a totally different library which probably wouldn’t even use any GSL function (could we call it an extension?); then we’ll end up with another C library which probably won’t get integrated into GSL, so I thought you might be interested in including it directly into the main library (obviously after testing ecc.). Just let me know if you prefer that I work on the anonymous clone of the Savannah repo, or that I start a separate project, maybe on GitHub. Yours sincerely, Tito Sacchi ^ permalink raw reply [flat|nested] 5+ messages in thread

*Re: intpart module?2018-05-31 19:01 intpart module? Tito Sacchi@ 2018-05-31 19:16 ` Patrick Alken2018-06-02 7:26 ` Tito Sacchi 0 siblings, 1 reply; 5+ messages in thread From: Patrick Alken @ 2018-05-31 19:16 UTC (permalink / raw) To: gsl-discuss Hello, Â I certainly encourage more people working on GSL! Though keep in mind GSL aims to be a general-purpose scientific computing library. I personally don't work in combinatorics, so its difficult for me to gauge how many people would benefit / use these new algorithms you propose. If indeed a large number of users would like to see these algorithms in GSL, then certainly I would like to add them. However if only a small number of specialists would be interested, then I would say this work should be made into an extension library, which is as you say a self-contained external library which may or may not rely on GSL itself. Perhaps as a first step you could give some examples of what kinds of problems people can solve with these algorithms you are planning to code? Patrick On 05/31/2018 01:01 PM, Tito Sacchi wrote: > Greetings, > > Iâ€™d like to start working on some code on integer partitions, > combinatorics, and related algorithms > (Young tableaux, hook lengths...) in a new module that Iâ€™d call > â€œintpartâ€ (or â€œintpartsâ€, tell me). > I have already read the GSL Homepage which says that â€œany new > functionality is encouraged as > packagesâ€, but such module isnâ€™t very specific, and creating a package > would signify creating a totally > different library which probably wouldnâ€™t even use any GSL function > (could we call it an extension?); > then weâ€™ll end up with another C library which probably wonâ€™t get > integrated into GSL, so I thought > you might be interested in including it directly into the main library > (obviously after testing ecc.). > Just let me know if you prefer that I work on the anonymous clone of > the Savannah repo, or that I > start a separate project, maybe on GitHub. > > Yours sincerely, > Tito Sacchi ^ permalink raw reply [flat|nested] 5+ messages in thread

*Re: intpart module?2018-05-31 19:16 ` Patrick Alken@ 2018-06-02 7:26 ` Tito Sacchi2018-06-06 2:33 ` Patrick Alken 0 siblings, 1 reply; 5+ messages in thread From: Tito Sacchi @ 2018-06-02 7:26 UTC (permalink / raw) To: gsl-discuss;+Cc:Massimiliano Sacchi Hello, I understand your doubts about the inclusion of new features into GSL. I think that the combinatoric algorithms related to integer partitions are of general interest and useful for a wide range of subjects. The fact that many software companies have implemented packages (e.g. Wolfram's Combinatorica [1], Maplesoft's Iterator [2]) for these algorithms for their own programs proves the importance and the general-purpose property. Among the most common applications: - Young tableaux are useful for solving many basic combinatorial problems. For example, the answer to the question "How many ways are there to arrange a group of 25 students into a 5x5 grid such that in every row and every column their heights are in incresing order (each row/column is independent from each other)?" is greater than 700M, and can be efficiently calculated using the hook-length formula [3]: it corresponds to the number of standard Young tableaux [4] of shape [5, 5, 5, 5, 5]. - Also, they have applications in other fields of mathematics and in physics. By means of the Schur-Weyl duality [5] applied to the joint action of the symmetric group S_k and the general linear group GL(n) of invertible n x n matrices on tensor spaces, using both the hook-lenght formula [3] and the hook-content formula one can obtain the dimensions of the irreducible representations along with their multiplicities of S_k and GL(n). This has many applications in group representation theory, quantum information theory, quantum metrology, and particle physics. The implementation of this wouldn’t even require (representation) group theory support in the library. For more information see the Wikipedia pages below. [1] http://reference.wolfram.com/language/Combinatorica/guide/CombinatoricaPackage.html [2] https://www.maplesoft.com/support/help/maple/view.aspx?path=Iterator [3] https://en.wikipedia.org/wiki/Hook_length_formula [4] https://en.wikipedia.org/wiki/Young_tableau [5] https://en.wikipedia.org/wiki/Schur%E2%80%93Weyl_duality 2018-05-31 21:16 GMT+02:00 Patrick Alken <alken@colorado.edu>: > Hello, > > I certainly encourage more people working on GSL! Though keep in mind GSL > aims to be a general-purpose scientific computing library. I personally > don't work in combinatorics, so its difficult for me to gauge how many > people would benefit / use these new algorithms you propose. If indeed a > large number of users would like to see these algorithms in GSL, then > certainly I would like to add them. However if only a small number of > specialists would be interested, then I would say this work should be made > into an extension library, which is as you say a self-contained external > library which may or may not rely on GSL itself. > > Perhaps as a first step you could give some examples of what kinds of > problems people can solve with these algorithms you are planning to code? > > Patrick > > > On 05/31/2018 01:01 PM, Tito Sacchi wrote: >> >> Greetings, >> >> I’d like to start working on some code on integer partitions, >> combinatorics, and related algorithms >> (Young tableaux, hook lengths...) in a new module that I’d call >> “intpart” (or “intparts”, tell me). >> I have already read the GSL Homepage which says that “any new >> functionality is encouraged as >> packages”, but such module isn’t very specific, and creating a package >> would signify creating a totally >> different library which probably wouldn’t even use any GSL function >> (could we call it an extension?); >> then we’ll end up with another C library which probably won’t get >> integrated into GSL, so I thought >> you might be interested in including it directly into the main library >> (obviously after testing ecc.). >> Just let me know if you prefer that I work on the anonymous clone of >> the Savannah repo, or that I >> start a separate project, maybe on GitHub. >> >> Yours sincerely, >> Tito Sacchi > > > ^ permalink raw reply [flat|nested] 5+ messages in thread

*Re: intpart module?2018-06-02 7:26 ` Tito Sacchi@ 2018-06-06 2:33 ` Patrick Alken2018-06-06 18:28 ` Tito Sacchi 0 siblings, 1 reply; 5+ messages in thread From: Patrick Alken @ 2018-06-06 2:33 UTC (permalink / raw) To: gsl-discuss Hello, Thanks for some more details about what you want to do. It sounds from your description that this would be a substantial amount of code to be contributed to GSL (as opposed to one or two supporting functions, etc) - perhaps even a brand new module with numerous functions under it. First note that GSL attempts to follow the GNU coding standards (https://www.gnu.org/prep/standards/standards.html) as closely as possible, to achieve a uniform look and feel to the code throughout the library. Stability and clean interoperability is also a top priority for GSL, so adding a large chunk of new code will undoubtedly come with bugs and potential issues with interfacing with the rest of GSL. It is important that the design of your new module is well planned and thought out prior to adding it into the main GSL source tree, in order to achieve the simplest and cleanest API interfaces, the best implementation of the various algorithms you plan to use, etc. I recommend building your new module as a library extension, at least initially. This will give myself and others the chance to review your overall design, quality of the source code, etc, and make suggestions for improvement before it is folded into the main library. There will undoubtedly be multiple iterations of the code design before it is ready to be put in GSL. As an example, I myself have added a new module recently to GSL called gsl_movstat (moving window statistics). Prior to this, I had developed this as an external library more than 6 months ago, and did a complete redesign of that library twice in the last 6 months, before I knew it was ready to be put into GSL. Even after I put it into GSL, I spent several months writing tests, documentation, and tweaking the API calls to try to achieve the best results. None of this is meant to be discouraging. I think this has the potential to be a useful contribution to GSL. Its up to you now to do the work :) Patrick On 06/02/2018 01:26 AM, Tito Sacchi wrote: > Hello, > > I understand your doubts about the inclusion of new features into GSL. > I think that the combinatoric algorithms related to integer partitions are of > general interest and useful for a wide range of subjects. > The fact that many software companies have implemented packages > (e.g. Wolfram's Combinatorica [1], Maplesoft's Iterator [2]) for these > algorithms > for their own programs proves the importance and the general-purpose property. > > Among the most common applications: > - Young tableaux are useful for solving many basic combinatorial problems. > For example, the answer to the question "How many ways are there to arrange > a group of 25 students into a 5x5 grid such that in every row and every column > their heights are in incresing order (each row/column is independent > from each other)?" > is greater than 700M, and can be efficiently calculated using the > hook-length formula [3]: > it corresponds to the number of standard Young tableaux [4] of shape > [5, 5, 5, 5, 5]. > - Also, they have applications in other fields of mathematics and in > physics. By means of > the Schur-Weyl duality [5] applied to the joint action of the > symmetric group S_k and the > general linear group GL(n) of invertible n x n matrices on tensor > spaces, using both the > hook-lenght formula [3] and the hook-content formula one can obtain > the dimensions of > the irreducible representations along with their multiplicities of > S_k and GL(n). This has > many applications in group representation theory, quantum > information theory, quantum > metrology, and particle physics. The implementation of this wouldn’t > even require > (representation) group theory support in the library. > > For more information see the Wikipedia pages below. > > [1] http://reference.wolfram.com/language/Combinatorica/guide/CombinatoricaPackage.html > [2] https://www.maplesoft.com/support/help/maple/view.aspx?path=Iterator > [3] https://en.wikipedia.org/wiki/Hook_length_formula > [4] https://en.wikipedia.org/wiki/Young_tableau > [5] https://en.wikipedia.org/wiki/Schur%E2%80%93Weyl_duality > > > 2018-05-31 21:16 GMT+02:00 Patrick Alken <alken@colorado.edu>: >> Hello, >> >> I certainly encourage more people working on GSL! Though keep in mind GSL >> aims to be a general-purpose scientific computing library. I personally >> don't work in combinatorics, so its difficult for me to gauge how many >> people would benefit / use these new algorithms you propose. If indeed a >> large number of users would like to see these algorithms in GSL, then >> certainly I would like to add them. However if only a small number of >> specialists would be interested, then I would say this work should be made >> into an extension library, which is as you say a self-contained external >> library which may or may not rely on GSL itself. >> >> Perhaps as a first step you could give some examples of what kinds of >> problems people can solve with these algorithms you are planning to code? >> >> Patrick >> >> >> On 05/31/2018 01:01 PM, Tito Sacchi wrote: >>> Greetings, >>> >>> I’d like to start working on some code on integer partitions, >>> combinatorics, and related algorithms >>> (Young tableaux, hook lengths...) in a new module that I’d call >>> “intpart” (or “intparts”, tell me). >>> I have already read the GSL Homepage which says that “any new >>> functionality is encouraged as >>> packages”, but such module isn’t very specific, and creating a package >>> would signify creating a totally >>> different library which probably wouldn’t even use any GSL function >>> (could we call it an extension?); >>> then we’ll end up with another C library which probably won’t get >>> integrated into GSL, so I thought >>> you might be interested in including it directly into the main library >>> (obviously after testing ecc.). >>> Just let me know if you prefer that I work on the anonymous clone of >>> the Savannah repo, or that I >>> start a separate project, maybe on GitHub. >>> >>> Yours sincerely, >>> Tito Sacchi >> >> ^ permalink raw reply [flat|nested] 5+ messages in thread

*2018-06-06 2:33 ` Patrick AlkenRe: intpart module?@ 2018-06-06 18:28 ` Tito Sacchi0 siblings, 0 replies; 5+ messages in thread From: Tito Sacchi @ 2018-06-06 18:28 UTC (permalink / raw) To: gsl-discuss Hi Patrick, Thank you for your suggestions. I'll proceed following your advice. Tito Sacchi 2018-06-06 4:33 GMT+02:00 Patrick Alken <alken@colorado.edu>: > Hello, > > Thanks for some more details about what you want to do. It sounds from > your description that this would be a substantial amount of code to be > contributed to GSL (as opposed to one or two supporting functions, etc) > - perhaps even a brand new module with numerous functions under it. > > First note that GSL attempts to follow the GNU coding standards > (https://www.gnu.org/prep/standards/standards.html) as closely as > possible, to achieve a uniform look and feel to the code throughout the > library. Stability and clean interoperability is also a top priority for > GSL, so adding a large chunk of new code will undoubtedly come with bugs > and potential issues with interfacing with the rest of GSL. It is > important that the design of your new module is well planned and thought > out prior to adding it into the main GSL source tree, in order to > achieve the simplest and cleanest API interfaces, the best > implementation of the various algorithms you plan to use, etc. > > I recommend building your new module as a library extension, at least > initially. This will give myself and others the chance to review your > overall design, quality of the source code, etc, and make suggestions > for improvement before it is folded into the main library. There will > undoubtedly be multiple iterations of the code design before it is ready > to be put in GSL. > > As an example, I myself have added a new module recently to GSL called > gsl_movstat (moving window statistics). Prior to this, I had developed > this as an external library more than 6 months ago, and did a complete > redesign of that library twice in the last 6 months, before I knew it > was ready to be put into GSL. Even after I put it into GSL, I spent > several months writing tests, documentation, and tweaking the API calls > to try to achieve the best results. > > None of this is meant to be discouraging. I think this has the potential > to be a useful contribution to GSL. Its up to you now to do the work :) > > Patrick > > On 06/02/2018 01:26 AM, Tito Sacchi wrote: >> Hello, >> >> I understand your doubts about the inclusion of new features into GSL. >> I think that the combinatoric algorithms related to integer partitions are of >> general interest and useful for a wide range of subjects. >> The fact that many software companies have implemented packages >> (e.g. Wolfram's Combinatorica [1], Maplesoft's Iterator [2]) for these >> algorithms >> for their own programs proves the importance and the general-purpose property. >> >> Among the most common applications: >> - Young tableaux are useful for solving many basic combinatorial problems. >> For example, the answer to the question "How many ways are there to arrange >> a group of 25 students into a 5x5 grid such that in every row and every column >> their heights are in incresing order (each row/column is independent >> from each other)?" >> is greater than 700M, and can be efficiently calculated using the >> hook-length formula [3]: >> it corresponds to the number of standard Young tableaux [4] of shape >> [5, 5, 5, 5, 5]. >> - Also, they have applications in other fields of mathematics and in >> physics. By means of >> the Schur-Weyl duality [5] applied to the joint action of the >> symmetric group S_k and the >> general linear group GL(n) of invertible n x n matrices on tensor >> spaces, using both the >> hook-lenght formula [3] and the hook-content formula one can obtain >> the dimensions of >> the irreducible representations along with their multiplicities of >> S_k and GL(n). This has >> many applications in group representation theory, quantum >> information theory, quantum >> metrology, and particle physics. The implementation of this wouldn’t >> even require >> (representation) group theory support in the library. >> >> For more information see the Wikipedia pages below. >> >> [1] http://reference.wolfram.com/language/Combinatorica/guide/CombinatoricaPackage.html >> [2] https://www.maplesoft.com/support/help/maple/view.aspx?path=Iterator >> [3] https://en.wikipedia.org/wiki/Hook_length_formula >> [4] https://en.wikipedia.org/wiki/Young_tableau >> [5] https://en.wikipedia.org/wiki/Schur%E2%80%93Weyl_duality >> >> >> 2018-05-31 21:16 GMT+02:00 Patrick Alken <alken@colorado.edu>: >>> Hello, >>> >>> I certainly encourage more people working on GSL! Though keep in mind GSL >>> aims to be a general-purpose scientific computing library. I personally >>> don't work in combinatorics, so its difficult for me to gauge how many >>> people would benefit / use these new algorithms you propose. If indeed a >>> large number of users would like to see these algorithms in GSL, then >>> certainly I would like to add them. However if only a small number of >>> specialists would be interested, then I would say this work should be made >>> into an extension library, which is as you say a self-contained external >>> library which may or may not rely on GSL itself. >>> >>> Perhaps as a first step you could give some examples of what kinds of >>> problems people can solve with these algorithms you are planning to code? >>> >>> Patrick >>> >>> >>> On 05/31/2018 01:01 PM, Tito Sacchi wrote: >>>> Greetings, >>>> >>>> I’d like to start working on some code on integer partitions, >>>> combinatorics, and related algorithms >>>> (Young tableaux, hook lengths...) in a new module that I’d call >>>> “intpart” (or “intparts”, tell me). >>>> I have already read the GSL Homepage which says that “any new >>>> functionality is encouraged as >>>> packages”, but such module isn’t very specific, and creating a package >>>> would signify creating a totally >>>> different library which probably wouldn’t even use any GSL function >>>> (could we call it an extension?); >>>> then we’ll end up with another C library which probably won’t get >>>> integrated into GSL, so I thought >>>> you might be interested in including it directly into the main library >>>> (obviously after testing ecc.). >>>> Just let me know if you prefer that I work on the anonymous clone of >>>> the Savannah repo, or that I >>>> start a separate project, maybe on GitHub. >>>> >>>> Yours sincerely, >>>> Tito Sacchi >>> >>> > > ^ permalink raw reply [flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-06-06 18:28 UTC | newest]Thread overview:5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-31 19:01 intpart module? Tito Sacchi 2018-05-31 19:16 ` Patrick Alken 2018-06-02 7:26 ` Tito Sacchi 2018-06-06 2:33 ` Patrick Alken 2018-06-06 18:28 ` Tito Sacchi

This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).