Julia 0.5

julia> 1/1000000000000000*100000000000000000000
100000.00000000001

clisp> (/ 1 (* 1000000000000000 100000000000000000000))
1/100000000000000000000000000000000000

;;SBCL
* (/ 1 (* 1000000000000000 100000000000000000000))
1/100000000000000000000000000000000000

(guile-user)> (/ 1 (* 1000000000000000 100000000000000000000))
$1 = 1/100000000000000000000000000000000000

Так в Lisp и Scheme по стандарту(Numerical tower).

Память течь перестала? Год назад это была основная причина, почему отказались от Julia в пользу Numpy, хотя потеряли прилично по скорости.

Но то чушь, просто показал тип ratio в lisp. Должно быть:

(* (/ 1 1000000000000000) 100000000000000000000)
100000

Не нравится некоторым префиксная нотация для формул. Но при этом только в lisp операции над числами действительно пригодны для математических вычислений.

Ясно.

julia занимает место языков протитипирования (DSL)

Это каким макаром ты связал DSL и прототипирование?

А как ты относишься к DSL?

Это каким макаром ты связал DSL и прототипирование?

А это ровно оно!

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

Ну и прототипирование — это как раз занятие, где исследователь (программист) работает над проблемой в этом самом домене — обкатывает алгоритмы. Производительность тут вообще не на первом месте.

Возвращаясь к Julia, я как раз и говорю о том, что из DSL для вычметодов/матричной алгебры она начинает лезть в другие области, становясь языком общего назначения. К сожалению, делая все менее и менее удобным работу в своём домене — программист начинает думать не в терминах домена, а в терминах языка и его ограничений. Начиная с некоторого порога Julia может растерять все свои преимущества перед, например, Фортраном, который в цепочке 77-90-95-2003 как раз мигрировал в обратном направлении, становясь все более и более DSL для матричных вычислений. В 2003 стандарте уже можно писать почти что как в матлабе, особливо если заранее определить такие операции как «матричное умножение».

А как ты относишься к DSL?

положительно.

Возвращаясь к Julia, я как раз и говорю о том, что из DSL для вычметодов/матричной алгебры она начинает лезть в другие области, становясь языком общего назначения. К сожалению, делая все менее и менее удобным работу в своём домене — программист начинает думать не в терминах домена, а в терминах языка и его ограничений.

С этим согласен. Не хотелось бы чтоб Юля превратилась язык общего назначения - таких уже много. Она должна остатся доменным языком математиков, статистиков, и прочих научных деятелей.

Ну и прототипирование — это как раз занятие, где исследователь (программист) работает над проблемой в этом самом домене — обкатывает алгоритмы. Производительность тут вообще не на первом месте.

А тут не соглашусь. Тем кому надо язык прототипирования - уже есть все от Матлаба до R до Питона - выбирай на вкус. Но очень многим нужен именно высокопроизводительный язык для трудоемких вычислений, но при этом сохранивший упор на математико-научный подход. Например, производительные операции на векторах (целиком), символные вычисления, анализ измерений встроенный в типовую систему, итп.

Прочая шняга, например библиотеки TCP/IP или Юникод - нафиг не нужны в стандартной библиотеке, и жаль что на это тратится куча времени. Но производительность - нужна абсолютно. Julia нужна как язык самих вычислений, а не только как язык прототипирования вычислений.

Иными словами - Юла должна стать идейным продолжителем Фортрана и Алгола, а не только Питона и Матлаба.

Тем кому надо язык прототипирования - уже есть все от Матлаба до R до Питона

Не совсем. Матлаб и R — это языки прототипирования «предыдущего» поколения. Они накопили уже legacy багаж и кардинальные изменения языка уже невозможны.

У julia есть (был) такой шанс — стать языком протипирования следующего поколения. И при этом увеличить эффективность — хотя это последствия, а не цель.

И поначалу она двигалась в нужном направлении. Мне очень импонирует идея multiple dispatch вкупе с развитой системой типов — она позволяла бы реализовывать generic алгоритмы с минимальными трудозатратами. Например, диагонализация матриц с элементами из числовых полей, а то и вообще колец (типа целых). Но потом всё пошло наперекосяк — разработчики скатились в низкоуровневое программирование. Например, меня искренне возмутила рекомендация по де-векторизации кода. Это надо крепко укуриться, чтобы, грубо говоря, рекомендовать писать цикл для вычисления скалярного произведения или матрично-векторного умножения! И дело даже не в эффективности, а в компактности и читаемости кода. Вместо одной строчки, которая недвусмысленно выражает суть вычисления, получаем опять много строк generic кода, который надо пристально разглядывать, чтобы понять, что в нём делается. Тогда уж Фортран, раз всё равно надо сначала топтать клаву, а потом читатель должен разбирать простыню тривиального кода, чтобы вычленить из неё суть.

Другой пример, где julia могла бы выстрелить — вычисления с повышенной и произвольной точностью, опять-таки при условии эффективной реализации generic алгоритмов. Я лично возлагал большие надежды на неё, но увы — в этом направлении движения нет. А как было бы здорово не переписывая программу увеличить, скажем, точность расчетов с 15 до 30 знаков! У меня вот есть алгоритм экспоненциально точного решения уравнения Хартри-Фока для атомов, так что увеличение точности в 2 раза означает лишь некоторый полиномиальный рост затрат. И эффекты интересные можно обсуждать, такие как «ложные» узлы орбиталей или свойства density (orbital)-to-potential mappings.

Ну это лирика. А суть в том, что julia, по моему мнению, движется не туда.

Хз, по-моему у тебя каша в голове, прототипирование это этап разработки, DSL - один из способов выражения абстракций, связи я никакой не вижу.

Держи

