Stjepan Rajko | 15 Jul 09:47

[fusion] constructing all elements of the fusion vector with the same argument

Hello,

I recently ran into a need to initialize a fusion vector with a single
argument which is then used to construct all of the vector elements.
For example, something that would allow:

fusion::vector<int, float, double> ones(initialize_all_with(),1);

// at_c<0>(ones) == 1
// at_c<1>(ones) == 1.0f
// at_c<2>(ones) == 1.0;

I hacked fusion::vector so that the above works.  Is this addition of
interest to anyone else?

There is another (perhaps more elegant) solution in implementing a new
fusion "array" Sequence (one where all element types are identical)
which can construct all elements from a single constructor argument,
and then using that sequence to do the above initialization.  E.g.,

fusion::vector<int, float, double> ones(fusion::array<int, 3>(1));

... or (another solution) a make_array function that returns a fusion::vector:

fusion::vector<int, float, double> ones(fusion::make_array<3>(1));

It would be great if one of these solutions (or a different solution)
were added to fusion. I can take a stab at putting something together,
if any of them are acceptable.  That is, unless this is already
possible in some way that I can't see at the moment :-)
(Continue reading)

Joel de Guzman | 15 Jul 12:49

Re: [fusion] constructing all elements of the fusion vector with the same argument

Stjepan Rajko wrote:
> Hello,
> 
> I recently ran into a need to initialize a fusion vector with a single
> argument which is then used to construct all of the vector elements.
> For example, something that would allow:
> 
> fusion::vector<int, float, double> ones(initialize_all_with(),1);
> 
> // at_c<0>(ones) == 1
> // at_c<1>(ones) == 1.0f
> // at_c<2>(ones) == 1.0;
> 
> I hacked fusion::vector so that the above works.  Is this addition of
> interest to anyone else?

Definitely. I'm not sure about the interface though. It seems
there could be a more generic "lazy-construction" scheme that
can have a more general appeal.

After thinking about it, we don't even have to do anything
-- fusion already supports it, but we haven't taken advantage
of it yet.

As you know, *all* fusion containers can be initialized
from arbitrary fusion sequences. For example:

     vector<int, double> v(std::pair<char, short>(1, 2));

schematically:
(Continue reading)

Stjepan Rajko | 15 Jul 19:39

Re: [fusion] constructing all elements of the fusion vector with the same argument

On Tue, Jul 15, 2008 at 3:49 AM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
>
> If we have a /lazy-sequence/ s, that generates the ones for you,
> then you can use that for s:
>
>    vector<int, float, double> ones(all_ones);
>
> all_ones is a lazy-sequence. It generates the ones every time
> the iterator is dereferenced.
>
> A nice strategy is to write a function adaptor that creates
> a fusion sequence. Example:
>
>    int one() {return 1}
>
> ...
>
>    vector<int, float, double> ones(fusion::make_lazy_sequence(&one));
>
>  [snip]
>
> How about hacking on the /lazy_sequence/ idea? Thoughts?
>

I *love it*.  Attached is something... similar ;-) (I used the
triple.cpp example as a starting point, it was pretty straightforward)

What do you think?

(Continue reading)

Joel de Guzman | 16 Jul 04:53

Re: [fusion] constructing all elements of the fusion vector with the same argument

Stjepan Rajko wrote:

>> How about hacking on the /lazy_sequence/ idea? Thoughts?
>>
> 
> I *love it*.  Attached is something... similar ;-) (I used the
> triple.cpp example as a starting point, it was pretty straightforward)
> 
> What do you think?

I Love it! I think this should be an official part of Fusion.
There are some matters though that we should consider
very well:

1) The concept of an infinite-sequence.

    I'm not quite happy that all sequences has a finite size.
    Perhaps we can return something like fusion::infinite_size
    for size for such kind of sequences. We'll have to tweak the
    library though to cater to these kinds of sequences. IFAIR,
    these size checks are only done with algos dealing with 2
    sequences and one sequence need to have equal or more elements
    than the other. Better check on this one.

    If this is possible, then we should have a new infinite-sequence
    concept. I wonder where and how that will fit in the fusion
    concepts hierarchy.

