[feature request] new free functions for matrix/vector sizes

[Gunter Winkler]

Hello uBLAS community,

I created a new feature request which summarizes the current discussion.

https://svn.boost.org/trac/boost/ticket/3449

I think that we found a usable conclusion. Is there any one going to
take the task. I will collect the corresponding patches and commit them
to the SVN.

It would be nice to finish this until end of September in order to have
this feature in release 1.41.

mfg
Gunter

PS: We also need a new HTML page for the documentation of these
functions - everybody is welcome to contribute.

_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Marco Guazzone]

On Mon, Sep 14, 2009 at 9:50 PM, Gunter Winkler <guwi17@...> wrote:

> Hello uBLAS community,
>
> I created a new feature request which summarizes the current discussion.
>
> https://svn.boost.org/trac/boost/ticket/3449
>
> I think that we found a usable conclusion. Is there any one going to
> take the task. I will collect the corresponding patches and commit them
> to the SVN.
>
> It would be nice to finish this until end of September in order to have
> this feature in release 1.41.
>

I'll try to make my best.
However I cannot give any guarantees since I've some deadlines for my
research work too ;)

-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Michael Norel]

Hi comunity.

https://svn.boost.org/trac/boost/ticket/3449

My opinion than it is just syntatic sugar. It can be contributed as extension to UBLAS library.

thanks.



--- On Mon, 9/14/09, Gunter Winkler <guwi17@...> wrote:

> From: Gunter Winkler <guwi17@...>
> Subject: [ublas] [feature request] new free functions for matrix/vector sizes
> To: "ublas mailing list" <ublas@...>
> Date: Monday, September 14, 2009, 9:50 PM
> Hello uBLAS community,
>
> I created a new feature request which summarizes the
> current discussion.
>
> https://svn.boost.org/trac/boost/ticket/3449
>
> I think that we found a usable conclusion. Is there any one
> going to
> take the task. I will collect the corresponding patches and
> commit them
> to the SVN.
>
> It would be nice to finish this until end of September in
> order to have
> this feature in release 1.41.
>
> mfg
> Gunter
>
> PS: We also need a new HTML page for the documentation of
> these
> functions - everybody is welcome to contribute.
>
> _______________________________________________
> ublas mailing list
> ublas@...
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: minorlogic@...
>

     
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Marco Guazzone]

On Thu, Sep 17, 2009 at 9:16 PM, Michael Norel <minorlogic@...> wrote:
> Hi comunity.
>
> https://svn.boost.org/trac/boost/ticket/3449
>
> My opinion than it is just syntatic sugar. It can be contributed as extension to UBLAS library.
>
> thanks.

Hi Michael,

Well, yes it is... But take a look at this thread for the underlying reason:

http://lists.boost.org/MailArchives/ublas/2009/09/3677.php

Cheers,

-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Marco Guazzone]

On Wed, Sep 16, 2009 at 9:52 AM, Marco Guazzone
<marco.guazzone@...> wrote:

> On Mon, Sep 14, 2009 at 9:50 PM, Gunter Winkler <guwi17@...> wrote:
>> Hello uBLAS community,
>>
>> I created a new feature request which summarizes the current discussion.
>>
>> https://svn.boost.org/trac/boost/ticket/3449
>>
>> I think that we found a usable conclusion. Is there any one going to
>> take the task. I will collect the corresponding patches and commit them
>> to the SVN.
>>
>> It would be nice to finish this until end of September in order to have
>> this feature in release 1.41.
>>
>
> I'll try to make my best.
> However I cannot give any guarantees since I've some deadlines for my
> research work too ;)

Hello!

I've tried to implement these features plus the begin/end operation.
* size:
  - size(v)
  - size<1>(v)
  - size<1>(M)
  - size<2>(M)
  - size<tag::major>(M)
  - size<tag::minor>(M)
  - size<tag::leading>(M)
* num_columns
  - num_columns(M)
* num_rows
  - num_rows(M)
* begin:
  - begin(v) ==> alias of v.begin()
  - begin<tag::major>(M) ==> alias of M.begin1() or M.begin2()
[according to the orientation]
  - begin<tag::minor>(M) ==> alias of M.begin2() or M.begin2()
[according to the orientation]
  - begin(outer_mat_iter) ==> alias of outer_mat_iter.begin()
* end:
  - end(v) ==> alias of v.end()
  - end<tag::major>(M) ==> alias of M.end1() or M.end2() [according to
the orientation]
  - end<tag::minor>(M) ==> alias of M.end2() or M.end2() [according to
the orientation]
  - end(outer_mat_iter) ==> alias of outer_mat_iter.end()
* iterator_type
  - iterator_type<VectorExpression>::type ==> alias of
VectorExpression::iterator
  - iterator_type<MatrixExpression>::type ==> alias of
MatrixExpression::iterator1 or MatrixExpression::iterator2 [according
to the orientation]
* const_iterator_type
  - const_iterator_type<VectorExpression>::type ==> alias of
VectorExpression::const_iterator
  - const_iterator_type<MatrixExpression>::type ==> alias of
MatrixExpression::const_iterator1 or MatrixExpression::const_iterator2
[according to the orientation]


Under:
  boost/numeric/ublas/operation
you will find one header for each operation.
Note: I like to have one header for each operation because (1) the
user can include only the needed headers, (2) the resulting compiled
file should be smaller, (3) make the code clearer. Anyway, you're free
to put all of them in a single header.

Under:
  libs/numeric/ublas/test
there various tests.
You can compile them through the make file which I've provided.

