minor cleaning of bayesflow 1.0 to 2.0 notebook

Author: paul-buerkner

examples/2.0_Changes.ipynb renamed to examples/From_BayesFlow_1.0_to_2.0.ipynb

@@ -4,16 +4,18 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "# Moving from Bayesflow 1.0 to 2.0"
+    "# Moving from Bayesflow 1.0 to 2.0\n",
+    "\n",
+    "_Author: Leona Odole_"
    ]
   },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Current users of bayesflow will notice that with the update to 2.0 many things have changed and this short guide aims to clarify those changes. Users familiar with the previous Quickstart guide will notice that it  follows a similar structure but assumes that users are already familiar with bayesflow so omits many of the the mathematical explaination in favor of demonstrating the differences in workflow. For a more detailed explaination of any of the bayesflow framework, users should read the linear regresion example notebook. \n",
+    "Older users of bayesflow will notice that with the update to version 2.0 many things have changed. This short guide aims to clarify those changes. Users familiar with the previous Quickstart guide will notice that it follows a similar structure, but assumes that users are already familiar with bayesflow. So we omit many of the the mathematical explaination in favor of demonstrating the differences in workflow. For a more detailed explaination of any of the bayesflow framework, users should read, for example, the linear regresion example notebook. \n",
     "\n",
-    "Additionally to avoid confusion, when necessary similarly named objects from _bayesflow1.0_ will have 1.0 after their name, whereas those from _bayesflow2.0_ will not. Finally a short table with a summary of the function call changes is provided at the end of the guide. "
+    "Additionally to avoid confusion, similarly named objects from _bayesflow1.0_ will have 1.0 after their name, whereas those from _bayesflow2.0_ will not. Finally, a short table with a summary of the function call changes is provided at the end of the guide. "
    ]
   },
   {
@@ -81,7 +83,7 @@
     "\n",
     "def likelihood_model(theta, n_obs):\n",
     "    x = np.random.normal(loc=theta, size=(n_obs, theta.shape[0]))\n",
-    "    return dict(x=x)\n"
+    "    return dict(x=x)"
    ]
   },
   {
@@ -107,7 +109,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Whereas the new framework directly uses the likelihood and prior functions directly in the simulator. We also a define a meta function which allows us to dynamically set the batch size. "
+    "Whereas the new framework directly uses the likelihood and prior functions directly in the simulator. We also a define a meta function which allows us, for example, to dynamically set the number of observations per simulated dataset. "
    ]
   },
   {
@@ -116,7 +118,7 @@
    "metadata": {},
    "outputs": [],
    "source": [
-    "def meta(batch_size):\n",
+    "def meta():\n",
     "    return dict(n_obs=1)\n",
     "\n",
     "simulator = bf.make_simulator([theta_prior, likelihood_model], meta_fn=meta)"
@@ -146,7 +148,7 @@
    "source": [
     "### 2. Adapter and Data Configuration\n",
     "\n",
-    "In _bayesflow2.0_ we now need to specify the data configuration. For example we should specify which variables are `summary_variables` meaning observations that will be summarized in the summary network, the `inference_variables` meaning the prior draws on which we're interested in training the posterior network and the `inference_conditions` which specify our number of observations. Previously these things were inferred from the type of network used, but now they should be defined explictly with  the `adapter`. This allows users to ???  "
+    "In _bayesflow2.0_ we now need to specify the data configuration. For example we should specify which variables are `summary_variables` meaning observations that will be summarized in the summary network, the `inference_variables` meaning the prior draws on which we're interested in training the posterior network and the `inference_conditions` which specify our number of observations. Previously these things were inferred from the type of network used, but now they should be defined explictly with  the `adapter`. The new approach is much more explicit and extensible. It also makes it easier to change individual settings, while keeping other settings at their defaults."
    ]
   },
   {
@@ -224,7 +226,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Previously the actual training and amortization was done in two steps with two different objects the `Amortizer1.0` and `Trainer1.0` . First users would create an amortizer containing the summary and inference networks."
+    "Previously the actual training and amortization was done in two steps with two different objects the `Amortizer1.0` and `Trainer1.0`. First, users would create an amortizer containing the summary and inference networks."
    ]
   },
   {
@@ -266,7 +268,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Whereas previously a  `Trainer1.0` object for training, now users call fit on the `approximator` directly. For additional flexibility in training the `approximator` also has two additional arguments the `learning rate` and `optimizer`. The optimizer can be any keras optimizer."
+    "Whereas previously a  `Trainer1.0` object for training, now users call fit on the `approximator` directly. For additional flexibility in training the `approximator` also has two additional arguments the `learning_rate` and `optimizer`. The optimizer can be any keras optimizer."
    ]
   },
   {
@@ -283,7 +285,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Users must then compile the `approximator` in oder to ??? "
+    "Users must then compile the `approximator` with the `optimizer` to make everything ready for training."
    ]
   },
   {
@@ -323,7 +325,7 @@
    "source": [
     "## 5.Diagnostics \n",
     "Another change was made in the model diagnostics, much of the functionality remains the same, but the naming convention has changes. For example previously users would plot losses by using \n",
-    "`bf.diagnostics.plot_losses()` in bf 2.0 we instead have all the plotting function group together in `bf.diagnostics.plots` which means the corresponding function in 2.0 is `bf.diagnostics.plots.loss()`."
+    "`bf.diagnostics.plot_losses()`. In *bayesflow2.0*, we instead have all the plotting function grouped together in `bf.diagnostics.plots`. This means, for example, that the loss function is now in `bf.diagnostics.plots.loss()`."
    ]
   },
   {
@@ -341,42 +343,23 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "This was done as we have also added diagnostic metrics such as calibration error, posterior contraction, and root mean squared error. These functions can accordingly be found in `bf.diagnostics.metrics` but for more information please see the API.  "
+    "This was done as we have also added diagnostic metrics such as calibration error, posterior contraction, and root mean squared error. These functions can accordingly be found in `bf.diagnostics.metrics`. For more information please see the documentation."
    ]
   },
-  {
-   "cell_type": "markdown",
-   "metadata": {},
-   "source": [
-    "# Other New Features? "
-   ]
-  },
-  {
-   "cell_type": "markdown",
-   "metadata": {},
-   "source": []
-  },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
     "# Summary Change Table \n",
     "\n",
-    "| 1.0      | 2.0 Useage |\n",
+    "| Bayesflow 1.0      | Bayesflow 2.0 useage |\n",
     "| :--------| :---------| \n",
     "| `Prior`, `Simulator` | Defunct and no longer standalone objects but incorporated into `simulator` | \n",
     "|`GenerativeModel` | Defunct with it's functionality having been taken over by `simulations.make_simulator` | \n",
     "| `training.configurator` | Functionality taken over by `Adapter` | \n",
     "|`Trainer` | Functionality taken over by `fit` method of `Approximator` | \n",
     "| `AmortizedPosterior`| Renamed to `Approximator` | "
    ]
-  },
-  {
-   "cell_type": "code",
-   "execution_count": null,
-   "metadata": {},
-   "outputs": [],
-   "source": []
   }
  ],
  "metadata": {