public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
* intpart module?
@ 2018-05-31 19:01 Tito Sacchi
  2018-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 Alken
  2018-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 Sacchi
  2018-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 Alken
  2018-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

* Re: intpart module?
  2018-06-06  2:33     ` Patrick Alken
@ 2018-06-06 18:28       ` Tito Sacchi
  0 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).