LINUX.ORG.RU

Data flow programming

 


1

3

Что-то мне приснилось на днях и подумал я запилить на коленке библиотеку для сабжа.

Основа системы - объект типа модель, который включает в себя ячейки с данными. Между ячейками есть связи, которые описываются наподобии:

(A, B, C) -> (X, Y)

и далее описывается код расчёта данных для ячеек в X и Y в зависимости от данных в ячейках A, B, С. При изменении данных отдельных ячеек в модели на основании вышеописаннх связей какие-то ячейки надо пересчитать, а какие-то нет (отображения функциональны). Называть этот процесс будем обновлением модели. Задача - определить данные каких именно ячеек нужно пересчитать и какой оптимальной последовательностью вычислений это сделать. Подобная задача решается такими программами как система сборки make и менеджерами пакетов. Здесь особенность в том, что основа ячейки - переменные в памяти программы.

Возникли следующие идеи:

Во-первых это понятие представления. Представление состоит из отдельных видов. Это чем-то похоже на модель с ячейками, но виды - это не области памяти, а порты в которые данные выводятся и уже не возвращаются (наподобие стандартных потоков, сокетов). Представление привязано к определённому типу моделей, а данные для видов зависят от данных в ячейках модели наподобие как зависят данные в ячейках между собой. Может в отдельном представлении могут быть переменные, но они уже не зависят от данных модели.

У одного объекта типа модели может быть несколько представлений причём как разных типов так и схожих. Поэтому адрес на объект модели должен быть содержаться в составе объекта представления - без отношения наследования из ООП не смотря на привязанность типа представления к типу модели.

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

Может ещё есть алгоритмы совершеннее вышеописанных идей? Какие алгоритмы полезно изучить для реализации такого?

★★★★★

Ответ на: комментарий от anonymous

xuspViewer :

ZigZag® internal structure as the storage mechanism for document parts and connections

Zzogl™ multidimensional viewer as the animation mechanism

anonymous
()
Ответ на: комментарий от anonymous

Почитал описание структур ZigZag.

У меня все это и много более реализовано, так как метаданные позволяют разработать объект, базу объектов, … любой сложности и ссылками /иерархии, вложенности, …/.

Но почитаю еще о нем.

Может быть какие-то новые идеи и найду ...
anonymous
()
Ответ на: комментарий от anonymous

MSH (см на хабре и на гитхабе репозиторий с реализацией – туда даже GTK впихнули)

автор MSH: Misha Shar хаброюзер announces comp.lang.mumps GitHub SharMisha/MSH

PSL aka Profile: see old GT.M and YottaDB news YottaDB/DBMS/YDBPIP

что-то про формы и lazarus ъ

не считая самого Cache Object Script, конечно же.

так что: реализации объектно-ориентированного MUMPS-а вполне себе доступны.

anonymous
()
Ответ на: комментарий от anonymous

зря его, ИМХО, на хабре заминусовали… я так понял, хабраюзеры вообще не врубились что это и зачем.

хоть он и описал несколько сумбурно, в духе MUMPS uber alles.

однако ж: вот есть реализация в гитхаб репозитории, вполне себе можно скачать и потыкать.

anonymous
()
Ответ на: комментарий от anonymous

в доке: libmshWin.so — библиотека построения экранных форм.

ещё где-то в доке было про то, что GTK поддерживается «из коробки»

anonymous
()
Ответ на: комментарий от anonymous

как там по умолчанию кеширование результатов вычисления функций реализовано

никак, но man мемоизация

Я далеко не эксперт в Haskell, только начал им недавно интересоваться. И почему-то решил, что раз язык гарантирует ссылочную прозрачность, то компилятор должен переиспользовать уже вычисленные значения функции.

Видимо, то, что я имел в виду, правильно называется мемоизация. Я таких тонкостей не знал и называл это кешированием. Спасибо за подсказку, буду знать как правильно гуглить.

