BUG: numpy.ma.put(a, indices, values, mode='wrap') runs for a very long time even when a, values are invalid

[coco1629]

Describe the issue:

When indices is a very large number and mode='wrap' , numpy.ma.core.put still takes a very long time to calculate the result even if a and values are invalid types.
When I tried to run numpy.ma.core.put('', 8259655103995416119, '', 'wrap'), it hadn't completed even after running for four hours, even though it wouldn't perform any operations on a. I understand that when mode='wrap', the strategy is to use the modulo operation to keep the indices within the valid range of the array. When the first parameter is a valid MaskedArray type and the second parameter is a very large number(8259655103995416119, for example) while the third parameter is an empty string(invalid), the following result will be produced:

Traceback (most recent call last):
  File "/root/experiment/seeds/numpy.ma.core.put/1#numpy#ma#core#put.py", line 66, in <module>
    ret = numpy.ma.put(a, indices, values, mode)
  File "/root/anaconda3/lib/python3.9/site-packages/numpy/ma/core.py", line 7397, in put
    return a.put(indices, values, mode=mode)
  File "/root/anaconda3/lib/python3.9/site-packages/numpy/ma/core.py", line 4889, in put
    self._data.put(indices, values, mode=mode)
ValueError: invalid literal for int() with base 10: ''

and the program finishes running quickly.
However, when the first parameter is changed to an invalid string type, the program takes an extremely long time to run, even though no operations need to be performed due to the invalidity of these parameters.

Reproduce the code example:

import numpy
import numpy.ma
import traceback

print("----- running ('',1, '', 'wrap')")
(a, indices, values, mode) = ('',1, '', 'wrap')
ret = numpy.ma.put(a, indices, values, mode)
print("a: " + a)  # a is still '', not changed, reasonable

print("----- running (numpy.ma.array([1, 2, 3, 4], mask=[False, True, False, False]) , 8259655103995416119, '', 'wrap')")
try:
    a = numpy.ma.array([1, 2, 3, 4], mask=[False, True, False, False])  
    (indices, values, mode) = (8259655103995416119, '', 'wrap')
    ret = numpy.ma.put(a, indices, values, mode) # ValueError: invalid literal for int() with base 10: ''. Reasonable
except Exception as e:
    traceback.print_exc()

print("----- running ('' , 8259655103995416119, '', 'wrap')")
(a, indices, values, mode) = ('' , 8259655103995416119, '', 'wrap')
ret = numpy.ma.put(a, indices, values, mode)
print("a: " + a)  # expected: a is still '', not changed. Actually runs long time, haven't got value after running 4 hours.

Error message:

----- running ('',1, '', 'wrap')
a: 
----- running (numpy.ma.array([1, 2, 3, 4], mask=[False, True, False, False]) , 8259655103995416119, '', 'wrap')
Traceback (most recent call last):
  File "/root/PyRTFuzz/experiment/seeds/numpy.ma.core.put/1#numpy#ma#core#put.py", line 65, in <module>
    ret = numpy.ma.put(a, indices, values, mode) # ValueError: invalid literal for int() with base 10: ''. Reasonable
  File "/root/anaconda3/lib/python3.9/site-packages/numpy/ma/core.py", line 7397, in put
    return a.put(indices, values, mode=mode)
  File "/root/anaconda3/lib/python3.9/site-packages/numpy/ma/core.py", line 4889, in put
    self._data.put(indices, values, mode=mode)
ValueError: invalid literal for int() with base 10: ''
----- running ('' , 8259655103995416119, '', 'wrap')

Python and NumPy Versions:

Python: 3.9.0
Numpy: 2.0.1

Runtime Environment:

No response

Context for the issue:

When the first parameter is a valid array, the program will very quickly report an error because the third parameter is ''. When both a and values are of invalid data types, the function should do nothing to a, regardless of whether indices is a large number or not. But when indices is large, the code will run for a very long time.

[gsmll]

this seems to be an issue with numpy.ndarray.put, I can't find the source though, I assume its compiled or something?

[seberg]

This is implemented as a loop, since it is expected to not be utterly out of bounds. Maybe that is not ideal, but to me the issue seems not like an actual user problem, but just some automatic tool finding potential problems.
So, without context of why this actually hurts a user, I don't think anyone should prioritize it.

[seberg]

And to be clear: It is not OK, to not disclose that an issue is just some automated tool finding possibly completely meaningless things.

We have a "Context for the issue:" section for a reason!

[coco1629]

And to be clear: It is not OK, to not disclose that an issue is just some automated tool finding possibly completely meaningless things.

We have a "Context for the issue:" section for a reason!

I think this would cause actual user problem. Regardless of how large the second parameter is, since the first parameter is not an array, the API should perform no operation according to intended behavior quickly. In this case, wasting a long time is meaningless

[coco1629]

This is implemented as a loop, since it is expected to not be utterly out of bounds. Maybe that is not ideal, but to me the issue seems not like an actual user problem, but just some automatic tool finding potential problems. So, without context of why this actually hurts a user, I don't think anyone should prioritize it.

I agree that the priority of this issue isn't high, but it does spend an inordinate amount of time on tasks that could have been resolved immediately. Since the first parameter isn't an array, the API doesn't actually need to care about what the second parameter is.

[seberg]

@coco1629 that doesn't answer the questions whether this actually affects you or anyone else in practice or whether this was found using some automated tool.

[coco1629]

@coco1629 that doesn't answer the questions whether this actually affects you or anyone else in practice or whether this was found using some automated tool.

I'm wondering if you think it's unlikely that this issue will be triggered by users. Users may inadvertently pass an invalid parameter a, perhaps due to an unexpected return value from another function. In such a situation, if a relatively large value of indices is used, the program might run meaninglessly for a long time because whatever indices is it should do nothing. This situation can actually be avoided, in expectation

[mattip]

Hmm. So I guess the answer is “ Yes I used an automated tool. I think the problem is significant enough to fix”. The second claim needs some evidence to back it up. Maybe the automated tool could weight its findings by actual code it can find by scanning projects on github, and further weight the code by how popular the project is.

[coco1629]

Hmm. So I guess the answer is “ Yes I used an automated tool. I think the problem is significant enough to fix”. The second claim needs some evidence to back it up. Maybe the automated tool could weight its findings by actual code it can find by scanning projects on github, and further weight the code by how popular the project is.

It was indeed found by an automated tool. I judge that the behavior of this API, which is spending a long time even when dealing with invalid parameters, does not meet the expectations.
In the second scenario I listed, the API can finish running quickly and conclude that the third parameter is invalid. However, after the first parameter is changed to invalid, it runs for a long time instead.
When 'a' is invalid and 'indices' is extremely large, the behavior of this API seems to deviate from the expectations. I'm not claiming that it's an important bug that affects many users, just believe that it doesn't meet the expected behavior of the API, which means it is a bug.

[seberg]

This may well be worthwhile to fix, I don't mind this issue as such. But:

1. If you are planning to open many issues similar issues, don't. At least bunch them up unless you are convinced yourself it is important (and that means fully understand the context).
2. If I see issues like these opened that smell like automation without that being clarified from the start, especially if it is a verbose explanation about basically nothing....
   ... I won't hesitate to just close them maybe without a comment even.

This type of behavior has been seen across many repositories recently, so it isn't a small little thing to shrug away anymore for me.
Every issue, no matter how meaningless, is read by a significant number of people on repositories like NumPy.

[coco1629]

This may well be worthwhile to fix, I don't mind this issue as such. But:

1. If you are planning to open many issues similar issues, don't. At least bunch them up unless you are convinced yourself it is important (and that means fully understand the context).
2. If I see issues like these opened that smell like automation without that being clarified from the start, especially if it is a verbose explanation about basically nothing....
   ... I won't hesitate to just close them maybe without a comment even.

This type of behavior has been seen across many repositories recently, so it isn't a small little thing to shrug away anymore for me. Every issue, no matter how meaningless, is read by a significant number of people on repositories like NumPy.

OK, I understand. I just thought it was an unexpected behavior, which may indicate a bug, so I tried to submit this issue. If you think it's meaningless, I understand and sorry for opening this, and I will no longer submit such issues. Thanks for your explanation