My development activity after v2.10.0
Daniel Lee
-> language
Michael Betancourt
> - if we wanted to do abbreviations, what should they be? lang, alg, api?
> Mike, hopefully this doesn't mess up your world. If you've pushed to branches, I can try to move all the branches over. That make sense to you?
there would be no problems (although we should keep the old branches
preserved in whatever gets renamed from stan-dev/stan).
Bob Carpenter
> On Apr 22, 2016, at 4:19 AM, Michael Betancourt <betan...@gmail.com> wrote:
>
>
>> - if we wanted to do abbreviations, what should they be? lang, alg, api?
>
> algo
>> Mike, hopefully this doesn't mess up your world. If you've pushed to branches, I can try to move all the branches over. That make sense to you?
>
> If we can merge Riemannian first then all active code will be in and
> there would be no problems (although we should keep the old branches
> preserved in whatever gets renamed from stan-dev/stan).
- Bob
Allen B. Riddell
> 3. Services. This is the biggie. This will take most of the duplicated code
> out of cmdstan, rstan, and pystan.
>
> (Mike, you were right about having a consolidated config. The
> implementation wasn't and I was too caught up in the details. Bob sketched
> out something that will work. I can implement it cleanly and I want to push
> so this can happen very quickly.)
>
> I'm pretty sure I know how all the pieces fit, so I'm ready to move forward
> and replace everything. The overall interfaces won't change, but the
> backend will be a lot easier to manage.
>
>
>
> Any objections? Any suggestions? Anyone want to help?
Allen B. Riddell
> -> language
>
I would also like to suggest that the functions `services` exposes to
rstan/pystan/cmdstan/etcstan not involve Eigen or Boost --- or at least
we adopt this as a long-term goal. IMHO, the C++11 standard library
offers us more than enough tools to work with.
Best,
Allen
Michael Betancourt
design pushed everything but configuration to callbacks, so
the interfaces would not use and Eigen or Boost code directly.
So it should be feasible.
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Bob Carpenter
readers
writers
services
The services are the facade for the algorithms like NUTS and L-BFGS
(I think that's what Michael and Daniel have been calling
"routes", but I'm not 100% sure). The services involve readers and
writers as callbacks. They shouldn't require any Boost or Eigen data
structures.
The services design will be very similar to Michael's
original plan in its client-facing API.
I don't know if there are any Eigen types left in the readers/writers.
Sticking to C++ is easy for 1D containers, but not so
good for 2D structures. But most (all?) of those are going to be
encapsulated in the readers/writers (I don't think user-supplied
mass matrices will land in the first version).
We won't be moving to C++11 until our interfaces can
cope.
We'll still need Boost and Eigen on the back end.
- Bob
Krzysztof Sakrejda
> Stan is now going to be split into language, algorithms, services. I forget if we decided to abbreviate or not, but it should look like:
>
> - language: stan-dev/language
>
> - algorithms: stan-dev/algorithms
>
> - services: stan-dev/services
>
> - math: stan-dev/math
>
Completely agree this will be helpful and I like the long names. To avoid drowning in multiple issues per real issue, I wonder if we could keep stan-dev/stan as the place where overarching issues with checklists live that need pull requests across all the interfaces.
> 2. Full logging instead of streams.
>
> Once we break apart the Stan repo, we can then implement full logging with logging levels. See https://github.com/stan-dev/stan/wiki/Consolidated-Output-for-Sample,-Optimize,-ADVI,-and-Diagnose
+1 for key-value output rather than trying a more complex structure. I guess the middle road would be a lightweight structure that makes it easy for interfaces to check whether a key is available.
> This means we can be consistent with our output from the core library and we can use structured output so rstan's output can be controlled easily.
>
>
> This will also help Krzysztof with what he's implementing with databases and other outputs.
Even now the writer interface is really good. I think the remaining problems are that output isn't sent to a clear part of the interface (e.g.-something that looks like a key-value message is sent all in one string, something that's just a string is pre-pended with spaces for formatting in a text file, etc...)
>
> 3. Services. This is the biggie. This will take most of the duplicated code out of cmdstan, rstan, and pystan.
>
>
> (Mike, you were right about having a consolidated config. The implementation wasn't and I was too caught up in the details. Bob sketched out something that will work. I can implement it cleanly and I want to push so this can happen very quickly.)
>
>
> I'm pretty sure I know how all the pieces fit, so I'm ready to move forward and replace everything. The overall interfaces won't change, but the backend will be a lot easier to manage.
>
>
>
>
>
> Any objections?
Nope.
> Any suggestions?
> Anyone want to help?
Yep, I had a good conversation with Bob at NESS about how to manage my involvement better. The specific list I could help on is something like: 1) pulling CmdStan through this process; 2) anything with the writers; 3) taking the current output spec you link to and proposing a key-value version; 4) replacing the reader(s) once we have a solid output spec; and 5) code review on any of the above.
Krzysztof
>
> Daniel