Re: intpart module?

[Tito Sacchi <tito dot sakki at gmail dot com>]

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
>>>
>>>
>
>