MAINT: special: Replace manually written wrappers with autogenerated ones

[pv]

Replace the manually written special._cephes ufunc definitions by an automatic one, generated from a concise description. This should make the whole thing easier to maintain.

Docstrings are moved to a separate Python file, which is used on autogeneration-time.

The autogeneration actually generates the wrappers in Cython --- this allows easier integration of Cython code, and removes the need to add new bloated modules. (This should also make things easier if we ever go back to the .NET port.) I collapsed the existing Cython-written ufuncs to this system.

Tests appear to pass. However, this might need some additional testing, since the test coverage of scipy.special is not very good.

[rgommers]

There was a question on the list a few weeks ago by Eric Moore about the orthogonal_eval functions, he wanted to do pretty much what you did here AFAIK. Maybe worth replying to it.

[rgommers]

Does this change the supported combinations of types?

[pv]

I think it may possibly change the supported types compared to previous.

Based on my understanding of _cephesmodule.c, this type of casts were used for many of the functions, to guarantee that float32 would be preserved even if computations were internally done in float64, and to allow floats given as inputs for integer parameters. This last one would silently truncate the results to integers, rather than raising an error message.

[rgommers]

int --> float now raising an error might be a small backwards compatibility issue, but if we advertise and test this well it should probably be OK.

[rgommers]

Looks like a very useful change. Also allows writing docstrings in a sane way. Will do some testing later.

[rgommers]

Two failures on Ubuntu 12.04:

======================================================================
FAIL: test_obl_ang1_cv (test_basic.TestCephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rgommers/Code/scipy/scipy/special/tests/test_basic.py", line 355, in test_obl_ang1_cv
    assert_almost_equal(result[0],1.0)
  File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 460, in assert_almost_equal
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 7 decimals
 ACTUAL: nan
 DESIRED: 1.0

======================================================================
FAIL: test_pro_ang1_cv (test_basic.TestCephes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rgommers/Code/scipy/scipy/special/tests/test_basic.py", line 388, in test_pro_ang1_cv
    array((1.0,0.0)))
  File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 800, in assert_array_almost_equal
    header=('Arrays are not almost equal to %d decimals' % decimal))
  File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 605, in assert_array_compare
    chk_same_position(x_id, y_id, hasval='nan')
  File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 588, in chk_same_position
    raise AssertionError(msg)
AssertionError: 
Arrays are not almost equal to 6 decimals

x and y nan location mismatch:
 x: array([ nan,  nan])
 y: array([ 1.,  0.])

[pv]

I don't see these failures on Ubuntu 12.10.

[pv]

Ok, the failures were caused by wrong signatures, these should be fixed in d776abc. (Interestingly, they occurred in tests for different functions due to FP stack corruption.)

I changed the approach a bit so that compilation fails if the function signatures do not match exactly, so we shouldn't get this sort of problems in the future.

The question on how exactly to handle downcasting e.g. floats to ints maybe needs some thinking. Previously, floats were truncated silently to integers via C casting rules. This is IMHO not very useful behavior, and it would be best to change it. Maybe returning NaNs and setting a domain error on the misbehaving values would be a better idea.

[rgommers]

Fixed indeed. Also looks good on OS X 10.6.

[rgommers]

+1 for NaNs / errors over silent truncation. Probably deserves a discussion on the list.

[pv]

I think the NaN cast issue is out of scope for this PR, but should be considered in #334

[rgommers]

Sounds fine to fix them in #334

[pv]

I'd like to merge this. I'm not aware of additional issues.

[rgommers]

Looks good to me and seems to cause no problems.

[rgommers]

(pressed "comment" too soon) --> so go ahead.