I forgot to express my opinion on the following:


> The good C++ style is to throw exception here and to leave the 
> matrix in initial state (i.e not altered).



It is good to throw exceptions, but I think this should be done when there is a requirement that the relevant portion of the code "needs to be terminated (used here loosely)". In other worlds in performance applications I would suggest providing the user with either an error code or an error flag. The fact for example that an array is not invertible is not a technical error relating to the functional implementation, but rather to run-time algebraic reality. I don't feel comfortable using try statements in the fear that a 4x4 matrix is not invertible. Maybe a reference bool flag (or return variable) is enough.


> The third question is the estimations of rounding errors.
>
> I suppose there are a several dozens of questions left.


Matwey is very true on both of those and we need to have some discussions. Do you think you can compile a list of items that need to be addressed so that we can be ahead of the problems to come?


Best
Nasos


> To: ublas@lists.boost.org
> From: matwey.kornilov@gmail.com
> Date: Sat, 24 Jul 2010 16:39:40 +0400
> Subject: Re: [ublas] todo list
>
>
> As far as I understand when we talk about implementation of such algorithms
> in uBLAS we mean that API should be 'ublas-style'. For instance, when we
> write inner_prod( v, u ) we get an object of this operation which looks like
> a scalar for us. The question is what is the 'ublas-style' for SVD,
> Cholesky, LU, QR, etc. algorithms? It is not clear for me.
>
> Most of the algorithms are in-place. For instance, we have to alter our
> matrix in order to get its SVD decomposition. The next example. Cholesky
> decomposition is defined only for positive-defined matrices. When matrix is
> not positive-defined there is a square root of negative number in the
> algorithm. The good C++ style is to throw exception here and to leave the
> matrix in initial state (i.e not altered). But known Cholesky implementation
> assumes undefined matrix at output in such cases.
>
> For instance the result of SVD decomposition is a triple of matrices: one
> singular diagonal S matrix and two unitary matrices U and V. Imagine we want
> to know only singular values to calculate conditioning number of matrix or
> it's rank. What happens when we don't want to know U and V matrices? As
> uBLAS user I expect that decomposition saves calculations and memory for
> placing unitary matrices. What happens when we want to use SVD for matrix
> inversion? In this case we have to know U and V and thus they should be
> calculated and allocated.
>
> The third question is the estimations of rounding errors.
>
> I suppose there are a several dozens of questions left.
>
>
> I tried to implement SVD and Cholesky for my purposes. The code is
> available:
> http://curl.sai.msu.ru/~matwey/lsp
> Subversion:
> svn://curl.sai.msu.ru/lsp
> But IMO the API definitely is not the good one.
>
>
> Marco Guazzone wrote:
>
> > # SVD, Cholesky, LU, QR, Shur
> > Do you think this should be written from scratch or maybe using
> > existent solvers like the one provided by LAPACK (possibly using the
> > boost::numeric::bindings lib)?
>
>
>
> _______________________________________________
> ublas mailing list
> ublas@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: nasos_i@hotmail.com

---

The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started.