уже успел пару проектов с R переписать на Julia.

«Проекты» по 100 строк?

Те, что переписал по 2000 - 2500 строк. По 100 строк пишут в основном никому не нужные кандидаты наук, либо эникейщики за нищенскую зарплату. У меня же коммерческая разработка либо для личных нужд.

В последнем случае, с нетерпением жду появления резюме со строчкой «Хулия-программист».

Ха)) прикол))

Те, что переписал по 2000 - 2500 строк.

Да ты скоростной просто! Спидами балуешься?

По 100 строк пишут в основном <поскипано> кандидаты наук

Ну так нам платят за то, что мы думаем, а не переписываем.

Ну, судя по тому, как вам платят, то не думаете вы там нихрена. Только штаны просижываете за 150-200 долларов в месяц.

Ну моя зарплата в 40 раз больше (если брать середину интервала, что ты привел, правда до налогов), но ты переписывай, переписывай.

зарплата
40 раз больше

Вахаха, это в каких влажных фантазиях такие зарплаты, когда в рашке средняя ЗП - 200 долларов? Такой доход может быть у предпринимателя, как у меня, но точно не у наемного раба.

Но ты фантазируй, фантазируй. Бугага!

PS. Ты тут же рыдал, что добавление одной строчки, это уже много. Выходит ты обычный эникейщик, с проектами на 10 строк, который даже детерминант не знает, как вычислить в Джулии. Бугага!

Пока одни спорили об индексации массивов и векторов, а другие флудерасты и эникейщики докапывались бомбящими пуканами до новости, я уже успел пару проектов с R переписать на Julia. Бугага!

Те, что переписал по 2000 - 2500 строк.

Итого, с вечера 09.08 по середину дня 15.08 ты переписал ~5000 строк, практически по 800 строк в день. Ты реально реактивный. Был тут парнишка, который писал по 400 строк в день - правда, выяснилось, что он чужой код присвоил.

Для справки, хулия зарелизена 5 лет назад. У тех кто хотел, всё давно переписано. У других, всё ещё на питончике и на фортране, но это наверное скоро изменится. По крайней мере с f2py больше ипаться нет желания.

И да, большинство моих например проектов, по 100-200 строк, а часто намного меньше. Думать башкой приходится больше, чем нажимать кнопок.

Для справки, хулия зарелизена 5 лет назад.

Для справки, персонаж указал время. И это 5 дней назад, а не 5 лет.

с вечера 09.08

О, еще один пятизвездочный флудераст. Даже за меня решил, когда я начал переписывать. Бугага!

PS. до 09.08 ведь небыло ни Джулии, ничего. Только дух пятизвездочных носился над водою. Гыы

Персонаж написал, что пока одни обсуждали индексирование, другие чего-то там переписали. За то время, пока тут идиоты обсуждают индексирование, действительно много чего можно переписать. Сомневаешься?

За то время, пока тут идиоты обсуждают индексирование, действительно много чего можно переписать.

Конечно. За эти 6 дней можно было переписать 5000 строк, если переписывать по ~800 строк в день.

Сомневаешься?

Что ты.

Да всё с тобой понятно. Обсуждай индексирование дальше.

Жульку не дураки делают.

А кто? Неужели (ч)удаки?

Нет, (ч|м)удаки делали R, тупо скопипастив проприетарный S. Который еще то дерьмо.

до 09.08 ведь небыло ни Джулии, ничего.

Это, что? Ты над этими своими строчками пердолился с момента заложения первого камня в жулю? Ну нафиг такой прогресс...

Хосспади, из крайности в крайность. А с бетки 0.7 нельзя было разве? Незналь. Ладно, пошел обратно на R все переписывать.

тупо скопипастив проприетарный S

Все еще хуже, они тупо скопипастили Схему прямо из курса Абельсон&Сасман.

Неужели (ч)удаки?

Да нормальные, грамотные ребята. К спорам, «а как оно на самом деле должно быть», совершенно открыты. Нормальные люди.

Да ладно, ты же сам не говоришь толком ничего.

8 месяцев на портирование готовых 2000 строк кода R.

