Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the use of linspace for numpy 1.18 #354

Merged
merged 1 commit into from
Jan 3, 2020

Conversation

ppwwyyxx
Copy link
Contributor

The original code cannot run under latest numpy 1.18:

╰─$ np.linspace(.5, 0.95, np.round((0.95 - .5) / .05) + 1, endpoint=True)                                          
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
~/.local/lib/python3.8/site-packages/numpy/core/function_base.py in linspace(start, stop, num, endpoint, retstep, dtype, axis)
    116     try:
--> 117         num = operator.index(num)
    118     except TypeError:

TypeError: 'numpy.float64' object cannot be interpreted as an integer

During handling of the above exception, another exception occurred:

TypeError                                 Traceback (most recent call last)
<ipython-input-2-62ed634c156c> in <module>
----> 1 np.linspace(.5, 0.95, np.round((0.95 - .5) / .05) + 1, endpoint=True)

<__array_function__ internals> in linspace(*args, **kwargs)

~/.local/lib/python3.8/site-packages/numpy/core/function_base.py in linspace(start, stop, num, endpoint, retstep, dtype, axis)
    117         num = operator.index(num)
    118     except TypeError:
--> 119         raise TypeError(
    120             "object of type {} cannot be safely interpreted as an integer."
    121                 .format(type(num)))

TypeError: object of type <class 'numpy.float64'> cannot be safely interpreted as an integer.

This fix addresses this issue. The issue is originally reported at facebookresearch/detectron2#580

cc @rbgirshick @agrimgupta92: lvis seems to have the same issue

@WarrenWeckesser
Copy link

The change looks good. Accepting a floating point value for the num argument of numpy.linspace has been deprecated since NumPy 1.12. That deprecation has been converted to an error in NumPy 1.18, so anyone using cocoapi with NumPy 1.18 will get an error such as the one reported here or at numpy/numpy#15192.

@@ -503,8 +503,8 @@ def setDetParams(self):
self.imgIds = []
self.catIds = []
# np.arange causes trouble. the data point on arange is slightly larger than the true value
self.iouThrs = np.linspace(.5, 0.95, np.round((0.95 - .5) / .05) + 1, endpoint=True)
self.recThrs = np.linspace(.0, 1.00, np.round((1.00 - .0) / .01) + 1, endpoint=True)
self.iouThrs = np.linspace(.5, 0.95, int(np.round((0.95 - .5) / .05)) + 1, endpoint=True)
Copy link

@eric-wieser eric-wieser Dec 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tempting to rewrite this as

Suggested change
self.iouThrs = np.linspace(.5, 0.95, int(np.round((0.95 - .5) / .05)) + 1, endpoint=True)
self.iouThrs = np.arange(10, 19+1) / 20

Read as "between 10/20 and 19/20, inclusive"

Or If you prefer hundredths:

Suggested change
self.iouThrs = np.linspace(.5, 0.95, int(np.round((0.95 - .5) / .05)) + 1, endpoint=True)
self.iouThrs = np.arange(50, 95+1, 5) / 100

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean np.arange(10, 19+1) / 20?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than that, I agree with your suggestion to use some form of arange instead of the floating point shenanigans in np.round((0.95 - .5) / .05).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed the typo above, also for the hundredths case - good catch.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Best use floats in the division for Python 2.7 compatibility.

@CDahmsCellarEye
Copy link

Somebody please integrate this ASAP!! Until this change is merged, pycocotools will cause a crash for both TensorFlow and PyTorch object detection during the evaluation phase of training!!

It took me many hours of troubleshooting to work out that backdating to Numpy 1.17.4 was the only currently available resolution.

See:

https://stackoverflow.com/questions/59493606/pytorch-and-tensorflow-object-detection-evaluate-object-of-type-class-nump

pytorch/vision#1700

numpy/numpy#15192

@eaidova
Copy link

eaidova commented Feb 3, 2020

