Argument casts in special functions
Hi, Related to: https://github.com/scipy/scipy/pull/334 Currently we have the following behavior for the integer-order Bessel function: from scipy.special import yn print yn(1, 0.123) # -> -5.2816754510498471 print yn(1.5, 0.123) # -> -5.2816754510498471 That is, the floating point argument is silently truncated to an integer. This is not so optimal: the more strict behavior would be to return a `nan` to signify the domain error. The question now is: is it worth preserving the old behavior of the existing functions? My guess would be yes, but I think the unsafe casts should be used just as a legacy special case, and not as a general rule. (Also, the integer-order functions could be deprecated --- there is no speed advantage in them as the kernel selection can be done based on input / input data type). -- Pauli Virtanen
On Sat, Oct 20, 2012 at 7:04 AM, Pauli Virtanen <pav@iki.fi> wrote:
Hi,
Related to: https://github.com/scipy/scipy/pull/334
Currently we have the following behavior for the integer-order Bessel function:
from scipy.special import yn print yn(1, 0.123) # -> -5.2816754510498471 print yn(1.5, 0.123) # -> -5.2816754510498471
That is, the floating point argument is silently truncated to an integer.
This is not so optimal: the more strict behavior would be to return a `nan` to signify the domain error.
The question now is: is it worth preserving the old behavior of the existing functions?
My guess would be yes, but I think the unsafe casts should be used just as a legacy special case, and not as a general rule.
(Also, the integer-order functions could be deprecated --- there is no speed advantage in them as the kernel selection can be done based on input / input data type).
The behavior of jn is different and its docstring is the jv docstring, so it looks like an alias of jv. For the modified functions of the first kind there is only iv, probably because in is an unfortunate name for python. However, the modified function of the second kind, kn, behaves like yn. I'd suggest leaving the various integer functions as they are, but making the real order functions dispatch to the integer computations, if there are such, for integer orders. A note could then be added to the integer order versions suggesting the real versions and at some point it would probably be reasonable to deprecate them. Chuck
participants (2)
-
Charles R Harris -
Pauli Virtanen