Re: [Haskell-cafe] ANN: combinatorics

-------------------------------------------- -- combinatorics 0.1.0 --------------------------------------------
The combinatorics package offers efficient *exact* computation of common combinatorial functions like the binomial coefficients and factorial. (For fast *approximations*, see the math-functions package instead.)
Shameless self-promotion: The combinat package (which deliberately does not try to own the valuable namespace Math.Combinatorics) is a more extensive combinatorics library: http://hackage.haskell.org/package/combinat While the main focus is the generation of combinatorial objects themselves, counting functions and common number sequences like the above are also offered. Even though the binomial and factorial definition in this package are the naive ones, a quick experiment imply that the differences start show themselves around 100,000 factorial, or choosing 50,000 elements out of 100,000, which is probably a rather specialized use case. The primes function in the combinat package is based on an old Cafe thread, and actually seems to be faster than the one in the combinatorics package. In any case, I may switch to the faster algorithms in the future :) Balazs

On 1/30/12 12:55 PM, Balazs Komuves wrote:
-------------------------------------------- -- combinatorics 0.1.0 --------------------------------------------
The combinatorics package offers efficient *exact* computation of common combinatorial functions like the binomial coefficients and factorial. (For fast *approximations*, see the math-functions package instead.)
Shameless self-promotion: The combinat package (which deliberately does not try to own the valuable namespace Math.Combinatorics) is a more extensive combinatorics library:
http://hackage.haskell.org/package/combinat
While the main focus is the generation of combinatorial objects themselves, counting functions and common number sequences like the above are also offered.
I came across that package when looking around, but I only noticed the generation of combinatorial objects rather than the counting functions. As for namespacing, I'd be happy to move things further down to Math.Combinatorics.Exact (or similar)[1] it's just that Math.Combinatorics.* seemed not to be used by the numerous packages floating around this area with different purposes[2], and it seems the natural place for this sort of work. I think it'd be nice to get a bit more collaboration among folks doing this stuff so we can (a) clean up the namespace for this topic, and (b) reduce the amount of duplicated effort. [1] I'll probably end up doing that anyways, if I follow through with the proposed pure solution to the space-leak issue about storing the primes. [2] HaskellForMaths, gamma, statistics, erf, math-functions, combinat,...
Even though the binomial and factorial definition in this package are the naive ones, a quick experiment imply that the differences start show themselves around 100,000 factorial, or choosing 50,000 elements out of 100,000, which is probably a rather specialized use case.
In my experiments the threshold was a bit lower, but yes it's special purpose for people who need exact answers for big problems.
The primes function in the combinat package is based on an old Cafe thread, and actually seems to be faster than the one in the combinatorics package.
The primes generator was some old code I had laying around for one of those online programming challenges; fast enough for the task. I'll probably trade it in for your algorithm though. One of the things I'm disappointed by about the current implementation is the memory overhead for storing the primes. It'd be nice to use chunked arrays of unboxed integers in order to remove all the pointers; but my attempt at doing so had catastrophic performance... -- Live well, ~wren

On Wed, Feb 01, 2012 at 01:53:03AM -0500, wren ng thornton wrote:
[2] HaskellForMaths, gamma, statistics, erf, math-functions, combinat,...
To this list I'd like to add 'species' and also the specialized 'multiset-comb' packages. The former doesn't build under recent GHCs but I plan to fix that (and continue extending the library) soon. Would people be interested in creating a mailing list for those interested in combinatorics+Haskell? -Brent

On 3 February 2012 07:11, Brent Yorgey
On Wed, Feb 01, 2012 at 01:53:03AM -0500, wren ng thornton wrote:
[2] HaskellForMaths, gamma, statistics, erf, math-functions, combinat,...
To this list I'd like to add 'species' and also the specialized 'multiset-comb' packages. The former doesn't build under recent GHCs but I plan to fix that (and continue extending the library) soon.
Would people be interested in creating a mailing list for those interested in combinatorics+Haskell?
I would.
-Brent
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

ditto On Thu, Feb 2, 2012 at 4:06 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
On 3 February 2012 07:11, Brent Yorgey
wrote: On Wed, Feb 01, 2012 at 01:53:03AM -0500, wren ng thornton wrote:
[2] HaskellForMaths, gamma, statistics, erf, math-functions, combinat,...
To this list I'd like to add 'species' and also the specialized 'multiset-comb' packages. The former doesn't build under recent GHCs but I plan to fix that (and continue extending the library) soon.
Would people be interested in creating a mailing list for those interested in combinatorics+Haskell?
I would.
-Brent
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 2/2/12 6:46 PM, Carter Schonwald wrote:
On Thu, Feb 2, 2012 at 4:06 PM, Ivan Lazar Miljenovic wrote:
On 3 February 2012 07:11, Brent Yorgey wrote:
On Wed, Feb 01, 2012 at 01:53:03AM -0500, wren ng thornton wrote:
[2] HaskellForMaths, gamma, statistics, erf, math-functions, combinat,...
To this list I'd like to add 'species' and also the specialized 'multiset-comb' packages. The former doesn't build under recent GHCs but I plan to fix that (and continue extending the library) soon.
Would people be interested in creating a mailing list for those interested in combinatorics+Haskell?
I would.
ditto
I don't know how involved I'd be, but I'd join. It's just a side interest for me (more a curiosity than a hobby at this point), though I would definitely like to see things better organized and integrated since it seems like there are a bunch of folks with passing interest in the area, and it's someplace that Haskell could really shine. -- Live well, ~wren

