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:
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?
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>
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
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
It'll be soon. (but not for the docs :p) Regards
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...
On 2/3/13 11:50 AM, TONGARI wrote:
Do you have a use-case?
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
On 2/3/13 4:07 PM, TONGARI wrote:
Sorry, I do not understand that.
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>
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.
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:
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>
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:
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.
Good idea. But it's better if you can provide both versions. Something similar to filter and filter_if.
Perhaps mapping is not a good name? Then of course, we already have "join".
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>
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)?
Well, I don't have a better one, do you?
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:
What original one?
while the later is lazily evaluated.
what later one? filter & filter_if are both lazily
Not sure.
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.
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