From 4a58a07688db026d93a82d1281b95614f89d11af Mon Sep 17 00:00:00 2001
From: Axel Marmoret <axel.marmoret@inria.fr>
Date: Fri, 5 Feb 2021 17:40:48 +0100
Subject: [PATCH] Fixing some typos/errors
---
Notebooks/Tutorial - Handling polytopes.ipynb | 23 +++++++++++--------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/Notebooks/Tutorial - Handling polytopes.ipynb b/Notebooks/Tutorial - Handling polytopes.ipynb
index af6e40d..1d1d79c 100644
--- a/Notebooks/Tutorial - Handling polytopes.ipynb
+++ b/Notebooks/Tutorial - Handling polytopes.ipynb
@@ -135,7 +135,7 @@
"metadata": {},
"source": [
"### Irregularities in practice\n",
- "In practice, we need to define a modus operandis for irregularities. This is made by encoding the positions which need to be altered with \"codes\", which are lists of booleans (0 or 1).\n",
+ "In practice, we need to define a modus operandis to construct the irregularities. This is made by encoding the location of additions or deletions in the pattern. This encoding is in fact two lists of booleans (0 or 1) which we call codes.\n",
"\n",
"Codes are constructed to indicate where and how many positions need to be altered. Even though each element in the polytope can be specified by dichotomy (by construction, by concatenating two polytopes when increasing the dimension, see part \"Antecedents\"), **the goal of codes here is not to indicate individually each position which need to be altered**. \n",
"\n",
@@ -768,7 +768,7 @@
"metadata": {},
"source": [
"# Indexing elements, antecedents and successors\n",
- "In this part, we will focus on linking and accessing to elements in the pattern. More particularily, we will focus on the paradigm developed by C. Guichaoua [1]. In this paradigm, elements are studied in comparison with the previous ones. In that sense, we need to know the position of each element, and to be able to compare this position with others.\n",
+ "In this part, we will focus on linking and accessing elements in the pattern. More particularily, we will focus on the paradigm developed by C. Guichaoua [1]. In this paradigm, elements are studied in comparison with the previous ones. In that sense, we need to know the position of each element, and to be able to compare this position with others.\n",
"\n",
"**Disclaimer: as we need to access to particular elements, all patterns will have to be indexed ones.**\n",
"\n",
@@ -800,11 +800,16 @@
"\n",
"With recursion, we can find every element with as much booleans as the dimension of the polytope.\n",
"\n",
- "<img src=\"imgs/index_gif.gif\" width=\"700\"/>\n",
- "\n",
+ "<img src=\"imgs/index_gif.gif\" width=\"700\"/>"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
"A special case appears for additions in the polytope, because we need to specify which element on the added edge we are studying. Similarly to addition in patterns, we use tuples to indicate which element we are looking at. To remain consistent with the dichotomy principle, the tuple contains two booleans, the first one indicating the position of the edge in the last dimension (as for any other element), and the second representing the position of the element on the edge (0 for left, *i.e.* the original element, and 1 for the right, *i.e.* the added element).\n",
"\n",
- "Using a tuple has the advantage of specifying we're dealing with an addition not another dimension, which could be hard to differentiate otherwise. In addition, indexed still contains $d$ elements (with $d$ the dimension), with the last element being a tuple with two booleans rather than a unique boolean.\n",
+ "Using a tuple has the advantage of specifying that we're dealing with an addition, and not another dimension. In addition, indexes still contains $d$ elements (with $d$ the dimension), with the last element being a tuple with two booleans rather than a unique boolean.\n",
"\n",
"<img src=\"imgs/indexes_examples.png\" width=\"700\"/>\n",
"\n",
@@ -898,15 +903,15 @@
"## Antecedents and successors\n",
"A new concept, defined in [1], is the **antecedent** of an element.\n",
"\n",
- "Looking at a polytope as an oriented graph, edges become oriented arrows, oriented in chronological order ($a_0$ → $a_1$). In this example, $a_0$ is originating an arrow pointing towards $a_1$. $a_0$ is called \"antecedent\" of $a_1$, and $a_1$ is called \"successor\" of $a_0$.\n",
+ "Looking at a polytope as an oriented graph, edges become oriented arrows, oriented in chronological order ($a_0$ → $a_1$). In this example, $a_0$ is spawning an arrow pointing towards $a_1$. $a_0$ is called \"antecedent\" of $a_1$, and $a_1$ is called \"successor\" of $a_0$.\n",
"\n",
- "Hence, the antecedents of an element are all elements originating an arrow pointing towards them, and the successors of an element are the destination of all arrows they originate.\n",
+ "Hence, the antecedents of an element are all elements spawning an arrow pointing towards them, and the successors of an element are the tip of all arrows they spawn.\n",
"\n",
"For instance, in the following polytope, $a_3$ has two antecedents ($a_1$ and $a_2$), $a_4$ has one ($a_3$) and $a_5$ has one ($a_0$).\n",
"\n",
"<img src=\"imgs/dim_3_add_100_del_001.png\" width=\"200\"/>\n",
"\n",
- "> NB: the definition of antecedents in [1] is wider, including every element originating an oriented *path* to the current one. In that definition, $a_0$ would be antecedent of every element. We didn't followed this definition and restricted ourselves with \"direct\" antecedents, *i.e.* element originating a direct arrow with the current element.\n",
+ "> NB: the definition of antecedents in [1] is wider, including every element originating an oriented *path* to the current one. In that definition, $a_0$ would be antecedent of every element. We didn't followed this definition and restricted ourselves with \"direct\" antecedents, *i.e.* element spawning a direct arrow with the current element.\n",
"\n",
"Antecedents of an elements can be computed using the functions ``get_antecedents_from_element`` or ``get_antecedents_from_idx`` depending or whether the studied element is in the form of an element (element 1, 2, 3, etc) or as an index."
]
@@ -1104,7 +1109,7 @@
"source": [
"This work has been extended to irregular polytopes, and can be used with the function `generate_ppp`, starting from an indexed pattern.\n",
"\n",
- "> This extension is not explained here, but is in [TODO: Add My Own Reference] (not released yet, so this document should be updated with the reference when available). In two words, the idea is to define the interesting faces with different couples of edges (seen as vectors), and compute polytope through these faces. In that sense, alteration does not change the paradigm, and are permuted too.\n",
+ "> This extension is not explained here, but is in [TODO: Add My Own Reference] (not released yet, so this document should be updated with the reference when available). In a nutshell, the idea is to define the interesting faces with different couples of edges (seen as vectors), and compute polytope through these faces. In that sense, alteration does not change the paradigm, and are permuted too.\n",
"\n",
"An example of PPP on an irregular polytope is presented in the figure below:\n",
"\n",
--
GitLab