Re: [boost] garbled boostboc output in online docs
Hi Doug, Hmm, I just viewed it with a different browser (Apple's Safari instead of and old version of Netscape on a Sun) and now I see lots of newlines (there were none before). Is this a case of non-portability of a html tag, or a bug in Netscape? Cheers, Jeremy On Monday, August 18, 2003, at 07:28 PM, Douglas Gregor wrote: On Monday 18 August 2003 06:04 pm, Jeremy Siek wrote: The Header section in the following pages is garbled. Looks like a bunch of missing newlines. http://www.boost.org/doc/html/any.reference.html http://www.boost.org/doc/html/function.reference.html -Jeremy Where would you like to see the newlines? Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: garbled boostboc output in online docs
Guess that would be a curiously recurring email subject line ;) On Monday, August 18, 2003, at 08:15 PM, David Abrahams wrote: Subject: Re: garbled boostboc output in online docs ^ Pretty funny.-^ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] garbled boostboc output in online docs
The Header section in the following pages is garbled. Looks like a bunch of missing newlines. http://www.boost.org/doc/html/any.reference.html http://www.boost.org/doc/html/function.reference.html -Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] Proposal to add 'buffer' parameter to dfsalgorithms
Hi Bruce,
Sounds like a good idea to me! Do you want to take a stab at making this
change? Perhaps just DFS to begin with and then the other algorithms
afterwards.
On Thu, 14 Aug 2003, Bruce Barr wrote:
schmoo> template
schmoo> class dfs_traits {
schmoo> typedef typename graph_traits::vertex_descriptor Vertex;
schmoo> typedef typename graph_traits::out_edge_iterator Iter;
schmoo>
schmoo> public:
schmoo> typedef std::pair > buffer_value_type;
schmoo> };
instead of "dfs_traits::buffer_value_type" how about
"dfs_buffer_traits::value_type"
schmoo>
schmoo> The buffer parameter could be added to each of the DFS based algorithms:
schmoo> connected_components(), strong_components(), topological_sort(),
schmoo> depth_first_visit(), and depth_first_search(). Also, non-named parameter
schmoo> overloads could be added to use a buffer parameter.
To preserve backwards compatibility, instead of changing the non-named
parameter overload, I suggest adding another overload (with a longer list
of parameters).
Cheers,
Jeremy
------
Jeremy Siek http://php.indiana.edu/~jsiek/
Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED]
C++ Booster (http://www.boost.org) office phone: (812) 855-3608
--
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Documentation bug in boost::graph
Hi Jarl, On Thu, 14 Aug 2003, Jarl Friis wrote: jarl> Hi. jarl> jarl> On http://www.boost.org/libs/graph/doc/graph_concepts.html the image jarl> http://www.boost.org/libs/graph/doc/figs/concepts.gif jarl> There is a spelling error jarl> jarl> The bottom line says "AdacencyMatrix" it should be "AdjacencyMatrix" Thanks, fixed. jarl> I believe the last template parameter EdgeList is used to determine jarl> return type for the function 'edges(g)' where g is of type jarl> adjacency_list. where as the first one determines the internal jarl> container type for outgoing edges. Am I right? You are right. What happened was that the last EdgeList parameter was added, and the old EdgeList parameter was changed to OutEdgeList, after the html docs and book were written. I've updated the html docs. Regards, Jeremy ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] (newbie)Finding the root of tree
Hi Jonathan, You'll need to be more specific for anyone to help you. How about posting the code (hopefully a page or less) that builds the tree. Cheers, Jeremy On Thu, 14 Aug 2003, Jonathan de Halleux wrote: dehall> I have a tree built with the BGL. I want to find the root of the tree. dehall> dehall> Has anybody an idea on the algorithm I should be using ? thks dehall> ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::array
I believe the intention of the container_facade (which I was calling
ptr_array) was that the initialization would be just of the pointer, so
the array itself would not be copied. The motivation for something like
ptr_array (versus using std::vector) is that sometimes you get chunks of
memory from non-C++ sources (like C or Fortran libraries) and need a way
to deal with them in C++ in an efficient manner.
On Mon, 11 Aug 2003, Alisdair Meredith wrote:
alisda> Robert Ramey wrote:
alisda>
alisda> > const int array[] = {1, 2, 3, 4};
alisda> > boost::container_facade cfa(array, sizeof(array)/sizeof(int));
alisda>
alisda> I guess my problem is I still don't understand what is wrong with
alisda>
alisda> const boost::array< int, 4 > = { 1, 2, 3, 4 };
alisda>
alisda> in this case.
alisda>
alisda> If you are referring to having to dictate the size of the array in
alisda> advance, rather than deduce it, that is a known deficiency and I would
alisda> welcome any solutions for this!
alisda>
alisda> [I have proposed array to the ISO committee and this is one of the
alisda> issues that I suspect may hold back its adoption]
alisda>
alisda>
alisda> As for making the copy above:
alisda> Would a constructor template perform the deduction correctly?
alisda>
alisda> template< typename T, unsigned int N >
alisda> container_facade( const T[N] source )
alisda> {
alisda> std::copy( source, source + N, m_data );
alisda> }
alisda>
--
Jeremy Siek http://php.indiana.edu/~jsiek/
Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED]
C++ Booster (http://www.boost.org) office phone: (812) 855-3608
--
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::array
On Fri, 8 Aug 2003, Dave Gomboc wrote:
dave> >
dave> > const in array{] = {1, 2, 3, 4};
dave> > boost::array ba(array);
dave> > std::copy(ba.begin(), ba.end(), std_ostream_iterator(std::cout));
dave> >
dave> > Is there already a way to do this? Or is there some reason why
dave> > one would never want to do this?
dave>
dave> AFAICR boost::array allows initialization. I would try
dave>
dave> const boost::array ba = {1, 2, 3, 4};
dave> std::copy(ba.begin(), ba.end(), std_ostream_iterator(std::cout));
But he doesn't want coping. There's the simple solution
const int array[] = {1, 2, 3, 4};
std::copy(array, array + 4, ...);
and also there's the array_traits in the sandbox.
However, did he want the exact interface as boost::array? If so, I'd say
we need a new class called ptr_array that adapts a pointer and a size into
an array.
Cheers,
Jeremy
--
Jeremy Siek http://php.indiana.edu/~jsiek/
Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED]
C++ Booster (http://www.boost.org) office phone: (812) 855-3608
--
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] bug in incremental_components examples /documentation
Thanks Janusz. I've checked in the fixes. On Saturday, August 9, 2003, at 12:27 PM, Janusz Piwowarski wrote: Hi all I've found bug in incremental_components examples and documentation. Type _Rank_ is expected to be size_type, but container _rank_ is created from vertex_descriptor. Examples work because adjacency_list VertexList container type is vector. // ... typedef adjacency_list Graph; typedef Graph::vertex_descriptor Vertex; // ... // create the disjoint-sets structure, which requires // rank and parent vertex properties std::vector rank(num_vertices(G)); //^^ std::vector parent(num_vertices(G)); typedef std::vector::iterator Rank; // typedef std::vector::iterator Parent; disjoint_sets ds(rank.begin(), parent.begin()); //... Regards, Janusz ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sudden VC6 ICEs in BGL code
I seem to remember the named parameters mechanism being fragile under VC6. On Wednesday, July 30, 2003, at 08:35 PM, David Abrahams wrote: Recently (I haven't narrowed down when, yet) libs/python/src/object/inheritance.cpp started to produce an INTERNAL COMPILER ERROR on VC6. This file almost exclusively uses the Boost Graph Library; there's almost nothing specific to Boost.Python going on there. The ICE happens, it seems, because of the use of breadth_first_search. In an effort to see what was going on, I made the graph library's own bfs.cpp test compile with BOOST_NO_PARTIAL_SPECIALIZATION; it works on vc7, but (guess what?) ICEs on VC6. Does anyone have a clue what's going on? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [BGL] Proxy Graph ?
Hi David and Dave, On Tue, 27 May 2003, David Abrahams wrote: dave> David Pearce <[EMAIL PROTECTED]> writes: dave> dave> > David, dave> > dave> >> I think I had the same problems when I implemented the reverse_graph dave> >> adaptor, and never found a good answer :( dave> > dave> > Thanks for the reply. Looking at the reverse_graph_adaptor, I notice dave> > that you achieve what I want using the dave> > "reverse_graph_*_property_selector" classes. But, what do these dave> > actually do? Or, put another way, what needs to be implemented to make dave> > get/put work in a similar fashion to that of reverse_graph ? dave> > dave> > Cheers, dave> > dave> > David Pearce dave> dave> I'm afraid all that stuff was added in version 1.10 by Jeremy. He'll dave> have to fill you in. dave> That stuff has to do with accessing the type of an internal property map. The user gets the map's type from the edge/vertex_property_map classes in graph/properties.hpp. These classes then dispatch to the vertex/edge_property_selector which is defined in property.hpp and fully specialized for each graph class in their respective headers. The reason for the extra levels of indirection was to avoid using partial specialization so that this would all work on VC++. As for what you need to do for the proxy graph... the reverse_graph is a good example of what to do. You'll need to do all the same stuff. Cheers, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Graph, Property "patches" and remarks from HP
The graph_type.hpp file gets generated by a test file, in fact, it gets generated over and over again. The purpose is to test the many different variations of the adjacency_list. Cheers, Jeremy On Mon, 17 Feb 2003, David Abrahams wrote: dave> Vladimir Prus <[EMAIL PROTECTED]> writes: dave> dave> > David Abrahams wrote: dave> dave> > 2.1) libs/graph/test/graph_type.hpp dave> > dave> > #line 136 dave> > Graph g; dave> > typedef boost::graph_traits::vertex_descriptor Vertex; dave> > typedef boost::graph_traits::edge_descriptor Edge; dave> > dave> > I have something completely different in this file. dave> dave> Yes, I think they (and you) are being thrown off by their dave> preprocessor. If you look in the archive I posted I think you may dave> find the actual filename nearby. It's surely the .cpp file being dave> compiled. dave> dave> -- dave> Dave Abrahams dave> Boost Consulting dave> www.boost-consulting.com dave> -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BGL: external properties
We currenly do not have a solution for this in the BGL (other than internal properties). I seem to remember LEDA having a solution for this, so you might want to look there for ideas. Cheers, Jeremy On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Well, external properties still confuse me. Assume I want to attach ghost> some data to vertices in adjacency_list. No problem: ghost> ghost> vector< vertex > alternative_s ; ghost> iterator_property_map< vector::iterator, ghost> property_map > alternative = ... ghost> ghost> The problem is that I have to pass alternative_s.begin() when ghost> constructig alternative, but I might want to add new vertices. ghost> In that case the iterator can be invalidated. ghost> ghost> Is there a solution to this problem, except for resorting to internal ghost> properties? ghost> ghost> - Volodya ghost> ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: BGL: graph direction
Adding typedef bidirectionalS bidirectedS; would be fine by me. I just don't want to break current code or docs by removing bidirectionalS. Cheers, Jeremy On Wed, 29 Jan 2003, Jason House wrote: jhouse> I'm not familiar with the details, but could there be a typedef or jhouse> something like that in order to accept bidirectedS? jhouse> Or maybe replacing the bidirectionalS with bidirectedS and making jhouse> bidirectionalS typedef'd to bidirectedS? ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
Hi Volodya, On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Oh.. I only now realized how to use ReabablePropertyGraph concept: ghost> ghost>function_requires< ReadablePropertyGraphConcept >(); ghost> ghost> Are you suggesting that this become ghost> ghost>function_requires< EdgePropertyGraphConcept >(); ghost> ghost> and the same split done to PropertyGraphConcept and LvaluePropertyGraphConcept? I'm not so sure that change is worth it because the Edge/Vertex versions would look exactly the same except for name unless I am mistaken. ghost> I agree. The type basically is a structure, which fields are not named in a ghost> regular C++ way, but are identified by type. A subscript operator can take the ghost> "tag" type and return the value (or reference to it). Lookings at the code, ghost> it seems like this is actually implemented. ghost> BTW the following code does not compile for me at the moment. Is it correct? ghost> ghost> typedef adjacency_list property > > G; ghost> ghost> vertex_property::type p; ghost> // p[vertex_edge_t()] = 10; No, operator[] is not supported for the property class, though it is supported for property maps (I know, the naming here is a bit confusing). ghost> I think the best approach would be to make this concept explicit, and ghost> independent from BGL. Something like ghost> ghost>type_indexed_container< ghost> mpl::list< ghost> pair, ghost> pair > > c; ghost>c[vertex_name_t()] = 10; ghost> I wonder if something like this already exists... I vaguely recall ghost> someone was doing that. Yes, Emily Winch was working on this, and I thought she was going to submit to boost. The following URL has a paper she wrote about this. http://www.oonumerics.org/tmpw01/schedule.html Cheers, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: checking for internal properties
Hi Volodya, I do this kind of checking in the BGL algorithms. Look at the function choose_param in boost/graph/named_function_params.hpp Warning: the code is pretty ugly :( Regards, Jeremy On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Jeremy, ghost> ghost> suppose I got lazy and don't want my graph algorithm to be passed a ghost> graph which does not have internal edge_weight property. What's the ghost> best way to check? I can do ghost> ghost> get(edge_weight, g); ghost> ghost> but that causes compile error in instantination deeps. What I'd like is ghost> something like: ghost> ghost> BOOST_STATIC_ASSERT(has_property::value); ghost> ghost> Is it possible now? If not, is this a reasonable feature? ghost> ghost> - Volodya ghost> ghost> ___ ghost> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ghost> -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: graph direction
Hi Volodya, No reason in particular for the spelling. I'm sorry it is confusing, but it is a bit late to change this now. Cheers, Jeremy P.S. In LEDA "bidirected" means something different than what "bidirectional" means in the BGL. On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Jeremy, ghost> ghost> When declaring adjacency_list, one can specify whether graph is directed or ghost> not, using selectors ghost> ghost> directedS ghost> undirectedS ghost> ghost> and ghost> ghost> bidirectionalS ghost> ghost> No wonder I always try to type "bidirectedS" and get a compile error. ghost> Is there any reason for different naming? No sure which is correct ghost> grammatically, but "bidirected" certainly used. For example, in LEDA ghost> docs: ghost> ghost> http://www.algorithmic-solutions.info/leda_manual/graph.html ghost> ghost> (in the second section). ghost> ghost> What do you think? ghost> ghost> - Volodya -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: concept docs buglets
On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost> ghost> Does it mean that all MutablePropertyGraphConcept instances of docs should ghost> be renamed to LvaluePropertyGraphConcept? ghost> Yes, I think that is correct. Also, I just checked in a fix to LvaluePropertyGraphConcept in graph_concepts.hpp. Cheers, Jeremy ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Errors in Boost.Graph's topological_sort
Hi Christoph,
The problem with your example is that you forgot to initialize the
vertex_index property for each vertex. Perhaps you thought that the
adjacency_list would do this for you. However, this is not the case when
using VertexList=listS. I know this is confusing, but it is stated in the
docs that there is a builtin vertex_index property when VertexList=vecS,
whereas you were using listS.
So you need to add a couple calls to "put" to fix the situation.
u = boost::add_vertex( g );
put(boost::vertex_index, g, u, 0);
v = boost::add_vertex( g );
put(boost::vertex_index, g, v, 1);
Regards,
Jeremy
P.S. You know, it isn't polite to be accusatory before you really know
what the problem is.
On Wed, 19 Dec 2002, Christoph [ISO-8859-1] Kögl wrote:
christ> Hi there,
christ>
christ> I am using 1.29.0 on a Linux PC running Mandrake 8.1, and I am using
christ> gcc-2.96 (GNU CPP version 2.96 2731 (Mandrake Linux 8.1
christ> 2.96-0.62mdk).
christ>
christ> See the following code. Topological sort has all sorts of problems with
christ> directed graphs (using adjacency lists) having two vertices and a single
christ> edge connecting them:
christ>
christ> #include
christ> #include
christ> #include
christ> #include
christ> #include
christ> #include
christ>
christ> typedef
christ> boost::adjacency_list<
christ> boost::listS
christ> , boost::listS
christ> , boost::directedS
christ> , boost::property<
christ> boost::vertex_index_t
christ> , int
christ> >
christ> >
christ> Graph;
christ>
christ> void testing( bool flip )
christ> {
christ> Graph g;
christ> Graph::vertex_descriptor u, v;
christ> u = boost::add_vertex( g );
christ> v = boost::add_vertex( g );
christ> if( flip )
christ> {
christ> boost::add_edge( v, u, g );
christ> }
christ> else
christ> {
christ> boost::add_edge( u, v, g );
christ> }
christ> std::list< Graph::vertex_descriptor > seq;
christ> try
christ> {
christ> boost::topological_sort( g, std::front_inserter( seq ) );
christ> }
christ> catch( const boost::not_a_dag & )
christ> {
christ> std::cout << "G(" << (flip ? "v, u" : "u, v") << ") not a DAG\n";
christ> }
christ> }
christ>
christ> int main( )
christ> {
christ> testing( false );
christ> testing( true );
christ> return 0;
christ> }
christ>
christ> Running this program results in the following output (slightly edited):
christ> > G(u, v) not a DAG
christ> > Speicherzugriffsfehler (German for SIGSEV)
christ> Hence u->v is not a DAG, the top. sorting routine detects a back edge.
christ> BYP?
christ> And the second call get stuck consistently at this point:
christ> template
christ> inline void put(const put_get_helper& pa, K k,
christ> const V& v)
christ> {
christ> static_cast(pa)[k] = v; // Crash occurs here.
christ> }
christ>
christ> Inverting the above function invocation sequence results in the
christ> following
christ> output:
christ> > G(u, v) not a DAG
christ> Same wrong answer, but no crash this time in testing( false ).
christ>
christ> Running only the testing( false ) call results in the same output.
christ>
christ> Boost.Graph's interfaces really appeal to me, they are very cleverly
christ> designed, but I am
christ> unable to use the current implementation in any serious project, since
christ> the above seems to
christ> point to nasty little QOI problems ... It's back to LEDA again, I
christ> suppose ...
christ>
christ> Cheers
christ>
christ> Christoph
christ>
christ> ___
christ> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
christ>
--
Jeremy Siek http://php.indiana.edu/~jsiek/
Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED]
C++ Booster (http://www.boost.org) office phone: (812) 855-3608
--
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BGL: more doc buglets
Hi Volodya, On Sun, 5 Jan 2003, Vladimir Prus wrote: ghost> ghost> I've come across more problems with documentation. ghost> ghost> 1. The docs for topological_sort say that if (u,v) edge is present, ghost> then u comes before v in the topological order. I was assuming ghost> that if I store the order in vector, then u will be found before ghost> v. Instead, the order is reversed! This can only be learned from ghost> the example at the botton -- which is the last place to look at. Yes. ghost> 2. The example for the same function is wrong. The graph has a ghost> 5 -> 5 edge and is not DAG. libs/graph/example/topo_sort.cpp ghost> fails for that reason. Right. ghost> 3. Docs the the same function say that the default value of i_map ghost> parameter is "get(vertex_index, g)". Unless I'm missing something, ghost> this should be "get(vertex_index_t(), g)". No, I think vertex_index is fine. vertex_index_t is an enum with one value in it, namely vertex_index. See properties.hpp. ghost> 4. The docs for the "write_graphviz" function do not mention the ghost> "default_writer" class. I believe they should --- it's important ghost> when one want to output onle edge properties. Yes. ghost> 5. libs/graph/doc/PropertyGraph.html says: ghost> ghost> boost::property_map::type ghost> The type of the property map for the property specified by PropertyTag. ghost> This type must be a model of ReadWritePropertyMap with a key type the same ghost> as the graph's vertex or () descriptor type. ghost> ghost> "edge" is missing in the marked position. Right. ghost> 6. I did not see anywhere the stament that property map obtained from ghost> PropertyGraph are actually a kind of references into the internal ghost> property map. I can conjecure this is so, but a clean statement would ghost> we better. Sure. ghost> It would be nice to fix those problem. In fact, I can fix most of them ghost> myself, if Jeremy doesn't mind. Thanks for all these fixes! Please go ahead and check them in. Regards, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: random_access_iterator_property_map missing?
That's right. The name changed. Sorry! On Sat, 4 Jan 2003, Douglas Gregor wrote: gregod> On Saturday 04 January 2003 11:53 am, Vladimir Prus wrote: gregod> > I was just going to use the class named in the subject. Unfortunately, gregod> > it can't be found anywhere. Here what grep on an up-to-date CVS tree gives: gregod> gregod> You probably want "iterator_property_map", which takes a RandomAccessIterator gregod> and is used throughout the BGL. Maybe it was once called gregod> "random_access_iterator_property_map"? gregod> gregod> Doug gregod> gregod> gregod> ___ gregod> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost gregod> -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL bug in examine_edge(...) indijkstra_shortest_paths.hpp?
Hi Duncan, Sorry for the lagged reply. I think the problem is in the value used for "zero" in file_dependencies.cpp. Since we are using > for comparison, I think "zero" should be std::numeric_limits::max() instead of 0. Cheers, Jeremy On Sun, 22 Dec 2002, Duncan Clarke wrote: duncan> I downloaded the 1_29_0 version of Boost, compiled the file_dependencies.cpp duncan> example, and when I run it, the sample program aborts after throwing duncan> negative_edge in examine_edges(...) (from dijkstra_shortest_paths.cpp). duncan> duncan> After a little investigation, it looks to me like examine_edges(...) is duncan> supposed to protect against negative edge weights. It does so by calling duncan> the user-supplied comparison function to test each edge to make sure its duncan> weight is greater than the user-supplied zero value. But the call in duncan> examine_edges(...) is coded so that "if (EdgeWeight ? 0) then throw duncan> negative_edge()," where the example program uses the ">" operator for "?". duncan> Seems to me that those parameters are presented in the wrong order. duncan> duncan> I downloaded Boost 1_28_0 and the example compiled and ran without problems. duncan> A quick diff showed that the code to test for negative edge weights is new duncan> in BGL 1_29_0. duncan> duncan> So... is it a feature or a bug? duncan> duncan> I checked through all the boost newsgroups and couldn't find anything about duncan> this, but I'm new to Boost, so forgive me (and point me to the resolution) duncan> if this is a known problem. duncan> duncan> Thanks, duncan> duncan> Duncan Clarke duncan> Computer Science and Engineering duncan> University of South Carolina duncan> duncan> duncan> -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: concept docs buglets
Hi Volodya, On Sun, 5 Jan 2003, Vladimir Prus wrote: ghost> ghost> I think that BGL concept docs are a little bit out of sync with ghost> the concept cheking code. I've corrected some of problems and ghost> attach a patch. Is it OK to apply it? Yes, those corrections look fine. ghost> Another issue is that doc talk about MutablePropertyGraphConcept, ghost> while code has LvaluePropertyGraphConcept. I'm not sure which one ghost> is correct. Looks like the stuff in the code is correct and the docs are out of date. Cheers, Jeremy ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
Hi Volodya, On Tue, 10 Dec 2002, Vladimir Prus wrote: ghost> Looking at BGL's MutablePropertyGraph docs I can't understand ghost> two things: ghost> ghost> ep is an object of type G::edge_property_type ghost> ghost> Is that really so? Why not graph_traits::edge_property_type? Actually, I think it really should be edge_property::type and vertex_property::type. Also MutablePropertyGraph should be split into VertexMutablePropertyGraph and EdgeMutablePropertyGraph. The BGL book is more up-to-date than the online-docs, so I'd look there for the final story. If you see discrepencies between the online-docs and the book, feel free to update the html to match the book. ghost> Unfortunately, this description says nothing about that concept ghost> these types model. As the result, I don't know how can I ghost> use 'add_edge' and 'add_vertex' as defined in MutablePropertyGraph. ghost> ghost> Can it be clarified? Yes, that is a problem. We need some more concepts for this. If you're dealing with an adjacency_list you know that they are nested instances of the property class, but this doesn't help generic code. I'm not sure how this could be made generic... maybe if we hade a concept that covered what the property class does (BTW, a better name for the property class would be static_alist). Also, it would be good to have a notion of what copying these objects does. Any help on solving the above problems would be welcomed! Cheers, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Equivalence Relation class
It still would be nice to have the underlying disjoint sets (union/find) data structure as an official boost library. On Fri, 17 Jan 2003, Jeffrey Yasskin wrote: jyassk> > Isn't this functionality equivalent to the dynamic connected components jyassk> > in the Boost graph library? jyassk> > jyassk> > Miro jyassk> jyassk> Oops. Yes. Never mind. jyassk> jyassk> Jeffrey ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Equivalence Relation class
Hi Jeffrey, I think so. union/find is used in the Boost Graph Library, and there is an implementation of it, in boost/pending/disjoint_sets.hpp. The reason it is in pending is that I've never bothered to write docs and submit it to boost. Anyways, it would be interesting to compare the interface and implementation to what you've got. And if you're interested in championing the addition of union/find to boost I'd be behind you. Cheers, Jeremy On Thu, 16 Jan 2003, Jeffrey Yasskin wrote: jyassk> I have a small class that uses the union/find algorithm to jyassk> implement a dynamic equivalence relation. With some work, it could jyassk> probably also be used to iterate through the equivalent partition. jyassk> jyassk> Would this be a good thing to add to boost? jyassk> jyassk> Jeffrey Yasskin jyassk> jyassk> jyassk> ___ jyassk> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost jyassk> ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost Graph Library: Beginner question: Serialize
Hi Loic, Take a look at boost/graph/adjacency_list_io.hpp and libs/graph/example/adjacency_list_io.cpp. Also there are functions to read and write graphs in the graphviz format... though the primary reason for that format is for creating postscript displays of graphs, not for persistence. Cheers, Jeremy On Tue, 14 Jan 2003, loic d'Anterroches wrote: moteur> Hello, moteur> moteur> After looking into the mailing list archives, the documentation moteur> and over the net, I haven't find the answer to my question, that moteur> is why I ask you. moteur> moteur> I want to save a graph in a file to restore the state of my moteur> algorithm later. For example I have a graph with complete family moteur> (like in family-tree-eg.cpp) I want to save it, then restore it to moteur> add new members. I am coming from FORTRAN, so the objects are not moteur> so complex, it is quite easy to save matrix etc... Here, how to moteur> serialize my graph with the properties attached to edge and vertix moteur> easily? Like the serialization process of MFC (I am using VC++ 6)? moteur> I feel a little bit stupid, especially because, it seams that moteur> nobody has asked this question before! moteur> moteur> Thank you for your help, moteur> loic d'Anterroches ------ Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Concept Check tests
Hi Dave, You're right, they should be compile-file, not link-fail. Cheers, Jeremy P.S. Sorry for the delayed response. Currently in the end-of-the-semester grind. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator_adaptors
Hi Herve, --On Tuesday, November 19, 2002 1:21 AM -0500 Herve Bronnimann <[EMAIL PROTECTED]> wrote: Just because I posted something about a new iterator adaptor, and I happened to take a look at the boost sandbox, that David was referring me to, I'd like to ask: is what is in the sandbox intended to replace or to complement the current ? Yes, it is intended to replace the current iterator_adaptors.hpp. The reason I am asking is that a brief reading failed to point out how what's in the sandbox provides reverse_iterator_adaptor, and all the existing ones. So am I correct in assuming that the code in the sandbox is intended to replace some/all the machinery (first 700 lines or so) of the current ? that it's internal to the implementation of the adaptors? and that we'll be able to use in the future the iterator adaptors unchanged in syntax and semantic? No, the sandbox stuff is just incomplete and very much under construction. And it will have a different public interface from the old version. Thomas, have you checked your new version in yet? Cheers, Jeremy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::graph - incorrect answers withdikjstra_shorts_paths
Hi Marc, I don't have time to look at this right now, but I'll try to get to it this weekend. Regards, Jeremy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Property_map docs
Hi Edward, What you say below is an excellent suggestion, and I'll add that to the introduction in the docs for property map. Best Regards, Jeremy --On Thursday, November 14, 2002 4:23 PM -0500 Edward Diener <[EMAIL PROTECTED]> wrote: I would still say to anyone willing to listen that the doc should spell this out, ie. "all these concepts are for you the implementor to put together to create the generic functions that work using the categories mentioned. There is no implementation here." If I had read that I might still have been interested in the concepts as pure ideas, but I would have probably moved on pretty quickly, or further looked into the BGL to see what was a practical implementation of this concept, but I would not have posted anything here regarding the doc which I clearly didn't understand and couldn't make heads or tails out of. It was my frustration about reading the pieces of what I though was an implementation, and not having any idea how these pieces were supposed to fit together to form some sort of reality, that led to my frustration and initial post. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Property_map docs
Hi Edward, Since you feel so strongly about this, please write a new version of the property map docs and send them to me. In future emails, I would appreciate it if you refrained from using such an accusatory tone. At this point I'm feeling hurt by your words and discouraged about volunteering my time to boost. Sincerely, Jeremy On Mon, 11 Nov 2002, Edward Diener wrote: eddiel> "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message eddiel> news:Pine.GSO.4.44.021110230.4424-10@;zaphod.osl.iu.edu... eddiel> > Hi Edward, eddiel> > eddiel> > On Sun, 10 Nov 2002, Edward Diener wrote: eddiel> > eddiel> OK, here are some questions regarding the property map library; eddiel> > eddiel> eddiel> > eddiel> 1) What is a property map ? Is it a template class, a class, a eddiel> > eddiel> template function, a function ? eddiel> > eddiel> > It is a "concept", as the term is used in the SGI STL docs: eddiel> > http://www.sgi.com/tech/stl/stl_introduction.html eddiel> > It has to do with specifying the contract between generic algorithms eddiel> > (function templates) and the user of such algorithms. eddiel> eddiel> I am aware of your defintion of "concept" from Matt Austern's fine book. But eddiel> concepts imply implementations. eddiel> eddiel> > eddiel> > If you were looking for some useful concrete component to implement some eddiel> > kind of mapping, then I'm afraid you will be disappointed in the property eddiel> > map library. eddiel> eddiel> I am disappointed in the doc. The concept sounds interesting but I have no eddiel> idea how it is implemented or used in a real situation. eddiel> eddiel> > eddiel> > eddiel> 2) What does the word "property" mean in the context of the name ? eddiel> > eddiel> > Here by property we mean something that is associated with some object. I eddiel> > know this is vague, but there just is not much to the property map eddiel> > concept. eddiel> eddiel> Yes, it is vague. Does that make you happy about it ? eddiel> eddiel> > eddiel> > eddiel> 3) What is the difference between property map and std::map<> ? eddiel> > eddiel> > std::map<> is a class. property map is a concept (well, a collection eddiel> > of concepts). You can use the boost::associative_property_map eddiel> > adaptor to adapt std::map<> into a type that *models* property map. eddiel> eddiel> OK, why not explain that in the doc and how it is done. eddiel> eddiel> > eddiel> > eddiel> 4) How does one use a property map ? eddiel> > eddiel> > You write function templates with template parameters that eddiel> > have property map as their requirement. eddiel> eddiel> Example of this in the doc please. eddiel> eddiel> > eddiel> > eddiel> 5) How does one create a property map of one's own ? eddiel> > eddiel> > Create a class and then define get(), put() and operator[] eddiel> > function for the class. eddiel> eddiel> Example of this in the doc please. eddiel> eddiel> > eddiel> > eddiel> 6) What are the prototypes for the get(), put(), and operator[] eddiel> > eddiel> functions, and are these really global functions as the doc eddiel> > eddiel> suggests or are they functions in the boost namespace ? eddiel> > eddiel> > They can live anywhere that argument dependent lookup can find them, which eddiel> > means just about anywhere. eddiel> eddiel> You didn't answer the first question. eddiel> eddiel> > eddiel> > eddiel> 7) What do the various categories actually do for property maps ? eddiel> > eddiel> > Like the iterator tags in the C++ std, they allow function templates to eddiel> > dispatch to different code depending on the category of the property map. eddiel> eddiel> Example of this in the doc please, with some function template showing this eddiel> technique as practical usage within your "concept". eddiel> eddiel> > eddiel> > eddiel> I do not believe that any of these questions are answered clearly eddiel> > eddiel> in the property map documentation although they are all basic eddiel> > eddiel> points which should be explained to the end user. I know there is eddiel> > eddiel> a concept there of mapping keys to values but beyond that the eddiel> > eddiel> documentation seems abstruse at best and needlessly irritating at eddiel> > eddiel> worst. eddiel> > eddiel> eddiel> > eddiel> Please Boosters , think about explaining your ideas to the eddiel> > eddiel> programming world in ways that they understand and can use, rather e
Re: [boost] Re: Property_map docs
Hi Edward, On Sun, 10 Nov 2002, Edward Diener wrote: eddiel> OK, here are some questions regarding the property map library; eddiel> eddiel> 1) What is a property map ? Is it a template class, a class, a eddiel> template function, a function ? It is a "concept", as the term is used in the SGI STL docs: http://www.sgi.com/tech/stl/stl_introduction.html It has to do with specifying the contract between generic algorithms (function templates) and the user of such algorithms. If you were looking for some useful concrete component to implement some kind of mapping, then I'm afraid you will be disappointed in the property map library. eddiel> 2) What does the word "property" mean in the context of the name ? Here by property we mean something that is associated with some object. I know this is vague, but there just is not much to the property map concept. eddiel> 3) What is the difference between property map and std::map<> ? std::map<> is a class. property map is a concept (well, a collection of concepts). You can use the boost::associative_property_map adaptor to adapt std::map<> into a type that *models* property map. eddiel> 4) How does one use a property map ? You write function templates with template parameters that have property map as their requirement. eddiel> 5) How does one create a property map of one's own ? Create a class and then define get(), put() and operator[] function for the class. eddiel> 6) What are the prototypes for the get(), put(), and operator[] eddiel> functions, and are these really global functions as the doc eddiel> suggests or are they functions in the boost namespace ? They can live anywhere that argument dependent lookup can find them, which means just about anywhere. eddiel> 7) What do the various categories actually do for property maps ? Like the iterator tags in the C++ std, they allow function templates to dispatch to different code depending on the category of the property map. eddiel> I do not believe that any of these questions are answered clearly eddiel> in the property map documentation although they are all basic eddiel> points which should be explained to the end user. I know there is eddiel> a concept there of mapping keys to values but beyond that the eddiel> documentation seems abstruse at best and needlessly irritating at eddiel> worst. eddiel> eddiel> Please Boosters , think about explaining your ideas to the eddiel> programming world in ways that they understand and can use, rather eddiel> than in metaprogramming terminology which only a select few know. eddiel> Good documentation is as important, in its own way, as good code. I've taken another look at the docs, and I'm afraid I do not see a lot of room for improvement. The docs say pretty much what I said above, and include links to resources where one can learn more about generic programming. The property map library is by nature abstract. The main point of the library is not to provide concrete classes, but instead to describe a whole family of classes so that they can be used interchangeably in function templates (generic algorithms). The property map library is for generic programming, and is described using the terminology of generic programming. If you aren't doing generic programming, then you don't need the property map library. Regards, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