@pdollar do you plan update pycocotools package on pypi (https://pypi.org/project/pycocotools/)?
Because this version still contains numpy1.18 incompatible code.

@aCuria
Copy link

aCuria commented Mar 3, 2020

Has this been integrated? The pytorch tutorials dont work and I am wondering which version of pycocotools to upgrade to

@CDahmsCellarEye
Copy link

Has this been integrated? The pytorch tutorials dont work and I am wondering which version of pycocotools to upgrade to

For the moment the easiest solution is to make everything current, except numpy, which can be backdated to 1.17.4, see my post here for more info:

https://stackoverflow.com/questions/59493606/pytorch-and-tensorflow-object-detection-evaluate-object-of-type-class-nump

@aCuria
Copy link

aCuria commented Mar 4, 2020

What is preventing cocoapi from being fixed? I will downgrade numpy for now, but Numpy 1.18 was released months ago

@CDahmsCellarEye
Copy link

What is preventing cocoapi from being fixed? I will downgrade numpy for now, but Numpy 1.18 was released months ago

The pull request to cocoapi was merged in, but it seems the apt-get package has not been updated per this change so you still have to back to Numpy 1.17.4 for the moment.

@ppwwyyxx
Copy link
Contributor Author

ppwwyyxx commented Mar 4, 2020

It was already fixed two months ago. No one should use cocoapi from apt-get or pip install or conda because cocoapi was never officially released on those places. The correct way to install cocoapi is pip install cython; pip install -U 'git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI'.

UPDATE: pip install pycocotools becomes official since Jun, 2020

@CDahmsCellarEye
Copy link

It was already fixed two months ago. No one should use cocoapi from apt-get or pip install or conda because cocoapi was never officially released on those places. The correct way to install cocoapi is pip install cython; pip install -U 'git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI'

The reality of the situation is that most people will use pip packages (I meant to say pip rather than apt-get) rather than installing from a git repo.

@aCuria
Copy link

aCuria commented Mar 4, 2020

@CDahmsCellarEye This didnt work for me,
The following line

pip install -U "git+https://github.com/cocodataset/cocoapi.git#subdirectory=PythonAPI"

Failed with the error

``cl : Command line error D8021 : invalid numeric argument '/Wno-cpp'`

@ppwwyyxx
Copy link
Contributor Author

ppwwyyxx commented Mar 4, 2020

@aCuria google can tell that your issue is #51

@aCuria
Copy link

aCuria commented Mar 4, 2020

I did see #51 but that's a workaround for a bug unfixed since 2017. All other libraries I have seen so far work with pip install .... and don't require you to download / modify source before it would run. I don't usually use python as much but its been harder to get pycocotools to work than even C/C++ libraries so far.

@Michael-J98
Copy link

Has this already been fixed? I still get the same error.
I install it on colab by lines:
"
git clone https://github.com/cocodataset/cocoapi.git
cd cocoapi/PythonAPI
python setup.py build_ext install
".
Anyone can help me?

@glenn-jocher
Copy link

I still get this error in May 2020. pycocotools with numpy 18.4:

loading annotations into memory...
Done (t=0.38s)
creating index...
index created!
Loading and preparing results...
DONE (t=5.31s)
creating index...
index created!
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/numpy/core/function_base.py", line 117, in linspace
    num = operator.index(num)
TypeError: 'numpy.float64' object cannot be interpreted as an integer

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 257, in <module>
    opt.augment)
  File "test.py", line 214, in test
    cocoEval = COCOeval(cocoGt, cocoDt, 'bbox')
  File "/usr/local/lib/python3.6/dist-packages/pycocotools/cocoeval.py", line 76, in __init__
    self.params = Params(iouType=iouType) # parameters
  File "/usr/local/lib/python3.6/dist-packages/pycocotools/cocoeval.py", line 527, in __init__
    self.setDetParams()
  File "/usr/local/lib/python3.6/dist-packages/pycocotools/cocoeval.py", line 507, in setDetParams
    self.iouThrs = np.linspace(.5, 0.95, np.round((0.95 - .5) / .05) + 1, endpoint=True)
  File "<__array_function__ internals>", line 6, in linspace
  File "/usr/local/lib/python3.6/dist-packages/numpy/core/function_base.py", line 121, in linspace
    .format(type(num)))
TypeError: object of type <class 'numpy.float64'> cannot be safely interpreted as an integer.

@AKMourato
Copy link

@ppwwyyxx I've already gathered that. The problem is that I've installed the latest version of pycocotools from pip and source and I'm still getting this error on numpy 1.20. Any advice?

@ppwwyyxx
Copy link
Contributor Author

Most likely you're not using what you "installed". See https://ppwwyyxx.com/blog/2019/On-Environment-Packaging-in-Python/ for some possible reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.