aquadon ★★★★★
()
Ответ на: комментарий от aquadon

компилятор должен переиспользовать уже вычисленные значения функции.

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

aquadon ★★★★★
()

Всё уже украдено до нас. (ц)

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

При этом, чтобы начать вычисления во всей цепочке(вообще, не в цепочке, а в ориентированном графе), нам нужно всего лишь обновить самый первый нейрон в этой цепочке, а остальные пересчитаются автоматически. То есть, это такое обобщение event-driven программирования - сигналов-слотов, например.

Но, что самое важное - при всем этом, мы не указываем статически, как нейрон связан с другими нейронами, мы просто внутри функции нейрона «вытаскиваем» значения из них, функцией neuron-value, и связи образуются автоматически и динамически(то есть, в рантайме, а не на основе статического анализа формул).

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

(ц) [Java][Python] Скорость разработки (комментарий)

Код библиотеки: https://github.com/Lovesan/neural-flow

anonymous
()
Ответ на: комментарий от anonymous

А свой синтаксис реализуешь макросами.

anonymous
()
Ответ на: комментарий от anonymous

Интересно конечно как образец, но начинать с этого и погружаться слишком сложно.

Возьму оттуда только идеи пока что.

kolpakchi
()
Ответ на: комментарий от Miguel

Поспорил бы с вами, но вживую … Здесь местные тролли не дадут вести ЗДОРОВУЮ ДИСКУССИЮ.

Владимир

anonymous
()
Ответ на: комментарий от kolpakchi

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

anonymous
()

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

byko3y ★★★★
()
Ответ на: комментарий от kolpakchi

я тут недавно подумал, что нечто подобное также можно было бы изобразить на основе literate programming подхода ссылка и/или, гипертекста в духе Emacs org-mode (ссылка и ниже) или Emacs hyperbole (ссылка и ниже про гиперкнопки)

ну вот то есть:

  1. Jupyter Notebook формат файла в реализации Wolfram Mathematica – это тензор.

клетки, связанные внутри – как говорил молодой репликант, сдавая тест на семантическое ядро для детектора NLP double binding эмоций/логики.

то есть, если например, Emacs org-mode как я понял реализует альтернативное представление .org файлов в формате AST типа SExprs и обрабатывает их далее через емаксовое API, то в hyperbole тут идут уже представления AST в виде матриц. в Mathematica это ещё более явно выражено, то есть, это язык для обработки массивов а не списков.

  1. этот разреженный (не хранящий пустые ячейки в многомерном представлении) тензор запихиваем в нечто вроде объектно-ориентированного MUMPSа.

  2. по которому реализуем истинно многомерный векторный гипертекстовый фидонет или там Xanadu, ну гипермедиа гипертекст то есть. наподобие ZigZag zzStructures.

  3. невозбранно достигнув желаемого, обрабатываем его чем-то вроде hyperbole с неявными гиперкнопками, вызывающими скрипты на любых языках.

  4. и реализуем какой-то OLAP типа Gnumeric (который только 2D, а надобно n-D) с вычисляемыми скриптами в отдельных ячейках.

  5. поверх которой натягиваем нечто вроде skribilo для литературного программирования, редактора на 4,5, ну или

  6. dataflow интерактивный редактор и генератор метапроговый поверх всего этого

  7. реализуя какой-то алгоритм обхода всех этих ячеек (я так понимаю, именно про 8 был изначальный вопрос топикстартера).

kolpakchi> Возьму оттуда только идеи пока что.

у тебя, кажется, тоже был проект какой-то интерактивной среды?

раскажи про него подробнее, что это и зачем.

anonymous
()
Ответ на: комментарий от anonymous

занятная штука этот ваш AbiWord.

вот судя по документу со страницы с скриншотами у него родной формат файла это XML.

который тривиально обрабатывается той же схемой, например в skribilo на guile достаточно реализовать свой reader (да и для xml там вроде уже есть generic reader)