связи я никакой не вижу.

Бывает.

Явное лучше неявного. Да, а ещё префиксные нотации и скобки не нужны.

In [2]: from fractions import Fraction

In [3]: Fraction(1, 1000000000000000) * 100000000000000000000
Out[3]: Fraction(100000, 1)

Prelude> (1 / 1000000000000000 :: Rational) * 100000000000000000000
100000 % 1

Покажешь или ты просто так потрепаться зашел?

нормальный наркоманский язык. а насколько он быстр?
надо язык что-бы парсить большие логи быстро. так-же быстро как мапленные файлы на c, но компактно и скриптово.

Был бы ты менее хамлом, показал бы. Но видимо, придётся ответить, что зашёл потрепаться.

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

Тут не место манерами раскидываться, это можешь со своими коллегами потренировать. Раз сказал «a» говори и «б».

а насколько он быстр?

Вот ты нам и расскажешь. Могу сказать только что Red/System компилится в натив, а сам Red - скриптовый, динамичный с кучей возможностей. Насколько он подойдет для парсинга больших логов напрямую зависит от того как ты сможешь это использовать.

Вообще-то я зарплату получаю за то, что объясняю дубам непонятливым то, что им не очевидно. А хамлу, да ещё и бесплатно, я уж точно не отвечаю. Так что не обессудь.

Левенчук для DeepLearning'a нахваливал

что тут делается.

Что тут делается, что тут делается... Тут что-то крякает как утка, а там оно плавает как утка. Вот это и делается.

И поначалу она двигалась в нужном направлении. Мне очень импонирует идея multiple dispatch вкупе с развитой системой типов — она позволяла бы реализовывать generic алгоритмы с минимальными трудозатратами. Например, диагонализация матриц с элементами из числовых полей, а то и вообще колец (типа целых). Но потом всё пошло наперекосяк — разработчики скатились в низкоуровневое программирование. Например, меня искренне возмутила рекомендация по де-векторизации кода. Это надо крепко укуриться, чтобы, грубо говоря, рекомендовать писать цикл для вычисления скалярного произведения или матрично-векторного умножения!

Согласно блог-посту http://julialang.org/blog/2016/10/julia-0.5-highlights , все не так плохо. В Julia 0.5 добавлена авто-оптимизация функций до эквивалентной векторизации, и сама векторизация доступна через синтаксис языка: пишем f.(a,b,c) вместо f(a,b,c) и все.

Ну да, все равно как бы лишний символ писать нужно, но думаю все же язык не сферический конь в вакуме, и при высоких требованиях к скорости, полностью абстрактироватся от примитивов железа не получится. Иначе возвращаемся к Питону/R и соответсвтующей производительности.

Иными словами, например, я полностью ЗА легкое и доступное символьное вычисление, но если в коде стоит просто 1.23, то это должно оставаться именно флоат 1.23 согласно IEEE 754, а не какой нибудь символьный тип.

Для Deep Learning рулят библиотеки (TensorFlow, Torch, Caffe и т.д.), а не языки. У Julia в репах ничего толком нет для DL и ML.

Например, меня искренне возмутила рекомендация по де-векторизации кода. Это надо крепко укуриться, чтобы, грубо говоря, рекомендовать писать цикл для вычисления скалярного произведения или матрично-векторного умножения!

Это устаревшая рекомендация еще версии 0.3. Начиная с 0.4 (больше в 0.5, еще больше в будущем) авто-оптимизации векторизированого кода не будет уступать ручному алгоритму, и для многих алгоритмов авторы уже наоборот рекомендуют использовать векторизацию.

Пруф - https://github.com/JuliaLang/julia/issues/16285

Блин, пусти меня во вселенную, где сначала существуют фреймворки, библиотеки, и комьюнити, а потом уже под них пилят собственно языки :-)

О, это здорово!

Да фигню человек спорол, не обращай внимания.

http://ailev.livejournal.com/1164251.html

Об Julia language

Сегодня в порядке воскресного развлечения поставил Juno+Julia (http://junolab.org/ — это IDE Light Table + Julia), потрогал язык живьём. Эх, мне бы этот язык году так в 1977 (когда я начал заниматься распознаванием образов/image recognition, тогда так называлось machine learning), я был бы счастлив безумно. Но нет, приходилось работать на Fortran и PL/1 (ибо считал я тогда на EC-1022 главным образом). Для численного моделирования в этом языке есть всё и ещё чуть-чуть. Поддержка изнутри языка кодов LaTeX (ага, греческие идентификаторы — не вопрос), встроенные типы комплексных и рациональных чисел.

Интересно, только надо учесть, что написано полтора года назад. Вытащу более свежие записи

http://ailev.livejournal.com/1304085.html

http://ailev.livejournal.com/1218155.html

Синтаксис это замечательно. Поддержка чисел это замечательно, но, по моему мнению, этого сейчас недостаточно.

В том же image recognition нужна куча алгоритмов. Где они есть? Например в OpenCV. Смотрим на состояние биндингов.

Биндинги к стабильным модулям не доделаны (см. список модулей тут https://juliaopencv.github.io/latest/index.html и смотрим список модулей тут http://docs.opencv.org/master/).

И если для Core модулей биндинги есть, то для Extra их нет вообще. А в Extra есть такие полезности, как tracking.

Вот и получается, что легче и логичнее взять Python, для которого биндинги уже имеются (и ими пользуются сами разработчики модулей, см. https://github.com/opencv/opencv_contrib/tree/master/modules/tracking/samples).

Да, вариант сделать биндинги самому или реализовать нужный алгоритм на Julia имеется. Но это время. И сравнивая варианты - взять Python с готовыми модулями или взять Julia без модулей, я не вижу таких громадных преимуществ у Julia.