From cfd01185d2d7bcfa8b3184bed5c813a1caf12e6a Mon Sep 17 00:00:00 2001
From: Marin Tomic <marin.tomic@memgraph.io>
Date: Fri, 27 Oct 2017 10:27:59 +0200
Subject: [PATCH] create public readme for elliott

Reviewers: buda

Reviewed By: buda

Subscribers: pullbot

Differential Revision: https://phabricator.memgraph.io/D936
---
 .../elliott/{README.md => README_internal.md} |  6 +--
 customers/elliott/README_public.md            | 54 +++++++++++++++++++
 2 files changed, 57 insertions(+), 3 deletions(-)
 rename customers/elliott/{README.md => README_internal.md} (94%)
 create mode 100644 customers/elliott/README_public.md

diff --git a/customers/elliott/README.md b/customers/elliott/README_internal.md
similarity index 94%
rename from customers/elliott/README.md
rename to customers/elliott/README_internal.md
index cbddc4864..a5d4cd419 100644
--- a/customers/elliott/README.md
+++ b/customers/elliott/README_internal.md
@@ -26,7 +26,7 @@ Now we initialize the values of all other nodes in the graph:
 
 Change the value of a leaf:
 
-    MATCH (u:Leaf {id: "9"}) SET u.value = 10
+    MATCH (u:Leaf {id: "18"}) SET u.value = 10
 
 We have to reset all the updated nodes to a neutral element:
 
@@ -45,12 +45,12 @@ There are a few assumptions made worth pointing out.
   of vertices in the graph.
 
 * It is possible to accumulate the value of the function.  Formally: 
-  $$f(x_1, x_2, ..., x_n) = g(...(g(g(x_1, x_2), x_3), ...), x_n).$$
+  $$f(x_1, x_2, ..., x_n) = g(...(g(g(x_1, x_2), x_3), ...), x_n)$$
 
 * There is a neutral element for the operation. However, this
   assumption can be dropped by introducing an artificial neutral element.
 
-Number of operations required is proportional to sum of degrees of affected
+Number of operations required is proportional to the sum of degrees of affected
 nodes.
 
 We generated graph with $10^5$ nodes ($20\ 000$ nodes in each layer),  varied the
diff --git a/customers/elliott/README_public.md b/customers/elliott/README_public.md
new file mode 100644
index 000000000..70eb1d548
--- /dev/null
+++ b/customers/elliott/README_public.md
@@ -0,0 +1,54 @@
+We tried generating a few sample graphs from the description given at
+the in-person meetings.  Then, we tried writing queries that would solve
+the problem of updating nodes when a leaf value changes, assuming all the
+internal nodes compute only the sum function.
+
+We started by creating an index on `id` property to improve initial lookup
+performance:
+
+    CREATE INDEX ON :Leaf(id)
+
+Afther that, we set values of all leafs to 1:
+
+    MATCH (u:Leaf) SET u.value = 1
+
+We then initialized the values of all other nodes in the graph:
+
+    MATCH (u) WHERE NOT u:Leaf SET u.value = 0
+
+    MATCH (u) WITH u
+    ORDER BY u.topological_index DESC
+    MATCH (u)-->(v) SET u.value = u.value + v.value
+
+Leaf value change and update of affected values in the graph can
+be done using three queries. To change the value of a leaf:
+
+    MATCH (u:Leaf {id: "18"}) SET u.value = 10
+
+Then we had to reset all the affected nodes to the neutral element:
+
+    MATCH (u:Leaf {id: "18"})<-[* bfs]-(v)
+    WHERE NOT v:Leaf SET v.value = 0
+
+Finally, we recalculated their values in topological order:
+
+    MATCH (u:Leaf {id: "18"})<-[* bfs]-(v)
+    WITH v ORDER BY v.topological_index DESC
+    MATCH (v)-->(w) SET v.value = v.value + w.value
+
+There are a few assumptions necessary for the approach above to work.
+
+* We are able to maintain topological order of vertices during graph
+  structure changes.  
+
+* It is possible to accumulate the value of the function.  Formally: 
+  $$f(x_1, x_2, ..., x_n) = g(...(g(g(x_1, x_2), x_3), ...), x_n)$$
+
+* There is a neutral element for the operation. However, this
+  assumption can be dropped by introducing an artificial neutral element.
+
+Above assumptions could be changed, relaxed or dropped, depending on the
+specifics of the use case.
+
+Number of operations required is proportional to the sum of degrees of affected
+nodes.