Нет

Значит дело было:
а) в функции findfirst
б) функция findfirst не могла работать с типом GPUArray

Вряд ли...
На всякий случай (да, это может быть немного странно, но это так), не надо использовать max(x...), есть специализированная функция maximum(x)

Ааааа

Интересно

Ну и equal можно через броадкаст просто заменить на maximum(x) .== x

Но в данном конкретном случае это все конечно просто argmax.
Но такие штуки могут быть полезны в других задачах.

Кстати!
Насчёт cpu(nn) - это хорошее замечание.
Что могло произойти - так как вычисления идут на GPU, то значит они паралельны.
Если они параллельны, то финальные суммирования могут идти в разном порядке между разными запусками. К сожалению float некоммутативен, и поэтому два разных запуска cpu(nn) давали два разных вектора.

И поэтому финальный findfirst не срабатывал, так как искал элемент, которого не было в массиве.

Ну а у argmax такой проблемы нет, так как он ищет внутри одного массива.

Это потому, что под ООП чаще всего понимается C++ вариант. В Ruby варианте, например, есть примеси, одной из которых является Enumerable. И всё, что имеет свою реализацию each, может использовать полный набор алгоритмов этой примеси.

Вот это и был для меня главный вопрос, так как я не понимал, как может случиться, что объекта из массива нет в самом массиве

Разве что мне нужно было nn(one) посчитать заранее один раз

А в findfirst вставить результат одного и того же общета два раза

Да.
Но лучше использовать argmax 😊)) Который работает в несколько раз быстрее, чем его самописные вариации :-)

Обожаю руби (мне его показали ещё до появления RoR и он восхитил своей красотой и продуманностью), но Джулия всё же нравится больше 😊))

Насколько я понимаю в современном мире OOP нужен в основном тогда, когда у тебя есть галера с гребцами, гребцов много, меняются часто и чтобы галера не развалилась на части, нужна поддержка контрактов со стороны языка. Прописал интерфейсы и никто уже ничего особо сделать не сможет, все ошибки ещё на этапе компиляции будут выловлены.

В языках типа Julia/python такого счастья нет, всё только количеством и качеством тестов определяется.

Могу ошибаться, сам вебом/прочим ужасом не занимался, в мире аналитики как раз наоборот свобода полная и чем меньше ограничений тем проще. Скрипты относительно короткие, ошибки как раз проще тестами выловить. Наследования, инкапсуляции - это всё тоже по большей части не нужно. Оформляешь нужный кусок в виде функции и пользуешься между разными задачами.

Кєк, фронтдевы вообще непонятно чем занимаются

Не то что ООП

Ну, под вебом я вообще сервис подразумеваю. И фронт и бэк.