1) Меня крепко смущает «2000 строк кода на R» (если это не «питоноRкод» конечно) Мало в каком мега пакете самого R столько будет именно кода.

2) Отчего так долго? 10 строчек в день для высокуровнего языка при отлаженном рабочем коде прототипе как то все равно долго... (Могу только предположить что некие батарейки пришлось самому писать.)

Ну и собственно вопрос — насколько быстрее стало. Тут не менее двух порядков ускорение должно выйти, по тестам «не дураков» из самой жулии?

Я месяц назад где-то начал, попутно разбирясь в Джулии.

Бенчмарки не делал, но где-то раз в 7-10 быстрее стало. Может можно и больше выжать, я не пробовал.

Да нет, чистый R. Пакеты почти не юзаю, кроме data.table и plyr. На питоне ни одной строчке кода не написал за всю жизнь. Он просто не нужен. Вот пример одного файла:

MergeBodyPeriod <- function(period.x, period.y) {
    united.periods <- union(period.x[, !colnames(period.x) %in% kBodyName, drop = F], period.y[, !colnames(period.y) %in% kBodyName, drop = F])
    is.dates <- sapply(united.periods, function(x) all(sapply(x, function(y) inherits(y, 'Date'))))

    united.dates <- united.periods[is.dates]
    if (length(united.dates) > 0L) {
        united.dates <- united.dates[order(do.call(c, lapply(united.dates, '[[', 1L)))]
    }

    result <- c(list(period.x[, kBodyName]), united.dates)
    names(result) <- c(kBodyName, paste0('PERIOD.', seq_len(length(result) - 1L)))
    do.call(cbind.data.frame, result)
}


AlignBodyField <- function(merged.period, period, field) {
    mth <- match(merged.period[1L, !colnames(merged.period) %in% kBodyName, drop = F], period[1L, !colnames(period) %in% kBodyName, drop = F])
    field.period <- field[, !colnames(field) %in% kBodyName, drop  = F]
    result <- c(list(field[, kBodyName]), lapply(mth, function(i) {
        if (!is.na(i)) {
            field.period[, i]
        } else {
            NA
        }
    }))
    names(result) <- colnames(merged.period)
    do.call(cbind.data.frame, result)
}


GetAlignedBody <- function(bodies, is.full.stmts) {
    periods <- Map(function(body, is.full.stmt) {
        if (is.full.stmt) {
            body[[kBodyTypePeriod]]
        } else {
            data.frame()
        }
    }, bodies, is.full.stmts)

    merged.periods <- Reduce(function(x, y) {
        b.x <- IsNonEmptyDataFrame(x)
        b.y <- IsNonEmptyDataFrame(y)
        if (b.x && b.y) {
            MergeBodyPeriod(x, y)
        } else if (b.x) {
            x
        } else if (b.y) {
            y
        } else {
            data.frame()
        }
    }, periods)

    aligned.fields <- Map(function(body, is.full.stmt) {
        if (is.full.stmt) {
            AlignBodyField(merged.periods, body[[kBodyTypePeriod]], body[[kBodyTypeField]])
        } else {
            data.frame()
        }
    }, bodies, is.full.stmts)

    result <- list(merged.periods, aligned.fields)
    names(result) <- names(kBodyTypes)
    result
}


GetCheckedHeader <- function(headers, is.full.stmts) {
    full.headers <- headers[is.full.stmts]
    if (length(unique(full.headers)) == 1L) {
        full.headers[[1L]]
    } else {
        data.frame()
    }
}


MergeStatement <- function(stmt.types) {
    headers <- lapply(stmt.types, function(x) x[[kStatementSubtypeHeader]])
    bodies <- lapply(stmt.types, function(x) x[[kStatementSubtypeBody]])

    is.full.stmts <- mapply(function(header, body) {
        IsNonEmptyDataFrame(header) && IsNonEmptyDataFrame(body[[kBodyTypePeriod]]) && IsNonEmptyDataFrame(body[[kBodyTypeField]])
    }, headers, bodies)

    checked.header <- GetCheckedHeader(headers, is.full.stmts)
    aligned.bodies <- if (IsNonEmptyDataFrame(checked.header)) {
        GetAlignedBody(bodies, is.full.stmts)
    } else {
        lapply(stmt.types, function(x) data.frame())
    }

    result <- list(checked.header, aligned.bodies)
    names(result) <- names(kStatementSubtypes)
    result
} 

