Stan General Meeting, Mar, 25, 2021, 11 am EST

Meetings
1

Hangouts Link: https://meet.google.com/gzm-wmum-pfm 3

Instructions: Ask to attend in the hangouts interface and someone should let you in in the first 10 minutes of the meeting. Email breck @ fbb2116@columbia.edu if you have problems or want to attend the physical meeting in New York City when they start again.

Please add your agenda items in replies.

2

Would that be 11am EDT as usual?

I would like to discuss the form of the meeting. In particular, I think the current format is not very helpful for an open community, as (in practice) the agenda is rarely known in advance and minutes are rarely available afterwards. At the same time, it seems that important topics/decisions are at least ocassionaly discussed, excluding involvement of the broader community. Additionally, from the ocasions I attended, the meetings seemed a bit inefficient.

I believe a big increase in both openness and efficiency of the meeting can be achieved, my proposal is roughly:

  • Instead of doing a verbal round-robin of who-did-what recently, people write a short summary of their recent progress in replies to the topic before the meeting.
    • Alternatively, if we don’t trust people to actually do that before the meeting, the first X minutes of the meeting could be reserved for writing the progress notes and reading the progress notes of others.
    • Putting the status in writing is definitely more time consuming than just describing it verbally, but reading is faster than listening, so I would expect this to result in a net time saving + providing written record of what is happening, so other members of the community can follow the developments.
    • Putting status reports in writing is IMHO likely to increase the quality of the status reports as people are pushed a bit more to actually formulate the status report in a coherent manner.
  • The actual meeting is then reserved for discussing questions and clarifications and for general socializing, seeing everybody, …
    • This discussions should also produce some form of written record. Either a designated person writes all the minutes (which should not be too much work as the vast majority of the discussion in the current format are the status updates that got written-down in a distributed manner), alternatively we can ask the person queried to write the main points down, distributing the task. I find the centralized approach a bit more likely to work well, but it is not a strong opinion.
    • Important aspect of writing down some notes of the discussions is to reduce the incidence of discussing the same things and rediscovering the same conclusions multiple times.

It is obviously possible I am misunderstanding some goals of the meeting or missing some important details. I’d be happy to hear your feedback on the proposal - either written here or spoken at the meeting.

4 Likes
3

Yeah

Yeah this is a good question for the meeting cuz we can check what things people use the meetings for.

I think the meetings are most useful to me if someone needs something I know how to help with or I need something someone else knows.

I haven’t been writing these things down, but the recent meetings haven’t been going too long (I think they’re mostly within the Universally Standard One Hour Meeting Window)? (Edit: I could be wrong here too – and no particular reason we couldn’t aim to make them shorter)

1 Like
4

Apologies everyone, I forgot to include part of the time for the meeting. Yes it is at 11 am EST.
I’ve been thinking about just having a summary of what was discussed after every meeting. We could start doing that going forward if you like @martinmodrak.

1 Like
5

I’d like to talk about @andrewgelman 's fixed parameter thing again. I think that would be nice to have

1 Like
6

& parallel chain cmdstan. Have a few design Qs I want to sort out with folks

1 Like
7

This came up in the Playroom yesterday and Bob said he thought it should be part of SlicStan. I guess that in any case it would be helpful for us to prepare a short document demonstrating what we’d like it to look like.

1 Like
8

Started working on that with @Dashadower and @hyunji.moon over here.

(Edit: also feel free to complement the beautiful kanban board :P)

There’s a description here with an outline and a strategy. I just used what we talked about in the meeting previously as a model.

Yeah I think SlicStan would just implicitly include something like this (because you’d have to infer what distribution things were data or parameters), but without a SlicStan we’d need something custom.

3 Likes
9

Cool cool tbh I mostly wanted to check if it was being worked on. We can discuss it if you like but sounds like your good to go!

1 Like
10

Simple curiosity while coding:
I know @andrewgelman’s original intention had been fixing the same set of parameters throughout the whole sampling steps. However, if the fixed parameters are dynamically designed, i.e. different sets of fixed parameters for every sampling (here from the code), could we call that Hamiltonian Gibbs? We are using Hamiltonian dynamics while conditioning on certain parameters, right?

1 Like
11

Yeah it would be possible to do blocked updates with a mechanism like this. I think pymc3 does blocked updates but it was an early decision in stan to not do updates like this.

I think the reasoning stan went with is if there are correlations between the two blocks, blocked updates get slow, and it’s not easy in a general purpose way to specify the blocking correctly, and it’s not clear how much of an advantage the blocking is even if it works. My guess is pymc3 wanted to support more models (discrete parameters and whatnot), though I don’t know for sure.

1 Like
12

I’m not sure Discourse is the best forum for this kind of record. At least, looking at what’s here today was immediately daunting because the lack of threading means it’s hard to distinguish top-level updates from in-the-weeds discussion.

Github actually has the ability to have a threaded discussion forum (ex: Discussions · wlandau/stantargets · GitHub). I know we would want to avoid splintering of the community, but I think it could make sense for records as you’d like for the GMs to live there and not on discourse.

1 Like
13

A bit late but adding some notes of what was discussed.

@avehtari :

@andrewgelman :

  • Struggling with impact of data and parameters on inferences
  • Preparing suggestions for page explaining Stan warnings
    • @Bob_Carpenter: Please do NOT replace error messages with tings that ONLY point to the web.
    • No plans to do this, but rather have a short message + link to web

@bbbales2 :

  • First PR for stanc3 thanks to help from Louis, Steve, Rok
  • Work with Hans to refactor algebra_solver
  • Starting clamped parameters project with Hyunji & Shin

@bparbhu :

  • Working with Mitzi on Windows installation

@charlesm93 :

  • Universal embedded Laplace: user defines likelihood, autodiff does everything else
    • Autodiff seems faster than analytical derivatives
  • Played with adjoint ODE solver for SEIR models
  • Class project on Bayesian neural networks with horseshoe prior, also with variational inference

@jonah

  • Working on MRP package with @mitzimorris and @lauren
  • Preparing PRs for CmdStanR
  • Working with Philip G on putting his fast normal-normal models in an R package

@louis-mandel

  • Working on Stan with NumPyro backend. Paper almost ready.
    • If people want to give feedback, reach out

@martinmodrak

  • Minor stuff for brms

@mike-lawrence

  • Noticed weird behaviour in test/retest reliability or similar problems in hierarchical models. Has solutions

@mitzimorris

  • Little things for CmdStanPy

@PhilClemson

  • SBC for benchmark models
  • Some issues in ARMA models and few others

Philip Greengard

  • Working with Jonah on putting fast normal-normal models in an R package

@wds15

  • 2 PRs in Stan math
  • Fixed TBB issues that could prevent multithreading with Stan math
  • Worked on design docs for adjoint ODE
  • On request from Mike will not add simplified call for the solver yet. If others disagree, please join the discussion.

@s.maskell

  • Promising results on SMC samplers
    • Needed to calculate the logprob for a lower-dimensional projection of the parameters.
    • Would be happy to discuss whether the approach makes sense

@stevebronder

  • New generator for constraint
  • Parallel CmdStan stuff
  • Answering GSoC questions
  • Looking into CMake
    • Probably not a good idea
    • @Bob_Carpenter : There have been many attempts before
1 Like