Subject: Re: [ublas] Status of development /Benchmarks
From: Sathyam Vellal (sathyam.vellal_at_[hidden])
Date: 2013-12-08 03:34:05
I'm very new here and don't know how much value I can add to the
discussion! But if a rewrite certainly wins over the current
implementation, then it could very well be a good choice! Python did the
same when they transitioned to Python 3.0; they had no other way to remove
some fundamental design flaws in Python2.x.
I'm no expert in the area, just pitching in an opinion.
-- *___________**_______________________________________* Sathyam M Vellal | Computer Science | PES Institute of Technology | Bangalore, India On Sat, Dec 7, 2013 at 4:08 PM, David Bellot <david.bellot_at_[hidden]> wrote: > Hi, > > it has been a long discussion we all had for many months now. Should we > rewrite ublas from scratch or simply improve it. > Joaquim and Oswin wants a brand new ublas > Nasos was more in favor of improving it. > > I personally find very exciting the idea of writing something new, but > ublas is very well known now. On the other hand, Eigen and Armadillo took > the crown of the main C++ blas library in users' hearts. > > On my todo list for ublas, there are things that will require ublas to be > deeply changed. At this stage, we can almost talk about a new library. > > Christmas is very close now, so maybe it's a good time to start talking > about the features we wish for ublas and see if they can be implemented > with the current version or if a new uBLAS 2.0 is necessary. > After all, Boost::signal did the same a few years ago. We can definitively > do the transition. > > > I begin: > > - unified representation of vectors and matrices to represent the fact > that a vector IS a matrix. Matlab does the same > - automated use of different algorithm to let the compiler "chooses" the > best implementation (if possible) and switch on SSE, distributed or whateve > we need > - implementation of solvers and decompositions algorithms > > and this is what Nasos and I think should be integrated too: > 1. Matrix multiplication > 2. Algorithms infrastructure (so that we can have real useful features) > 3. Matrix/vector views for interoperability <- I think this is ultra > critical because now ublas is monolithic in the sense that you have to use > it everywhere you manipulate data. This would really help into letting > people for example have a list of vectors (they are plotting) and ublas > working on top of that to do for example transformations > 4. NEW DOCUMENTATION - examples and the rest > 5. Incorporate some critical bindings (i.e. mumps bindings which is > currently probably the most efficient smp and distributed open source > linalg solver) > 6. matlab binding? > 7. distributed ublas > > > Please add and ESPECIALLY, please tell me your view on the current > infrastructure of uBLAS. It seems many people are not happy with the > current "expression template" grammar. > > I'm open to everything > > Best, > David > > > On Thu, Dec 5, 2013 at 11:14 AM, Joaquim Duran <jduran.gm_at_[hidden]>wrote: > >> I think that al stuff pending of merge listed by David, should be merged >> and migrate to uBlas 2.0 and while uBlas 2.0 is in development/maintenance >> then design from scratch uBlas 3.0. > > > > > _______________________________________________ > ublas mailing list > ublas_at_[hidden] > http://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: sathyam.vellal_at_[hidden] >