Скоро буду с нуля писать новый проект, где нужно из Постгреса вытягивать данные и делать всякие расчеты по финансовым отчетам 50 000 компаний. Вот там я оттянусь.

Даже за меня решил, когда я начал переписывать. Бугага!

Да упаси ТНБ. Ты сам во всём признался.

FilosofeM> Пока одни спорили об индексации массивов и векторов, а другие флудерасты и эникейщики докапывались бомбящими пуканами до новости, я уже успел

грамотные ребята

pisum = function() {
    t = 0.0
    for (j in 1:500) {
        t = 0.0
        for (k in 1:10000) {
            t = t + 1.0/(k*k)
        }
    }
    return(t)
}

Грамотные? (это «код» на R в их тестах)

В union совать датафреймы как совсем не по феншую, уж лучше явно написать unique() на список из их колонок.

Почему inherits(), а не is() ?

....

Если тут что то тормозит, то можно явно данные не копировать (через списки причем), а работать с их метаданными. (И опять же dplyr вполне все эти селекты наборов колонок и преобразования структуры может делать скорее всего куда быстрее.)

Пока одни спорили об индексации массивов и векторов, а другие флудерасты и эникейщики докапывались бомбящими пуканами до новости, я уже успел пару проектов с R переписать на Julia. Бугага!

Пару проектов по 20..50 kloc? Да ты волшебник.

Чо, отвык от циклов? Обычный такой код.

Чо, отвык от циклов? Обычный такой код.

поторопись, тебя с таким «кодом» явно ждет в жулии успех

в R нет скаляров

нормально написанный этот код работает в 30 раз быстрее

> pisum = function() {
+     t = 0.0
+     for (j in 1:500) {
+         t = 0.0
+         for (k in 1:10000) {
+             t = t + 1.0/(k*k)
+         }
+     }
+     return(t)
+ }
> pisum()
[1] 1.644834
> system.time(pisum())
пользователь      система       прошло 
       3.080        0.004        3.109 
> system.time(pisum())
пользователь      система       прошло 
       3.072        0.000        3.075 
> system.time(pisum())
пользователь      система       прошло 
       3.056        0.000        3.059 
> pisum = function() {    
+     for (j in 1:500) {
+         k <- 1:10000
+         t <- sum(1/(k*k))
+     }
+     t
+ }
> pisum()
[1] 1.644834
> system.time(pisum())
пользователь      система       прошло 
       0.116        0.000        0.118 
> system.time(pisum())
пользователь      система       прошло 
       0.104        0.000        0.102 
> system.time(pisum())
пользователь      система       прошло 
       0.096        0.000        0.098 
> 

Поиграю в адвоката дьявола немного. Твой код хорош, с векторизацией, однако, если я правильно понимаю суть, сначала будет создан массив 1/k^2, k=1:10000, а потом его элементы просуммированы, т.е. твой код требует O(N) памяти на выполнение. Джулькин же код требует O(1) памяти. Кроме того, твой код требует от компилятора умения векторизовать суммы, что тривиально для числовых данных, но нетривиально для объектов с перегруженным оператором суммы, так что если k — пользовательский объект (скажем, полином или дуальное число, да даже можно матричное тело взять), то твой код не сработает.

Как-то сыровато пока. В версии 1.0 не работают графики (ошибка при сборки одной из зависимостей). Ну да ладно, собрал из мастера. Чтобы нарисовать график, нужно импортить пакет Plots.

using Plots

plot(rand(5,5))

1) Операции вида 1:n в R в текущих версиях не требуют O(n) Так что даже по памяти никакого выигрыша нет.

2) Это конкретное вычисление над векторами чисел, и игнорирование типа представления данных как раз происходит со стороны кодеров жулии, у меня _полный_ эквивалент их «теста» приведен.

