RF: use wrappers for getting type information

Getting the min and max of the big float type goes bad on PPC; use our
own wrappers to avoid the problem.
BF: make integer tests safe for python 2

Longs can appear in place of integers, especially on Windows.  Use
compatible test for (int, long) or (int,) depending on python version.
RF: use abstract base class for integer check

Use numbers.Integer base class to check for integer instances.
DOC: update python and library dependencies

We depend on Python 2.6 and pydicom 0.9.7.
Merge pull request #223 from matthew-brett/int-long-check-fix

BF: make integer tests safe for python 2

Longs can appear in place of integers, especially on Windows. Use compatible
test for (int, long) or (int,) depending on python version.
BF: remove intercept only iuint-iuint scaling

Short version: remove conditional branch trying to preserve precision on
writing arrays by keeping working type as an integer type.

The advantages to removal are:

* fixing a bug for explicit scaling in `array_to_file`
* making the code simpler to think about

The disadvantages are:

* minor loss in precision for int64 / int64 output types.
* float output type rather than integer output type when reading images
  where this scaling trick could be used.

Long version:

``int`` means signed integer type
``uint`` means unsigned integer type
``iuint`` refers to set of all signed and unsigned integer types

When writing data to file, in `volumeutils.array_to_file`.

If:

* input type is iuint
* output type is iuint
* slope is 1
* integer is not 0 and is an integer

Then:

* Working type calculated by `volumeutils._inter_type`
* intercept cast to working type

Here is the relevant code from 1.3.0::

    # (u)int to (u)int with inter alone - select precision
    if (slope == 1 and inter != 0 and
        in_dtype.kind in 'iu' and out_dtype.kind in 'iu' and
        inter == np.round(inter)): # (u)int to (u)int offset only scaling
        # Does range of in type minus inter fit in out type? If so, use that as
        # working type.  Otherwise use biggest float for max integer precision
        inter = inter.astype(_inter_type(in_dtype, -inter, out_dtype))

The problem arises from the sign flip in the line above. Let's call the internal
intercept value in `_inter_type` : `minter` (minus inter in this case).  Define:

* `in_min = np.iinfo(in_dtype).min`
* `in_max = np.iinfo(in_dtype).max`

Looking at `_inter_type`, we will get a returned uint type if all of `in_min +
minter`, `in_max + minter`, `in_min`, `in_max`, `minter` are > 0.
If `_inter_type` returns uint as working type and `inter` is negative, then the
last line above will cast a negative number into a positive one and cause a
mess.

The problem then arises only when:

* input type is uint (in_min = 0)
* `inter` is negative
* output_type is larger than input type (`in_max + minter` > `in_max`)

See appended script for demonstration.

This is clearly a problem for `array_to_file` - but is it a problem for the
image reading / writing prior to the recent pull request allowing arbitrary
scaling?

Then the question is: is there any calculated scaling that results in:

* uint input type
* negative intercept
* larger iuint output type?

But - if the input type is uint and smaller then the output type, then it can
and will cast to the output type, so calculating scaling between these types
will never generate a negative intercept.  See the assert in appended script for
demonstration.

The problem doesn't arise for ``volumeutils.apply_read_scaling``, even though
we are using `_inter_type`.  This is because we pass `inter` to `_inter_type`
rather than `-inter`.  Because we are checking `minter` in `_inter_type`, and
this will be negative, we can't get a uint return type for a negative intercept.

<script>
""" Demonstrating the scaling problem
"""
from __future__ import print_function

from itertools import product

import numpy as np

import nibabel.volumeutils as vu
import nibabel.arraywriters as na

ints = np.sctypes['int']
uints = np.sctypes['uint']
iuints = ints + uints

def do_inter_type(in_type, inter, out_type):
    inter = np.atleast_1d(inter).astype(np.float)
    return vu._inter_type(in_type, -inter, out_type)

def has_problem(in_type, inter, out_type):
    scaling_type = do_inter_type(in_type, inter, out_type)
    return inter < 0 and np.dtype(scaling_type).kind == 'u'

print("Combinations generating uint scaling problem")
print('in type', 'out_type', 'inter', 'castable')
for in_type in iuints:
    i_min, i_max = np.iinfo(in_type).min, np.iinfo(in_type).max
    for out_type in iuints:
        problem = False
        for inter in (i_min-1, i_min, -1, 1, i_max):
            if not has_problem(in_type, inter, out_type):
                continue
            problem = True
            print(in_type, out_type, inter, np.can_cast(in_type, out_type))
        if not problem:
            continue
        # Show we can't get a negative intercept scaling between these types
        in_values = (i_min, 0, i_max)
        for values in product(in_values, in_values):
            arr = np.array(values, dtype=in_type)
            writer = na.SlopeInterArrayWriter(arr, out_type)
            assert (writer.slope, writer.inter) == (1, 0)
</script>
RF: adapt round trip tests to loss of int scaling

Now we've removed the offset-only scaling code, we're not promoting the
large integers to the biggest float type for conversion between integer
types.  Adapt the test to take this into account.
TST: test structarr->float cast if numpy allows

Don't test structarr to float cast if numpy does not allow it.
Merge pull request #222 from matthew-brett/intercept-scaling

MRG: remove intercept only iuint-iuint scaling

Fix bug in array_to_file for negative slopes converting from uints to other integer types.

This involves dropping an optimization where we used the largest double for int64 <-> uint64 conversion to keep integer precision.

See commit comments for detail.
BF: array to 1D to avoid bus error on SPARC

2D and larger dimension arrays of complex numbers causing bus error on
numpy 1.4.1 - probabably from bug
https://github.com/numpy/numpy/issues/2668

Go to 1D to work round this error.
RF: simplify and clarify scaling tests

Scaling tests were testing an undefined cast (of NaN to int); use 0
instead of NaN so the behavior is defined or test for cast value of NaN
directly.
BF: copy numpy config list so as not to change it

Use copy of numpy global variable so we don't change it accidentally.
NF: get_unscaled method for Analyze array proxy

Add get_unscaled for those of us who like to get the raw unscaled data
from the array.
TST: tests for read_img_data function

Test the behavior of the `read_img_data` function as of commit 6d8f6c6.
This is before the changes to Analyze image types to make the header
slope, intercept and data offset be consumed during write, and reset to
default values.  These tests pass against that commit but fail against
current master, which is 62f4c70.
RF: replicate read_img_data behavior + deprecate

Do approximate replication of the old behavior of read_img_data.

Deprecate with suggestions about alternatives.
RF: allow generic header to specify memory layout

Just in case someone needs the generic header to write in C order rather
than F order.
BF: fix invalid call to parent in minc classes

It was possible to call `data_from_fileobj` and `data_to_fileobj` from a
generic Header object, and the MINC classes use that object, so these
could cause confusion by making invalid calls.  Raise
NotImplementedError to reduce potential confusion.
RF: bdist_wheel, bdist_mpkg as setuptools commands

Make sure setup uses setuptools for specialized setup commands needing
setuptools.
Merge pull request #226 from matthew-brett/remove-minc-header-data-fetch

MRG: fix invalid call to parent in minc classes

Prevent invalid call to the minc header-like class.
Merge pull request #225 from matthew-brett/generalize-header-data-layout

RF: allow generic header to specify memory layout

Header base class can specify C as well as Fortran memory layout.