Мне кажется, многое на деле проще. Под конкретную задачу выбор инструмента обычно легче сделать из логики проекта, а популярность инструментов тут неважна.
Если проект учебный, чтобы научиться чем-то пользователься, то выбор уже сделан. Если чтобы научиться что-то сделать (а не чем-то), то выбор сделан и состоит в том, чтобы попробовать разное и сравнить (в том числе под что способы ищутся легче).
Если речь о выборе чего-то для самого начала обучения, величина проблемы тоже преувеличена. Во-первых, необязательно выбирать что-то, что точно пригодится. У меня в школе был BASIC, но я не сокрушаюсь о "бесцельно потраченных годах". Если тревожно искать вариант, который явно пригодится, то (как мне кажется) ещё долго будет надёжно как скриптовый выбирать Python, как более мощный чистый C (с учётом C API как универсальной связки разных инструментов между собой). Хотя надеяться изучить всё за минимум времени и не потратить лишней минуты зря уже ошибка, без готовности тратить много времени хорошо программирование не учится. Для изучения самых основ конкретный язык не так важен. После основ C и Python понимать стоит ну большинству. А дальше выбор более конкретных инструментов и выбор языка очень связаны. Тодга лучше выбирать, что хочется делать [новичку] на будущем месте работы, а не при помощи чего.
Общие рейтинги ЯП вообще штука заранее сомнительная, предвзятая и неоднозначная. А если делать их менее общими и специализировать под интересующую область, то рейтинги становятся неинтересными и рассыпаются, всё становится нередко "и так понятно", и рейтинг на практике бесполезен, вещь в себе.
Сначала и во-первых это красиво, учит правильным привычкам и любопытная головоломка. Но потом и во-вторых продолжать конкретные инструменты именно под Haskell оказывается надо очень редко, вакансии довольно редки, а также проблематично прототипировать, дебажить и оптимизировать, связь исходного кода и ассемблера тут ну очень непрозрачна. А делать производительные части условно на C/C++/Fortran, чтобы использовать Haskell как фронтенд вместо питона ну как-то overkill (и претит любителым чистых функций без unsafe, что часто среди ярых хаскелистов), тем более что потенциальных пользователей окажется тогда очень мало (а если делать под питон, то его условно "знают все" или по крайней мере, смогут воспользоваться), встречал такой пример, как hasktorch, который вроде забросили. Так что для любознательности и кругозора Haskell — это прекрасно и полезно, но чаще для души, чем для работы. А поскольку язык общего назначения, задач, под которые Haskell был бы идеально заточен, чтобы где-то сказать, что вот тут точно надо делать именно на нём, я не встречал.
Если апатия приводит в python, а безысходность в js, то конструктивный поиск приводит к Rust или порой к Go. Ещё бывает, что долг возвращает к C++ или Fortran.
А удаётся ли генерировать годные задачи? С решениями понятно, а вот для составления красивых задач это может быть любопытнее даже, чем с их же решением.
У специалистов слово "понимание" размывается, а у неспециалистов неверно используется. Про мелкие паттерны и свёрточные слои внутри слышали не все, но все слышат, что оно "понимает смысл", потому что это озвучивают на каждом углу так громко, что даже часть специалистов уже сомневается. Слова в естественном понимании и термины путать не стоит. Если с обучением ок, обязательное добавление слова "машинное" позволяет избежать проблем, то уже со словом "интеллект" всё очень спорно. А "машинного понимания" и "искусственного схватывания смысла" как терминов не существует, и вводить это не надо. Просто говорить тут про понимание вообще неуместно, это не термин.
Я бы больше боялся не появления злой воли у нейронок, а как раз приписывания нейронкам понимания, осознания, воли и прочего человеческого, к тому же, на широкую аудиторию. В итоге широкая аудитория верит и очеловечивает алгоритмы численной оптимизации, постепенно начнёт передавать ответственность за решения нейронкам. А в случае катастрофических последствий говорить, что интеллект стал слишком умный и вышел из-под контроля, хотя это просто функция с параметрами. Опасны не продвинутые алгоритмы, а такие упрощения для массовой аудитории.
"Это был первый переводчик, который действительно понимал контекст и схватывал смысл целиком"? Вы сами в это верите? О "понимании смысла" и у современных нейронок речь не идёт вообще. Вы путаете численную оптимизацию (что реально есть) и искусственное сознание (что не просто не сделано, а даже не определено чётко).
Простейший нетривиальный вариант, как всегда, LeNet на MNIST. Или пусть даже полносвязную нейронку в несколько слоёв на том же датасете (или тогда уж на чём попало), потому что известно, что MLP на MNIST тоже учится, пусть и не очень хорошо.
Можно при выводе массивов смотреть на массив xf64array (неточное будет помечено вопросиками), а также на вывод отдельно значений (поле values массива типа xf64array) и количества точных битов (поле exact_bits). Единственное, что это всё-таки расширение numpy, а не torch, так что исходную модель надо брать, где вычисление градиентов дополнительно реализуется, но такое в открытом доступе найти несложно, особенно, для чего-то простейшего типа MLP. Только надо поменять импорты numpy на xnumpy, и в большинстве случаев этого будет достаточно. И входные данные при конвертации в xf64array неплохо бы снабдить их естественной погрешностью. Например, если значения пикселей целые от 0 до 255, мы делим это на 256 для получения float, то логично предположить, что там вряд ли более 8 точных битов, а то и меньше, потому что это относительная погрешность.
Если выводить только values, то вывод будет, как если бы считалось на numpy, значения могут только чуть-чуть отличаться, если зависимые версии glibc, blas и прочие чуть-чуть поменялись, но это несущественные и крайне редкие изменения. Разница не в величине ошибки numpy и xnumpy, а в том, что в xnumpy величину ошибки мы знаем, а в numpy не имеем инструмента измерения ошибки вычислений, принимаем их как есть. Ошибки и какая-то мера их накопления неизбежны, а так можно эту величину увидеть без больших усилий заменой импорта. Поиграв с реализацией алгоритма, можно посмотреть, какие варианты надёжнее. И хотя выбор всё равно за лучшей целевой метрикой, из вариантов выбора важно исключить те, которым нельзя верить, зная величину их численной ошибки.
Это очень сильно замедлило бы. Да, есть boost/intervals, но для начала память увеличивается вдвое (а в xnumpy плюс байт на значение с плавающей точкой). И сами алгоритмы от классической теории погрешностей утяжеляют сильно. Здесь вместо этого используется число обусловленности для дифференцируемых функций, overhead получается вообще небольшой вместо минимум удвоения только на памяти и куда более тяжких алгоритмах. А для всяких округлений функции переписываются из glibc, чтобы не проходить два раза те же ветвления. Плюс к тому, особо важные функции типа матричного умножения (из blas/cublas/mkl) очень эффективны, но вроде не реализованы мощно для интервальной арифметики, вручную сделать настолько же эффективно и надёжно огромная проблема, а это нередко самые тяжеловесные операции. А оценки точностей в точных битах сводят всё к тем же матричным операциям с использованием тех же очень сильно оптимизированных библиотек при помощи оценки тропического произведения целочисленных матриц. Подход с точными битами потому и выбран, что иначе либо пользоваться станет невозможно, либо переписывать огромный тяжеловесный код, который десятки лет оптимизировали, это надо использовать, а не отказываться и переделывать с нуля. Матричные умножения с оценкой точных битов могут становиться тяжелее в разы, а если пытаться наивно посчитать точность интервалами, то медленнее станет в тысячи раз, что неприменимо на практике. С тригонометрией интервалы минимум удваивают стоимость вычислений, а в подходе с точными битам через число обусловленность получается overhead в процентах (например, на exp +21%, на log10 +9% по последнему бенчмарку, тогда как для intervals подсчёт для концов интервала и дополнительные проверки дадут сходу >100% overhead). Плюс к тому, для оценки точности мантиссы в битах часто вместо дополнительных операций с плавающей точкой используется целочисленная арифметика и работа с битовыми масками согласно представлению floating point в памяти, что тоже позволяет сделать ряд оптимизаций (как для арифметики, округлений). Но если добавить к увеличению времени ещё требование сокращать батч вдвое, то для нейронок на трансфере данных до gpu и обратно станет тратиться ещё большее время, так что выгоднее пользоваться оценкой точных битов вместо классических погрешностей очень сильно, а насколько именно, сильно зависит от железа и конкретных нейронок.
Тема предиктивной криминалистики начала появляться сильно до нынешней эры недетерминированных blackbox-алгоритмов. Даже во время классического ML была масса вопросов, правда, атрибутированных больше правовой системе США с её нюансами, чем нашей. Примеры сложностей (что-то из то ли книги, то ли статьи про PredPol, что-то добавил):
Если не балансировать данные, то одни этнические или прочие группы будут подозреваться ИИ чаще других.
Если балансировать, это делает целенаправленно одних более виноватыми, чем других.
Если делать централизованную систему, то правоприменительная практика будет отличаться от средней в отдельном штате, проблема.
Если учитывать особенности и законы отдельных штатов, то система сможет считать одного и того же человека виноватым или нет в зависимости от места преступления, тоже так себе.
Если системе не давать данные условно о расе и этнической принадлежности преступника, тем самым обосновав её якобы непредвзятость, то внутренние корреляции могут неявно "вычислить" этническую принадлежность через proxy-параметры (например, уровень дохода, образования и проживание в "чёрном" районе) и тем самым могут оказаться якобы очищенным от предвзятости обоснованием расизма со стороны правоохранительных органов, а подозрений в обоснованном скрытом проявлении расизма стремились избежать больше всего.
Если пытаться лишить алгоритм аугментацией данных возможности учитывать любые внутренние скрытые корреляции с этническими и расовыми группами (и прочими, чтобы осталась только социальная группа преступников), то алгоритм остаётся при минимуме параметров и практически теряет смысл и предсказательную силу. Вообще преступники не так сильно отличаются какими-то неочевидными признаками, иначе бы работа криминалистов не была такой сложной.
Наконец, если в прецедентном праве что-то изменится от очередного прецедента, как алгоритм начнёт это применять и когда? Алгоритмы машинного обучения с учителем не очень приспособлены для "прецедентного обучения", ну я такого по крайней мере не встречал, и существующие модели на базе нейронок подружить с этим может быть очень непросто, вопросов становится больше, чем ответов.
И плюс вопрос, кто несёт ответственность за признанное ошибочкным решение на основе ИИ? Разработчики, разметчики, обучатели ИИ? Ну странно. Вроде как всё равно только полицейский или судья, но алгоритмы и софт будут на места спускать свыше, так что всё равно будут винить систему и адресовывать пересмотр несправедливого решения выше. А если человека, например, задержали из-за ложного срабатывания системы распознавания лиц, каковы его возможности это оспорить на практике? И будет ли кому-то что-то за ложное срабатывание и ложное осуждение? Это очень сложно регулировать, при этом ответственность максимально размывается, а система может давать простые готовые решения с хорошим процентом по базам данных, то есть как бы обнадёживающе хорошо, но на деле надёжность может очень неочевидно быть устроена и проверяться.
У нас тема расовых претеснений не является настолько острой, к счастью, хотя наверняка найдётся масса возражений к этой фразе, я не против, но не об этом. Пока проблема касалась в основном более-менее явных whitebox-алгоритмов, уже возникала масса вопросов. Сейчас везде чёрные ящики, предвзятость которых сложно оценить в принципе.
Вообще немалая часть проблемы в том, что к алгоритмам ИИ всё чаще относят понятия "разобраться", "понять", "распознать", "принять взвешенное разумное решение", хотя стоит применять только слово "вычислить", и то с погрешностью, которую игнорируют. Даже "распознать" имеет весьма условное применение, потому что мы давно слышали про one-pixel-attack и про многое другое потом. А с большими языковыми моделями сложности получают сразу несколько дополнительных уровней косвенности и становятся ещё менее проверяемыми.
Но сейчас везде и всем пихают ИИ как магию, которая "делает любой текст лучше" или "напишет текст за вас", и человеческая лень в итоге придёт к написанию в том числе юридических документов генеративными нейронками, последствия будут катастрофическими. Причина просто в том, что этого практически невозможно избежать. Суровая наказуемость этого может несколько отсрочить, но не более того. Главное на этом пути не идти впереди всех и не пройтись по куче грабель первыми.
Безусловно, близкие точки с далёкими хэшами будут в любом случае. Чтобы близость хэшей была равносильна близости точек, надо, чтобы пространства точек и хэшей были топологически эквивалентны (гомеоморфны). Но хэши — это отрезок, а точки — сфера. Они негомеоморфны, что ни делай. Но остаётся вопрос, насколько далеко в среднем получается до непрерывности. Если математически, то "бесконечно далеко" — её нет (например, выкидыванием точки отрезок можно разбить на две компоненты связности, а сферу — нет). Но если считать расстояния в количествах старших битов, в метрике Левенштейна или в чём-то ещё, от отсутствие непрерывности может влечь разные степени неприятностей или отсутствия желаемого профита. Добиться непрерывности нельзя, а вот что-то конструировать для улучшения качества геосервисов можно, уменьшая влияние отсутствия непрерывности.
Тут немного другая тематика -- построение фрактала и его применение. Мало разбить пространство (поверхность сферы в данном случае) на кусочки итеративно. Важен также порядок обхода. Обходы (в том числе многомерных) кубов влияют на кластеризации и близость хэшей близких точек. И принято использовать Z-curve или Hilbert curve. Для H3 вместо S2 тесты пока не проводились, но для квадратных решёток преимущества существенные, гексагональный случай можно попробовать погонять тоже. Был бы благодарен за ссылки в этом направлении.
Ассоциация с дженгой понравилась. С деривативами тоже хорошо. Я бы ещё добавил ассоциацию с птолемеевским добавлением эпициклов, потому что часто задачи начинают не лучше или иначе анализировать, а просто отдавать всё более монструозным нейронкам. Хотя городить очень большие архитектуры тоже непросто, да и с эпициклами для орбит планет вряд ли было просто.
Если вы хотите в режиме отладки в PyCharm видеть точность переменных, вам для этого не требуется никакой плагин, достаточно наличия xnumpy в вашем venv. Рядом с переменными по ходу вычислений вы увидите значения с вопросами вместо неточных цифр, в списке локальных переменных аналогично. Выглядит это вот так:
Мы старались, чтобы практически все операции, где может теряться точность, автоматически приводили ndarray с dtype=float64 к xf64array, а также заменили тип float64 по умолчанию на xf64 в функциях, создающих новые массивы, чтобы учёт точность требовал минимума изменений в коде.
Проблема в том, что для точных вычислений надо либо вычислять значение в ленивой семантике, где требуемая в конце точность определяет точность предыдущих вычислений в направленном графе вычисления, что при неточностях начальных данных может быть проблематично, либо использовать символическую алгебру, что несильно спасёт.
При работе с большими данными структуры данных для точных вычислений на практике невозможны, вы не сможете сохранить в памяти и одно вещественное число полностью в десятичной или двоичной записи. На практике все используют что-то типа float64 или float32 в большинстве случаев.
Структуры для более точных вычислений (например, предоставляемые библиотекой gmp) дают повышенную точность, но всё равно не учитывают уровень ошибок. Но уже они неприменимы в больших вычислениях, так как очень медленно производятся. XNumPy решает проблему в стандартно используемом f64 (в перспективе f32 и прочих), не меняя само вычисление, но давая оценку точности.
Сборка производилась при помощи manylinux, так что на других Linux вроде как должно тоже работать, но пока что на других библиотека не тестировалась. В целом специфичны могут быть версии имеющихся от numpy зависимостей, таких как glibc, openblas и так далее.
Под Windows сложность в том, что библиотека включает бинарники (shared libraries в Linux, аналогично dll в Windows), а формат бинарников под Windows и Linux разный, так что бинарники одной ОС не запускаются в другой, для этого нужна отдельная сборка, ей пока не занимались.
А вот ссылки на первоисточники, откуда взят материал, только почему-то ни на что нет ссылки. Вопрос о существовании трегугольника Шарыгина -- журнал Квант, I. F. Sharygin, About bisectors, J. Kvant 1983 (1983), no. 8, 32–36. Нахождение первого целочисленного треугольника -- S. Markelov, Diophantine... bisectors!, unpublished manuscript accepted to Kvant, 2017. Доказательство существования бесконечного числа целочисленных попарно не подобных треугольников Шарыгина и описание группы рациональных точек эллиптической кривой, параметризующей треугольники Шарыгина -- Igor V. Netay, Alexei V. Savvateev, “Sharygin Triangles and Elliptic Curves”, Bull. Korean Math. Soc., 54:5 (2017), 1597–1617, arXiv: https://arxiv.org/abs/1610.04626.
И ещё чуть-чуть про треугольники. Второй треугольник Шарыгина (для краткости стороны разложены на простые множители): (2^5 · 5^2 · 17 · 23 · 137 · 7901 · 943429^2 , 29^2 · 37 · 1291 · 3041^2 · 11497^2 , 3 · 19 · 83 · 2593 · 14741 · 227257 · 7704617), третий (5 · 17 · 29 · 97 · 17182729 · 32537017 · 254398174040897 · 350987274396527, 7 · 1093889^2 · 4941193 · 894993889^2 · 331123185233, 83^2 · 571^2 · 13873 · 337789537 · 16268766383521^2 ), у пятого есть сторона, которая делится на простое число 3646312514774768838959262707271994342627321. А начиная с шестого, даже разложить на простые множители вычислительно проблематично.ничего из этого нет в библиографии
Уместность -- исключительно вопрос традиции. Говорить "операция" в неизвестной ситуации не любят. А если операция одна и отсутствует контекст, то заведомо коммутативную нередко называют сложением, а заведомо некоммутативную обычно умножением. Но появление контекста может внести изменения. Например, когда речь про моноид мономов в кольце многочленов, он обычно коммутативен, но их всё-таки перемножают.
Мне кажется, многое на деле проще. Под конкретную задачу выбор инструмента обычно легче сделать из логики проекта, а популярность инструментов тут неважна.
Если проект учебный, чтобы научиться чем-то пользователься, то выбор уже сделан. Если чтобы научиться что-то сделать (а не чем-то), то выбор сделан и состоит в том, чтобы попробовать разное и сравнить (в том числе под что способы ищутся легче).
Если речь о выборе чего-то для самого начала обучения, величина проблемы тоже преувеличена. Во-первых, необязательно выбирать что-то, что точно пригодится. У меня в школе был BASIC, но я не сокрушаюсь о "бесцельно потраченных годах". Если тревожно искать вариант, который явно пригодится, то (как мне кажется) ещё долго будет надёжно как скриптовый выбирать Python, как более мощный чистый C (с учётом C API как универсальной связки разных инструментов между собой). Хотя надеяться изучить всё за минимум времени и не потратить лишней минуты зря уже ошибка, без готовности тратить много времени хорошо программирование не учится. Для изучения самых основ конкретный язык не так важен. После основ C и Python понимать стоит ну большинству. А дальше выбор более конкретных инструментов и выбор языка очень связаны. Тодга лучше выбирать, что хочется делать [новичку] на будущем месте работы, а не при помощи чего.
Общие рейтинги ЯП вообще штука заранее сомнительная, предвзятая и неоднозначная. А если делать их менее общими и специализировать под интересующую область, то рейтинги становятся неинтересными и рассыпаются, всё становится нередко "и так понятно", и рейтинг на практике бесполезен, вещь в себе.
Сначала и во-первых это красиво, учит правильным привычкам и любопытная головоломка. Но потом и во-вторых продолжать конкретные инструменты именно под Haskell оказывается надо очень редко, вакансии довольно редки, а также проблематично прототипировать, дебажить и оптимизировать, связь исходного кода и ассемблера тут ну очень непрозрачна. А делать производительные части условно на C/C++/Fortran, чтобы использовать Haskell как фронтенд вместо питона ну как-то overkill (и претит любителым чистых функций без unsafe, что часто среди ярых хаскелистов), тем более что потенциальных пользователей окажется тогда очень мало (а если делать под питон, то его условно "знают все" или по крайней мере, смогут воспользоваться), встречал такой пример, как hasktorch, который вроде забросили. Так что для любознательности и кругозора Haskell — это прекрасно и полезно, но чаще для души, чем для работы. А поскольку язык общего назначения, задач, под которые Haskell был бы идеально заточен, чтобы где-то сказать, что вот тут точно надо делать именно на нём, я не встречал.
Если апатия приводит в python, а безысходность в js, то конструктивный поиск приводит к Rust или порой к Go. Ещё бывает, что долг возвращает к C++ или Fortran.
А удаётся ли генерировать годные задачи? С решениями понятно, а вот для составления красивых задач это может быть любопытнее даже, чем с их же решением.
У специалистов слово "понимание" размывается, а у неспециалистов неверно используется. Про мелкие паттерны и свёрточные слои внутри слышали не все, но все слышат, что оно "понимает смысл", потому что это озвучивают на каждом углу так громко, что даже часть специалистов уже сомневается. Слова в естественном понимании и термины путать не стоит. Если с обучением ок, обязательное добавление слова "машинное" позволяет избежать проблем, то уже со словом "интеллект" всё очень спорно. А "машинного понимания" и "искусственного схватывания смысла" как терминов не существует, и вводить это не надо. Просто говорить тут про понимание вообще неуместно, это не термин.
Я бы больше боялся не появления злой воли у нейронок, а как раз приписывания нейронкам понимания, осознания, воли и прочего человеческого, к тому же, на широкую аудиторию. В итоге широкая аудитория верит и очеловечивает алгоритмы численной оптимизации, постепенно начнёт передавать ответственность за решения нейронкам. А в случае катастрофических последствий говорить, что интеллект стал слишком умный и вышел из-под контроля, хотя это просто функция с параметрами. Опасны не продвинутые алгоритмы, а такие упрощения для массовой аудитории.
"Это был первый переводчик, который действительно понимал контекст и схватывал смысл целиком"? Вы сами в это верите? О "понимании смысла" и у современных нейронок речь не идёт вообще. Вы путаете численную оптимизацию (что реально есть) и искусственное сознание (что не просто не сделано, а даже не определено чётко).
Простейший нетривиальный вариант, как всегда, LeNet на MNIST. Или пусть даже полносвязную нейронку в несколько слоёв на том же датасете (или тогда уж на чём попало), потому что известно, что MLP на MNIST тоже учится, пусть и не очень хорошо.
Можно при выводе массивов смотреть на массив xf64array (неточное будет помечено вопросиками), а также на вывод отдельно значений (поле values массива типа xf64array) и количества точных битов (поле exact_bits). Единственное, что это всё-таки расширение numpy, а не torch, так что исходную модель надо брать, где вычисление градиентов дополнительно реализуется, но такое в открытом доступе найти несложно, особенно, для чего-то простейшего типа MLP. Только надо поменять импорты numpy на xnumpy, и в большинстве случаев этого будет достаточно. И входные данные при конвертации в xf64array неплохо бы снабдить их естественной погрешностью. Например, если значения пикселей целые от 0 до 255, мы делим это на 256 для получения float, то логично предположить, что там вряд ли более 8 точных битов, а то и меньше, потому что это относительная погрешность.
Если выводить только values, то вывод будет, как если бы считалось на numpy, значения могут только чуть-чуть отличаться, если зависимые версии glibc, blas и прочие чуть-чуть поменялись, но это несущественные и крайне редкие изменения. Разница не в величине ошибки numpy и xnumpy, а в том, что в xnumpy величину ошибки мы знаем, а в numpy не имеем инструмента измерения ошибки вычислений, принимаем их как есть. Ошибки и какая-то мера их накопления неизбежны, а так можно эту величину увидеть без больших усилий заменой импорта. Поиграв с реализацией алгоритма, можно посмотреть, какие варианты надёжнее. И хотя выбор всё равно за лучшей целевой метрикой, из вариантов выбора важно исключить те, которым нельзя верить, зная величину их численной ошибки.
Это очень сильно замедлило бы. Да, есть boost/intervals, но для начала память увеличивается вдвое (а в xnumpy плюс байт на значение с плавающей точкой). И сами алгоритмы от классической теории погрешностей утяжеляют сильно. Здесь вместо этого используется число обусловленности для дифференцируемых функций, overhead получается вообще небольшой вместо минимум удвоения только на памяти и куда более тяжких алгоритмах. А для всяких округлений функции переписываются из glibc, чтобы не проходить два раза те же ветвления. Плюс к тому, особо важные функции типа матричного умножения (из blas/cublas/mkl) очень эффективны, но вроде не реализованы мощно для интервальной арифметики, вручную сделать настолько же эффективно и надёжно огромная проблема, а это нередко самые тяжеловесные операции. А оценки точностей в точных битах сводят всё к тем же матричным операциям с использованием тех же очень сильно оптимизированных библиотек при помощи оценки тропического произведения целочисленных матриц. Подход с точными битами потому и выбран, что иначе либо пользоваться станет невозможно, либо переписывать огромный тяжеловесный код, который десятки лет оптимизировали, это надо использовать, а не отказываться и переделывать с нуля. Матричные умножения с оценкой точных битов могут становиться тяжелее в разы, а если пытаться наивно посчитать точность интервалами, то медленнее станет в тысячи раз, что неприменимо на практике. С тригонометрией интервалы минимум удваивают стоимость вычислений, а в подходе с точными битам через число обусловленность получается overhead в процентах (например, на exp +21%, на log10 +9% по последнему бенчмарку, тогда как для intervals подсчёт для концов интервала и дополнительные проверки дадут сходу >100% overhead). Плюс к тому, для оценки точности мантиссы в битах часто вместо дополнительных операций с плавающей точкой используется целочисленная арифметика и работа с битовыми масками согласно представлению floating point в памяти, что тоже позволяет сделать ряд оптимизаций (как для арифметики, округлений). Но если добавить к увеличению времени ещё требование сокращать батч вдвое, то для нейронок на трансфере данных до gpu и обратно станет тратиться ещё большее время, так что выгоднее пользоваться оценкой точных битов вместо классических погрешностей очень сильно, а насколько именно, сильно зависит от железа и конкретных нейронок.
С целыми числами не получится, потому что градиентный спуск работать не будет. Избавиться от IEEE754 разом невозможно, на него завязано слишком много.
Тема предиктивной криминалистики начала появляться сильно до нынешней эры недетерминированных blackbox-алгоритмов. Даже во время классического ML была масса вопросов, правда, атрибутированных больше правовой системе США с её нюансами, чем нашей. Примеры сложностей (что-то из то ли книги, то ли статьи про PredPol, что-то добавил):
Если не балансировать данные, то одни этнические или прочие группы будут подозреваться ИИ чаще других.
Если балансировать, это делает целенаправленно одних более виноватыми, чем других.
Если делать централизованную систему, то правоприменительная практика будет отличаться от средней в отдельном штате, проблема.
Если учитывать особенности и законы отдельных штатов, то система сможет считать одного и того же человека виноватым или нет в зависимости от места преступления, тоже так себе.
Если системе не давать данные условно о расе и этнической принадлежности преступника, тем самым обосновав её якобы непредвзятость, то внутренние корреляции могут неявно "вычислить" этническую принадлежность через proxy-параметры (например, уровень дохода, образования и проживание в "чёрном" районе) и тем самым могут оказаться якобы очищенным от предвзятости обоснованием расизма со стороны правоохранительных органов, а подозрений в обоснованном скрытом проявлении расизма стремились избежать больше всего.
Если пытаться лишить алгоритм аугментацией данных возможности учитывать любые внутренние скрытые корреляции с этническими и расовыми группами (и прочими, чтобы осталась только социальная группа преступников), то алгоритм остаётся при минимуме параметров и практически теряет смысл и предсказательную силу. Вообще преступники не так сильно отличаются какими-то неочевидными признаками, иначе бы работа криминалистов не была такой сложной.
Наконец, если в прецедентном праве что-то изменится от очередного прецедента, как алгоритм начнёт это применять и когда? Алгоритмы машинного обучения с учителем не очень приспособлены для "прецедентного обучения", ну я такого по крайней мере не встречал, и существующие модели на базе нейронок подружить с этим может быть очень непросто, вопросов становится больше, чем ответов.
И плюс вопрос, кто несёт ответственность за признанное ошибочкным решение на основе ИИ? Разработчики, разметчики, обучатели ИИ? Ну странно. Вроде как всё равно только полицейский или судья, но алгоритмы и софт будут на места спускать свыше, так что всё равно будут винить систему и адресовывать пересмотр несправедливого решения выше. А если человека, например, задержали из-за ложного срабатывания системы распознавания лиц, каковы его возможности это оспорить на практике? И будет ли кому-то что-то за ложное срабатывание и ложное осуждение? Это очень сложно регулировать, при этом ответственность максимально размывается, а система может давать простые готовые решения с хорошим процентом по базам данных, то есть как бы обнадёживающе хорошо, но на деле надёжность может очень неочевидно быть устроена и проверяться.
У нас тема расовых претеснений не является настолько острой, к счастью, хотя наверняка найдётся масса возражений к этой фразе, я не против, но не об этом. Пока проблема касалась в основном более-менее явных whitebox-алгоритмов, уже возникала масса вопросов. Сейчас везде чёрные ящики, предвзятость которых сложно оценить в принципе.
Вообще немалая часть проблемы в том, что к алгоритмам ИИ всё чаще относят понятия "разобраться", "понять", "распознать", "принять взвешенное разумное решение", хотя стоит применять только слово "вычислить", и то с погрешностью, которую игнорируют. Даже "распознать" имеет весьма условное применение, потому что мы давно слышали про one-pixel-attack и про многое другое потом. А с большими языковыми моделями сложности получают сразу несколько дополнительных уровней косвенности и становятся ещё менее проверяемыми.
Но сейчас везде и всем пихают ИИ как магию, которая "делает любой текст лучше" или "напишет текст за вас", и человеческая лень в итоге придёт к написанию в том числе юридических документов генеративными нейронками, последствия будут катастрофическими. Причина просто в том, что этого практически невозможно избежать. Суровая наказуемость этого может несколько отсрочить, но не более того. Главное на этом пути не идти впереди всех и не пройтись по куче грабель первыми.
Безусловно, близкие точки с далёкими хэшами будут в любом случае. Чтобы близость хэшей была равносильна близости точек, надо, чтобы пространства точек и хэшей были топологически эквивалентны (гомеоморфны). Но хэши — это отрезок, а точки — сфера. Они негомеоморфны, что ни делай. Но остаётся вопрос, насколько далеко в среднем получается до непрерывности. Если математически, то "бесконечно далеко" — её нет (например, выкидыванием точки отрезок можно разбить на две компоненты связности, а сферу — нет). Но если считать расстояния в количествах старших битов, в метрике Левенштейна или в чём-то ещё, от отсутствие непрерывности может влечь разные степени неприятностей или отсутствия желаемого профита. Добиться непрерывности нельзя, а вот что-то конструировать для улучшения качества геосервисов можно, уменьшая влияние отсутствия непрерывности.
Тут немного другая тематика -- построение фрактала и его применение. Мало разбить пространство (поверхность сферы в данном случае) на кусочки итеративно. Важен также порядок обхода. Обходы (в том числе многомерных) кубов влияют на кластеризации и близость хэшей близких точек. И принято использовать Z-curve или Hilbert curve. Для H3 вместо S2 тесты пока не проводились, но для квадратных решёток преимущества существенные, гексагональный случай можно попробовать погонять тоже. Был бы благодарен за ссылки в этом направлении.
Ассоциация с дженгой понравилась. С деривативами тоже хорошо. Я бы ещё добавил ассоциацию с птолемеевским добавлением эпициклов, потому что часто задачи начинают не лучше или иначе анализировать, а просто отдавать всё более монструозным нейронкам. Хотя городить очень большие архитектуры тоже непросто, да и с эпициклами для орбит планет вряд ли было просто.
Если вы хотите в режиме отладки в PyCharm видеть точность переменных, вам для этого не требуется никакой плагин, достаточно наличия xnumpy в вашем venv. Рядом с переменными по ходу вычислений вы увидите значения с вопросами вместо неточных цифр, в списке локальных переменных аналогично. Выглядит это вот так:
Мы старались, чтобы практически все операции, где может теряться точность, автоматически приводили ndarray с dtype=float64 к xf64array, а также заменили тип float64 по умолчанию на xf64 в функциях, создающих новые массивы, чтобы учёт точность требовал минимума изменений в коде.
Проблема в том, что для точных вычислений надо либо вычислять значение в ленивой семантике, где требуемая в конце точность определяет точность предыдущих вычислений в направленном графе вычисления, что при неточностях начальных данных может быть проблематично, либо использовать символическую алгебру, что несильно спасёт.
При работе с большими данными структуры данных для точных вычислений на практике невозможны, вы не сможете сохранить в памяти и одно вещественное число полностью в десятичной или двоичной записи. На практике все используют что-то типа float64 или float32 в большинстве случаев.
Структуры для более точных вычислений (например, предоставляемые библиотекой gmp) дают повышенную точность, но всё равно не учитывают уровень ошибок. Но уже они неприменимы в больших вычислениях, так как очень медленно производятся. XNumPy решает проблему в стандартно используемом f64 (в перспективе f32 и прочих), не меняя само вычисление, но давая оценку точности.
Да, опечатка, спасибо. Должно быть arcsin(1.0).
Сборка производилась при помощи manylinux, так что на других Linux вроде как должно тоже работать, но пока что на других библиотека не тестировалась. В целом специфичны могут быть версии имеющихся от numpy зависимостей, таких как glibc, openblas и так далее.
Под Windows сложность в том, что библиотека включает бинарники (shared libraries в Linux, аналогично dll в Windows), а формат бинарников под Windows и Linux разный, так что бинарники одной ОС не запускаются в другой, для этого нужна отдельная сборка, ей пока не занимались.
А вот ссылки на первоисточники, откуда взят материал, только почему-то ни на что нет ссылки. Вопрос о существовании трегугольника Шарыгина -- журнал Квант, I. F. Sharygin, About bisectors, J. Kvant 1983 (1983), no. 8, 32–36. Нахождение первого целочисленного треугольника -- S. Markelov, Diophantine... bisectors!, unpublished manuscript accepted to Kvant, 2017. Доказательство существования бесконечного числа целочисленных попарно не подобных треугольников Шарыгина и описание группы рациональных точек эллиптической кривой, параметризующей треугольники Шарыгина -- Igor V. Netay, Alexei V. Savvateev, “Sharygin Triangles and Elliptic Curves”, Bull. Korean Math. Soc., 54:5 (2017), 1597–1617, arXiv: https://arxiv.org/abs/1610.04626.
И ещё чуть-чуть про треугольники. Второй треугольник Шарыгина (для краткости стороны разложены на простые множители): (2^5 · 5^2 · 17 · 23 · 137 · 7901 · 943429^2 , 29^2 · 37 · 1291 · 3041^2 · 11497^2 , 3 · 19 · 83 · 2593 · 14741 · 227257 · 7704617), третий (5 · 17 · 29 · 97 · 17182729 · 32537017 · 254398174040897 · 350987274396527, 7 · 1093889^2 · 4941193 · 894993889^2 · 331123185233, 83^2 · 571^2 · 13873 · 337789537 · 16268766383521^2 ), у пятого есть сторона, которая делится на простое число 3646312514774768838959262707271994342627321. А начиная с шестого, даже разложить на простые множители вычислительно проблематично.ничего из этого нет в библиографии
Уместность -- исключительно вопрос традиции. Говорить "операция" в неизвестной ситуации не любят. А если операция одна и отсутствует контекст, то заведомо коммутативную нередко называют сложением, а заведомо некоммутативную обычно умножением. Но появление контекста может внести изменения. Например, когда речь про моноид мономов в кольце многочленов, он обычно коммутативен, но их всё-таки перемножают.