Users of Stan Math (not via Stan language) - scal/arr/mat distinction useful?

math

#1

Hey all,

Is anyone out there using the Math repo by itself? Of those people, is anyone using the Math repo without Eigen, i.e. something in stan/math/*/scal or stan/math/*/arr but nothing at all from stan/math/*/mat?

We’re planning to squash the prim/arr/mat distinction as it causes every one of our new developers significant pain when they first try to understand the code, and for many of us continuing pain as well.

There was some discussions of this in a previous thread here. about performance implications, but it also touched on squashing the autodiff versions (prim/rev/fwd/mix) which I think is less imperative to squash.


#2

@seantalts, perhaps post on the General category? We’ll keep this as a place to discuss why and how, but if you wanted to ask users, not all are subscribed to the Developers category.


#3

Changed it to General. I definitely assumed all people using just the math repo would consider themselves developers, but I actually have no idea.


#4

I can’t find the old thread or even the request of having the C++ autodiff library optionally include the standard template library, Boost, and Eigen. Maybe someone else can find the original discussion.

For some background:

If there aren’t any objections (or even if there are), I think the next step is to plan out how to accomplish this squash. It isn’t going to be trivial, but I think we should be able to script most of it. We’ll need to stitch different headers in the correct order to be able to instantiate the template specializations correctly.

It’s not only less imperative, it’s not something we can reasonably do.

Squashing scal/arr/mat affects compilation performance.
Squashing prim/rev/fwd/mix will (potentially) prevent users from using Stan due to increased memory usage by the C++ compiler.


#5

OpenMx uses the Stan math library. However, we already use Eigen so it’s fine that Stan math depends on Eigen too


#6

Is there a record somewhere of the context around why we split it out this way? Was there a user who approached us and asked for a version without Eigen?


#7

I can’t find it on stan-dev or stan-users, but there should be a record of it somewhere. I’ll try to look for it again. @Bob_Carpenter, do you remember what drove us to do this?

Yes. And I’ve been looking for it. I’ll see if I can find it.

We definitely didn’t do it cause we wanted to. We did it because there was a request and it seemed reasonable at the time.


#8

just as a point to consider is that this change has HUGE impact on the source.

Given the pile of ongoing pull requests this is not going to expedite merging these as collapsing this will cause major merge conflicts in just about anything.

… this is not to say we should not do it, but I am just raising the usual return on investment question? Is it worth the effort?

Maybe the pull list is shorter at some point in the near future?


#9

I think it’s a good idea to wait until MPI and GPU support are in, and to try to get anything else that’s pretty close in before doing the refactor.

Re: ROI - I think it’s a significant ongoing maintenance and on-boarding burden we can get rid of with a one-time payment.


#10

I agree.