Re: [ublas] Status of development /Benchmarks

Subject: Re: [ublas] Status of development /Benchmarks
From: Sathyam Vellal (sathyam.vellal_at_[hidden])
Date: 2013-12-08 03:34:05

Hi all,

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.

Best,
--
*___________**_______________________________________*
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]
>