АО
Когда люди спрашивают про пайп как в R, то обычно имеют в виду применение как в tidyverse
Size: a a a
2020 April 10
АО
Где можно длинные последовательности операций собирать в один большой пайп.
TL
одна из претензий к нему - он не является полноценным конвейером. Данные передаются на следующий этап целиком как результат предыдущего этапа. Никаких последовательных потоков и lazy-вычислений . Сейчас - это чисто синтаксическая последовательность выполнения вместо заворачивания в скобки
ну уже не плохо, чтобы скобки не городить.
TL
Когда люди спрашивают про пайп как в R, то обычно имеют в виду применение как в tidyverse
именно
АО
Есть ещё пакет
То есть вроде то, что нужно, но в то же время не совсем то. Получается менее красиво, но правда полная функциональность пайплайна есть.
Lazy.jl, он правда больше на кложуру похож по использованию.То есть вроде то, что нужно, но в то же время не совсем то. Получается менее красиво, но правда полная функциональность пайплайна есть.
RS
ну уже не плохо, чтобы скобки не городить.
один из плюсов, если на промежуточных этапах используются функции с одним аргументом, не надо писать
|> x -> f(x) |>. Достаточно |> f |>RS
Есть ещё пакет
То есть вроде то, что нужно, но в то же время не совсем то. Получается менее красиво, но правда полная функциональность пайплайна есть.
Lazy.jl, он правда больше на кложуру похож по использованию.То есть вроде то, что нужно, но в то же время не совсем то. Получается менее красиво, но правда полная функциональность пайплайна есть.
это тоже не то, что хотелось бы….
AP
Query.jl посмотрите
АО
Ну да, отсюда это длинное обсуждение про underscore. В R проблема функций с несколькими аргументами решается либо тем, что считается, что передавать в первый аргумент, либо точкой обозначается.
То, что хотят сделать, это чтобы можно было писать что-то вроде такого
вместо
Но нашли огромное количество подводных камней
То, что хотят сделать, это чтобы можно было писать что-то вроде такого
x |> f |> g(2, _)
вместо
x |> f |> y -> g(2, y)
Но нашли огромное количество подводных камней
TL
в р конечно изящно это решено
АО
Ну, на самом деле там все те же подводные камни 😊
Просто так как они были пионеры, то они на них забили/забыли, а теперь в R все уже привыкли.
Ну а в Джулии хотят подумать и сделать как лучше, поэтому не торопятся.
Просто так как они были пионеры, то они на них забили/забыли, а теперь в R все уже привыкли.
Ну а в Джулии хотят подумать и сделать как лучше, поэтому не торопятся.
RS
у меня рубический есть пример про lazy:
Если убрать lazy, то получим переполнение. Но если бы это был не бесконечный перечислитель, а что-то конечное, достаточно убрать вызов метода .lazy, а остальная алгоритмическая часть останется неизменной. И будет работать так же, как и |> в Julia
(1..1.0/0).lazy.select { |x| x**2 % 5 == 0 }.take(10).inject(:+)Если убрать lazy, то получим переполнение. Но если бы это был не бесконечный перечислитель, а что-то конечное, достаточно убрать вызов метода .lazy, а остальная алгоритмическая часть останется неизменной. И будет работать так же, как и |> в Julia
RS
в случае Julia мы не можем также легко добавить метод lazy, который создаёт lazy-перечислитель, потому как придётся переписать все операторы по цепочке.
АО
А разве это не итераторами решается?
RS
ну они же должны быть отстроены на каскад и инициированием от потребителя
RS
как только потребитель запросил значение, раскручиваются последовательно все остальные итераторы до источника
RS
вся идея в том, что данные не генерируются, пока нет потребителя
АО
Ну, это вроде бы и правда похоже на трансдьюсеры.
KT
а чем от итератора отличается не пойму