DOC: Correct some typos in numexpr documentation

doc/Makefile

@@ -22,7 +22,7 @@ help:
 	@echo "  singlehtml to make a single large HTML file"
 	@echo "  pickle     to make pickle files"
 	@echo "  json       to make JSON files"
-	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  htmlhelp   to make HTML files and an HTML help project"
 	@echo "  qthelp     to make HTML files and a qthelp project"
 	@echo "  applehelp  to make an Apple Help Book"
 	@echo "  devhelp    to make HTML files and a Devhelp project"

doc/intro.rst

@@ -32,7 +32,7 @@ expression is not compiled to machine code, you will have a big case statement
 (or a bunch of if's) inside the loop, which adds a large overhead for each
 element, and will hurt the branch-prediction used on the CPU.
 
-:code:`numexpr` uses a in-between approach. Arrays are handled as chunks (of
+:code:`numexpr` uses an in-between approach. Arrays are handled as chunks (of
 4096 elements) at a time, using a register machine. As Python code,
 it looks something like this::
 

doc/make.bat

@@ -23,7 +23,7 @@ if "%1" == "help" (
 	echo.  singlehtml to make a single large HTML file
 	echo.  pickle     to make pickle files
 	echo.  json       to make JSON files
-	echo.  htmlhelp   to make HTML files and a HTML help project
+	echo.  htmlhelp   to make HTML files and an HTML help project
 	echo.  qthelp     to make HTML files and a qthelp project
 	echo.  devhelp    to make HTML files and a Devhelp project
 	echo.  epub       to make an epub

doc/mkl.rst

@@ -13,7 +13,7 @@ simple expressions.  One is a pure algebraic one: :code:`2*y + 4*x` and the othe
 contains transcendental functions: :code:`sin(x)**2 + cos(y)**2`.
 
 For this, we are going to use this worksheet_.  I (Francesc Alted) ran this
-benchmark on a Intel Xeon E3-1245 v5 @ 3.50GHz. Here are the results when
+benchmark on an Intel Xeon E3-1245 v5 @ 3.50GHz. Here are the results when
 not using MKL::
 
     NumPy version: 1.11.1

doc/user_guide.rst

@@ -176,7 +176,7 @@ namely:
     * In operations implying a scalar and an array, the normal rules of casting
       are used in NumExpr, in contrast with NumPy, where array types takes
       priority.  For example, if :code:`a` is an array of type :code:`float32`
-      and :code:`b` is an scalar of type :code:`float64` (or Python :code:`float`
+      and :code:`b` is a scalar of type :code:`float64` (or Python :code:`float`
       type, which is equivalent), then :code:`a*b` returns a :code:`float64` in
       NumExpr, but a :code:`float32` in NumPy (i.e. array operands take priority
       in determining the result type).  If you need to keep the result a