2) If this is not possible, then the interface should at least
    be compatible with the at_c and at interfaces:
(Continue reading)

David Abrahams | 16 Jul 07:33

Re: [fusion] constructing all elements of the fusion vector with the same argument


on Tue Jul 15 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:

> Stjepan Rajko wrote:
>
>>> How about hacking on the /lazy_sequence/ idea? Thoughts?
>>>
>>
>> I *love it*.  Attached is something... similar ;-) (I used the
>> triple.cpp example as a starting point, it was pretty straightforward)
>>
>> What do you think?
>
> I Love it! I think this should be an official part of Fusion.
> There are some matters though that we should consider
> very well:
>
> 1) The concept of an infinite-sequence.
>
>    I'm not quite happy that all sequences has a finite size.

Where does that restriction come from?  You know you can always give
infinite sequences an (unreachable) end iterator.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Joel de Guzman | 16 Jul 08:48

Re: [fusion] constructing all elements of the fusion vector with the same argument

David Abrahams wrote:
> on Tue Jul 15 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
> 
>> Stjepan Rajko wrote:
>>
>>>> How about hacking on the /lazy_sequence/ idea? Thoughts?
>>>>
>>> I *love it*.  Attached is something... similar ;-) (I used the
>>> triple.cpp example as a starting point, it was pretty straightforward)
>>>
>>> What do you think?
>> I Love it! I think this should be an official part of Fusion.
>> There are some matters though that we should consider
>> very well:
>>
>> 1) The concept of an infinite-sequence.
>>
>>    I'm not quite happy that all sequences has a finite size.
> 
> Where does that restriction come from?  You know you can always give
> infinite sequences an (unreachable) end iterator.

Here: http://tinyurl.com/4b9m8q

The size(s), result_of::size<S> gives this restriction. The result
should be "MPL Integral Constant. Convertible to int.".

This is inherited from MPL:

http://tinyurl.com/6cbx9c
(Continue reading)

Stjepan Rajko | 16 Jul 20:30

Re: [fusion] constructing all elements of the fusion vector with the same argument

On Tue, Jul 15, 2008 at 7:53 PM, Joel de Guzman
<joel <at> boost-consulting.com> wrote:
>
> 1) The concept of an infinite-sequence.
>
>   I'm not quite happy that all sequences has a finite size.
>   Perhaps we can return something like fusion::infinite_size

That would be really nice!  I will make the Size template parameter a
typename, so fusion::infinite_size can be specified if/when it becomes
supported.  I think the implementation will only need to change its
behavior related to the end iterator.  That way, we can have both
finite and infinite lazy_sequences.

>
>   If this is possible, then we should have a new infinite-sequence
>   concept. I wonder where and how that will fit in the fusion
>   concepts hierarchy.
>

It seems orthogonal to other Sequence concepts...  Maybe the Sequence
concept should have the "size is an integral constant" requirement
pulled out of it, and then have FiniteSequence and InfiniteSequence
concepts that refine that?

> 2) If this is not possible, then the interface should at least
>   be compatible with the at_c and at interfaces:
>
>   make_lazy_sequence<MPL-N>(f);
>   make_lazy_sequence_c<N>(f);
(Continue reading)

Joel de Guzman | 17 Jul 03:48

Re: [fusion] constructing all elements of the fusion vector with the same argument

Stjepan Rajko wrote:
> On Tue, Jul 15, 2008 at 7:53 PM, Joel de Guzman
> <joel <at> boost-consulting.com> wrote:
>> 1) The concept of an infinite-sequence.
>>
>>   I'm not quite happy that all sequences has a finite size.
>>   Perhaps we can return something like fusion::infinite_size
> 
> That would be really nice!  I will make the Size template parameter a
> typename, so fusion::infinite_size can be specified if/when it becomes
> supported.  I think the implementation will only need to change its
> behavior related to the end iterator.  That way, we can have both
> finite and infinite lazy_sequences.
> 
>>   If this is possible, then we should have a new infinite-sequence
>>   concept. I wonder where and how that will fit in the fusion
>>   concepts hierarchy.
>>
> 
> It seems orthogonal to other Sequence concepts...  Maybe the Sequence
> concept should have the "size is an integral constant" requirement
> pulled out of it, and then have FiniteSequence and InfiniteSequence
> concepts that refine that?

Perhaps we need not add new concepts if we simply relax the size
requirement. We simply state that a Forward Sequence may be finite
or infinite, and add an /fusion::inf/ type representing infinity.
The library has to be tweaked though for code (using size) that may
break with this new size representation. This is a potentially
breaking change, so the user must also be warned (docs).
(Continue reading)

Steven Watanabe | 17 Jul 04:04

Re: [fusion] constructing all elements of the fusion vector with the same argument

AMDG

Joel de Guzman wrote:
> Yeah, I agree. All views are inherently "lazy" anyway. So it's
> not a good name. More suggestions, anyone, please? functional_view?
> computed_view?

I just looked at lazy_sequence.hpp.  Isn't it equivalent to
transform(mpl::range_c<int, 0, N>(), f)?

> Man! The fold algorithm can even be implemented in terms of this
> view. The only difference is that each "fold" is computed along the
> way. Maybe we should just call it "fold_view" ?

Awesome.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Joel de Guzman | 17 Jul 04:36

Re: [fusion] constructing all elements of the fusion vector with the same argument

Steven Watanabe wrote:
> AMDG
> 
> Joel de Guzman wrote:
>> Yeah, I agree. All views are inherently "lazy" anyway. So it's
>> not a good name. More suggestions, anyone, please? functional_view?
>> computed_view?
> 
> I just looked at lazy_sequence.hpp.  Isn't it equivalent to
> transform(mpl::range_c<int, 0, N>(), f)?

Hah! Yeah. You just spoiled the fun! ;-)

>> Man! The fold algorithm can even be implemented in terms of this
>> view. The only difference is that each "fold" is computed along the
>> way. Maybe we should just call it "fold_view" ?

So, can this too be implemented in terms of fusion/mpl alone?

Either way, what we should probably do is add some of these
examples with accompanying docs.

Regards,
--

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Steven Watanabe | 17 Jul 04:52

Re: [fusion] constructing all elements of the fusion vector with the same argument

AMDG

Joel de Guzman wrote:
>>> Man! The fold algorithm can even be implemented in terms of this
>>> view. The only difference is that each "fold" is computed along the
>>> way. Maybe we should just call it "fold_view" ?
>
> So, can this too be implemented in terms of fusion/mpl alone?

I don't think so.  The state would need to be stored in
the iterator and the function object called by next(), right?
None of the available fusion views supports this.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Stjepan Rajko | 17 Jul 23:02

Re: [fusion] constructing all elements of the fusion vector with the same argument

On Wed, Jul 16, 2008 at 7:04 PM, Steven Watanabe <watanabesj <at> gmail.com> wrote:
>
> I just looked at lazy_sequence.hpp.  Isn't it equivalent to
> transform(mpl::range_c<int, 0, N>(), f)?
>

LOL - well, this was a interestingly roundabout way of finding an
existing solution to my original problem.  Thanks Steven!

Stjepan
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Jeff Flinn | 17 Jul 15:36

Re: [fusion] constructing all elements of the fusion vector with the same argument

Joel de Guzman wrote:
> Stjepan Rajko wrote:
>> On Tue, Jul 15, 2008 at 7:53 PM, Joel de Guzman
>> <joel <at> boost-consulting.com> wrote:
...
> 
>> That maybe
>> suggests changing the name to something like "callable_view" (perhaps
>> there is a better variant that doesn't suggest that the view is
>> callable).
> 
> Yeah, I agree. All views are inherently "lazy" anyway. So it's
> not a good name. More suggestions, anyone, please? functional_view?
> computed_view?

 From mathematics/linear algebra:

	domain_view, field view

Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Gmane