Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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:43
    dmvianna added as member
  • Jun 15 2019 04:55

    ocramz on gh-pages

    Add pcg-random (compare)

  • Jun 14 2019 16:08
    ocramz labeled #42
  • Jun 14 2019 16:08
    ocramz labeled #42
  • Jun 14 2019 16:08
    ocramz labeled #42
  • Jun 14 2019 16:08
    ocramz labeled #42
  • Jun 14 2019 16:08
    ocramz labeled #42
  • Jun 14 2019 16:08
    ocramz labeled #42
  • Jun 14 2019 16:08
    ocramz opened #42
  • Jun 14 2019 16:08
    ocramz 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:21
    ocramz closed #41
  • Jun 06 2019 18:21
    ocramz closed #41
  • Jun 06 2019 17:32
    alx741 opened #41
  • Jun 06 2019 17:32
    alx741 opened #41
  • Jun 06 2019 16:46

    ocramz on gh-pages

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

  • Jun 06 2019 16:46
    ocramz closed #40
Austin Huang
@austinvhuang
@ocramz I’m not sure yet, wasn’t planning too though. we should definitely meet up if you attend!
Doug Burke
@DougBurke
I'm not yet sure if I'll go to PROBPROG, but as I live just down the road I may be interested in a meetup outside the conference.
Samuel Schlesinger
@SamuelSchlesinger
Hey all, its been years since I've been in here. Anyone want a hand with anything?
Tony Day
@tonyday567
hey sam, check out numhask-array for where I got to with higher kinded numbers.
feedback would be nice
Guillaume Desforges
@GuillaumeDesforges

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

Marco Z
@ocramz
@GuillaumeDesforges I maintained the homepage and the docs for almost three years
as for the roadmap .. everyone has different ideas on how that should look like.
Samuel Schlesinger
@SamuelSchlesinger
looking now @tonyday567
Gregory Nwosu
@gregnwosu
I think I've just found my spiritual home
Marco Z
@ocramz
hi @gregnwosu !
Gregory Nwosu
@gregnwosu
:wave:
what advantages does monad-bayes have over more traditional probablistic programming library such as say pymc3
MMesch
@MMesch
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.
MMesch
@MMesch
you can sample from standard datatypes, functions
Gregory Nwosu
@gregnwosu
oh cool, so in theory you can make any program probablistic?
MMesch
@MMesch
this might read misleading - it is actually quite easy to sample from whatever custom datatype with itas well. It thus integrates quite naturally with other libraries.
@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).
Alexey Kuleshevich
@lehins
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/
MMesch
@MMesch
nice, thanks for writing this!
Alexey Kuleshevich
@lehins
:+1:
Gregory Nwosu
@gregnwosu_gitlab
happy new year all!
is anyone else experiencing long compilation times with Frames?
Tim Pierson
@o1lo01ol1o
@gregnwosu_gitlab Yes, some of the higher-kinded generics can get quite long depending on what you're trying to do.
Marco Z
@ocramz
happy new year! :tada:
Aleksey Khudyakov
@Shimuuar

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.

Marco Z
@ocramz
@Shimuuar I like it a lot; by coincidence I'm also tinkering quite a bit with lenses in the past few days, in particular the microlens set of libraries
Aleksey Khudyakov
@Shimuuar
I suspect that here lens will be necessary to be useful. But I didn't check
Tim Pierson
@o1lo01ol1o
have you considered optics?
Aleksey Khudyakov
@Shimuuar
Not really. lens is sort of standard now so I just went with it.
Tim Pierson
@o1lo01ol1o
The errors and documentation on optics are quite good, though. I think you sacrifice some cases of compositionally, but, in terms of people new to lens on a project that uses it (those poor, dreaded newbs), it presents a strong case
Marco Z
@ocramz
yeah the thing is that lens and friends are perfectly integrated with base concepts : (.), traverse, etc. My personal journey with this stuff has been extremely slow and gradual; I only found a need for it while refactoring my vega bindings, which have very nested datatypes
Marco Z
@ocramz
(I'm saying this because others might be in a similar position: not needing a full-blown optics library but just some convenience functionality)
Aleksey Khudyakov
@Shimuuar
Yes error messages are better. But libraires are more likely to provide van-Laarhoven's lens and newbies will have to learn lens anyway. There's no escape from it
Tim Pierson
@o1lo01ol1o

libraires are more likely to provide van-Laarhoven's lens and newbies will have to learn lens anyway. There's no escape from it

be the change u want to see in 2020. :sunglasses:

Marco Z
@ocramz
@Shimuuar do you plan to introduce Prism and Iso in statistics as well?
Aleksey Khudyakov
@Shimuuar
I don't know yet. Currently type signatures looks like: meanOf :: Getting (Endo (Endo MeanKBN)) s Double -> s -> Double and yes one could plug prisms there
Aleksey Khudyakov
@Shimuuar
@o1lo01ol1o Having to wrangle both libraries seems much more likely outcome
Marco Z
@ocramz
@Shimuuar please also consider the downstream cost of having to compile lens and/or optics while building criterion etc.
Aleksey Khudyakov
@Shimuuar
I think that just ability to work with all sort of containers instead of just vectors is such big improvement that it justify lens dependency. However with lens it could be possible to provide API without icurring lens dependency.
Also various workarounds are possible. Splitting package into core algorithms with less nice API and nice API wrappers.
Yves Parès
@YPares
@Shimuuar that's a cool idea :) I've never strayed away from the blessed-yet-horrific 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 anyway
You'd expose prisms if some statistics couldn't be computed computed for some input data
Aleksey Khudyakov
@Shimuuar
Beauty of thing you don't need to know prism. API is very simple: you give me Getting - you get an answer. And since prisms are valid getting everything just magically works:
> meanOf (each . _Right . each) [Left "err", Right [1,2,3], Right [10] ]
4.0
Stefan Dresselhaus
@Drezil
Yves Parès
@YPares
@Shimuuar I was wondering, could meanOf be a Lens itself? That'd require some notion of setting a mean, but that's quite possible by adding to each each sample µ'-µ
same for stddev, multiply each sample by σ'/σ
Aleksey Khudyakov
@Shimuuar
@YPares It doesn't looks like really good idea since setting mean is sounds weird and not always possible. What if we have list of Ints with noninteger mean? We certainly can't set their mean!
Adam Conner-Sax
@adamConnerSax
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.