дальше – больше. смотрю в pyabiword для привязок пистона к абиворду, и вижу там вот такое: pyabiword.defs – то есть, питоновые обвязки реализованы поверх схемных на guile.

вот интересно, а родные схемные хипстеры ещё оттудова не выкинули ли.

ну то есть: это же тоже клетки, связанные внутри

со всеми для литературного многомерного гипертекста втекающими и dataflow вытекающими.

anonymous
()
Ответ на: комментарий от anonymous

у тебя, кажется, тоже был проект какой-то интерактивной среды?

я не он, но сам-то что-нибудь пишешь?

anonymous
()
Ответ на: комментарий от anonymous

Просто поначалу очень хотелось покритиковать творчество…

Но вот подумал, подумал и передумал.

ados ★★★★★
() автор топика
Ответ на: комментарий от ados

У него была статья об использовании в ЖЖшке и, возможно, на Хабре. Но проще спросить напрямую.

anonymous
()
Ответ на: комментарий от aquadon

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

Я как-то начитался популяризирующих статей по хаскелю и тоже подумал, что он и мемоизацию делает, и что там компилятор может сделать автоматическое распараллеливание (в статьях писалось, что такое возможно, только не уточнялось, на практике или в фантазиях), и что компилятор может по программе понять, что нужно сделать и сгенерировать эффективный код для этого, а не буквально копировать все это ехала монада через монаду. Но потом несколько разочаровался…

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

коэффекты github :

Dataflow language The second demo is a simple dataflow language where all variables represent streams of values and you can access previous value using the prev keyword. For example (x + prev x) / 2 calculates the average over the current and previous value. Here, coeffects track how many past values you need.

Dataflow computations
In dataflow languages, each expression denotes a stream of values. The streams can be low-level like hardware signals or high-level such as mouse position in modern reactive programming. In our language, you can use the prev keyword to access the previous value of a stream. Coeffects infer how many past values a function may access.

Experiment with dataflow programming here! You can use the same core language as earlier; prev e accesses the previous value of e and you can nest them and write prev (prev e).

fun n -> (n + prev n) / 2 The program is well-typed. The type system reports the following type and coeffect information:

@⊢fun n→…/2:num→1num The function requires some input streams. You can set their current and historical values here:

n[0] = 0 n[1] = 0 result = 0

ну чем борода не санки не жупитер ноутбук метапроговый, сам на себе?

anonymous
()
Ответ на: комментарий от goingUp

Еще я думал ленивые вычисления ускоряют выполнение программы, а потом я узнал, что это в том числе из-за них хаскель так и тормозит)

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

например, literate programming в noweb по сути тоже dataflow:

  • noweb был написан на icon с goal-oriented execution моделью вычислений, с ковыражениями лениво вычисляющими блоки кода/блоки данных.

  • ещё там были shell filters для postprocessing, например в Ulix OS book-ulix.pdf/.nw/Makefile стиль постпроцессингом на питоне прицепили.. но по сути что-то вроде dgsh

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

  • в Emacs org-mode например у блоков могут быть переменные входные и выходные. то есть, это уже больше на cells выше похоже

  • или на монады с контекстами к коэффектами (дуальными к эффектам)

anonymous
()
Ответ на: комментарий от anonymous

тыц :

If one builds a Web framework atop a generic dataflow library supporting dynamic, transparent, “point” dependency tracking, and state change propagation, then declarative authoring and efficient DOM maintenance comes for free. More comprehensively and more efficiently, by the way, than with ReactJS.

anonymous
()
Ответ на: комментарий от goingUp

А как проявляются тормоза от ленивых вычислений?

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

Может ты имел в виду недостаточную отзывчивость программы в тот момент, когда ты ждёшь от нее результата вычисления определенного выражения, а это влечет за собой рекурсивное вычисление других выражений, которые иначе могли быть вычислены в период простоя (ожидание пользовательского ввода, etc)?

aquadon ★★★★★
()
Ответ на: комментарий от aquadon

