По ходу тут какие-то проблемы с переводом, так как возможность обобщения модели, обученной на конечных наборах данных была показана Вапником и Червоненкисом ещё в 70-х. В итоге не понятно, о чем идёт речь в статье (скорее всего о чем-то другом), или что-то не так с формулировка и проблемы. Надо будет почитать оригинальную работу.
Я пользуюсь довольно давно (наверное как только он переехал на Chromium — уже наверное почти год). Очень нравится встроенный просмотр PDF, который оптимизирован для трансформеров — там рисовалка по экрану, которая позволяет выделять текст или что-то пометить/обвести. Он лучше интегрирован в Cortana (правда там будет Bing, а не Google, но если искать только на английском, то вполне норм). Плюс единая учетная запись на всю Windows, что тоже довольно удобно. Ну и там плагин OneNote получше работает, как мне показалось.
Из того, что я вижу — Julia сейчас вытесняет «научный» Python из физики и химии. Связано это действительно с нативной JIT-компиляцией и многопоточностью, которая позволяет людям без сторонних костылей (типа numba, которые не очень стабильны и не очень удобны) писать действительно быстрый код. Многие библиотеки для квантовой оптики, химии, квантовой механики и т.д. сейчас переписаны на Julia и активно поддерживаются. Julia это язык, созданный физиками для физиков. Даже индексация с единицы пришла из близкого физикам Fortran. Почему не C++? Потому что на Julia проще и быстрее прототипировать. В машинном обучении и Deep Learning сейчас Julia практически не используется. Преимущества JIT теряются, так как все «строительные блоки» уже написаны, а уровень готовых библиотек Julia проигрывает значимо. Сравните тот же Flux с Tensorflow или PyTorch и все сразу станет ясно. Нет никаких аргументов в пользу перехода с Python на Julia в промышленном машинном обучении или в исследовательских задачах Deep Learning. Скорее всего Julia так и останется языком научной среды.
Я имел ввиду сборку толстых jar, если я хочу использовать что-то (например, из тех же spark-packages), чего нет на кластере. Да, я могу клась jar-ники в hdfs и указывать в параметрах запуска. Но в том и преимущество Maven, что он гарантирует мне, что скачаны все зависимости и нет конфликтов версий. Качать jar руками не всегда удобно.
Но ок, я подумаю, как перефразировать, спасибо за замечание!
Официального резила и тех репорта про NetKet действительно еще не было, но они ее цитировали в своей работе про бозоны: http://arxiv.org/abs/1903.03076v1
По ходу тут какие-то проблемы с переводом, так как возможность обобщения модели, обученной на конечных наборах данных была показана Вапником и Червоненкисом ещё в 70-х. В итоге не понятно, о чем идёт речь в статье (скорее всего о чем-то другом), или что-то не так с формулировка и проблемы. Надо будет почитать оригинальную работу.
Еще раз спасибо!
Обязательно посмотрю!
Рад, что Вам было интересно)
Я имел ввиду сборку толстых jar, если я хочу использовать что-то (например, из тех же spark-packages), чего нет на кластере. Да, я могу клась jar-ники в hdfs и указывать в параметрах запуска. Но в том и преимущество Maven, что он гарантирует мне, что скачаны все зависимости и нет конфликтов версий. Качать jar руками не всегда удобно.
Но ок, я подумаю, как перефразировать, спасибо за замечание!
Официального резила и тех репорта про NetKet действительно еще не было, но они ее цитировали в своей работе про бозоны: http://arxiv.org/abs/1903.03076v1