On Fri, Feb 03, 2012 at 01:06:16AM -0500, wren ng thornton wrote:
On 2/2/12 6:46 PM, Carter Schonwald wrote:
On Thu, Feb 2, 2012 at 4:06 PM, Ivan Lazar Miljenovic wrote:
On 3 February 2012 07:11, Brent Yorgey wrote:
On Wed, Feb 01, 2012 at 01:53:03AM -0500, wren ng thornton wrote:
[2] HaskellForMaths, gamma, statistics, erf, math-functions, combinat,...
To this list I'd like to add 'species' and also the specialized 'multiset-comb' packages. The former doesn't build under recent GHCs but I plan to fix that (and continue extending the library) soon.
Would people be interested in creating a mailing list for those interested in combinatorics+Haskell?
I would.
ditto
I don't know how involved I'd be, but I'd join. It's just a side interest for me (more a curiosity than a hobby at this point), though I would definitely like to see things better organized and integrated since it seems like there are a bunch of folks with passing interest in the area, and it's someplace that Haskell could really shine.
OK, I've emailed mailman@haskell.org requesting the creation of a combinatorics@haskell.org mailing list (if anyone knows of a better way to go about this let me know). -Brent

On Wednesday 01 February 2012, 07:53:03, wren ng thornton wrote:
The primes function in the combinat package is based on an old Cafe thread, and actually seems to be faster than the one in the combinatorics package.
Yes, but it has a memory leak. On my box at least, with ghc 6.12, 7.0 and 7.2.
The primes generator was some old code I had laying around for one of those online programming challenges; fast enough for the task. I'll probably trade it in for your algorithm though.
Why not use one of the packages on hackage which offer faster prime generators? I'm aware of the following usable packages: - primes: decentish performance if you don't need to sieve high, but not recommendable if you want to sieve above ~10^7, in my measurements about the same performance as the algorithm used in combinat, but without memory leak. - NumberSieves: The O'Neill sieve, about twice as fast as the primes sieve, uses less memory (and scales better if you want to sieve to higher limits). - arithmoi: A segmented Eratosthenes sieve using mutable unboxed arrays. Much faster than the above and uses less memory. If you don't like arrays, it also has a priority queue sieve similar to the O'Neill sieve, but with a more efficient PQ implementation.
One of the things I'm disappointed by about the current implementation is the memory overhead for storing the primes. It'd be nice to use chunked arrays of unboxed integers in order to remove all the pointers; but my attempt at doing so had catastrophic performance...
arithmoi's Eratosthenes sieve offers the option to get a list of sieve chunks, basically UArray Int Bool, which gives far more compact storage than a list of Integers (~33KB per million range, much more compact than an unboxed array of primes for the reachable ranges) from which the list of primes can rather efficiently obtained when needed. That may do what you want well enough. Cheers, Daniel

On 2/5/12 10:21 AM, Daniel Fischer wrote:
Why not use one of the packages on hackage which offer faster prime generators?
Mostly because I hadn't looked, having had the code already laying around. I'm not opposed to it, however another goal is to remain portable to other compilers, which means being H98/H2010 compliant. NumberSieves uses BangPatterns, but that would be easily remedied if the author is willing; arithmoi looks quite nice, however it is GHC-only. -- Live well, ~wren

On Sunday 05 February 2012, 23:14:35, wren ng thornton wrote:
On 2/5/12 10:21 AM, Daniel Fischer wrote:
Why not use one of the packages on hackage which offer faster prime generators?
Mostly because I hadn't looked, having had the code already laying around.
Yeah, that's fine, it was just
I'll probably trade it in for your algorithm though.
that made me wonder.
I'm not opposed to it, however another goal is to remain portable to other compilers, which means being H98/H2010 compliant.
A noble goal.
NumberSieves uses BangPatterns, but that would be easily remedied if the author is willing; arithmoi looks quite nice, however it is GHC-only.
The curse of striving for efficiency. "Portability is on the to-do list (with low priority, however)." It just climbed a place. Cheers, Daniel

On 2/5/12 5:40 PM, Daniel Fischer wrote:
On Sunday 05 February 2012, 23:14:35, wren ng thornton wrote:
On 2/5/12 10:21 AM, Daniel Fischer wrote:
Why not use one of the packages on hackage which offer faster prime generators?
Mostly because I hadn't looked, having had the code already laying around.
Yeah, that's fine, it was just
I'll probably trade it in for your algorithm though.
that made me wonder.
Well, I would've looked around before making the change :)
I'm not opposed to it, however another goal is to remain portable to other compilers, which means being H98/H2010 compliant.
A noble goal.
By which I really mean H98/H2010 plus all the things that were already 'standard' in the days of GHC 6.6 and Hugs. MPTCs and some of the related extensions for making type classes more flexible really need to be added to the standard, despite the valid political reasons for wanting to wait for the FD vs TF/AT issues to get resolved.
NumberSieves uses BangPatterns, but that would be easily remedied if the author is willing; arithmoi looks quite nice, however it is GHC-only.
The curse of striving for efficiency. "Portability is on the to-do list (with low priority, however)." It just climbed a place.
Unless I'm doing something that by its nature requires GHC extensions, I've been doing my best to avoid them in published packages. Not that I have anything against them, but rather that I'd like to support JHC, UHC, and other alternatives (just as I used to support Hugs before it died). I think there's great value in compiler competition, so I'd like to foster it as much as I can. There're quite a number of efficiency hacks you can do while remaining in standard Haskell (and you can always hide the GHC-only parts with CPP). -- Live well, ~wren
participants (6)
-
Balazs Komuves
-
Brent Yorgey
-
Carter Schonwald
-
Daniel Fischer
-
Ivan Lazar Miljenovic
-
wren ng thornton