Самоорганизация не работала, не работает и работать не будет. Если вы предоставите возможность сообществу "договариваться между собой", то в лучшем случае, у вас будет ResearchGate, в котором поговорить как бы можно, а толку нет. Или "рынок" будет очень быстро перекроен "под себя" воротилами от науки. Настройка рейтинга — вещь очень тонкая и сделать так, чтобы он играл на руку, скажем, большим коллаборациям, не сложно. Если участь, что эти рейтинги — это живые деньги, то нет, так это точно работать не будет.
Идея правильная, но разумеется простые операции типа «сложить» и «умножить» работать не будут. Систему рейтингов надо долго и нудно балансировать, чтобы она работала правильно.
Ну и кроме того, тут есть две дополнительные потенциальные ошибки:
Никакая публикация не должна давать бесконечный рейтинг, независимо от уровня ее признания. Должен быть максимальный уровень признания. Иначе система развалится за счет эффекта Матфея.
Должна быть система учета вкладов в статью. Иначе подвалы по 3000 авторов опять забьют все. Это надо проектировать и это не просто.
Вообще, важно понимать, что наука занимается не поиском абстрактной истины, которую сложно определить, а поиском консенсуса в научном сообществе, который определить уже вполне реально, в том числе формально на уровне теории графов.
Именно как препринт архив. Их сейчас очень не много. На основе архива препринтов можно делать формальных журнал. Делать свой журнал с нуля не реально. А вот делать журнал на основе готовой базы публикаций вполне реально. Но я повторюсь: балансировка прав и репутаций, а также прозрачная организация peer review — это самые сложные моменты.
Основная проблема все-таки не консерватизм. Это система непрерывной верификации материалов. Мы довольно много думали на эту тему и некоторые решения выработали. Единственный вариант, в котором оно может полететь хорошо и быстро я вижу следующим образом: сама платформа представляет собой препринт сервер, на который можно загрузить работы с минимальной фильтрацией. При этом в отличие от arxiv должна быть система публичных и приватных комментариев с модерацией. Нужно продумать сложную систему правил и градаций прав пользователей таким образом, чтобы видны были только адекватные комментарии адекватных пользователей. Также пользователи с определенными правами могут оставлять анонимные и публичные оценки работа. Работа, набравшая определенный рейтинг (или работа автора с некоторым рейтингом) может быть подана на peer review, который делается в той же системе и пользователями этой же системы. При этом должны быть соблюдены все правила (отсутствие конфликта интересов, квалификация и т. д.). После прохождения ревью, статья может получить статус опубликованной и попасть в систему индексации типа Scopus. Вероятно нужен еще один статус между препринтом и публикацией — верифицированная статья. То есть некоторый документ, который не содержит глупости и является научным, но при этом все еще не готовая публикация.
В общем много про это думали и готовы поделиться наработками. Не готов читать все комментарии на хабре, так что пишите лично, если интересно.
Хорошая статья. Тут в том числе шла речь о финансовой составляющей и именно о ней надо говорить в первую очередь. Проблема в том, что если электронная бумага, на которой печатается журнал, действительно стоит не дорого, то вот экспертная работа стоит очень дорого. В настоящее время журналы играют роль экспертов. Факт публикации в том или ином журнале вроде как говорит об уровне качества работы. И на самом деле в этом ничего плохого нет. Проблема начинается, когда в качестве критерия начинают брать не наличие публикации в хорошем журнале, а их качество. Вот тут и начинается. К примеру, в физике частиц есть проблема коллективных подвалов — статей с 3000 авторов. Как только человек оказывается включен в коллаборацию, он получает очень высокий рейтинг даже если вообще ничего в коллаборации не делает. ВУЗы и фонды используют журналы как бесплатных экспертов и вместо того, чтобы поставить экспертизу, просто считают публикации. Никакими манипуляциями с журналами и KPI эту проблему не решить. Решить ее можно только созданием хорошей системы экспертной оценки.
В обществе научных работников (http://onr-russia.ru/) было довольно много дискуссий на эту тему.
QT — это очень специфичный под-язык и экосистема, которая берет от С++ в основном разумные компоненты и оставляет за кадром остальное. На нем вполне можно писать. Но знаете… если сравнивать… В общем пообщаемся, когда JavaFX попробуете.
А в микроконтроллерах вы скорее всего используете С с классами или даже без них, опять же касаясь только очень маленькой разумной части стандарта.
К сожалению, скорость высокая только пока пользователей мало. Кроме того, это не всегда хорошо. Можно прийти к тому же С++ если понапихать всего-всего.
Да, книжка (Феномен науки) рекомендуется к прочтению всем, кто видит себя в должности архитектора сложных систем. Вот запись семинара на эту тему: youtu.be/fpBGnYMm3PM (качество к сожаление посредственное).
Физики — это понятие растяжимое. Если говорить о физике частиц, то почти повсеместно используется вот эта система: root.cern.ch. Данные к сожалению в ней же. Документацию по формату можете искать долго и читать ее еще дольше, но разобраться там невозможно. Достаточно сказать, что там используется самодельная квази-рефлексия на С++ с самодельным же форматом сериализации как Java serialization, только на С++ и с кучей граблей и костылей. В общем, никто кроме самого рута, читать этот формат не может (ну еще немного умеет вот эта штука: github.com/scikit-hep/uproot, но далеко не все).
Анализ бывает очень разный. Если брать ускорительную физику, то как правило есть что-то вроде таблицы (Root TTree, который совсем не дерево), элементы строк которой могут быть вложенными таблицами или произвольными объектами. По этой таблице делается что-то типа фильтрации и строятся гистограммы определенных параметров и их производных. Потом по этим гистограммам делаются картинки и как-то сравниваются. Как-то так, если не брать калибровки, которые очень индивидуальны для каждого эксперимента. Ну там еще есть аспект сбора, потому что с ускорителей сыплются дикие объемы данных, и для того, чтобы их просто предварительно отсеять надо распределенные системы подключать.
Если мы говорим о неускорительной физике, то тут уже все совсем индивидуально. К примеру, анализ данных на Троицк ню-масс — это очень многослойная композиция, состоящая из считывания первичных данных в бинарном формате, обработке и группировке данных (там совсем не тривиальная процедура, могу ссылку на диссертацию Василия дать), потом применении кучи калибровок, которые надо получить из других данных и правильно отнормировать, потом построения модели, интегрирования и фитирования всего этого (могу ссылку на свою диссертацию дать). В общем черт ногу сломит (правда это один из самых сложных анализов в области). Достаточно сказать, что после получения данных на окончательную обработку как правило уходит несколько лет. Объемы данных у нас маленькие — масштаб десятки и сотни гигабайт в бинарнике, но обработку надо провести неисчислимое количество раз, подставляя разные параметры.
По визуализации как правило используют тот же Рут — он исходно создавался для построения гистограм. Но к счастью в последнее время начали переползать на питон. Мы на эксперименте используем в процессе сбора свою собственную систему на JFreeChart (с большим количеством настроек). Для статей использовали Origin, но сейчас переползли на Plotly.
С публикациями туго, поскольку у физиков не принято говорить о софте. Это такая магия, которая или работает или не работает. Сейчас ситуация начала меняться и физики хотя бы начали признавать факт того, что software matters, но очень медленно.
Если что, это шутка была. Я его никому не рекомендую брать без острой необходимости, но в физике частиц без него никто не работает. Я не очень понял, как вы можете о нем не знать, если из этой области.
Мы перешли на питон для визуализации пару лет назад по этой причине. Сейчас постепенно подтягиваем инструментарий на Kotlin, но пока наверное его не стоит использовать если анализ не на JVM.
Excell из серьезного анализа кстати предлагаю выкинуть (для построить график на коленке во время сеанса — нормально), как впрочем и Origin. Origin — это мощная система, но работает только если это одноразовый анализ. Для того, чтобы второй раз сделать то же самое, надо сделать примерно столько же работы, как в первый.
Ну так возьмите ROOT или какую-нибудь монструозную поделку на основе него. Тут надо все-таки разделять фреймворк и модули к нему для работы с конкретной задачей. Универсального тут ничего нет.
Для начала кэширование. Если у тебя есть кэш, он может протухнуть. Ты что-то поменял в программе и ожидаемый результат поменялся. Если ты не инвалидировал кэш, получаешь ошибку. Валидация кэшей — это вообще глобальная проблема и у нее нет простых решений.
Теперь про типы. Есть разные уровне проверки данных. Первый уровень проверки — это структуры — это у тебя есть, ты проверяешь, что к тебе прилетели твои Sequence, а не что-то левое. Следующий уровень — это проверка типов содержимого, если твоя задача берет таблицу, она должна проверить, что это таблица, а не число. Вот этого уже нет. И наконец, твои x и x+1 — это проверка состоятельности данных. Как правило это уже делается в момент выполнения, хотя в супер-типизированных языках вроде Хаскеля, можно частично перенести это на уровень типов.
Фреймворк не стремится быть лучше Питона
Это точно. Но я сильно не уверен, что подобные системы можно всерьез делать на питоне. Минимальные штуки и прототипы — возможно.
Ярослав, хорошая работа, но давай я поизображаю из себя оппонента и укажу на проблемные места.
В том, что касается конкурентов, список явно не избыточен, и начать, разумеется, надо было с https://spark.apache.org/ или с его питоновской производной pyspark. Собственно, все системы такого рода должны сравниваться именно с ним. Есть еще несколько аналогичных систем, в том числе с байндингами на питоне. Ну и в порядке знакомства, мог бы сослаться на https://doi.org/10.1051/epjconf/201817705003.
Ключевая проблема, которая не решается pipeline процессорами, и твоя система тут не исключение — это валидация промежуточных состояний. Собственно проблемы нет, если нет кэширования промежуточных результатов, но если ее нет, то ленивость оказывается не очень полезной.
Еще одна проблема — это валидация типа данных в элементах "последовательности". Что будет, если кто-то забудет вписать промежуточный преобразующий элемент и данные окажутся невалидным для следующего действия? Вероятно у тебя все упадет в рантайме. Если дейсвтия перед этим достаточно дорогие, то это может быть сильно дорого. Я не уверен, что человеческую валидацию типов можно сделать в питоне без сильных костылей.
Третья проблема тоже с типами. Рано или поздно приходится работать с неоднородными данными, то есть когда у тебя есть не просто массив, а какая-то смесь данных с разными типами (например данные и калибровки). Как поступать с этим? Можно конечно подмешивать калибровки путем захватывания элементов из внешней программы, но тогда элементы последовательности получают явные сайд-эффекты (в идеале они должны быть чистыми или псевдо-чистыми, то есть иметь доступ только к ограниченному количеству внешних операций).
Есть еще куча вопросов, но пока остановимся на этом.
Согласен. Но за пробелами следить — это как-то слишком напряжно. Я как правило код для статей и презентаций делаю в play.kotlinlang.org или в VSCode, чтобы не плодить проекты в идее. В обоих случаях поддержка код-стайла ограниченная.
Это один из вариантов. Но к сожалению он не особо осмысленный, поскольку все равно не будет ссылки на элемент, как на `this`. Проще передать параметрами. Кроме того, из за генерации пар может быть существенная потеря в перформансе на аллокацию лишнего объекта.
Самоорганизация не работала, не работает и работать не будет. Если вы предоставите возможность сообществу "договариваться между собой", то в лучшем случае, у вас будет ResearchGate, в котором поговорить как бы можно, а толку нет. Или "рынок" будет очень быстро перекроен "под себя" воротилами от науки. Настройка рейтинга — вещь очень тонкая и сделать так, чтобы он играл на руку, скажем, большим коллаборациям, не сложно. Если участь, что эти рейтинги — это живые деньги, то нет, так это точно работать не будет.
Ну и кроме того, тут есть две дополнительные потенциальные ошибки:
Вообще, важно понимать, что наука занимается не поиском абстрактной истины, которую сложно определить, а поиском консенсуса в научном сообществе, который определить уже вполне реально, в том числе формально на уровне теории графов.
В общем много про это думали и готовы поделиться наработками. Не готов читать все комментарии на хабре, так что пишите лично, если интересно.
В обществе научных работников (http://onr-russia.ru/) было довольно много дискуссий на эту тему.
А в микроконтроллерах вы скорее всего используете С с классами или даже без них, опять же касаясь только очень маленькой разумной части стандарта.
Анализ бывает очень разный. Если брать ускорительную физику, то как правило есть что-то вроде таблицы (Root TTree, который совсем не дерево), элементы строк которой могут быть вложенными таблицами или произвольными объектами. По этой таблице делается что-то типа фильтрации и строятся гистограммы определенных параметров и их производных. Потом по этим гистограммам делаются картинки и как-то сравниваются. Как-то так, если не брать калибровки, которые очень индивидуальны для каждого эксперимента. Ну там еще есть аспект сбора, потому что с ускорителей сыплются дикие объемы данных, и для того, чтобы их просто предварительно отсеять надо распределенные системы подключать.
Если мы говорим о неускорительной физике, то тут уже все совсем индивидуально. К примеру, анализ данных на Троицк ню-масс — это очень многослойная композиция, состоящая из считывания первичных данных в бинарном формате, обработке и группировке данных (там совсем не тривиальная процедура, могу ссылку на диссертацию Василия дать), потом применении кучи калибровок, которые надо получить из других данных и правильно отнормировать, потом построения модели, интегрирования и фитирования всего этого (могу ссылку на свою диссертацию дать). В общем черт ногу сломит (правда это один из самых сложных анализов в области). Достаточно сказать, что после получения данных на окончательную обработку как правило уходит несколько лет. Объемы данных у нас маленькие — масштаб десятки и сотни гигабайт в бинарнике, но обработку надо провести неисчислимое количество раз, подставляя разные параметры.
По визуализации как правило используют тот же Рут — он исходно создавался для построения гистограм. Но к счастью в последнее время начали переползать на питон. Мы на эксперименте используем в процессе сбора свою собственную систему на JFreeChart (с большим количеством настроек). Для статей использовали Origin, но сейчас переползли на Plotly.
С публикациями туго, поскольку у физиков не принято говорить о софте. Это такая магия, которая или работает или не работает. Сейчас ситуация начала меняться и физики хотя бы начали признавать факт того, что software matters, но очень медленно.
Если вопрос про котлин, то вот статья: medium.com/@altavir/plotly-kt-a-dynamic-approach-to-visualization-in-kotlin-38e4feaf61f7, а вот светлое будущее: kotlinlang.org/docs/reference/data-science-overview.html
Теперь про типы. Есть разные уровне проверки данных. Первый уровень проверки — это структуры — это у тебя есть, ты проверяешь, что к тебе прилетели твои Sequence, а не что-то левое. Следующий уровень — это проверка типов содержимого, если твоя задача берет таблицу, она должна проверить, что это таблица, а не число. Вот этого уже нет. И наконец, твои x и x+1 — это проверка состоятельности данных. Как правило это уже делается в момент выполнения, хотя в супер-типизированных языках вроде Хаскеля, можно частично перенести это на уровень типов.
Это точно. Но я сильно не уверен, что подобные системы можно всерьез делать на питоне. Минимальные штуки и прототипы — возможно.
Ярослав, хорошая работа, но давай я поизображаю из себя оппонента и укажу на проблемные места.
В том, что касается конкурентов, список явно не избыточен, и начать, разумеется, надо было с https://spark.apache.org/ или с его питоновской производной pyspark. Собственно, все системы такого рода должны сравниваться именно с ним. Есть еще несколько аналогичных систем, в том числе с байндингами на питоне. Ну и в порядке знакомства, мог бы сослаться на https://doi.org/10.1051/epjconf/201817705003.
Ключевая проблема, которая не решается pipeline процессорами, и твоя система тут не исключение — это валидация промежуточных состояний. Собственно проблемы нет, если нет кэширования промежуточных результатов, но если ее нет, то ленивость оказывается не очень полезной.
Еще одна проблема — это валидация типа данных в элементах "последовательности". Что будет, если кто-то забудет вписать промежуточный преобразующий элемент и данные окажутся невалидным для следующего действия? Вероятно у тебя все упадет в рантайме. Если дейсвтия перед этим достаточно дорогие, то это может быть сильно дорого. Я не уверен, что человеческую валидацию типов можно сделать в питоне без сильных костылей.
Третья проблема тоже с типами. Рано или поздно приходится работать с неоднородными данными, то есть когда у тебя есть не просто массив, а какая-то смесь данных с разными типами (например данные и калибровки). Как поступать с этим? Можно конечно подмешивать калибровки путем захватывания элементов из внешней программы, но тогда элементы последовательности получают явные сайд-эффекты (в идеале они должны быть чистыми или псевдо-чистыми, то есть иметь доступ только к ограниченному количеству внешних операций).
Есть еще куча вопросов, но пока остановимся на этом.