I made a package for manipulating finite discrete probability distributions, and before submitting it to Hackage I would love to get some feedback from you.
The code is available on github: https://github.com/redelmann/haskell-distribution
The package has modules for creating and transforming distributions, measuring them, efficiently sampling random values from them and plotting them to file.
I'm wondering if including the plotting feature is worthwhile considering the number of dependencies. Would you put that module in a package of its own, or would you leave it as is?
I am also unsure about the Data.Distribution.Aggregator package. The naming of the module and some of its functions doesn't feel right. The point of the module is to provide functions that can modify the probabilities of lists of pair of value and probability. This is useful for instance for getting cumulative probability distributions for instance.
Thanks for any feedback you might have!submitted by wargotad
[link] [7 comments]
Haskell design patterns differ from mainstream design patterns in one important way:
Conventional architecture: Combine a several components together of type A to generate a "network" or "topology" of type B
Haskell architecture: Combine several components together of type A to generate a new component of the same type A, indistinguishable in character from its substituent parts
This distinction affects how the two architectural styles evolve as code bases grow.
The conventional architecture requires layering abstraction on top of abstraction:
Oh no, these Bs are not connectable, so let's make a network of Bs and call that a C.
Well, I want to assemble several Cs, so let's make a network of Cs and call that a D
Wash, rinse, and repeat until you have an unmanageable tower of abstractions.
With a Haskell-style architecture, you don't need to keep layering on abstractions to preserve combinability. When you combine things together the result is still itself combinable. You don't distinguish between components and networks of components.
In fact, this principle should be familiar to anybody who knows basic arithmetic. When you combine a bunch of numbers together you get back a number:3 + 4 + 9 = 16
Zero or more numbers go in and exactly one number comes out. The resulting number is itself combinable. You don't have to learn about "web"s of numbers or "web"s of "web"s of numbers.
If elementary school children can master this principle, then perhaps we can, too. How can we make programming more like addition?
Well, addition is simple because we have (+) and 0. (+) ensures that we can always convert more than one number into exactly number:(+) :: Int -> Int -> Int
... and 0 ensures that we can always convert less than one number into exactly one number by providing a suitable default:0 :: Int
This will look familiar to Haskell programmers: these type signatures resemble the methods of the Monoid type class:class Monoid m where
-- `mappend` is analogous to `(+)`
mappend :: m -> m -> m
-- `mempty` is analogous to `0`
mempty :: m
In other words, the Monoid type class is the canonical example of this Haskell architectural style. We use mappend and mempty to combine 0 or more ms into exactly 1 m. The resulting m is still combinable.
Not every Haskell abstraction implements Monoid, nor do they have to because category theory takes this basic Monoid idea and generalizes it to more powerful domains. Each generalization retains the same basic principle of preserving combinability.
For example, a Category is just a typed monoid, where not all combinations type-check:class Category cat where
-- `(.)` is analogous to `(+)`
(.) :: cat b c -> cat a b -> cat a c
-- `id` is analogous to `0`
id :: cat a a
... a Monad is like a monoid where we combine functors "vertically":-- Slightly modified from the original type class
class Functor m => Monad m where
-- `join` is analogous to `(+)`
join :: m (m a) -> m a
-- `return` is analogous to `0`
return :: a -> m a
... and an Applicative is like a monoid where we combine functors "horizontally":-- Greatly modified, but equivalent to, the original type class
class Functor f => Applicative f where
-- `mult` is is analogous to `(+)`
mult :: f a -> f b -> f (a, b)
-- `unit` is analogous to `0`
unit :: f ()
Category theory is full of generalized patterns like these, all of which try to preserve that basic intuition we had for addition. We convert more than one thing into exactly one thing using something that resembles addition and we convert less than one thing into exactly one thing using something that resembles zero. Once you learn to think in terms of these patterns, programming becomes as simple as basic arithmetic: combinable components go in and exactly one combinable component comes out.
These abstractions scale limitlessly because they always preserve combinability, therefore we never need to layer further abstractions on top. This is one reason why you should learn Haskell: you learn how to build flat architectures.
Many monad transformers are instances of MFunctor. That is, you can lift base-monad-changing operations into them. The obvious candidates are all instances of MFunctor except ContT.
Is ContT the only exception? Are there other monad transformers somehow weaker than ContT that are not MFunctors?submitted by tomejaguar
[link] [23 comments]
I'm currently working on a project that will be incorporating recording and playing audio, but I'm a little stumped when it comes to which library to use.
I would really like a platform independent library, which seems to be the tricky part, and it would be nice if the library could perform both capturing audio and playing it.
I've been looking at the OpenAL bindings, but they seem a little literal and the basics aren't documented well (mostly just links to using OpenAL in other languages). I would really like a more functional library, but I'll take what I can get.
If you guys have any pointers it would be much appreciated. This is one of my first "larger" haskell projects, and so far this seems like the first stumbling point.submitted by clark_poofs
[link] [2 comments]
What's the most efficient way to print a big array of Ints? I used below method, but seems quite slow:pr uarr = go begin end uarr where (begin, end) = bounds uarr go k n u | k > n =  | otherwise = C.pack (show (u ! k) ++ "\n") : go (1+k) n u
For print: mapM_ C.putStr . pr
Below is the profiling output, which shows go insides pr is the bottle neck:MAIN MAIN 44 0 0.1 0.0 100.0 100.0 main Main 89 0 20.9 22.4 99.9 100.0 pr Main 98 1 0.0 0.0 47.0 53.6 pr.go Main 102 1000001 47.0 53.6 47.0 53.6 pr.end Main 101 1 0.0 0.0 0.0 0.0 pr.begin Main 100 1 0.0 0.0 0.0 0.0 pr.(...) Main 99 1 0.0 0.0 0.0 0.0 tsort Main 95 1 1.1 0.6 11.1 4.5 bucksort Main 96 1000001 10.0 3.9 10.0 3.9 getinputs Main 90 1 0.0 0.0 20.9 19.5 getinputs.inputs Main 97 1 0.0 0.0 0.0 0.0 getinputs.(...) Main 92 1 11.5 15.6 20.9 19.5
Thank you.submitted by sigsegv11
[link] [17 comments]
I'm aware of hakyll, but I'm looking for something more like Drupal. clckwrks seems like something, but it hasn't been updated since February 2013. Plugins also appear sparse.
Anyone working on anything? It's a shame that specialized server-side web packages aren't getting that much love.submitted by beerdude26
[link] [12 comments]