[SciPy-Dev] Argument casts in special functions
Charles R Harris
charlesr.harris@gmail....
Sat Oct 20 10:15:20 CDT 2012
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20121020/baf1a7b8/attachment.html
More information about the SciPy-Dev
mailing list