Tom Vladeck writes:
I thought you may be interested in some internal research my company did using a conjoint experiment, with analysis using Stan! The upshot is that we found that vaccine hesitant people would require a large payment to take the vaccine, and that there was a substantial difference between the prices required for J&J and Moderna & Pfizer (evidence that the pause was very damaging). You can see the model code here.
My reply: Cool! I recommend you remove the blank lines from your Stan code as that will make your program easier to read.
Vladeck responded:
I prefer a lot of vertical white space. But good to know that I’m likely in the minority there.
For me, it’s all about the real estate. White space can help code be more readable but it should be used sparingly. What I’d really like is a code editor that does half white spaces.
“I recommend you remove the blank lines from your Stan code as that will make your program easier to read.”
You really should stop pushing this preference since the opposite is true for many.
Will:
As long as the advice does more good than harm, I think it’s good to offer it. Lots of people include blank lines in their code without even thinking about it; advice such as mine could make them reflect on whether they could do better without the blank lines. For that matter, I think the opposite advice (“Add blank lines to your code to make it easy to read”) could be useful too.
What’s relevant is not just the particular advice but also that it’s in a context of thinking about workflow. As you can see in the above post, I didn’t just offer advice; I also interacted with the person who’d asked the question, and I gave my reasons. Readers can use this information as they see fit.
So, yeah, I completely disagree with your statement that I should “stop pushing” a preference about which there is some disagreement. I think it’s good to get the discussion of white space out there, because I think it would be good for people to be more aware of tradeoffs in the display of code on the screen.
Cognitive scientists study such questions of course.
I think the general rule is that it’s a good idea to be able to get a coherent “chunk” of code (or documents) on-screen at once.
If the chunks are small enough to add white space, probably good, if the extra white space causes chunks to be split across screens, probably bad.
When we went from 24X80 character terminals to 800X1204 BLIT bimap displays, it was a Good Thing.
These days, with cheap large disiplays and widespread ability to use multiple displays, bigger chunks are more practical.
If you look at the code its got a lot of arbitrary whitespace not following any apparent rule. Its inconsistent enough to make one question the quality of this project. Ie, “If they are that sloppy with whitespace where else are they sloppy?”
But whitespace in the code is the ultimate queens duck:
https://bwiggs.com/notebook/queens-duck/
As long as its consistently applied whitespace, different people can display the code according their preferences. Its like changing the font.
100% agree that Andrew’s preference is almost certainly the small minority view. I’m also not sure why he seems so hell-bent on trying to persuade others to adopt this approach.
Then again – it’s HIS blog :)
I also like to reduce the height of blank lines. Emacs can do this very easily, eg this makes them 50%:
(defface reduced-blank-line-face
‘((t (:inherit default :height 0.5)))
“Face used for blank lines.”)
(define-minor-mode reduced-blank-line-mode
“make blank lines smaller” :init-value t
(let ((keywords ‘((“^[[:space:]]*\n” 0 ‘reduced-blank-line-face))))
(if reduced-blank-line-mode
(font-lock-add-keywords nil keywords)
(font-lock-remove-keywords nil keywords))
;; use (font-lock-flush) when that version arrives
(font-lock-fontify-buffer)))
I don’t have much to say on vax hesitancy modeling. The Stan model looks fine. And yes that is an unusual spacing style. We usually want to cut down on vertical space so we can see more code at once but with tiny models this isn’t such a big deal.
1. We have a style guide: https://mc-stan.org/docs/stan-users-guide/style-guide.html. I’m the type of person who just lets black do all my Python formatting.
2. You can use vectorization to make the code a lot smaller, replacing this
vector[n_choices] phi; for(i in 1:n_choices) { phi[i] = respondent_intercept[respondent[i]] + b_money * money[i] + a_vaccine[vaccine[i]]; }with
You can also vectorize one of the two loops in generated quantities to reduce code size, though it doesn’t help with efficiency as loops are just as fast in generated quantities.
3. I’d recommend adding lower bounds to the data declarations to declare they are positive and make the intent of the code clearer to readers.
4. It can help to include a multiplier to variables with prior normal(0, 0.5) if you really expect them to be smaller than unit scale. It’ll also help with random initialization.
5. With a variable name like “intercept” I would’ve expected to see “b_money” called “slope_money” for consistency. Generally, I’d recommend against variable names like “intercept” when you have another varying effect acting as a varying intercept.
6. You can save output space moving the transformed parameters to the model block as local variables.
There are basically 2 blank lines I think are weird and would remove, the ones around the brackets in the transformed parameters… but other than that I like the blank line structure. Weird thing to have a strong preference about.
In general I like blank lines where there’s a difference in kind between the things before and the things after… for example
a = 1
b = 2
for i in 1:10
stuff_goes_here()
end
the line between the variable assignments and the for loop gives me a place to anchor my eyes when I’m scanning for a for loop.. I don’t need to look at a long block of variable assignments (could be 10 or 20 lines) I can skip all that to get to the next “chunk”. Especially with using control-arrow to go from chunk to chunk.
probably all of these preferences have to do with people’s editors.
On the other hand I’m really not a fan of the line
responses ~ bernoulli_logit(phi);
with phi defined in a completely different block of code.
I’m in Daniel’s camp: just as paragraphs help understand a book or article, blank lines to separate different ‘thoughts’ in the program are helpful to me.
Data/params: no blank lines
transformed: before the loop, start/end of the loop, before final closing bracket
model: now its after the open and before the closing bracket, also around b-money
generated: now only before closing bracket and before the loop, but no blank line after either nested loop
There doesn’t seem to be any rhyme or reason to it, so in that case Andrew is probably right to say just get rid of all those blank lines. But really consistent use of white space in the way you describe would be better for most people.
Wow — how to encourage people to share analyses and code that they’ve done. “Post it here and we’ll rip it to shreds for you.”
and completely hijack the thread, so that no one discusses the actual very interesting content of the post!
Well, the real problem is thinking “vaccine hesitancy” should be addressed by paying people to inject themselves with stuff rather than by addressing the concerns. Ie making the manufacturer liable for harm, follow good manufacturing practices, run long term safety testing, and so on.
And I get the distinct idea the author was under the misimpression that these injections would stop or meaningfully slow the spread of covid in 2021. An idea pushed by marketers/propagandists that went against everything we knew about how respiratory viruses and vaccines work. Something Fauci explained in a paper the week after he retired.
So basically they fell for it, but whatever.
You can’t reason something out of ideas they arrived at via authority/consensus. Its just too costly. Either the consensus/authority changes or some significant personal experience changes their mind.
Robin:
Tom Vladeck, who sent me the material to post above, thanked me for my response. He’s since emailed me on other topics. So no need for you to be concerned on his behalf.
Also, nobody’s “ripping his code to shreds.” I offered him an opinion on formatting and Bob shared some Stan tips. If anyone’s coming here thinking that their work is perfect and can’t be improved by criticism, they probably shouldn’t be reading this blog in any case. A continuing theme here is the importance of learning from error, and I often talk about my own mistakes too.