JOAQUIN M. LOPEZ MUÑOZ wrote:

First of all, you're defining a multi_index_container of *lists*, i.e. each element of the container is a list of triplets (value,x,y). Is this what you really meant, or maybe the std::list part has to be dropped?

Thank you. Yes, I'll drop the list. Each element should only be (value,x,y); Grateful, Etienne

JOAQUIN M. LOPEZ MUÑOZ wrote:

________________________________________ De: boost-users-bounces@lists.boost.org [boost-users-bounces@lists.boost.org] En nombre de Etienne Philip Pretorius [icewolfhunter@gmail.com] Enviado el: domingo, 26 de abril de 2009 16:17 Para: boost-users@lists.boost.org Asunto: Re: [Boost-users] Multi Index: Nested std::pair

JOAQUIN M. LOPEZ MUÑOZ wrote:

...

...

First of all, you're defining a multi_index_container of *lists*, i.e. each element of the container is a list of triplets (value,x,y). Is this what you really meant, or maybe the std::list part has to be dropped? Thank you. Yes, I'll drop the list. Each element should only be (value,x,y);

OK, let's analyze the problem then. For the sake of brevity we first introduce the following typedef:

typedef std::pair< /*value*/ unsigned char, std::pair< /*x co-ordinate*/ unsigned char, /*y co-ordinate*/ unsigned char >

...

value_type;

The value extractor can be specified using boost::multi_index::member:

boost::multi_index::member< value_type, unsigned char, &value_type::first

...

As for x and y, there is no way to do it with predefined extractors and we have to write our own custom key extractor (http://tinyurl.com/dafk2f ):

struct x_extractor { typedef unsigned char result_type; result_type operator()(const value_type& x)const { return x.second.first; } };

struct y_extractor { typedef unsigned char result_type; result_type operator()(const value_type& x)const { return x.second.second; } };

So the final declaration looks like this:

boost::multi_index_container< value_type, boost::multi_index::indexed_by< /*value*/ boost::multi_index::ordered_non_unique< boost::multi_index::member< value_type, unsigned char, &value_type::first > >, /*x co-ordinate*/ boost::multi_index::ordered_non_unique, /*y co-ordinate*/ boost::multi_index::ordered_non_unique >

...

m;

Nevertheless, I don't see any good reason why you have to define your elements using such a convoluted combination of std::pairs. You can have it in a more user friendly way, say:

struct value_type { value_type(unsigned char value,unsigned char x,unsigned char y): value(value),x(x),y(y){} unsigned char value; unsigned char x; unsigned char y; };

which allows us you to define your multi_index_container without resorting to custom key extractors:

boost::multi_index_container< value_type, boost::multi_index::indexed_by< /*value*/ boost::multi_index::ordered_non_unique< boost::multi_index::member< value_type, unsigned char, &value_type::value > >, /*x co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::member< value_type, unsigned char, &value_type::x > >, /*y co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::member< value_type, unsigned char, &value_type::y > > >

...

m;

HTH.

Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Thank you!

It is starting to make sense. Just what I needed :). Etienne

/*unique values per x co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::x >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > > > > matrix_t;

How would I define the "unique values per x co-ordinate" as there x co-ordinate is suppose to be non unique while value in this key should ONLY point to unique instances within that x co-ordinate?

Would this work? /*unique values per x co-ordinate*/ boost::multi_index::ordered_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::x >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > > As it is not clear in the documentation what the "boost::multi_index::ordered_unique" scope is. IE is it the combination of the defined members (member vs member) of is it based on the first and then on the second (first vs first, second vs second). Etienne

Etienne Philip Pretorius escribió:

Etienne Philip Pretorius wrote:

...

...

/*unique values per x co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::x >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > > > > matrix_t;

How would I define the "unique values per x co-ordinate" as there x co-ordinate is suppose to be non unique while value in this key should ONLY point to unique instances within that x co-ordinate?

Would this work?

/*unique values per x co-ordinate*/ boost::multi_index::ordered_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::x >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > >

As it is not clear in the documentation what the "boost::multi_index::ordered_unique" scope is. IE is it the combination of the defined members (member vs member) of is it based on the first and then on the second (first vs first, second vs second).

The above does not seem to be correct as the algo does not succeed. Could someone please give me advise on constructing a key that has duplicate ("x" || "y") members while unique "values".

Hi Etienne, Could you please elaborate on what is meant by "unique values"? This is not clear to me from the explanations on your previous posts. It might help to state your requirements in the reverse way: what kind of duplications involving value should be banned from the container? For instance, the ordered_unique index you show us above bans duplicate elements having the same form (x,*,value), where * indicates that the y member is immaterial here. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

Etienne Philip Pretorius escribió:

...

Hi Etienne,

Could you please elaborate on what is meant by "unique values"? This is not clear to me from the explanations on your previous posts. It might help to state your requirements in the reverse way: what kind of duplications involving value should be banned from the container? For instance, the ordered_unique index you show us above bans duplicate elements having the same form (x,*,value), where * indicates that the y member is immaterial here.

Hello Joaquín,

I am doing a matrix operation where I need to know the number of unique values per x co-ordinate and number of unique values per y co-ordinate.

N-th row, x=N, but how many unique "values" are there in this row? N-th column, y=N, but how many unique "values" are there in the column?

Hi Etienne, I'm not compleetely sure I'm getting you, but let me try. If by unique values you simply mean all the elements with given x coordinate, you can write: std::size_t values_with_x(const matrix_t& m,unsigned char x) { return m.get<1>().count(x); } However, if you're after elements with a given x coordinate having *distinct* values, you can define your container as typedef boost::multi_index_container< element_t, boost::multi_index::indexed_by< /*value*/ boost::multi_index::ordered_non_unique< boost::multi_index::member< element_t, unsigned char, &element_t::value > >, /*x co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::x >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > >, /*y co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::y >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > > >

matrix_t;

and write the following: std::size_t distinct_values_with_x(const matrix_t& m,unsigned char x) { typedef matrix_t::nth_index<1>::type index_t; typedef index_t::iterator iterator; std::pair p=m.get<1>().equal_range(x); std::size_t res=0; while(p.first!=p.second){ ++res; p.first=m.get<1>(). upper_bound(boost::make_tuple(p.first->x,p.first->value)); } return res; } Does this approach your goal? Please find attached a complete test program. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo #include #include #include #include #include <iostream> struct element_t { element_t( unsigned char value, unsigned char x, unsigned char y ):value(value),x(x),y(y){} unsigned char value; unsigned char x; unsigned char y; }; typedef boost::multi_index_container< element_t, boost::multi_index::indexed_by< /*value*/ boost::multi_index::ordered_non_unique< boost::multi_index::member< element_t, unsigned char, &element_t::value > >, /*x co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::x >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > >, /*y co-ordinate*/ boost::multi_index::ordered_non_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::y >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > > >

matrix_t;

std::size_t values_with_x(const matrix_t& m,unsigned char x) { return m.get<1>().count(x); } std::size_t distinct_values_with_x(const matrix_t& m,unsigned char x) { typedef matrix_t::nth_index<1>::type index_t; typedef index_t::iterator iterator; std::pair p=m.get<1>().equal_range(x); std::size_t res=0; while(p.first!=p.second){ ++res; p.first=m.get<1>(). upper_bound(boost::make_tuple(p.first->x,p.first->value)); } return res; } int main() { matrix_t m; m.insert(element_t(0,0,0)); m.insert(element_t(0,0,0)); m.insert(element_t(1,0,0)); m.insert(element_t(1,0,0)); m.insert(element_t(2,0,0)); m.insert(element_t(4,0,0)); std::cout<

Does this approach your goal? Please find attached a complete test program.

Just a quick thought... Would this approach not be slow? As the program needs to run through all the values on every loop to find *distinct* values per row/column. If I had 65536 (256 rows by 256 columns) elements in the container, it would have been nice if I could have the container indexed it in such a way as what you proposed. The container could then effectively used a caching mechanism, because if I delete a row then all columns are effected but only one row is effected (the one I deleted), likewise if it was a column that I deleted. So at most 257 values would have to updated. The serious overhead comes when I delete per value but that is the cost of the algo and there is nothing that can be done for it. Grateful, Etienne.

Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

------------------------------------------------------------------------

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hello list, I'm using fs::recursive_directory_iterator(path), when the path given by 'path' does not exist, an exception will be thown with the message similar to the following: error: boost::filesystem::basic_directory_iterator constructor: the given directory not found: "any\path\that\does\not\exist" I want to depress the part that is added by the lib: " boost::filesystem::basic_directory_iterator constructor:" How can I do? I've searched the archive and the doc but not found an answer. Thanks for help. B/Rgds Max

Hello Ovanes, Thanks for your reply. You means like this? catch ( const fs::basic_filesystem_errorfs::path& e ) { // transform e.what() to a new string by search and replace // rethrow an exception } That would be ok for this single case. But who knows if there's other similar cases that need this similar hand-written code processing? I want to depress the similar message in a uniform way. B/Rgds Max From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ovanes Markarian Sent: Wednesday, April 29, 2009 8:49 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [filesystem] Hoe to depress boost::filesystem::basic_directory_iterator constructor? Hi! what about catching the exception and rethrowing your own one? Greetings, Ovanes

And of course you can catch these some layers higher and transform these exceptions into the needed ones. e.g. void scan_directories(fs::path const& path) { //.... } void do_smth() { //... } void foo() { scan_directories("c:“); } void rethow_my_exception(std::exception const& e) { //could be throw std::logic_error(std::string("execution failed: ").append(e.what())); } //you can even overload rethrow_my_exception for different formattings void bar() { try { foo(); do_smth(); } catch(std::exception const& e) { rethrow_my_exception(e); } } As you see, there are no limits. Good Luck, Ovanes On Wed, Apr 29, 2009 at 4:26 PM, Ovanes Markarian wrote:

On Wed, Apr 29, 2009 at 3:20 PM, Max wrote:

...

Hello Ovanes,

Thanks for your reply.

You means like this?

catch ( const fs::basic_filesystem_errorfs::path& e ) { // transform e.what() to a new string by search and replace // rethrow an exception }

That would be ok for this single case. But who knows if there's other similar cases that need this similar hand-written code processing? I want to depress the similar message in a uniform way.

You can also catch more general exceptions like: boost::system_error or std::runtime_error or std::exception (or any other unknown exception via catch(...) )

And handle them...

Regards, Ovanes

               boost::multi_index::ordered_unique<                    boost::multi_index::composite_key<                        element_t,                        boost::multi_index::member<                            element_t,                            unsigned char,                            &element_t::x                        >,                        boost::multi_index::member<                            element_t,                            unsigned char,                            &element_t::value                        >                    >                >

As it is not clear in the documentation what the "boost::multi_index::ordered_unique" scope is.

The scope is the key you define under "ordered_unique". In the above example you define a unique key that consists of (x, value). I.e., the container would disallow duplicate (x, value) pair.

Igor R wrote:

...

boost::multi_index::ordered_unique< boost::multi_index::composite_key< element_t, boost::multi_index::member< element_t, unsigned char, &element_t::x >, boost::multi_index::member< element_t, unsigned char, &element_t::value > > >

As it is not clear in the documentation what the "boost::multi_index::ordered_unique" scope is.

The scope is the key you define under "ordered_unique". In the above example you define a unique key that consists of (x, value). I.e., the container would disallow duplicate (x, value) pair. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hello list, You see I need all the values in the container, but I only perform operations on a subset based on the least amount of unique values per row or per column. The problem is, when I recode the algo to build up the relationship on every iteration and the destroy it when it goes out of scope and then update the contents of the container based on the selected column or row - causes too much computational overhead as I am testing every element in every row or column rather then only ones that should qualify (unique values per row or column). The container builds up the relationships defined, when it is populated, and then adjusts it as modifications occur to the contents, allowing me not to have to worry about the book keeping of the relationships. It should also be faster as lifetime of the container holds the relationships relevant and are re-evaluated on change of the containers contents rather than build up and destroyed the relationship on every iteration. Kind Regards, Etienne