А как проявляются тормоза от ленивых вычислений?

Под тормозами имелась в виду низкая производительность, а не залипания программы, хотя я не утверждаю, что залипаний в стиле gc жавы не будет) Оверхед от ленивых вычислений превышает преимущества. Хаскель под них создает структурки в памяти, а потом оно по большей части все равно вычисляется, а все эти структурки идут в оверхед. Возможны даже неожиданные побочные эффекты Степпер для SBCL - помогайте (комментарий) Тем временем в каком-то C++ все равно лишнее не будет вычисляться, потому что будут стоять какие-то ifы, а компилятор реально выкинет какие-то формулы, результаты которых нигде не используются, и всё это с нулевым оверхедом.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 3)
Ответ на: комментарий от anonymous

в Emacs org-mode например у блоков могут быть переменные входные и выходные

я как-то испытывал орг бабел. че-то с чем-то соединял. вроде по началу норм было.

ВНЕЗАПНО вся эта мазня начала тормозить просто как ублюдок дауна. из-за конверсий стурктур, вестимо. перешел тупа на обычные проекты, все перевел на питон. не пожалел ни разу. все стало о понятнее и быстрее, заметки отдельно.

anonymous
()
Ответ на: комментарий от anonymous

у тебя, кажется, тоже был проект какой-то интерактивной среды?

раскажи про него подробнее, что это и зачем.

В данный момент у меня целая таблица одних только абстрактных идей, которые я хочу реализовать прямо или косвенно в одном устройстве. И 3 написанных с нуля версии, с кучей бэкапов.

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

Во второй версии была одна структура данных в виде JSON дерева (основная структура - список объектов, который отображался как таблица, в ячейки которой можно вводить текст, число, undefined, или ссылку. Каждая строка - объект), в которую я пытался впихнуть все подряд с переменным успехом. Некоторые ячейки содержали функции (методы объекта), одни вызвались при загрузке по несколько раз, пока не возвращали true, другие просто при нажатии на ячейку.

Однажды я заметил что мой JSON файл стал очень большим, процесс пересчёта всех ячеек стал очень долгим. Тогда появилась 3я текущая версия, где вместо json дерева - база данных (bson файл). Тут уже нельзя пересчитать сразу все ячейки, и база данных не позволяет составить так просто дерево, поэтому некоторые рабочие идеи из 2й версии до сих пор отсутствуют. Хотя и вторая версия по сравнению с первой потеряла возможность связываться с микроконтроллером. Так что тут сплошные эксперименты.

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

Таким образом моя база данных содержит таблицы, каждая ячейка которых является объектом. Таблица напоминает Excel, но вместо формул - JavaScript, который можно попытаться запустить по двойному нажатию. Вот тут я и провожу все эксперименты. Получился Jupiter notebook с минималистичным интерфейсом типа Excel, и хранением таблиц в базе данных.

В текущей версии я запускаю сервер, который в зависимости от запроса либо просто возвращает файлы как обычный сервер, либо возвращает таблицы с объектами из базы данных и сохраняет их.

Потом открываю одностраничный сайт-приложение, который связывается с сервером. Сайт выглядит как Excel, является объектом JavaScript. Это центральный объект, он создаётся один раз при загрузке страницы.

Этот объект - это общий контекст для всего проекта.

При старте после загрузки сайта он содержит методы отображения и редактирования.

Затем он загружает первую таблицу из базы и добавляет к себе в поля в виде двумерного массива. Он отображает таблицу в HTML-таблицу, которая вызывает его методы. То есть когда я меняю таблицу в браузере, браузер просто вызывает методы центрального объекта.

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

Скрипт из ячейки при запуске свободно получает доступ к этому центральному объекту и может делать что угодно: лазить по таблице, лазить в базу данных, перегружать таблицы, модифицировать страницу.

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

Например календарь сделал недавно. Прямо в таблице. Ну, этим никого не удивишь, но мне нравится.

kolpakchi
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.