Hi, Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::transform(a, b, some_void_return_ftor)) * Conversion function 'as_view' to make Container a view to reserve the mutability. What do you think? Are these already achieved in some way that I didn't aware of? BTW, I just implemented left_mapping/left_mapped_view, it's used like result = left_mapping(m1, m2, transform); For elements not mapped, fusion::void_ is passed to transform. Still mapping & full_mapping to do...
On 2/2/13 3:52 PM, TONGARI wrote:
Hi,
Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ? Also, what will be the container type of the result of "eval" ?
* Conversion function 'as_view' to make Container a view to reserve the mutability.
You mean to make it immutable?
What do you think? Are these already achieved in some way that I didn't aware of?
BTW, I just implemented left_mapping/left_mapped_view, it's used like
result = left_mapping(m1, m2, transform);
For elements not mapped, fusion::void_ is passed to transform.
Still mapping & full_mapping to do...
Awesome! Looking forward to this. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/2/13 3:52 PM, TONGARI wrote:
Hi,
Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::**transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
* Conversion function 'as_view' to make Container a view to reserve the
mutability.
You mean to make it immutable?
No, the opposite, to keep the elements mutable as they were. Algorithms in Fusion take const&, 'as_view' is mean to workaround. Not sure if Fusion will insist on functional-style. What do you think? Are these already achieved in some way that I didn't
aware of?
BTW, I just implemented left_mapping/left_mapped_view, it's used like
result = left_mapping(m1, m2, transform);
For elements not mapped, fusion::void_ is passed to transform.
Still mapping & full_mapping to do...
Awesome! Looking forward to this.
It'll be soon. (but not for the docs :p) Regards
I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::**transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
Why not use for_each [1] instead of transform then? Regards, Nate [1] http://www.boost.org/doc/libs/1_52_0/libs/fusion/doc/html/fusion/algorithm/i...
2013/2/3 Nathan Ridge <zeratul976@hotmail.com>
I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::**transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
Why not use for_each [1] instead of transform then?
"eval" is for those transform-like, not necessary 'transform'. The now implemented mappings are all transform-like. Regards
On 2/3/13 11:50 AM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/2/13 3:52 PM, TONGARI wrote:
Hi,
Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::**transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
Do you have a use-case?
* Conversion function 'as_view' to make Container a view to reserve the
mutability.
You mean to make it immutable?
No, the opposite, to keep the elements mutable as they were. Algorithms in Fusion take const&, 'as_view' is mean to workaround. Not sure if Fusion will insist on functional-style.
No, the opposite. I'm thinking about allowing mutable views. Would you be willing to implement them? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 11:50 AM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/2/13 3:52 PM, TONGARI wrote:
Hi,
Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::****transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
Do you have a use-case?
e.g. eval(mapping(view(dst), src, _1 = _2))
* Conversion function 'as_view' to make Container a view to reserve the
mutability.
You mean to make it immutable?
No, the opposite, to keep the elements mutable as they were. Algorithms in Fusion take const&, 'as_view' is mean to workaround. Not sure if Fusion will insist on functional-style.
No, the opposite. I'm thinking about allowing mutable views. Would you be willing to implement them?
OK, function: view(seq) returns: if seq is view -> seq else -> container_view // in detail or public? Or better name suggestions?
On 2/3/13 4:07 PM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 11:50 AM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/2/13 3:52 PM, TONGARI wrote:
Hi,
Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::****transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
Do you have a use-case?
e.g.
eval(mapping(view(dst), src, _1 = _2))
Sorry, I do not understand that.
* Conversion function 'as_view' to make Container a view to reserve the
mutability.
You mean to make it immutable?
No, the opposite, to keep the elements mutable as they were. Algorithms in Fusion take const&, 'as_view' is mean to workaround. Not sure if Fusion will insist on functional-style.
No, the opposite. I'm thinking about allowing mutable views. Would you be willing to implement them?
OK, function: view(seq) returns: if seq is view -> seq else -> container_view // in detail or public?
Or better name suggestions?
No, I meant: I am considering allowing views to be mutable by allowing algorithms take const&. I suggest starting with a clear use case on a problem that can't be solved (currently) with Fusion and a clear proposal on a solution. It's very possible that I am missing a lot. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 4:07 PM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 11:50 AM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/2/13 3:52 PM, TONGARI wrote:
Hi,
Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::******transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
Do you have a use-case?
e.g.
eval(mapping(view(dst), src, _1 = _2))
Sorry, I do not understand that.
Uh, "view(dst)" is what I proposed to keep dst mutable, and "mapping(...)" is also what I proposed to map the intersected part (like inner join in relational DB), "_1 = _2" may be Phoenix, without "eval", the assignments won't happen. Although the above can be written as: foreach(mapping(view(dst), src, _1 = _2), nop) But that's not elegant and not works with void-return.
* Conversion function 'as_view' to make Container a view to reserve
the
mutability.
You mean to make it immutable?
No, the opposite, to keep the elements mutable as they were. Algorithms in Fusion take const&, 'as_view' is mean to workaround. Not sure if Fusion will insist on functional-style.
No, the opposite. I'm thinking about allowing mutable views. Would you be willing to implement them?
OK, function: view(seq) returns: if seq is view -> seq else -> container_view // in detail or public?
Or better name suggestions?
No, I meant: I am considering allowing views to be mutable by allowing algorithms take const&.
The algorithms currently take const&, even for containers, that's why I need an indirect view to keep the elements mutable. So what do you mean by "allowing views to be mutable" & "allowing algorithms take const&" here? I suggest starting with a clear use case on a problem that can't
be solved (currently) with Fusion and a clear proposal on a solution. It's very possible that I am missing a lot.
FWIW, I adapted GIL pixel as Associative Sequence, trying to find an effective way to manipulate pixels. Regards
Just uploaded to: https://github.com/jamboree/Boost.FusionEx There are: + mapping + left_mapping + full_mapping Simple tests contained. Comments/improvements are welcome :^)
On 2/3/13 9:59 PM, TONGARI wrote:
Just uploaded to:
https://github.com/jamboree/Boost.FusionEx
There are: + mapping + left_mapping + full_mapping
Simple tests contained. Comments/improvements are welcome :^)
By looking at the sample code, it seems I misunderstood your original post by a long shot. Could you please provide some rough text about these algorithms/views by presenting some real world use cases and how these are solved by your additions? Thanks for your patience! Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 9:59 PM, TONGARI wrote:
Just uploaded to:
https://github.com/jamboree/**Boost.FusionEx<https://github.com/jamboree/Boost.FusionEx>
There are: + mapping + left_mapping + full_mapping
Simple tests contained. Comments/improvements are welcome :^)
By looking at the sample code, it seems I misunderstood your original post by a long shot.
How did you understand it then? There's a bit different than what I originally wrote. The first thought was to map-assign the data: mapping(dst, src) And now it's more general: result = mapping(a, b, binary_op_on_data) returns a view which is also associative FWIW, "mapping/left_mapping/full_mapping" are analog to "inner join/left join/full join" in relational DB. Could you please provide some rough text about
these algorithms/views by presenting some real world use cases and how these are solved by your additions?
I intend to do it for mapping between different pixel formats. e.g. gil::rgba8_pixel_t dst; gil::bgra8_pixel_t src; eval(left_mapping(view(dst), src, alpha_blend));
Thanks for your patience!
Thanks
On 2/3/13 11:24 PM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 9:59 PM, TONGARI wrote:
Just uploaded to:
https://github.com/jamboree/**Boost.FusionEx<https://github.com/jamboree/Boost.FusionEx>
There are: + mapping + left_mapping + full_mapping
Simple tests contained. Comments/improvements are welcome :^)
By looking at the sample code, it seems I misunderstood your original post by a long shot.
How did you understand it then?
I guess it's irrelevant how I understood it then. What's important is how I can understand it now and I really want to understand what it is exactly you are trying to achieve.
There's a bit different than what I originally wrote.
The first thought was to map-assign the data:
mapping(dst, src)
And now it's more general:
result = mapping(a, b, binary_op_on_data)
Good idea. But it's better if you can provide both versions. Something similar to filter and filter_if.
returns a view which is also associative
FWIW, "mapping/left_mapping/full_mapping" are analog to "inner join/left join/full join" in relational DB.
Perhaps mapping is not a good name? Then of course, we already have "join".
Could you please provide some rough text about
these algorithms/views by presenting some real world use cases and how these are solved by your additions?
I intend to do it for mapping between different pixel formats.
e.g.
gil::rgba8_pixel_t dst; gil::bgra8_pixel_t src;
eval(left_mapping(view(dst), src, alpha_blend));
I still don't understand "view" and "eval" enough. Pardon me for being slow. It would be best to collect all your thoughts in a single, complete explanation of all these new additions so that we don't have any misunderstandings. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 11:24 PM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 9:59 PM, TONGARI wrote:
Just uploaded to:
https://github.com/jamboree/****Boost.FusionEx<https://github.com/jamboree/**Boost.FusionEx> <https://github.**com/jamboree/Boost.FusionEx<https://github.com/jamboree/Boost.FusionEx>
There are: + mapping + left_mapping + full_mapping
Simple tests contained. Comments/improvements are welcome :^)
By looking at the sample code, it seems I misunderstood your original post by a long shot.
How did you understand it then?
I guess it's irrelevant how I understood it then. What's important is how I can understand it now and I really want to understand what it is exactly you are trying to achieve.
There's a bit different than what I originally wrote.
The first thought was to map-assign the data:
mapping(dst, src)
And now it's more general:
result = mapping(a, b, binary_op_on_data)
Good idea. But it's better if you can provide both versions. Something similar to filter and filter_if.
I don't see how they related. The original one gives an immediate result, while the later is lazily evaluated. filter & filter_if are both lazily evaluated. Are you suggesting a shorthand for mapping(a, b, _2)?
returns a view which is also associative
FWIW, "mapping/left_mapping/full_**mapping" are analog to "inner join/left join/full join" in relational DB.
Perhaps mapping is not a good name? Then of course, we already have "join".
Well, I don't have a better one, do you?
I still don't understand "view" and "eval" enough. Pardon me for being slow. It would be best to collect all your thoughts in a single, complete explanation of all these new additions so that we don't have any misunderstandings.
Maybe I have to implement all these to show what they really are... But I'll try to explain with a simple use-case here: Given: vector<int, string, int> v; How would you assign to the ints in v? foreach(filter<int>(v), _1 = 99); Will that compile? No, you can't assign to read-only value. Why are they read-only? Because filter<int>(v) takes v as 'const&', there's no '&' overload. So how could I do? Make something that takes v by reference, and that's what 'view' is for, and this time foreach(filter<int>(view(v)), _1 = 99); would work. BTW, algorithms in GIL only work for Views, while Fusion takes both Sequence & View, I think it's a good idea to only accept View, but this is not the way that fusion was designed. Regards
On 2/4/13 12:39 AM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 11:24 PM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 9:59 PM, TONGARI wrote:
Just uploaded to:
https://github.com/jamboree/****Boost.FusionEx<https://github.com/jamboree/**Boost.FusionEx> <https://github.**com/jamboree/Boost.FusionEx<https://github.com/jamboree/Boost.FusionEx>
There are: + mapping + left_mapping + full_mapping
Simple tests contained. Comments/improvements are welcome :^)
By looking at the sample code, it seems I misunderstood your original post by a long shot.
How did you understand it then?
I guess it's irrelevant how I understood it then. What's important is how I can understand it now and I really want to understand what it is exactly you are trying to achieve.
There's a bit different than what I originally wrote.
The first thought was to map-assign the data:
mapping(dst, src)
And now it's more general:
result = mapping(a, b, binary_op_on_data)
Good idea. But it's better if you can provide both versions. Something similar to filter and filter_if.
I don't see how they related. The original one gives an immediate result,
What original one?
while the later is lazily evaluated.
what later one? filter & filter_if are both lazily
evaluated. Are you suggesting a shorthand for mapping(a, b, _2)?
returns a view which is also associative
FWIW, "mapping/left_mapping/full_**mapping" are analog to "inner join/left join/full join" in relational DB.
Perhaps mapping is not a good name? Then of course, we already have "join".
Well, I don't have a better one, do you?
Not sure.
I still don't understand "view" and "eval" enough. Pardon me for being slow. It would be best to collect all your thoughts in a single, complete explanation of all these new additions so that we don't have any misunderstandings.
Maybe I have to implement all these to show what they really are... But I'll try to explain with a simple use-case here:
Given:
vector<int, string, int> v;
How would you assign to the ints in v?
foreach(filter<int>(v), _1 = 99);
Will that compile? No, you can't assign to read-only value. Why are they read-only? Because filter<int>(v) takes v as 'const&', there's no '&' overload.
Exactly what I was saying in a previous reply. I am considering allowing mutability (i.e. taking in & arguments). That way, your code above will work as-is.
So how could I do? Make something that takes v by reference, and that's what 'view' is for, and this time
foreach(filter<int>(view(v)), _1 = 99);
would work.
BTW, algorithms in GIL only work for Views, while Fusion takes both Sequence & View, I think it's a good idea to only accept View, but this is not the way that fusion was designed.
Let's take this off-line for discussion. Feel free to reply to me by email. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
participants (3)
-
Joel de Guzman -
Nathan Ridge -
TONGARI