[Scipy-tickets] [SciPy] #1648: Bug in orthogonal.py: values between 0 and 1 not accepted as "positive".
SciPy Trac
scipy-tickets@scipy....
Mon Jun 4 11:17:15 CDT 2012
#1648: Bug in orthogonal.py: values between 0 and 1 not accepted as "positive".
---------------------------+------------------------------------------------
Reporter: mforbes | Owner: pv
Type: defect | Status: needs_review
Priority: normal | Milestone: 0.11.0
Component: scipy.special | Version: devel
Keywords: |
---------------------------+------------------------------------------------
Comment(by pv):
@rgommers:
`n` is the order of the constructed poly1d-based object, and must be an
integer.
Prior to Scipy 0.9 (or 0.8?), these functions simply did the equivalent of
`n = int(n)` which rounds the order down. In Scipy 0.9, a stabler
evaluation path for values was added. This in hindsight was not such a
good idea, since also this breaks the `np.poly1d(...) == ...` invariant.
As an *unintended* side effect, this then allowed also evaluating values
of non-integer polynomials.
For non-integer `n`, however, all the other attributes apart from
`__call__` of the orthopoly1d objects, however, correspond to a polynomial
of order `int(n)`. Any code that uses both `__call__` and other attributes
of these objects or does arithmetic with the polynomials, produces wrong
results for non-integer `n`.
There are a couple of options for fixing this:
- disallow non-integer orders
- round order down, like in pre-0.9
- make the object with non-integer `n` not behave as a polynomial (i.e.,
make the other attributes non-accessible)
All of these break backwards compatibility in some way. I'd maybe see the
last option as the best one.
--
Ticket URL: <http://projects.scipy.org/scipy/ticket/1648#comment:5>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.
More information about the Scipy-tickets
mailing list