BUG: SparseArray numeric ops misc fixes

[sinhrks]

• no existing issue
• tests added / passed
• passes git diff upstream/master | flake8 --diff
• whatsnew entry

Fixed following 3 issues occurred on the current master.

1. addition ignores rhs fill_value

pd.SparseArray([1., 1.]) + pd.SparseArray([1., 0.], fill_value=0.)
# [2.0, nan]
# Fill: nan
# IntIndex
# Indices: array([0], dtype=int32)

Expected:
# [2.0, 1.0]

2. mod raises AttributeError

pd.SparseArray([1, 1]) % pd.SparseArray([1, np.nan])
# AttributeError: 'module' object has no attribute 'sparse_nanmod'

3. pow outputs incorrect result wiht 1.0 ** np.nan

pd.SparseArray([1., 1.]) ** pd.SparseArray([1., np.nan])
# [1.0, nan]
# Fill: nan
# IntIndex
# Indices: array([0], dtype=int32)

Expected:
# [1.0, 1.0]

# NumPy result
np.array([1., 1.]) ** np.array([1, np.nan])
# array([ 1.,  1.])

[jreback]

so this begs the question of why we don't just always pass the fill values to the ufuncs (e.g. sparse_sub etc), which can then decide (based on np.isnan or (isnull better)) on left and/or rhs whether to use it?

[sinhrks]

Yes removing nanop simplifies the logic. Because data is sparse, it shouldn't affect to performance in most cases.

[jreback]

do you want to do that in this PR?

[sinhrks]

Yes, let me try.

[jreback]

whoosh you blew away lots of code. must have been work-arounds built in there for maybe an old cython or something. Just want to be sure (since tests were removed) everything still working (as may not be testing some of the numeric ops as much, though did see you added some tests)

[sinhrks]

The removed test calls _nan funcs which is no longer exists, and remaining logic is tested with _op_tests below. I'm willing to add more tests if you have anything.

[jreback]

thanks!