You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes it produces a singleton, sometimes it produces a list. We did this because otherwise flatMap had a surprising semantics (if would fix the first choice, and process the second list with the first value fixed). But this ends up in frequent mistakes that we think we have a sample, but we have a single value. I slowly start to understand that it would be better to have lazy / infinite lists for all results (and killing repeat?) but a different semantics of flatMap from the one of lazyLists. One should l.flatMap (a => f(a)) should roughly give l.flatMap (a => f(a).head) - the problem is that we do not want to make it deterministic in the second result accidentally. A good test case is that coin(e).flatMap ( c => (c, coin(e))) should produce a mulitvariate sample with statistically independent components.
One requirement that would be good to meet is that:
for
x <-Randomized.Gaussian (...) // or any other distribution, not dependent on y
y <-Randomized.Gaussian (...) // or any other distribution, not dependent on xyield (x,y)
should have the same (statistical) semantics as:
for
y <-Randomized.Gaussian (...) // or any other distribution, not dependent on x
x <-Randomized.Gaussian (...) // or any other distribution, not dependent on yyield (x,y)
Right now is not equivalent if the constructors produce infinite lists (the first will lock the value of x, the second will lock the value of y).
The text was updated successfully, but these errors were encountered:
Sometimes it produces a singleton, sometimes it produces a list. We did this because otherwise
flatMap
had a surprising semantics (if would fix the first choice, and process the second list with the first value fixed). But this ends up in frequent mistakes that we think we have a sample, but we have a single value. I slowly start to understand that it would be better to have lazy / infinite lists for all results (and killing repeat?) but a different semantics of flatMap from the one of lazyLists. One shouldl.flatMap (a => f(a))
should roughly givel.flatMap (a => f(a).head)
- the problem is that we do not want to make it deterministic in the second result accidentally. A good test case is thatcoin(e).flatMap ( c => (c, coin(e)))
should produce a mulitvariate sample with statistically independent components.One requirement that would be good to meet is that:
should have the same (statistical) semantics as:
Right now is not equivalent if the constructors produce infinite lists (the first will lock the value of x, the second will lock the value of y).
The text was updated successfully, but these errors were encountered: