- Idea: a FactorGraph and a RegionGraph are often equipped with extra properties for nodes and edges. The code to initialize those is often quite similar; maybe this can be abstracted to classes like ExtFactorGraph and ExtRegionGraph (Ext stands for Extended), e.g. template class ExtFactorGraph : public FactorGraph { public: std::vector nodeProps; std::vector > edgeProps; // blabla } A disadvantage of this approach may be worse cachability. - BipartiteGraph::isConnected should be optimized. - http://www.boost.org/development/requirements.html#Design_and_Programming - Would it be a good idea to cache second-order neighborhoods (delta's) in BipGraph? - Would it be a good idea to add the variable label -> index hashmap in FactorGraph, to replace the linear searches that are performed every time for findVar()? No, a better idea is to avoid calls to findVar() as much as possible. - Can the FactorGraph constructors be optimized further? - Solve the proliferation of type checks for all different ENUM's in properties.cpp - Remove x2x? TODO FOR RELEASE: - Test Visual C++ compatibility - Figure out which libraries are required and document in README boost headers, boost::program_options library, boost::graph library, boost::math library (under Windows) - Change email address FILES IN SVN HEAD THAT ARE NO LONGER RELEVANT FOR GIT MASTER: diffs.h index.h util.h util.cpp bipgraph.h weightedgraph.h weightedgraph.cpp clustergraph.h clustergraph.cpp varset.h var.h utils/createfg.cpp exceptions.h exceptions.cpp enum.h doxygen.conf example.cpp FILEFORMAT Makefile exact.h exact.cpp alldai.h alldai.cpp properties.h properties.cpp FILES IN SVN HEAD THAT ARE STILL RELEVANT: ChangeLog README TODO prob.h factor.h factor.cpp factorgraph.h factorgraph.cpp regiongraph.h regiongraph.cpp daialg.h daialg.cpp bp.h bp.cpp hak.h hak.cpp jtree.h jtree.cpp lc.h lc.cpp mf.h mf.cpp mr.h mr.cpp treeep.h treeep.cpp matlab/* tests/* utils/* DOCUMENTATION READY: - bipgraph.h, bipgraph.cpp - var.h