From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50998 invoked by alias); 6 Jun 2018 02:33:45 -0000 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org Received: (qmail 50945 invoked by uid 89); 6 Jun 2018 02:33:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=knew, UD:aspx, wouldn, young X-HELO: NAM03-DM3-obe.outbound.protection.outlook.com Received: from mail-dm3nam03on0113.outbound.protection.outlook.com (HELO NAM03-DM3-obe.outbound.protection.outlook.com) (104.47.41.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Jun 2018 02:33:41 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=patrick.alken@colorado.edu; Received: from [192.168.0.8] (75.166.58.187) by BN3PR0301MB1234.namprd03.prod.outlook.com (2a01:111:e400:403d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.13; Wed, 6 Jun 2018 02:33:36 +0000 Subject: Re: intpart module? To: gsl-discuss@sourceware.org References: From: Patrick Alken Openpgp: preference=signencrypt Message-ID: Date: Wed, 06 Jun 2018 02:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: CY4PR22CA0062.namprd22.prod.outlook.com (2603:10b6:903:ae::24) To BN3PR0301MB1234.namprd03.prod.outlook.com (2a01:111:e400:403d::22) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PR0301MB1234: X-Exchange-Antispam-Report-Test: UriScan:(250305191791016)(191161893330683)(278428928389397)(22074186197030); X-MS-Exchange-SenderADCheck: 1 X-Forefront-PRVS: 06952FC175 Received-SPF: None (protection.outlook.com: colorado.edu does not designate permitted sender hosts) SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Office365-Filtering-Correlation-Id: 9a369144-3936-4b89-4b66-08d5cb55e812 X-OriginatorOrg: colorado.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2018 02:33:36.6777 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9a369144-3936-4b89-4b66-08d5cb55e812 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3ded8b1b-070d-4629-82e4-c0b019f46057 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 X-SW-Source: 2018-q2/txt/msg00010.txt.bz2 Hello, =C2=A0 Thanks for some more details about what you want to do. It sounds fr= om 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 ar= e 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 prop= erty. > > 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 arr= ange > 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=E2= =80=99t > 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/Combinatori= caPackage.html > [2] https://www.maplesoft.com/support/help/maple/view.aspx?path=3DIterator > [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 : >> 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 ma= de >> 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=E2=80=99d like to start working on some code on integer partitions, >>> combinatorics, and related algorithms >>> (Young tableaux, hook lengths...) in a new module that I=E2=80=99d call >>> =E2=80=9Cintpart=E2=80=9D (or =E2=80=9Cintparts=E2=80=9D, tell me). >>> I have already read the GSL Homepage which says that =E2=80=9Cany new >>> functionality is encouraged as >>> packages=E2=80=9D, but such module isn=E2=80=99t very specific, and cre= ating a package >>> would signify creating a totally >>> different library which probably wouldn=E2=80=99t even use any GSL func= tion >>> (could we call it an extension?); >>> then we=E2=80=99ll end up with another C library which probably won=E2= =80=99t 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 >> >>