@bgoodri, thank you. That’s enough information for me.
@sakrejda, ok with the decision based on @bgoodri’s clear endorsement? (perhaps those tests are what’s needed to come up with a clean spec, which we don’t have, but it seems like a lot of work needs to be done in order to make that decision.)
I think the PR should move forward because 1) @bbbales2 said in his testing the Boost integrator does not handle mixed (or forward?) types but does handle reverse and doubles types; 2) if we can rely on Boost to implement correctly that’s great; and 3) we agreed in the meeting that that was enough to meet the requirements for Stan usage. Endorsement is cool and all but if we rely on it that means the rationale for decisions is not spelled out.
In general I think we should move towards smaller decisions that are easier to justify. For example if we can’t articulate the requirements in an issue, evaluate some alternative in a video call, or evaluate different implementations with direct tests I think we’re making decisions that are too big (this is just on technical issues).
Ok will do, I made some comments to get going on the issue.
Modularity is the key to scalability of development.
Were you looking for more rationale of Boost over John Cook’s ported code? Or an overall set of decision criteria?
For me, correctness/reliability and maintainability are major issues, followed by simplicity and efficiency.
Is it still possible to join these meetings? Would love to join.
That would be great! We missed last month due to a variety of reasons.
Let’s have one in the next couple weeks. Preference in times?
I have a very flexible schedule, so no preferences from me.
Anything finishing before 7 PM in the US is OK with me.