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

Subject: Re: [ublas] [feature request] new free functions for matrix/vector sizes
From: Marco Guazzone (marco.guazzone_at_[hidden])
Date: 2010-09-21 04:24:20

On Mon, Sep 20, 2010 at 11:29 PM, Marco Guazzone
<marco.guazzone_at_[hidden]> wrote:
> On Sat, Jul 3, 2010 at 12:16 AM, Marco Guazzone
> <marco.guazzone_at_[hidden]> wrote:
>> On Sun, Jun 20, 2010 at 10:31 PM, Marco Guazzone
>> <marco.guazzone_at_[hidden]> wrote:
>>> On Fri, Oct 9, 2009 at 8:16 PM, Gunter Winkler <guwi17_at_[hidden]> wrote:
>>>> 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.
>>>>
>>>
>>> Hello,
>>>
>>> I'm considering to change the code of the "size" operation (that I
>>> wrote months ago) for two reasons:
>>>
>>> 1. to use the new uBLAS traits system introduced by Gunter
>>>     E.g.:
>>>        typename ExprT::size_type size(...)
>>>        ==>
>>>        typename matrix_traits<ExprT>::size_type size(...)
>>>
>>> 2. to make it directly usable with *_expression<E> types rather than
>>> passing the contained expression E
>>>     E.g.:
>>>        template <typename E>
>>>        void do_something(vector_expression<E> const& ve)
>>>        {
>>>           s = size(ve());
>>>        }
>>>        ==>
>>>        template <typename E>
>>>        void do_something(vector_expression<E> const& ve)
>>>        {
>>>           s = size(ve);
>>>        }
>>>  (surely less annoying ;) )
>>>
>>
>> [big-cut]
>>
>>> PS: ok! One solution might be to create a different function
>>> "size_by_tag" and to remove the polymorphic call "size<tag>()"; but
>>> this would break compatibility with code developed after the release
>>> of boost 1.41.
>>>
>>
>> At the end, after several trials, I am unable to make the
>> "size<tag>()" works with the new changes.
>>
>> I've created a new ticket
>>
>>  https://svn.boost.org/trac/boost/ticket/4399
>>
>> where I propose a change (and a patch) which however *break back compatibility*.
>> Specifically, instead of using "size<tag>" one should call "size_by_tag<tag>"
>>
>> What do you think?
>>
>
> Finally I've found a way to make the new version of size back compatible.
>
> Real credits go to Daniel & Stefan, two guys that suggested to me the way to go.
> For more info see:
>  http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/bd5080b28865f826
>
> In the Trac ticket you can find the new patch (ignore the one
> previously submitted).
>
> Summary of changes:
> * Use of ublas type-traits system (e.g. typename matrix_traits<M>::size_type).
> * Explicit use of matrix_/vector_expression in function arguments
> (e.g. size(matrix_expression<M> const& m).
> * Call to size<1>(v), with v a vector expression, is legal and returns
> the length of the vector-
>
> Do you like it?'
>

Hello,

I'd like to get from you some opinion about the size function.

Actually, I'm unsure about the fom:
   size< dimension_number >(v)
where v is a vector expression.

The rationale would be to let a vector behaves like a special kind of matrix.
Actually, only the form size<1>(v) is implemented, which returns the
length of v.
So my doubts are:
1. Do you think this form is useful?
1.1. If you do, do you think we should also provide the form size<2>(v)?
1.1.1. If you do, what should size<2>(v) return? The length of v or
(thinking of v as a special n-by-1 matrix) the number 1?

Cheers,

-- Marco