scipy: BUG: cKDtree.query no longer accepts DataFrame as input
Describe your issue.
Under scipy 1.10.1, scipy.spatial.cKDTree.query method accepts a pandas.DataFrame as an input to x. Once updated to 1.11.1 or 1.11.0, this no longer works and returns an error.
1.10.1 does not emit any deprecation on that front and I haven’t found anything in the release notes so I believe this is actually a regression.
Reproducing Code Example
import scipy.spatial
import pandas as pd
points = [
    [66.22, 32.54], 
    [22.52, 22.39], 
    [31.01, 81.21],
    ]
tree = scipy.spatial.cKDTree(points, 10)
tree.query(pd.DataFrame(points), 1)
Error message
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[1], line 11
      4 points = [
      5     [66.22, 32.54], 
      6     [22.52, 22.39], 
      7     [31.01, 81.21],
      8     ]
     10 tree = scipy.spatial.cKDTree(points, 10)
---> 11 tree.query(pd.DataFrame(points), 1)
File _ckdtree.pyx:794, in scipy.spatial._ckdtree.cKDTree.query()
File ~/mambaforge/envs/pointpats_dev/lib/python3.11/site-packages/pandas/core/generic.py:1466, in NDFrame.__nonzero__(self)
   1464 @final
   1465 def __nonzero__(self) -> NoReturn:
-> 1466     raise ValueError(
   1467         f"The truth value of a {type(self).__name__} is ambiguous. "
   1468         "Use a.empty, a.bool(), a.item(), a.any() or a.all()."
   1469     )
ValueError: The truth value of a Series is ambiguous. Use a.empty, a.bool(), a.item(), a.any() or a.all().
SciPy/NumPy/Python version and system information
1.11.0 1.24.4 sys.version_info(major=3, minor=11, micro=4, releaselevel='final', serial=0)
Build Dependencies:
  blas:
    detection method: pkgconfig
    found: true
    include directory: /Users/martin/mambaforge/envs/pointpats_dev/include
    lib directory: /Users/martin/mambaforge/envs/pointpats_dev/lib
    name: blas
    openblas configuration: unknown
    pc file directory: /Users/martin/mambaforge/envs/pointpats_dev/lib/pkgconfig
    version: 3.9.0
  lapack:
    detection method: pkgconfig
    found: true
    include directory: /Users/martin/mambaforge/envs/pointpats_dev/include
    lib directory: /Users/martin/mambaforge/envs/pointpats_dev/lib
    name: lapack
    openblas configuration: unknown
    pc file directory: /Users/martin/mambaforge/envs/pointpats_dev/lib/pkgconfig
    version: 3.9.0
  pybind11:
    detection method: pkgconfig
    include directory: /Users/martin/mambaforge/envs/pointpats_dev/include
    name: pybind11
    version: 2.10.4
Compilers:
  c:
    commands: arm64-apple-darwin20.0.0-clang
    linker: ld64
    name: clang
    version: 15.0.7
  c++:
    commands: arm64-apple-darwin20.0.0-clang++
    linker: ld64
    name: clang
    version: 15.0.7
  cython:
    commands: cython
    linker: cython
    name: cython
    version: 0.29.35
  fortran:
    commands: /Users/runner/miniforge3/conda-bld/scipy-split_1687763513919/_build_env/bin/arm64-apple-darwin20.0.0-gfortran
    linker: ld64
    name: gcc
    version: 12.2.0
  pythran:
    include directory: ../../../_build_env/venv/lib/python3.11/site-packages/pythran
    version: 0.13.1
Machine Information:
  build:
    cpu: x86_64
    endian: little
    family: x86_64
    system: darwin
  cross-compiled: true
  host:
    cpu: arm64
    endian: little
    family: aarch64
    system: darwin
Python Information:
  path: /Users/martin/mambaforge/envs/pointpats_dev/bin/python
  version: '3.11'
About this issue
- Original URL
 - State: closed
 - Created a year ago
 - Comments: 26 (23 by maintainers)
 
Links to this issue
Commits related to this issue
- TST: test for gh-18800 * adds a regression test for gh-18800, which I verified fails before and passes after the patch applied in gh-18804 * the test is based on the gory details of https://numpy.or... — committed to tylerjereddy/scipy by tylerjereddy a year ago
 - TST: test for gh-18800 (#18808) * adds a regression test for gh-18800, which I verified fails before and passes after the patch applied in gh-18804 * the test is based on the gory details of ht... — committed to scipy/scipy by tylerjereddy a year ago
 
I am +1 on deprecating a path. We should not have n functions doing the same thing. It’s confusing for users and costly for us.
A new deprecation @j-bowhay 😃
KDTree used to be a pure Python implementation that had more methods than cKDTree. It was a pure Cython version that only had the query method. Now, KDTree is a wrapper for cKDTree, which is a Cython wrapper for C++ code. So today we only need to export KDTree in the API. We still have cKDTree in the API for backwards compatibility. We cannot deprecate cKDTree as such, it is needed internally, but we can deprecate it in the exported API.