Почему Numpy преобразует тип «объект»-«int» в тип «объект»-«float»?

Скорее всего, [1158941147679947299,0] преобразуется в массив int dtype и контролирует добавление. [1158941147679947299] может оставаться скаляром Python. Математические операции с массивами dtype объектов являются случайными, не так четко определены и последовательны, как обычные числовые массивы.

@hpaulj Но обычные числовые массивы нельзя использовать, если используются целые числа с несколькими сотнями цифр. Обновлено: добавлен лучший пример, который показывает, что он не выполняет преобразование, поскольку [2**63,0] не работает, но [2**63,2**63] работает.

Я предполагаю, что это ошибка, а не функция. Я пошел дальше и опубликовал это github.com/numpy/numpy/issues/26818

Не можете ли вы явно указать dtype объекта для второго списка/массива? Скажите ему именно то, что вы хотите.

@hpaulj Боже мой, да!! Это работает, И мне не нужно менять весь свой код на циклы for. Гений. Если вы хотите опубликовать это, я приму это.

Я согласен, что это, по-видимому, пороговые значения. Однако ваше объяснение, похоже, предполагает, что A + [2**63,0] должно вести себя так же, как A + 2**63 или A + [2**63,2**63], но это не так. Таким образом, дело не только в том, что numpy имеет определенные пороговые значения, которые используются, но и в том, что numpy непоследователен, когда эти пороговые значения применяются (если это ожидаемая функция).

Еще одно замечание. Насколько я понимаю, dtype=object — это способ заполнить массив numpy указателями вместо целых чисел, чисел с плавающей запятой или чего-то еще. Эти указатели могут быть ЛЮБЫМ объектом Python, и, как правило, numpy будет зависеть от того, как ведет себя этот объект Python. В целом непоследовательно, чтобы numpy приступил к преобразованию типов «объектов» вместо того, чтобы делать то, что ему говорят объекты. Следовательно, A + 1 должен вести себя аналогично циклу for, если объекты в A являются объектами Python. Вот почему массив объектов может содержать 1000-значные целые числа и выполнять с ними модульную арифметику.

Вы правы, отмечая различное поведение, которое сбивает с толку и, возможно, в некоторых случаях нежелательно. Я хотел указать на конкретные границы и на то, как избежать, казалось бы, произвольного поведения. Идея «указателей» здесь мутит воду. Если вас волнует тип, не стоит уточнять object — то, что там делает NumPy, соответствует, хотя я согласен, что результат может быть нежелательным. Почему NumPy выбирает тот или иной вариант, скорее всего, связано с внутренней оптимизацией для конкретных случаев использования, и лучше всего исследовать его исходный код и, возможно, документацию — я не стал искать причину.

Ключевой момент, на который следует обратить внимание: передача object в качестве типа не должна рассматриваться как «сохранить тот тип, который я вам дал». Если вы специально хотите сохранить переданный тип, NumPy не позволит вам — вместо этого вы можете самостоятельно установить тип на основе какого-либо условия.

Я не уверен в вашем желании избегать типов object. Их суть в том, что такие вещи, как np.array(['thing','other'],dtype=object) + 's', имеют смысл и работают. Причина в том, что numpy подчиняется использованию объекта +. Pandas, как и многие другие модули, наполнены такого рода организационным поведением. В комбинаторике следует ожидать, что такие вещи, как np.array([2**100,3**100],dtype=object) % 1234, будут работать (как они и работают в настоящее время, используя произвольные встроенные целые числа Python). Фактически, при создании массива размером более int64 происходит автоматическое приведение к типу object.

Ошибка, описанная выше, ничем не отличалась бы от того, если бы мои строки, помещенные в массив numpy, вместо этого были преобразованы в кортежи с некоторыми произвольными порогами сложения длины строки.

Я думаю, что «ошибка» — это не столько ошибка, сколько запланированная функция: StackOverflow — не место для обсуждения проектных решений в сторонних библиотеках. Я понимаю вашу точку зрения и советую вам сообщить о проблеме разработчикам. Но я бы порекомендовал обосновать обнаруженный вами недостаток конструкции, поскольку я не думаю, что это «ошибка», поскольку она не противоречит спецификации.

Тем не менее, я думаю, что ответил на вопрос «почему» так хорошо, как и можно было ожидать (по сути, это первая строка моего ответа). Я не могу решить, что вы не согласны с причиной (и это не самое подходящее место).

Я ценю ваш анализ и обсуждение. И я согласен, что никогда бы не опубликовал это, если бы с самого начала был убежден, что это ошибка, и ждал отзывов. Однако после рассмотрения нескольких примеров с большими целыми числами, строками, смешанными типами объектов Python и т. д. кажется гораздо более очевидным, что это «ошибка», а не задуманная.

Ваш ответ очень полезен. Однако я не согласен с вашей оценкой того, что пользователь должен знать, что «dtype — это «приемный ребенок»». Проблема не в том, что пользователь предполагает согласованность с A+[2**62,0], A+[2**63,0], A+[2**64,0], A+[2**62,2**62], A+[2**63,2**63], A+[2**64,2**64], A+2**62, A+2**63, A+2**64. Скорее, numpy должен относиться к этому по-другому. Либо выдайте ошибку/предупреждение, либо сделайте все списки одинаковыми, либо сделайте все большие целые числа одинаковыми, либо сделайте все маленькие целые числа одинаковыми. Здесь у нас ничего этого нет.