likelybear

I'm a big fan of Weave/knitr/Rmd style notebooks over Jupyter for reproducibility. I've had a great experience with parameterized Weave.jl reports.

My one complaint is that a streamlined dev workflow depends on good caching. knitr nailed that part, checking code hashes and checking dependencies between chunks. Weave.jl caching has been... finicky.

For a completely different style of notebook, folks should check out Pluto.jl https://github.com/fonsp/Pluto.jl

That's arguably the goal of [Pluto.jl](https://github.com/fonsp/Pluto.jl). It's a (Julia-specific) reactive notebook that automatically updates all affected cells and has no hidden state.

Given this appears in Gale and Shapley 1962, I'd say it is part of the original formulation (though they do it by saying people are simply not allowed to apply to colleges where they'd be a hard no rather than apply and be rejected). They're looking at stable matchings for college admissions, not perfect matchings.

The difference based on which side proposes turns out to be a knife-edge result for balanced markets! For imbalanced markets, the short side gets average rank `O(log(n))` in every stable matching and the long side gets `O(n / log(n))`

Edit: reference is Ashlagi et al (2015). "Unbalanced Random Matching Markets: The Stark Effect of Competition" http://web.mit.edu/iashlagi/www/papers/UnbalancedMatchingAKL...

Hard no's are fine in the classic stable marriage problem. "Remain single" gets added as an option to each person's preference list, then you can run Gale-Shapley deferred acceptance more-or-less as normal with each person on the accepting side starting with "remain single".