All the code has been successfully compiled with GCC 4.4.1 on Fedora
11 x86_64, with very paranoic flags (like -Wall -Wextra -ansi
-pedantic): no errors nor warnings.

Since I'm very a beginner in template meta-programming, I would very
appreciate any hint/suggestion/comment for improving the code and my
knowledge about C++ ;)

PS: Should I post the code in the Trac site? If I do, how? I've
noticed the Login link ask me a login/password credentials...which I
have not :)

Thank you!!

Best,

-- Marco


_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Gunter Winkler]

Marco Guazzone schrieb:
> I've tried to implement these features plus the begin/end operation.
>
> Since I'm very a beginner in template meta-programming, I would very
> appreciate any hint/suggestion/comment for improving the code and my
> knowledge about C++ ;)
>
>  
After a quick look, the code is very clean and well documented. I'll
merge the provided files to trunk during this week and give more
detailed feedback.

> PS: Should I post the code in the Trac site? If I do, how? I've
> noticed the Login link ask me a login/password credentials...which I
> have not :)
No, sending patches to the list is fine. This way anyone interested can
review and discuss the details. BTW. anyone is allowed to add comments
to a ticket. Thus feel free to use the tool, because this is a good
place to document changes.

mfg
Gunter

_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Gunter Winkler]

Hello Marco,

I am still reviewing your code. It is very clear and well documented.
Below I give some comments - more will follow soon.

Am Sunday 20 September 2009 schrieb Marco Guazzone:
> On Wed, Sep 16, 2009 at 9:52 AM, Marco Guazzone
>
> [new free functions]

in begin.hpp:

Why do you use a static cast

return detail::begin_impl<typename
ExprT::type_category>::apply(static_cast<ExprT const&>(e));

instead of the operator()?

return detail::begin_impl<typename ExprT::type_category>::apply(e());

> Since I'm very a beginner in template meta-programming, I would very
> appreciate any hint/suggestion/comment for improving the code and my
> knowledge about C++ ;)

BTW: The code looks very sophisticated - I wouldn't call you a
beginner ...

I have not committed the new files because I'd like to do some more
tests.

mfg
Gunter



_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Marco Guazzone]

On Wed, Sep 30, 2009 at 12:15 AM, Gunter Winkler <guwi17@...> wrote:
> Hello Marco,
>
> I am still reviewing your code. It is very clear and well documented.

Thank you! I'm glad to hear this.

> Below I give some comments - more will follow soon.
>
> Am Sunday 20 September 2009 schrieb Marco Guazzone:
>> On Wed, Sep 16, 2009 at 9:52 AM, Marco Guazzone
>>
>> [new free functions]
>
> in begin.hpp:
>
> Why do you use a static cast
>
> return detail::begin_impl<typename
> ExprT::type_category>::apply(static_cast<ExprT const&>(e));
>
> instead of the operator()?
>
> return detail::begin_impl<typename ExprT::type_category>::apply(e());
>

Your right! The result is essentialy the same even if the use of "e()"
implies an additional indirection, that is:
- my version:
  ExprT::type_category>::apply(static_cast<ExprT const&>(e));

- your version (with e()) -- "expanded" view:
  ExprT::type_category>::apply(*static_cast<ExprT const*>(&e)); //
this is what e() would result

Anyway, I think your version is more elegant.
So I vote for you! :)
I send you changes in the attachment. To apply them:

$ patch -p4 < begin_end-remove_static_cast.patch

Cheers,

-- Marco


_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Gunter Winkler]

Am Wednesday 30 September 2009 schrieb Marco Guazzone:
> On Wed, Sep 30, 2009 at 12:15 AM, Gunter Winkler <guwi17@...>
wrote:
> > Hello Marco,
> >
> > I am still reviewing your code. It is very clear and well
> > documented.
>
> Thank you! I'm glad to hear this.
>

Finally, I committed your patch to trunk. In a few places I replaced
X::size_type by matrix_traits<X>::size_type (and similar) because we
should try to use traits whereever possible. My personal goal is to be
able to use uBLAS with plain c-arrays. (see c_array.hpp)

https://svn.boost.org/trac/boost/ticket/3449

mfg
Gunter


_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Marco Guazzone]

On Tue, Oct 6, 2009 at 1:02 AM, Gunter Winkler <guwi17@...> wrote:

> Am Wednesday 30 September 2009 schrieb Marco Guazzone:
>> On Wed, Sep 30, 2009 at 12:15 AM, Gunter Winkler <guwi17@...>
> wrote:
>> > Hello Marco,
>> >
>> > I am still reviewing your code. It is very clear and well
>> > documented.
>>
>> Thank you! I'm glad to hear this.
>>
>
> Finally, I committed your patch to trunk. In a few places I replaced
> X::size_type by matrix_traits<X>::size_type (and similar) because we
> should try to use traits whereever possible. My personal goal is to be
> able to use uBLAS with plain c-arrays. (see c_array.hpp)
>
> https://svn.boost.org/trac/boost/ticket/3449
>

OK Got it!
I'll try to follow this way in future implementations.
For what concern my committed code, I've seen some code need still to
be adequated. If you I can help you to change it. Let me know.


Cheers,

-- Marco
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...

[Gunter Winkler]

Marco Guazzone schrieb:
> OK Got it!
> I'll try to follow this way in future implementations.
> For what concern my committed code, I've seen some code need still to
> be adequated. If you I can help you to change it. Let me know.
>  
Feel free to send patches at any time.

mfg
Gunter
_______________________________________________
ublas mailing list
ublas@...
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: lists@...