Сделать функцию принимающую вектор на входе настолько тривиально, что это автоматизировано

> Vectorize(function(x,y)x+y)
function (x, y) 
{
    args <- lapply(as.list(match.call())[-1L], eval, parent.frame())
    names <- if (is.null(names(args))) 
        character(length(args))
    else names(args)
    dovec <- names %in% vectorize.args
    do.call("mapply", c(FUN = FUN, args[dovec], MoreArgs = list(args[!dovec]), 
        SIMPLIFY = SIMPLIFY, USE.NAMES = USE.NAMES))
}

Это возможно не даст той скорости что оптимизация на уровне компиятора, но у меня сомнение что у жулии дела сильно лучше будут обстоять именно с векторизацией кода...

Быстрый for() и «двигание битами в массовых объемах» у R это возможность прозрачно инлайнить код на фортране и си.

1) Операции вида 1:n в R в текущих версиях не требуют O(n) Так что даже по памяти никакого выигрыша нет.

Это я понимаю, а вот вычисление 1/k^2, k=1:10000 в аргументе sum? В джулии, как и в питоне, возможны два случая: comprehensions и generators. Последние не строят массив (являются ленивыми), а в R как?

но у меня сомнение что у жулии дела сильно лучше будут обстоять именно с векторизацией кода...

Фишка джулии, на которую давят разработчики именно в девекторизации, почитай вот https://stackoverflow.com/a/34810523

1) конечно все методы доступа системные к таким объектам переписаны и фактически вместо данных отвечает (причем эффективно) функция https://svn.r-project.org/R/branches/ALTREP/ALTREP.html

2) Рекламировать быстрый for это «по накалу» пожалуй соответствует их манере писать «сравнительные тесты» :)

Ну возрадуются «могущие на любом языке программировать на фортране», но где здесь прогресс? Опять килотонны строк вложенных цикликов, за которыми сути задачи не видно?

Вот что «циклы головного мозга» делают с казалось бы более чем вменяемыми программистами

вот из https://www.manning.com/books/deep-learning-with-r

Listing 6.1 Word-level one-hot encoding (toy example)

samples <- c("The cat sat on the mat.", "The dog ate my homework.")
token_index <- list()
for (sample in samples)
for (word in strsplit(sample, " ")[[1]])
if (!word %in% names(token_index))
token_index[[word]] <- length(token_index) + 2
max_length <- 10
results <- array(0, dim = c(length(samples),
max_length,
max(as.integer(token_index))))
for (i in 1:length(samples)) {
sample <- samples[[i]]
words <- head(strsplit(sample, " ")[[1]], n = max_length)
for (j in 1:length(words)) {
index <- token_index[[words[[j]]]]
results[[i, j, index]] <- 1
}
}

но это так не пишут блин в языке где нет скаляров

    > samples <- c("The cat sat on the mat.", "The dog ate my homework.")
    > parse <- strsplit(samples, " ")
    > token_list <- unique(unlist(parse))
    > lapply(parse,function(s)sapply(s, function(w) (1:length(token_list))[token_list %in% w] ))
    [[1]]
    The cat sat on the mat.
    1 2 3 4 5 6

    [[2]]
    The dog ate my homework.
    1 7 8 9 10 

более того поменяв всего один параметр вместо следующей фигни по ссылке в Listing 6.2

мы просто получаем

> parse <- strsplit(samples, "")
> parse
[[1]]
 [1] "T" "h" "e" " " "c" "a" "t" " " "s" "a" "t" " " "o" "n" " " "t" "h" "e" " "
[20] "m" "a" "t" "."

[[2]]
 [1] "T" "h" "e" " " "d" "o" "g" " " "a" "t" "e" " " "m" "y" " " "h" "o" "m" "e"
[20] "w" "o" "r" "k" "."

> token_list <- unique(unlist(parse))
> lapply(parse,function(s)sapply(s, function(w) (1:length(token_list))[token_list %in% w] ))
[[1]]
 T  h  e     c  a  t     s  a  t     o  n     t  h  e     m  a  t  . 
 1  2  3  4  5  6  7  4  8  6  7  4  9 10  4  7  2  3  4 11  6  7 12 

