- Join over
**1.5M+ people** - Join over
**100K+ communities** - Free
**without limits** - Create
**your own community**

- Jan 30 07:37
ocramz on gh-pages

Add arrayfire (compare)

- Jan 02 12:51
ocramz on gh-pages

add inliterate (compare)

- Jan 02 12:43
ocramz on gh-pages

update hvega entry (compare)

- Jul 01 2019 09:43dmvianna added as member
- Jun 15 2019 04:55
ocramz on gh-pages

Add pcg-random (compare)

- Jun 14 2019 16:08ocramz labeled #42
- Jun 14 2019 16:08ocramz labeled #42
- Jun 14 2019 16:08ocramz labeled #42
- Jun 14 2019 16:08ocramz labeled #42
- Jun 14 2019 16:08ocramz labeled #42
- Jun 14 2019 16:08ocramz labeled #42
- Jun 14 2019 16:08ocramz opened #42
- Jun 14 2019 16:08ocramz opened #42
- Jun 06 2019 18:21
ocramz on gh-pages

Fix graphite link Merge pull request #41 from alx… (compare)

- Jun 06 2019 18:21ocramz closed #41
- Jun 06 2019 18:21ocramz closed #41
- Jun 06 2019 17:32alx741 opened #41
- Jun 06 2019 17:32alx741 opened #41
- Jun 06 2019 16:46
ocramz on gh-pages

Add graphite Merge pull request #40 from alx… (compare)

- Jun 06 2019 16:46ocramz closed #40

Hi, it's been a while (studies and stuff). I'm still motivated tho! I am currently looking at http://www.datahaskell.org/, so I have a few questions:

- who maintains it ?
- is it still updated ?

And more general questions : is there a general roadmap, a "place" where people here would like to take Data Haskell to ?

Sorry if those topics have been discussed many times already, but I believe that as time goes by it can be clearer and change

as for the roadmap .. everyone has different ideas on how that should look like.

what advantages does monad-bayes have over more traditional probablistic programming library such as say pymc3

I am just an occasional user but I find Monad Bayes quite comfortable to use. Here are three things that come to my mind at the moment, compared to pymc3:

- it integrates with standard Haskell syntax, you can sample from standard datatypes, functions and use do notation to combine those operations. With pymc3 you have to deal with theano tensors etc ...
- Haskell syntax make the code really concise. It really looks almost like what you would write with standard math notation in an article.
- Monad Bayes provides an abstraction on top of different inference representations and you can build new ones out of these basic building blocks. For example, mcmc requires a different representation of a prob distribution (in terms of accumulated log likelihood of the samples) than sequential monte carlo, or inverse sampling (cumulative distribution function) or a particle filter. Checkout table 1 in https://pdfs.semanticscholar.org/76ad/0090bf4a076391fe2cc6d6029f79ebc66308.pdf . AFAIK in pymc3 you basically chose a configurable out-of-the box sampler and than run it.

@gregnwosu yes exactly - afterwards you might have to adapt your sampler a bit. E.g. with hamilton monte carlo, you cannot easily sample from discrete distributions (atm).

This seems like a crowd that could potentially benefit from information in this blog post: https://www.reddit.com/r/haskell/comments/edr9n4/random_benchmarks/

is anyone else experiencing long compilation times with Frames?

Hi!

I'm proposing new lens-based API for statistics: bos/statistics#162 What to you think about it?

TL/DR example of use: `meanOf (each . filtered (>0) . to log)`

will compute mean of logarithm of every positive number.

I suspect that here

`lens`

will be necessary to be useful. But I didn't check
Also various workarounds are possible. Splitting package into core algorithms with less nice API and nice API wrappers.

@Shimuuar that's a cool idea :) I've never strayed away from the blessed-yet-horrific

You'd expose prisms if some statistics couldn't be computed computed for some input data

`lens`

myself (even if quick ways to convert exist, considering another lib for the sake of err messages could be a good idea), but in the meantime it's safe to stick to `lens`

due to widespreadness anywayYou'd expose prisms if some statistics couldn't be computed computed for some input data

same for stddev, multiply each sample by

`σ'/σ`

There are also notions of “optics" that might be a different/useful fit here. I’m thinking of another Chris Penner post: https://chrispenner.ca/posts/algebraic, about “Algebraic Lenses” which he characterizes thusly: "an Algebraic lens allows us to run some aggregation over a collection of substates of our input, then use the result of the aggregation to pick some result to return.” Maybe something to keep an eye on. I’m thinking about how those optics and “Kaleidoscopes” fit in for map/reduce type operations.

Anyway, the lens thing is cool! I wonder how easy/hard it would be to have conversions between the Control.Foldl versions of these things. The applicative instance of Folds is useful for combining one-pass operations on the same data. Is there some equally straightforward way to combine

`meanOf folded`

and `sumOf folded`

so that the fold only happens once? That might go back to the idea of “meanOf” as the optic and then maybe there’s a way to compose the optics?
As for foldl-like functionality I'm not sure seems difficult since accumulator type leaks in type signatures. But could be possible.

Another problem is one frequently *needs* multiple passes over data to avoid precision loss. Numerically stable computation of variance requires computing mean first

Foldl dodges that accumulator-type-leaking problem by quantifying over it and then adding an extra bit to the data type so you can return something else, thus separating the accumulator type from the return type. Then it is an Applicative in that returned type rather than the accumulator type.

Not sure how the multi-pass part could work but it’d be very cool if two multi-pass computations could be composed such that they need only do the max of the indivudual number of passes each needs. I wonder of there is a way to stack them, as a type-level list, like a list of effect handlers?

Not sure how the multi-pass part could work but it’d be very cool if two multi-pass computations could be composed such that they need only do the max of the indivudual number of passes each needs. I wonder of there is a way to stack them, as a type-level list, like a list of effect handlers?