John Maddock wrote:
Thijs van den Berg wrote:
There's nothing in development at present (that I know of), so a submission would certainly be welcome. The main open issue IMO is getting the interface right for the mutivariate case.
Yes, exactly, the interface is one of the main reason for me to team up with C++ pears, to try and get that right. That a thing where feedback is very helpful!
Nod.
As I see it, there are a couple of interface issue: * containers for the multivariate parameters (vectors and matrices) and operators on those containers -inverse of a matrix-
Can we not define a *Concept* for multivariate parameters, and convert them internally to whatever internal representation is used?
Yes, that would be the most flexible approach, separating containers from algorithm acting upon them!
Boost.uBlas has matrix inversion (via LU decomposition), but it's not necessarily all that stable :-( Is matrix inversion really necessary?
It could indeed be the case that inversion is not needed. It all depends on the type of functions what will be supported. I know of some who *do* need inversion.
* specifying generic functions/properties of multivariate densities, that would apply to *any* multivariate density
Nod. The list that applies to the univariate densities in Boost.Math would be a good place to start, modulo the ones that cannot be implemented in the multivariate case (quantile for example).
Yes. that would be a very good start. I'll do that.
Ask here for comments on the design right here: it helps a great deal to have some docs at this point, as it's easier for folks to get their heads around. You're also most welcome to fly your ideas past myself, Paul (Bristow), and whoever else volunteers first of course :-) Thanks! The docs will be someting I'm going to start on tomorrow. What is a good doc format, and what are good tools for that format?
Cheers, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost