[fusion] More quanfusion
Hi Boosters, Continuing my experiments with fusion, towards the goal of a fusion matrix, here is my latest efforts: Fisrtly I created a fusion advance_iterator (I think it needs an offset to be added which I will do next) Heres an example of use: Select 2 range with advance_iterator and then do the dot product. Also shows use of static values which can be optimised away http://tinyurl.com/zj4uw Second question. I have now created various bits and pieces which seem tailor made for fusion : dot_product aka inner_product static_value advance_iterator. I am not quite sure whether put these into the fusion namespace and put them in the Boost Vault as extensions to fusion, or just to keep them in my own namespace? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:ee8te1$pgt$1@sea.gmane.org...
Second question. I have now created various bits and pieces which seem tailor made for fusion :
dot_product aka inner_product static_value advance_iterator.
Also add to that functional functors eg plus, minus etc, AFAICS Boost.Typeof works really nicely for these and ther is no problem with return types in gcc with functors rather than functions regards Andy Little
Andy Little wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:ee8te1$pgt$1@sea.gmane.org...
Second question. I have now created various bits and pieces which seem tailor made for fusion :
dot_product aka inner_product static_value advance_iterator.
Also add to that functional functors eg plus, minus etc, AFAICS Boost.Typeof works really nicely for these and ther is no problem with return types in gcc with functors rather than functions
Could you give me some time to think about it? I'll need to review it first, at the very least. Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries; fusion seems not to be the right place for it. MPL has lambda and those little arithmetic metafunctions, but the fusion counterparts of these can be found in other libraries (e.g. lambda/phoenix). In any case, I really appreciate the effort you are putting into this, Andy! Please keep up the good work :) Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:eea4i0$8lq$1@sea.gmane.org...
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries;
So What? Only Boost.Typeof binds compile time types to function signatures. F* the "functional" type deduction schemes, including mine,lambda, phoenix, Boost.Typeof provides a common syntax via the function return type, and is the future. (Apologies to the 12 year olds reading the list.) fusion *must* have type deduction, and Boost.Typeof is the placeholder. regards Andy Little
Andy Little wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:eea4i0$8lq$1@sea.gmane.org...
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries;
So What? Only Boost.Typeof binds compile time types to function signatures.
F* the "functional" type deduction schemes, including mine,lambda, phoenix,
Boost.Typeof provides a common syntax via the function return type, and is the future.
(Apologies to the 12 year olds reading the list.)
fusion *must* have type deduction, and Boost.Typeof is the placeholder.
I think you missed my point. I am not arguing against using Boost.Typeof for plus, minus, etc. I am only stating my apprehension towards adding a functional module into fusion. It seems not the right place. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:eea6t1$esb$1@sea.gmane.org...
Andy Little wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:eea4i0$8lq$1@sea.gmane.org...
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries;
So What? Only Boost.Typeof binds compile time types to function signatures.
F* the "functional" type deduction schemes, including mine,lambda, phoenix,
Boost.Typeof provides a common syntax via the function return type, and is the future.
(Apologies to the 12 year olds reading the list.)
fusion *must* have type deduction, and Boost.Typeof is the placeholder.
I think you missed my point. I am not arguing against using Boost.Typeof for plus, minus, etc. I am only stating my apprehension towards adding a functional module into fusion. It seems not the right place.
There is no other right place. What I mean is, fusion is kind of important to C++, hence , fusion is the right place. regards Andy Little
"Joel de Guzman" <joel@boost-consulting.com> wrote
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries; fusion seems not to be the right place for it.
Fusion is the right place to get rid of manual type deduction. I strongly believe this. regards Andy Little
Andy Little wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries; fusion seems not to be the right place for it.
Fusion is the right place to get rid of manual type deduction. I strongly believe this.
Can you say why? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Andy Little wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries; fusion seems not to be the right place for it.
Fusion is the right place to get rid of manual type deduction. I strongly believe this.
We're talking about functional objects here, right? Like a plus() object that uses Boost.Typeof to deduce its result type. Then I agree with Joel that Fusion is the wrong place for that. I have a start on such a collection of numeric functional objects here: http://tinyurl.com/zokre I decided for my work that the right place was to make it a sub-library of boost/numeric and put it in boost/numeric/functional.hpp. I am hoping to one day have the time to flesh this out and submit it to Boost. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4508A32F.7050606@boost-consulting.com...
Andy Little wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries; fusion seems not to be the right place for it.
Fusion is the right place to get rid of manual type deduction. I strongly believe this.
We're talking about functional objects here, right? Like a plus() object that uses Boost.Typeof to deduce its result type. Then I agree with Joel that Fusion is the wrong place for that. I have a start on such a collection of numeric functional objects here:
I decided for my work that the right place was to make it a sub-library of boost/numeric and put it in boost/numeric/functional.hpp. I am hoping to one day have the time to flesh this out and submit it to Boost.
A + B isnt a numeric... regards Andy Little
Andy Little wrote:
"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4508A32F.7050606@boost-consulting.com...
Andy Little wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote
Some of these elements you mentioned do have generic appeal. static_value and advance_iterator looks general enough. plus, minus etc, have overlaps over other "functional" libraries; fusion seems not to be the right place for it. Fusion is the right place to get rid of manual type deduction. I strongly believe this.
We're talking about functional objects here, right? Like a plus() object that uses Boost.Typeof to deduce its result type. Then I agree with Joel that Fusion is the wrong place for that. I have a start on such a collection of numeric functional objects here:
I decided for my work that the right place was to make it a sub-library of boost/numeric and put it in boost/numeric/functional.hpp. I am hoping to one day have the time to flesh this out and submit it to Boost.
A + B isnt a numeric...
How about boost/functional ? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Eric Niebler" wrote in message
We're talking about functional objects here, right? Like a plus() object that uses Boost.Typeof to deduce its result type. Then I agree with Joel that Fusion is the wrong place for that. I have a start on such a collection of numeric functional objects here:
I decided for my work that the right place was to make it a sub-library of boost/numeric and put it in boost/numeric/functional.hpp. I am hoping to one day have the time to flesh this out and submit it to Boost.
A + B isnt a numeric...
But Nevertheless it looks quite useful :-) regards Andy Little
"David Abrahams" wrote
Joel de Guzman writes:
advance_iterator looks general enough.
What *is* an advance_iterator?
FWIW: fusion::advance_iterator< Sequence, // the sequence to advance over Stride, // number of positions in underlying //sequence to move on 'next' StridedPosition, // underlying sequence::position * // Stride + Offset Offset // offset in underlying sequence units
The main use is to return a column in a linear sequence representing a matrix. Also consider : sequence seq; advance_iterator<sequence,..> i1(seq); advance_iterator<sequence,..> i2(seq); iterator_range<i1_type,i2_type> range(i1,i2);: advance_iterator<range, ..> j1(range); advance_iterator<range, ..> j2(range); iterator_range<j1_type,j2_type> range_on_range (j1,j2); etc ... regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:eeb265$m3u$1@sea.gmane.org...
"David Abrahams" wrote
Joel de Guzman writes:
advance_iterator looks general enough.
What *is* an advance_iterator?
FWIW:
fusion::advance_iterator< Sequence, // the sequence to advance over Stride, // number of positions in underlying //sequence to move on 'next' StridedPosition, // underlying sequence::position * // Stride + Offset Offset // offset in underlying sequence units
The main use is to return a column in a linear sequence representing a matrix.
And here FWIW is an example use. The example sets up a 2D rotation matrix comprised partly of static_values and partly of runtime values( here with a runtime settable 90 degree rotation ) and a homogeneous coordinate again comprised partly of static and partly of runtime values. Because some members are static_values, calcs on them will be completetly optimised away by the compiler , hence, even though the matrix and coordinate directly represent length quantities using quan::length's , the only runtime calcs are on double values and even there the calcs will be reduced compared to the equivalent double only matrix. (The matrix will of course survive serialisation, so that the static_values will survive) http://tinyurl.com/e7729 regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
Joel de Guzman writes:
advance_iterator looks general enough.
What *is* an advance_iterator?
FWIW:
fusion::advance_iterator< Sequence, // the sequence to advance over Stride, // number of positions in underlying //sequence to move on 'next' StridedPosition, // underlying sequence::position * // Stride + Offset Offset // offset in underlying sequence units
The main use is to return a column in a linear sequence representing a matrix.
That's a well-known idea already in the literature; it's known as a "strided iterator." Can we use the common terminology? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
Joel de Guzman writes:
advance_iterator looks general enough. What *is* an advance_iterator? FWIW:
fusion::advance_iterator< Sequence, // the sequence to advance over Stride, // number of positions in underlying //sequence to move on 'next' StridedPosition, // underlying sequence::position * // Stride + Offset Offset // offset in underlying sequence units The main use is to return a column in a linear sequence representing a matrix.
That's a well-known idea already in the literature; it's known as a "strided iterator." Can we use the common terminology?
Yeah, that's one of my review items when I get to it. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"David Abrahams" <dave@boost-consulting.com> wrote in message news:874pvayao2.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
Joel de Guzman writes:
advance_iterator looks general enough.
What *is* an advance_iterator?
FWIW:
fusion::advance_iterator< Sequence, // the sequence to advance over Stride, // number of positions in underlying //sequence to move on 'next' StridedPosition, // underlying sequence::position * // Stride + Offset Offset // offset in underlying sequence units
The main use is to return a column in a linear sequence representing a matrix.
That's a well-known idea already in the literature;
Its not just an idea. I got one that works with fusion :-) it's known as a
"strided iterator." Can we use the common terminology?
OK, but it doesnt sound very cool, compared to advance_iterator. IMO everything in fusion should have a cool name :-) Same with inner_product. dot_product is way cooooler. regards Andy Little
On Thu, 14 Sep 2006 14:39:03 +0100 "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:874pvayao2.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" wrote
Joel de Guzman writes:
advance_iterator looks general enough.
What *is* an advance_iterator?
FWIW:
fusion::advance_iterator< Sequence, // the sequence to advance over Stride, // number of positions in underlying //sequence to move on 'next' StridedPosition, // underlying sequence::position * // Stride + Offset Offset // offset in underlying sequence units
The main use is to return a column in a linear sequence representing a matrix.
That's a well-known idea already in the literature;
Its not just an idea. I got one that works with fusion :-)
it's known as a
"strided iterator." Can we use the common terminology?
OK, but it doesnt sound very cool, compared to advance_iterator. IMO everything in fusion should have a cool name :-)
Though I think this sort of thing would be flushed out in a review, honestly, when I first read "advance_iterator", I had the same question pop into my head - what is it? Admittedly, strided_iterator is a better name, and you get the gist of its purpose by name alone - can't say that for advance_iterator though.
Same with inner_product. dot_product is way cooooler.
If your dot product is indeed an inner product, then an inner_product is what you should call your op - being explicit rather than suggestive is always better (, sorry, just that my mathematics grounding makes me speak out on this one). Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA
On Fri, Sep 15, 2006 at 11:21:16AM +1000, Manfred Doudar wrote:
Same with inner_product. dot_product is way cooooler.
If your dot product is indeed an inner product, then an inner_product is what you should call your op - being explicit rather than suggestive is always better (, sorry, just that my mathematics grounding makes me speak out on this one).
Actually, dot_product is more specific, and therefore a better name: http://mathworld.wolfram.com/InnerProduct.html Geoffrey
On Thu, 14 Sep 2006 18:49:13 -0700 Geoffrey Irving <irving@cs.stanford.edu> wrote:
On Fri, Sep 15, 2006 at 11:21:16AM +1000, Manfred Doudar wrote:
Same with inner_product. dot_product is way cooooler.
If your dot product is indeed an inner product, then an inner_product is what you should call your op - being explicit rather than suggestive is always better (, sorry, just that my mathematics grounding makes me speak out on this one).
Actually, dot_product is more specific, and therefore a better name:
Hmm, I knew that comment would get me into trouble; but was kind-of in two heads/minds when I wrote that - indeed a dot-product is more "specific", yes ... you are limited to operations of addition and multiplication with a dot-product (effectively a constraint on the kinds of spaces you are prepared to deal with), not so for its generalization. Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA
"Manfred Doudar" wrote
If your dot product is indeed an inner product, then an inner_product is what you should call your op - being explicit rather than suggestive is always better (, sorry, just that my mathematics grounding makes me speak out on this one).
Dunno, but FWIW , from the source code: http://tinyurl.com/e7729 involving transform of a homogeneous 2D coordinate (3 elements) by a 2D transform matrix (9 elements) here's the resulting assembler of my latest CVS version in VC8 with optimisation. I'm no expert but it looks pretty good to me ; 113 : // do runtime calc ; 114 : quan::fusion::dot_product dot; ; 115 : result_type result( ; 116 : dot(coordinate,col0), ; 117 : dot(coordinate,col1), ; 118 : dot(coordinate,col2) ; 119 : ); 00164 dd 44 24 1c fld QWORD PTR _coordinate$[esp+304] 00168 8d b4 24 d4 00 00 00 lea esi, DWORD PTR $T303578[esp+296] 0016f dd 44 24 40 fld QWORD PTR $T303558[esp+296] 00173 d8 c9 fmul ST(0), ST(1) 00175 dd 44 24 14 fld QWORD PTR _coordinate$[esp+296] 00179 dd 44 24 28 fld QWORD PTR $T303561[esp+296] 0017d d8 c9 fmul ST(0), ST(1) 0017f de c2 faddp ST(2), ST(0) 00181 d9 ee fldz 00183 dc c2 fadd ST(2), ST(0) 00185 d9 cb fxch ST(3) 00187 dc 4c 24 30 fmul QWORD PTR $T303559[esp+296] 0018b d9 c9 fxch ST(1) 0018d dc 8c 24 f0 00 00 00 fmul QWORD PTR _rotation$[esp+296] 00194 de c1 faddp ST(1), ST(0) 00196 de c2 faddp ST(2), ST(0) 00198 d9 c9 fxch ST(1) 0019a dd 5c 24 14 fstp QWORD PTR _result$[esp+296] 0019e dd 5c 24 1c fstp QWORD PTR _result$[esp+304] // start of output routine 001a2 e8 00 00 00 00 call tuple_delimiter regards Andy Little
On Fri, 15 Sep 2006 03:01:07 +0100 "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
"Manfred Doudar" wrote
If your dot product is indeed an inner product, then an inner_product is what you should call your op - being explicit rather than suggestive is always better (, sorry, just that my mathematics grounding makes me speak out on this one).
Dunno, but FWIW , from the source code:
involving transform of a homogeneous 2D coordinate (3 elements) by a 2D transform matrix (9 elements) here's the resulting assembler of my latest CVS version in VC8 with optimisation. I'm no expert but it looks pretty good to me
; 113 : // do runtime calc ; 114 : quan::fusion::dot_product dot; ; 115 : result_type result( ; 116 : dot(coordinate,col0), ; 117 : dot(coordinate,col1), ; 118 : dot(coordinate,col2) ; 119 : );
Please see my brief reply to Geoffrey Irving; ... and apologies for any apprehension caused, but its my fault - the best name to use really depends on context. Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA
"Manfred Doudar" wrote
Please see my brief reply to Geoffrey Irving; ... and apologies for any apprehension caused, but its my fault - the best name to use really depends on context.
Then I guess in fusion you would do : fusion::inner_product<SequenceA, SequenceB,Function1,Function2>{...} fusion::dot_product<SequenceA, SequenceB> : fusion::inner_product< SequenceA,SequenceB, boost:functional::multiplies,boost::functional::plus
{};
regards Andy Little
Andy Little wrote:
"Manfred Doudar" wrote
Please see my brief reply to Geoffrey Irving; ... and apologies for any apprehension caused, but its my fault - the best name to use really depends on context.
Then I guess in fusion you would do :
fusion::inner_product<SequenceA, SequenceB,Function1,Function2>{...}
fusion::dot_product<SequenceA, SequenceB> : fusion::inner_product< SequenceA,SequenceB, boost:functional::multiplies,boost::functional::plus
{};
Reminds me of fusion and mpl fold/accumulate. It's the same thing with a different name. fusion and mpl have both as synonyms. Cheers! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Fri, 15 Sep 2006 03:28:39 +0100 "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
"Manfred Doudar" wrote
Please see my brief reply to Geoffrey Irving; ... and apologies for any apprehension caused, but its my fault - the best name to use really depends on context.
Then I guess in fusion you would do :
fusion::inner_product<SequenceA, SequenceB,Function1,Function2>{...}
fusion::dot_product<SequenceA, SequenceB> : fusion::inner_product< SequenceA,SequenceB, boost:functional::multiplies,boost::functional::plus
{};
..Back to C++, kinda, yeah .. though for the inner_product (and this is where variadic template parameters would be a nice fit): fusion::inner_product<SequenceA, SequenceB, ...> { /*...*/ } (, or whatever the syntax was - forgot the exact semantics Doug Gregor implemented) and your dot_product would be as specified. Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA
"Manfred Doudar" <manfred.doudar@rsise.anu.edu.au> wrote in message news:20060915124632.096ed245@mathmcn.rsise.anu.edu.au...
On Fri, 15 Sep 2006 03:28:39 +0100
..Back to C++, kinda, yeah .. though for the inner_product (and this is where variadic template parameters would be a nice fit):
fusion::inner_product<SequenceA, SequenceB, ...> { /*...*/ }
(, or whatever the syntax was - forgot the exact semantics Doug Gregor implemented)
fusion::inner_product< SequenceA, SequenceB, FunctionSequenceA,FunctionSequenceB
{ /*...*/ }
? regards Andy Little
On Fri, 15 Sep 2006 09:26:43 +0100 "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
"Manfred Doudar" <manfred.doudar@rsise.anu.edu.au> wrote in message news:20060915124632.096ed245@mathmcn.rsise.anu.edu.au...
On Fri, 15 Sep 2006 03:28:39 +0100
..Back to C++, kinda, yeah .. though for the inner_product (and this is where variadic template parameters would be a nice fit):
fusion::inner_product<SequenceA, SequenceB, ...> { /*...*/ }
(, or whatever the syntax was - forgot the exact semantics Doug Gregor implemented)
fusion::inner_product< SequenceA, SequenceB, FunctionSequenceA,FunctionSequenceB
{ /*...*/ }
?
No (, at least I don't see how) ... you'd expect the valid functions to be the operations sensible on sequences A&B both. With this in mind (sequences not variadics), it would be more reasonable to propose the following methinks: fusion::inner_product<SequenceA, SequenceB, FunctionSequence> { /*,,,*/ } Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA
"Manfred Doudar" <manfred.doudar@rsise.anu.edu.au> wrote in message news:20060915185102.4ab9a2af@mathmcn.rsise.anu.edu.au...
On Fri, 15 Sep 2006 09:26:43 +0100 "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
"Manfred Doudar" <manfred.doudar@rsise.anu.edu.au> wrote in message news:20060915124632.096ed245@mathmcn.rsise.anu.edu.au...
On Fri, 15 Sep 2006 03:28:39 +0100
..Back to C++, kinda, yeah .. though for the inner_product (and this is where variadic template parameters would be a nice fit):
fusion::inner_product<SequenceA, SequenceB, ...> { /*...*/ }
(, or whatever the syntax was - forgot the exact semantics Doug Gregor implemented)
fusion::inner_product< SequenceA, SequenceB, FunctionSequenceA,FunctionSequenceB
{ /*...*/ }
?
No (, at least I don't see how) ... you'd expect the valid functions to be the operations sensible on sequences A&B both. With this in mind (sequences not variadics), it would be more reasonable to propose the following methinks:
fusion::inner_product<SequenceA, SequenceB, FunctionSequence> { /*,,,*/ }
It occurs that I took the accumulate algorithm and particularised it for dot product. Now you are taking dot product and generalising it back into accumulate :-) , but I could be wrong ... regards Andy Little
On Fri, Sep 15, 2006 at 03:28:39AM +0100, Andy Little wrote:
Then I guess in fusion you would do :
fusion::inner_product<SequenceA, SequenceB,Function1,Function2>{...}
fusion::dot_product<SequenceA, SequenceB> : fusion::inner_product< SequenceA,SequenceB, boost:functional::multiplies,boost::functional::plus
{};
Just to clarify the terminology: that inner_product function is still essentially a dot product. A dot_product is anything that looks like product = x*x + y*y + z*z + ... where + and * can be any ring operations. A general inner product function would have to allow for cross terms, e.g., product = a*x*x + b*x*y + c*y*y + ... So, I'd go for calling everything dot_product and giving it default arguments for + and *. Geoffrey
On 09/13/2006 07:26 AM, Andy Little wrote:
Hi Boosters,
Continuing my experiments with fusion, towards the goal of a fusion matrix, here is my latest efforts:
Matrix is rank 2 array. What's the disadvantage (besides further development effort) of generalizing this fusion container to any rank?
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:ee94tl$m3d$1@sea.gmane.org...
On 09/13/2006 07:26 AM, Andy Little wrote:
Hi Boosters,
Continuing my experiments with fusion, towards the goal of a fusion matrix, here is my latest efforts:
Matrix is rank 2 array. What's the disadvantage (besides further development effort) of generalizing this fusion container to any rank?
Further development effort :-) Seriously. I would prefer to work on this thing bottom up, rather than top down, and keep it simple for the moment. Currently there is a practical limit to the size of matrix that can be used set by compilation time and compiler resources. Once I get a simple matrix working then it will be possible to analyse how practical that is to start with, and then consider how to generalise it. regards Andy Little
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:ee94tl$m3d$1@sea.gmane.org...
On 09/13/2006 07:26 AM, Andy Little wrote:
Hi Boosters,
Continuing my experiments with fusion, towards the goal of a fusion matrix, here is my latest efforts:
Matrix is rank 2 array. What's the disadvantage (besides further development effort) of generalizing this fusion container to any rank?
BTW advance_iterator is (should be) a conforming iterator so it should be possible to stack it. regards Andy little
On 09/13/2006 07:26 AM, Andy Little wrote: [snip]
I am not quite sure whether put these into the fusion namespace and put them in the Boost Vault as extensions to fusion, or just to keep them in my own namespace?
Joel, would a new directory, boost/fusion/sequence/container/matrix, be a good place?
On 09/13/2006 07:26 AM, Andy Little wrote: [snip]
I am not quite sure whether put these into the fusion namespace and put them in the Boost Vault as extensions to fusion, or just to keep them in my own namespace?
Joel, would a new directory, boost/fusion/sequence/container/matrix, be a good place? Joel, I'm also thinking this matrix *might* help in calculating
On 09/13/2006 10:18 AM, Larry Evans wrote: the First and/or Follow sets for the deterministic parsing discussed in the post with headers: From: Joel de Guzman <joel@boost-consulting.com> Newsgroups: gmane.comp.parsers.spirit.devel Subject: Re: Re: first sets and deterministic parsing Date: Fri, 27 Feb 2004 12:59:15 +0800 using the method described in section 3.3 of: http://facweb.cs.depaul.edu/tchristopher/grmanl.pdf
Larry Evans wrote:
On 09/13/2006 07:26 AM, Andy Little wrote: [snip]
I am not quite sure whether put these into the fusion namespace and put them in the Boost Vault as extensions to fusion, or just to keep them in my own namespace?
Joel, would a new directory, boost/fusion/sequence/container/matrix, be a good place?
I need more time to think about it. I'd like to parallel MPL and STL as much as possible. inner_product is an STL algorithm, so it can just be in fusion "algorithm". If you are planning a more complete matrix package, then, my knee jerk reaction is to have it as a separate library on top of fusion. More deliberation will be needed, I think, especially on how this relates to other matrix projects in the making within the boost community, etc. For now, it would be probably be good to have it as a fusion example until it matures enough to be part of the library. But then again, I welcome more thoughts on this. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Joel de Guzman" <joel@boost-consulting.com> wrote in message news:eea5l4$bpa$1@sea.gmane.org...
Larry Evans wrote:
On 09/13/2006 07:26 AM, Andy Little wrote: [snip]
I am not quite sure whether put these into the fusion namespace and put them in the Boost Vault as extensions to fusion, or just to keep them in my own namespace?
Joel, would a new directory, boost/fusion/sequence/container/matrix, be a good place?
I need more time to think about it. I'd like to parallel MPL and STL as much as possible. inner_product is an STL algorithm, so it can just be in fusion "algorithm".
If you are planning a more complete matrix package, then, my knee jerk reaction is to have it as a separate library on top of fusion. More deliberation will be needed, I think, especially on how this relates to other matrix projects in the making within the boost community, etc. For now, it would be probably be good to have it as a fusion example until it matures enough to be part of the library. But then again, I welcome more thoughts on this.
For myself I am pretty much sure that Boost.Fusion will be an essential part of my Quan library, therefore I reckon I am going to rework the dot product example, as a matrix example , but using the Quan components, as it seems daft to have to make 3 versions of everything. So, anyone that wants to try the examples will have the Quan CVS dependency for the moment. I may as well start promoting Quan AFAICS! Quan promotion warning....... Quan, The serious library for modelling and manipulating physical quantities in C++. Download Quan here ( Note: for the fusion stuff you will need to download CVS) http://sourceforge.net/projects/quan/ regards Andy Little
participants (7)
-
Andy Little -
David Abrahams -
Eric Niebler -
Geoffrey Irving -
Joel de Guzman -
Larry Evans -
Manfred Doudar