I like the fact that your should focus is on performance and
correctness. But I think that you are selling yourself short on your
current support for a truly readable syntax. I've been using Matlab
for 21 years and C++ for almost that long, and I find your syntax to
be the best by far.
The extensions that I've done to make it closer to Matlab are really
just copies of your existing code with a few cut and paste operations:
copy code from vector_expression.hpp lines 1170 to 1180
change operator* to operator+
change scalar_multiplies to scalar_plus
and you can now add a scalar to a vector or matrix.
Not exactly rocket science, and pretty true to your original
performance goals (I think). The only one still vexing me is creating
a simple syntax for element_prod(), and that's mostly because
multiplication of vectors and matrices with a scalar uses a wide open
template argument instead of a scalar_expression.
For my application:
* I don't really care if you "allow people using any STLcomplaiant
container".
* Double precision is just fine, as is.
* I'm very interested in the ATLAS binding. But I don't need a lot of
variety. Having one LAPACK like thing that works is better that a
world encompassing solution.
* I'm very interest in the work that ViennaCL is doing to wrap GPU
stuff in a uBLAs syntax.
BTW  I'd be happy to share any of my extension code with you. I
understand the time limitation one has with this kind of side project.
Sean
On Wed, Feb 1, 2012 at 12:11 PM, Andrea Cassioli
wrote:
> Hi guys,
> I have been a uBlas user for a couple of years. I have enjoyed much of
> the progresses made along the versions and the great effort push over
> to improve documentation. I sadly must admit that too many patches and
> not always coherent extentions have harmed the library and I deeply
> agree with Nasos that it would be good to start from scratch a brand
> new version.
>
> In my opinion, uBlas shuold rely on linear algebra core that any uses
> can access too, i.e. blas, lapack and whatever else you like, using
> either Boost numeric Bindings ( the one in the Boost sandbox work
> pretty well) or vice versa calling from the uBlas code. I consider
> performances in a C++ library the core business, as for readability
> other tools can do much better.
>
> Yesterday I was just talking with a friend of mine that usually uses
> MATLAB. He is a computer scientist and pretty good C++ programmer too.
> I was mentioning uBlas and other libraries, but he just told me: "they
> cannot catch up the seamless notation that a specialized language can
> reach".
>
> Indeed, taking a look to eigen, Armadillo or MTL4, none of them is
> even close to a truly readable syntax. I therefore consider the very
> priority to push on performances and code correctness, being ready to
> loose a little bit in math style.
>
> Leave the math kernel to who is specialized and built on a more
> sophisticated layer that ensure correctness and avoid some ambiguity.
>
> Another interesting issues, that what mentioned from the very first
> days, is the compatibility to the STL container concept. It would be
> nice to allow people using any STLcomplaiant containers (vectors,
> carray) along with uBlas, wouldn't be?
>
> I understand the great effort in writing a new code, but the
> experience piled up in theses years could be of great use to guide the
> development.
>
> Cheers,
> Andrea
>
> On Wed, Feb 1, 2012 at 11:54 AM, Nasos Iliopoulos
wrote:
>> It would be great if we could start uBlas2, rewriting the core maybe
using
>> proto for the template functionality and add all the goodies. As David
says
>> I also think a unified representation would help a lot in realizing the
same
>> algorithms for similar operations (i.e. dot product defined as the
>> multiplication of a row and column matrix  using an already optimized
>> matrix matrix multiplication algorithm). I am just a bit skeptical about
>> vectorization though  mainly due to lack of language support and lack
of
>> incore higher than double precision arithmetic (I think double
precision is
>> internally done in 96bit on an intel cpu).
>>
>> Another item that would be very useful is opening the submission of
>> auxiliary functions. It would be great if people could contribute their
own
>> SVD, or optimizer, or linear system solver etc., as I am sure most of as
>> have a ton of those from one project or another.
>>
>> Of course keeping the template interface the same (if possible) for
backward
>> compatibility and trying not to hinder the bindings development would be
of
>> utmost importance.
>>
>> Best,
>> Nasos
>>
>>
>>
>>
>>
>> On 02/01/2012 10:29 AM, David Bellot wrote:
>>
>> There has been a few changes and documentation written in fact. A few
new
>> algorithms has been added like the assignment operators.
>>
>> It is actively maintained even if in it's current state there is not a
lot
>> to do.
>> In fact, I'm seriously thinking at ...
>>
>>
>>  changing the core library to make it able to be faster, introduce new
>> algorithms, and autovectorization
>>
>>  removing the vector class in favor of a unique matrix class (and
vector
>> would simply be a onecolumn matrix). That would allow us to simply
>> represent column and row vector and unify the computation engine
>>
>>  be faster than eigen and armadillo: ok that one is gonna be pretty
hard
>> :D
>>
>>
>> Meanwhile, I'm slowly improving little things... Fortunately, I have
been
>> using ublas for my job for the last few years.
>> But for sure, it needs more love.
>>
>> On Wed, Feb 1, 2012 at 15:15, Sean Reilly wrote:
>>>
>>> I'm using uBLAS for a big project, and just wanted to see if it is
>>> still being actively maintained. It doesn't seem like there have been
>>> many changes in the last few years.
>>>
>>> Sean Reilly
>>> _______________________________________________
>>> ublas mailing list
>>> [email protected]
>>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>>> Sent to: [email protected]
>>
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> [email protected]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: [email protected]
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> [email protected]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: [email protected]
>
>
>
> 
> Andrea Cassioli
> _______________________________________________
> ublas mailing list
> [email protected]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [email protected]
_______________________________________________
ublas mailing list
[email protected]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [email protected]