[[2]]
 T  h  e     d  o  g     a  t  e     m  y     h  o  m  e  w  o  r  k  . 
 1  2  3  4 13  9 14  4  6  7  3  4 11 15  4  2  9 11  3 16  9 17 18 12 

Если не секрет, в какой области предпринимательской деятельностью занимаетесь? Как давно? Зарегистрированы ли в налоговых органах по месту проживания или осуществления предпринимательской деятельности? Просто предположу, что это расчёты для строительства. Но есть у меня один знакомый, который делает ОВОС'ы (оценка экологического воздействия проектируемого объекта).

2) Рекламировать быстрый for это «по накалу» пожалуй соответствует их манере писать «сравнительные тесты» :)

Тут никакого накала нет вообще. Векторизация в julia работает так же, как и в R, но когда нужно написать вложенный цикл (не надо пожалуйста утверждать, что это никогда не нужно), в julia это будет работать на пару порядков быстрее, чем в R. Где накал?

Что до сравнительных тестов, то это предмет вечного срача. Напиши свои, а мы их тут дружно обосрём.

Фишка джулии, на которую давят разработчики именно в девекторизации, почитай вот https://stackoverflow.com/a/34810523

Ну где они давят? Фишка в том, что в R или питоне циклы написаны на Си, и обёрнуты в высокоуровневый язычок, чтобы тебе и мне было приятно. В джулии циклы не нужно писать на Си, их можно написать на джулии, и обернуть в высокоуровневый оператор, или функцию тоже на джулии. Для разработчиков такой подход представляет гораздо меньше гемороя.

Я не большой специалист в этом вопросе, но иногда векторизованный код не просто быстрее, но гораздо короче и не подвержен ошибкам выхода за границы массива. Например, в матлабе выражение v.*u гда v и u вектора разных длин выдаст ошибку, а в каком-нибудь С при пробегании по индексу массива, выделенного в куче можно с большой вероятностью вылететь за пределы u или v без segmentation fault, потому что защита памяти не побайтная, а постраничная... julia, вроде, такому не подвержена, но мало ли.

Ну и читабельность сильно страдает от вложенных циклов, иногда не плохо, когда язык поощряет векторизацию и заставляет думать, вместо вкорячивания цикла по ещё одной переменной.

Например, в матлабе выражение v.*u гда v и u вектора разных длин выдаст ошибку

В матлабе это всё написано на Си с помощью ужасных вложенных циклов, и спрятано от тебя в загружаемую библиотеку. В джулии, ты эти все циклы можешь написать на джулии, и спрятать от себя в модуль. Или подождать, когда кто-нибудь напишет твои циклы за тебя.

Ну, котлета, которую я ем тоже, знаешь сделали из коровы, за которой кто-то ухаживал, кормил-поил, потом забил, разделал... ну ты понял в общем. Но это не повод заставлять *меня* делать то же самое, и даже просто видеть это. Так мне не кажется, что идея скрыть всё это — плохая, и более того, то, что язык *заставляет* это не делать — скорее хорошо, чем плохо.

Далее, мне вот никогда за всю мою практику не понадобились ассемблерные вставки ни в C, ни в C++/Fortran, так что ни тепло, ни холодно от этих возможностей. Хуже того, я бы напрягся, если бы пришлось работать с community, где этими вставками злоупотребляют «патамучто могут».

Ну, котлета, которую я ем тоже, знаешь сделали из коровы, за которой кто-то ухаживал, кормил-поил, потом забил, разделал... ну ты понял в общем. Но это не повод заставлять *меня* делать то же самое, и даже просто видеть это.Так мне не кажется, что идея скрыть всё это — плохая, и более того, то, что язык *заставляет* это не делать — скорее хорошо, чем плохо.

Ты совсем плохо понял, похоже. Тебя никто не заставляет это делать. Подумай ещё разок над разницей между «можно» и «нужно».

