Сообщение Re: Зависимые ячейки новый мейнстрим? от 12.02.2024 5:50
Изменено 12.02.2024 6:23 novitk
Re: Зависимые ячейки новый мейнстрим?
Здравствуйте, Разраб, Вы писали:
Р>https://fsprojects.github.io/FSharp.Data.Adaptive/
Р>Наткнулся, предлагают как альтернативу обычной реактивщине.
Р>Кто-нибудь практикует или знает как это можно с пользой применить?
В финансах давно практикуют. Google по словам Athena(Python/JPMorgan), Optimus(Scala/MorganStanley), Incremental(OCaml/JaneStreet), Quartz(Python/BAML), SecDB(SLang/GoldmanSachs)
Технически самая интересная Optimus, но OSS к сожалению только Incremental.
В ближайшем приближении: строится DAG (direct acyclic graph) по зависимостям после чего параллизация, конкурентность, мемоизация и дифференцирование происходит более-менее автоматически, как в Excel. pull вместо push в Rх. Похоже на ML фреймворки типа tflow&pytorch, нo в них граф широкий, а в incremental computation глобокий. Отладчики соответственно нужны специализированные, так как все выполяется не линейно по зависимостям в монаде. Обычно компиляторы тоже меняют, чтобы DAG прямо из кода строить, а не прописывать явно.
Р>https://fsprojects.github.io/FSharp.Data.Adaptive/
Р>Наткнулся, предлагают как альтернативу обычной реактивщине.
Р>Кто-нибудь практикует или знает как это можно с пользой применить?
В финансах давно практикуют. Google по словам Athena(Python/JPMorgan), Optimus(Scala/MorganStanley), Incremental(OCaml/JaneStreet), Quartz(Python/BAML), SecDB(SLang/GoldmanSachs)
Технически самая интересная Optimus, но OSS к сожалению только Incremental.
В ближайшем приближении: строится DAG (direct acyclic graph) по зависимостям после чего параллизация, конкурентность, мемоизация и дифференцирование происходит более-менее автоматически, как в Excel. pull вместо push в Rх. Похоже на ML фреймворки типа tflow&pytorch, нo в них граф широкий, а в incremental computation глобокий. Отладчики соответственно нужны специализированные, так как все выполяется не линейно по зависимостям в монаде. Обычно компиляторы тоже меняют, чтобы DAG прямо из кода строить, а не прописывать явно.
Re: Зависимые ячейки новый мейнстрим?
Здравствуйте, Разраб, Вы писали:
Р>https://fsprojects.github.io/FSharp.Data.Adaptive/
Р>Наткнулся, предлагают как альтернативу обычной реактивщине.
Р>Кто-нибудь практикует или знает как это можно с пользой применить?
В финансах давно практикуют. Google по словам Athena(Python/JPMorgan), Optimus(Scala/MorganStanley), Incremental(OCaml/JaneStreet), Quartz(Python/BAML), SecDB(SLang/GoldmanSachs)
Технически самая интересная Optimus, но OSS к сожалению только Incremental.
В ближайшем приближении: строится DAG (direct acyclic graph) по зависимостям после чего параллизация, конкурентность, мемоизация и дифференцирование происходит более-менее автоматически, как в Excel. pull вместо push в Rх. Похоже на ML фреймворки типа tflow&pytorch, нo в них граф широкий, а в incremental computation глобокий. Отладчики соответственно нужны специализированные, так как все выполяется не линейно по зависимостям в монаде. Обычно компиляторы тоже меняют, чтобы DAG прямо из кода строить, а не прописывать явно.
Р>https://fsprojects.github.io/FSharp.Data.Adaptive/
Р>Наткнулся, предлагают как альтернативу обычной реактивщине.
Р>Кто-нибудь практикует или знает как это можно с пользой применить?
В финансах давно практикуют. Google по словам Athena(Python/JPMorgan), Optimus(Scala/MorganStanley), Incremental(OCaml/JaneStreet), Quartz(Python/BAML), SecDB(SLang/GoldmanSachs)
Технически самая интересная Optimus, но OSS к сожалению только Incremental.
В ближайшем приближении: строится DAG (direct acyclic graph) по зависимостям после чего параллизация, конкурентность, мемоизация и дифференцирование происходит более-менее автоматически, как в Excel. pull вместо push в Rх. Похоже на ML фреймворки типа tflow&pytorch, нo в них граф широкий, а в incremental computation глобокий. Отладчики соответственно нужны специализированные, так как все выполяется не линейно по зависимостям в монаде. Обычно компиляторы тоже меняют, чтобы DAG прямо из кода строить, а не прописывать явно.