ENH: default read scaling from slope dtype

The apply_read_scaling routine was previously ignoring the dtype of
slope and inter when choosing the floating point type to scale with.
This change makes sure that the floating point type chosen for scaling
has precision at least as high as the input slope dtype.
NF - add best_float function

Function to select floating point type with highest precision, avoiding
useless np.longdouble type on windows.
RF: use best_float instead of np.longdouble

Refactor to use float64 instead of np.longdouble on systems (?only
windows) in which np.longdouble is no more capable than float64.
NF - add able_int_type function

Function selects integer type capable of representing all passed values

Numpy doesn't itself try and minimize the integer type so able_int_type
has to do this the slow way.

Confirm able_int_type corresponds to numpy casting.
NF - add ulp function (cf. matlab eps function)

Function to return gap between value and nearest representable value of
same type.

Use ``ulp`` instead of ``eps` because the wikipedia article pointed out
the different meanings possible for eps:

http://en.wikipedia.org/wiki/Machine_epsilon#Variant_definitions
NF - add assert_dt_equal testing function

Tests whether two simple dtypes are equal, allowing for int32 != intp
case (on 32 bit)
ENH: add integer to integer offset-only cases

Add offset-only special case to scaling, to keep maximum precision.
RF: make floor_exact like np.floor, add ceil_exact

Floor exact previously floored towards 0. This was unlike np.floor,
which finds the nearest integer <= val.

Added ceil_exact function (nearest exact integer >= val).

Infs from floor / ceil_exact return infs (previously pulled infs down to
float max)

Consider -+ infs in shared_range calculation (now infs not removed by
floor / ceil_exact).
BF - high value comparisons hit float error

Found using the round trip tester - high values for min or max were
hitting floating point error in comparisons, and comparing equal when
they were not.
RF: check fp error in offset for offset scaling

When trying to scale integers only with inter, we need to make sure the
inter as cast to the scaling type does in fact keep the integers in the
range of the output type.  We also want to make sure that inter
generates numbers with the smallest possible absolute magnitude to
avoid floating point error in the resulting numbers.
BF: adapt arraywriter tests to new offset scaling

Tests tested previous behavior of offset scaling. New offset scaling
also gives valid scaling, so adapt tests to results from new scaling.
TEST: add round trip tests

With some investigation, identify the causes of small errors for the
round trip tests, add reasonable default thresholds.
BF: untested windows, PPC float fixes broken

Was returning results of a dict update, which were obviously None, thence
crashes loading modules.
BF: direct comparison of numpy types failing

Replace with comparison against numpy dtype kinds.
BF: increase relative error threshold for win32o

Test was failing with very small relative error values; increase threshold by 2
- it is very low.
BF: account for float rouding in 64 bit (u)ints

Input / output of int64 -> uint64 and uint64 -> int64 need to go through
floating point types as they are stored and loaded.  If the best floating point
type is not capable of 64 bits of integer precision, there will be rounding
error; we need to take this into account.
Merge pull request #115 from matthew-brett/int_uint_futz

Improving int to int scaling and adding roundtrip tests

After discussion on the mailing list, use various tricks to make int to int scaling more accurate.

Add functions useful for estimating floating point error.

Avoid using useless windows 32 longdouble because it gives no higher precision.

Make roundtrip tests with fairly rational bounds on error.

Check and fix on windows 32 and 64 bit, PPC.