Я вроде для тебя привел другой пример: ассемблер в C. *Иногда* он может пригодиться, но в большинстве прикладных задач — не нужен, и более того, вреден, потому что повышает порог вхождения для тех, кто хочет что-то изменить/расширить.

Я — за разумные ограничения языка или, хотя бы, за discourage языком некоторых практик, среди которых обход по структурам данных в циклах.

Я вроде для тебя привел другой пример: ассемблер в C.

Это вообще пример не в ту кассу.

Я — за разумные ограничения языка или, хотя бы, за discourage языком некоторых практик, среди которых обход по структурам данных в циклах.

Ну если тебе нужны ограничения, тут ничем помочь не могу. Многим они не нужны. Я лично затрудняюсь назвать язык программирования без циклов, наверное это потому, что циклы не нужны. Но, в джулии например, они быстрые, а в матлабе или R - адски медленные. И это при том, что джулия - такой же высокоуровневый язык, как матлаб или R. Наверное это потому, что создатели джулии всё испортили, да?

Многим они не нужны.

Не только лишь всем (С)

Релиз языка Julia 1.0 (комментарий)

Напиши свои, а мы их тут дружно обосрём.

Я написал свой вариант Релиз языка Julia 1.0 (комментарий) , давай начинай.

Ох, как же трудно говорить с упертыми. Ограничения не нужны, но нужно поощрение/не поощрение определенного стиля. Одну и ту же мысль можно выразить иероглифами или алфавитным письмом, но алфавитное письмо повсеместно вытестило пиктограммы, хотя и сейчас вместо фразы можно пытаться донести мысль картинками.

Так и тут. Хочешь циклов — welcome в Фортран, он тоже не месте не стоял и сейчас представляет довольно приятный язык. Правда, отлаживать алгоритмы со смехотворным 4-кратным вложением уже довольно трудно и векторная нотация тут могла бы здорово помочь. И это даже в фортране поняли, т.к. там можно писать что-то вроде

v(:) = u

для векторов, и даже будет проведена проверка, что размеры совпадают, или можно написать

v = 2*u, где u и v — массивы, причем v может быть только объявлен, но не размечен (выделения памяти в инициализации).

Поэтому поощрение «писать циклами» может быть не пользу языка, хотя бы потому, что у него уже есть множество конкурентов, с уже сложившейся кодовой базой и пользовательским сообществом.

Ладно, посмотрим, что выйдет. Я по-прежнему отношусь к Julia с некоторым предубеждением — слишком сложно для простого.

Да расслабься. Котлета растёт на кустике уже намазанная на булочку, а продавщица просто срывает бутерброд и продаёт тебе. Продолжай жить в мире своих иллюзий.

Я написал свой вариант Релиз языка Julia 1.0 (комментарий) , давай начинай.

А ты ведь жульничаешь, мошенник маленький. В первом случае ты оцениваешь производительность самого R, а во втором - производительность библиотеки, написанной на C. Ты просто пользуешься тем, что функцию sum, за тебя уже кто-то написал. Конечно, C на порядок быстрее чем R.

R - прекрасный пакет. Но для простого смертного он полезен только в том случае, если нужная модель в нём уже есть. А ты попробуй новую модель написать на R. Я это делал, поэтому знаю, какой это геморой. Kуски кода нужно переносить на фортран (или C). Julia как раз решает эту проблему, ничего никуда переносить не нужно.

И да, в julia функция sum тоже есть, из коробки. Написана она на julia.

Спасибо за разрешение, я пока для прототипирования матлабом с октавой обхожусь, а в продакшн всё равно на фортране писать, поскольку мегалайнсы кода на фортране все равно никто никуда не перепишет. Ну а julia удачи, посмотрим, пройдёт ли она «естественный отбор» или окажется там же, где коболы с бейсиками находятся.

я пока для прототипирования матлабом с октавой обхожусь
Ну а julia удачи, посмотрим, пройдёт ли она «естественный отбор» или окажется там же, где коболы с бейсиками находятся.

С добрым утром, «матлаб с октавой» уже давно там находятся.