doc fixes

Author: segasai

docs/source/dynamic.rst

@@ -40,7 +40,7 @@ We can illustrate this directly using the same example from
     # Define our 3-D correlated multivariate normal log-likelihood.
     C = np.identity(ndim)
     C[C==0] = 0.95
-    Cinv = linalg.inv(C)
+    Cinv = np.linalg.inv(C)
     lnorm = -0.5 * (np.log(2 * np.pi) * ndim +
                     np.log(np.linalg.det(C)))
 

docs/source/faq.rst

@@ -261,40 +261,6 @@ with (3) a large number of varying live points can make the stopping criteria
 difficult to evaluate quickly. See 
 :ref:`Nested Sampling Errors` for additional details.
 
-**I'm trying to sample using gradients but getting extremely poor performance.
-I thought gradients were supposed to make sampling more efficient!
-What gives?**
-
-While gradients are extremely useful in terms of substantially improving
-the scaling of most sampling methods with dimensionality (gradient-based
-methods have better polynomial scaling than non-gradient slice sampling, both
-of which are *substantially* better over the runaway exponential scaling
-of random walks), it can take a while for these benefits to really kick in.
-These scaling arguments generally ignore the constant prefactor, which
-can be quite large for many gradient-based approaches that require
-integrating along some trajectory, often resulting in (at least) dozens of
-function calls per sample. This often makes it more efficient to run simpler
-sampling techniques on lower-dimensional problems. In general, Nested Sampling
-methods are also unable to exploit gradient-based information to the same
-degree as Hamiltonian Monte Carlo approaches, which further degrades
-performance and scaling relative to what you might naively expect.
-
-If you feel like your performance is poorer than expected even given these
-caveats, or if you notice other results that make you highly suspicious of the
-resulting samples, please double-check the :ref:`Sampling with Gradients`
-page to make sure you've passed in the correct log-likelihood gradient and are
-dealing with the unit cube Jacobian properly. Failing
-to apply this (or applying it twice) violates conservation of energy and
-momentum and leads to the integration timesteps along the trajectories
-changing in undesirable ways. 
-It's also possible the numerical errors in the Jacobian (if you've set
-`compute_jac=True`) might be propagating through to the computed trajectories.
-If so, consider trying to compute the analytic Jacobian by hand to reduce
-the impact of numerical errors.
-
-If you still find subpar performance, please feel free to 
-`open an issue <https://github.com/joshspeagle/dynesty/issues>`_.
-
 
 Live Point Questions
 --------------------

docs/source/quickstart.rst

@@ -140,7 +140,7 @@ define the :meth:`loglikelihood` and :meth:`prior_transform` functions::
     # Define our 3-D correlated multivariate normal log-likelihood.
     C = np.identity(ndim)
     C[C==0] = 0.95
-    Cinv = linalg.inv(C)
+    Cinv = np.linalg.inv(C)
     lnorm = -0.5 * (np.log(2 * np.pi) * ndim +
                     np.log(np.linalg.det(C)))
 
@@ -452,7 +452,7 @@ of parallelizing is using a dynesty provided pool (which is a thin wrapper aroun
 python's multiprocessing pool)::
 
     with Pool(10, loglike, ptform) as pool:
-        sampler = NestedSampler(pool.loglikehood, pool.prior_transform,
+        sampler = NestedSampler(pool.loglikelihood, pool.prior_transform,
 	                        ndim, pool = pool)
 	sampler.run_nested()
 
@@ -470,7 +470,7 @@ pickling of those arguments::
                                     logl_kwargs=logl_kwargs,
 				    ptform_args=ptform_args,
 				    ptform_kwargs=ptform_kwargs) as pool:
-        sampler = NestedSampler(pool.loglikehood, pool.prior_transform,
+        sampler = NestedSampler(pool.loglikelihood, pool.prior_transform,
 	                        ndim, pool = pool)
 	sampler.run_nested()