Merged regiongraph.* and daialg.* from SVN head,
[libdai.git] / STATUS
diff --git a/STATUS b/STATUS
index 5b19fe5..a532b03 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -10,6 +10,9 @@ class ExtFactorGraph : public FactorGraph {
        // blabla
 }
 A disadvantage of this approach may be worse cachability.
+A problem is if there are nog properties for nodes (type 1), nodes (type 2)
+or edges. Maybe this can be solved using specializations, or using variadac
+template arguments or something similar?
 - 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?
@@ -17,9 +20,10 @@ A disadvantage of this approach may be worse cachability.
   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?
+- Add iterations (like maxdiff, but counts iterations) to some algorithms
+- A DAIAlg<T> should not inherit from a FactorGraph/RegionGraph, but should store a
+reference to it
 
 TODO FOR RELEASE:
 - Test Visual C++ compatibility
@@ -54,21 +58,20 @@ 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
+prob.h
 factorgraph.h
 factorgraph.cpp
 regiongraph.h
 regiongraph.cpp
-
 daialg.h
 daialg.cpp
+
+FILES IN SVN HEAD THAT ARE STILL RELEVANT:
+ChangeLog
+README
+TODO
+
 bp.h
 bp.cpp
 hak.h