DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 03:23

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 83 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: ДРАКОН и Биржа
СообщениеДобавлено: Четверг, 08 Сентябрь, 2016 23:19 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
facevalue писал(а):
нужно разбираться еще и в этом софте. Он и сейчас не для новичков. Подход Дракона многое бы изменил.
Давайте различать сложность инструмента и сложность решения задачи с его помощью.

Дополнительная сложность, вносимая инструментом, есть безусловное зло. Однако в когнитивном плане не всё так страшно - это разовые затраты.
Имеет ли здесь ДРАКОН преимущества? Не очень корректный вопрос, потому что непонятно, что именно и как сравнивать.

О сложности решения задачи в зависимости от языка - ниже.

Цитата:
ЮМЛ... Потом кодится... Переделывается...
Какое вообще отношение плохо организованный процесс имеет к вопросу? ;) Боюсь, что это просто констатация очевидного бардака.
Но если мы говорим о user friendly софте, который позволяет пользователю решать специфическую задачу, не нужен UML, а нужен DSL (domain specific language), который в максимальной степени оберегает пользователя от дополнительной, не свойственной задаче сложности, выражается на понятном пользователю языке, направляет и поддерживает надёжный (безошибочный) процесс разработки.
Это, так сказать, общие требования, ТЗ.

Цитата:
логика построения ЮМЛ не помогает, а способствует допущению ошибок.
Что характеризует эклектичность набора инструментов, неадекватность инструмента решаемой задаче.

Цитата:
Если что-то в алгоритме не продумано до низкого уровня (вопрос - ответ да/нет), это видно сразу.
Агащаз.
Это в таблице решений непродуманные моменты видны сразу, а ДРАКОН тут практически ничего не даёт по сравнению с классическими блок-схемами.

Цитата:
Благодаря этому же принципу идеи и наработки появляются в процессе работы над БС, а не над кодом.
БС - это и есть код. Просто языки разные, перевод требуется.
А уже степень автоматизации этого перевода - качественная характеристика инструмента (IDE, например), но никак не самих языков.

Цитата:
и программист СРАЗУ написал РАБОЧИЙ ИЗНАЧАЛЬНО код.
См. выше. По-моему, совершенно неуместно восхищаться очевидным (почти) тождественным преобразованием.

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

Цитата:
Обычное ПО статичное, квадратное. Его можно разработать на бумажке, и оно будет работать. Биржевое ПО имеет дело с постоянно меняющимися данными.
Это шутка, непонимание или некорректный пиар?

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

Цитата:
В больших высоких небоскребах эта проблема решается брутфорсом - много-много программистов.
В ответственных приложениях (каковыми занимаются многие из здесь присутствующих) количеством программистов легче убить проект, чем решить задачу путём брутфорса! ;)

Цитата:
Это одна из проблем "евангелизации" - все думают, что ничего нового.
Нифига.
Просто есть специалисты, которые адекватно оценивают плюсы-минусы инструмента, а есть те, которые евангелия пишут ;)

Цитата:
Этот ряд исключает допущение ошибок.
Нифига.
Синтаксические ошибки никому не интересны - сегодня есть множество способов борьбы с ними вплоть до невозможности их совершения.
Основные ошибки всегда в семантике, а здесь "серебряной пули" нет.

Цитата:
Function Block Diagram? Напоминает упрощенный ЮМЛ... Или ошибаюсь?
FBD описывает структуру динамической системы (в которой протекает физический процесс).
В этом смысле FBD - первична, как первично дифференциальное уравнение, описывающее динамическую систему.
Здесь выражена суть системы.

Но вы постоянно говорите об алгоритмическом слое. А он вторичен. Он всего лишь даёт один из способов решения (расчёта процессов в системе).
И алгоритм не отображает сути процесса. В этом его ущербность (как в философском, так и в весьма практическом смысле).
И отношение между ними однозначное: из структурной схемы процесса выводится алгоритм его моделирования (или управления), причём МНОГИМИ способами. Но никак не наоборот!
Вы сначала строите матмодель процесса (дифуры etc.), а потом применяете алгоритмы, чтобы эту матмодель обсчитать (выполнить нужные действия по преобразованию потоков данных).
И никто по алгоритму дифуры (структуру системы) не восстанавливает.
Потому какие новые идеи могут вообще прийти в голову при работе с алгоритмами? Разве что технические (оптимизация самого алгоритма).

Цитата:
Алгоритмический язык нужен для построения логики, для единого обмена информацией между разработчиками алгоритмов и программистами.
Что делают разработчики алгоритмов и зачем вообще здесь нужны программисты?
Нормальный DSL не требует промежуточных прослоек!

...
Что-то не срастается - движок пишет "Достигнут максимальный общий размер ваших вложений". Что бы это значило?
Попробую остальное отдельным сообщением.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Четверг, 08 Сентябрь, 2016 23:54 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Продолжим.
Что есть биржевая задача (алготрейдинг)?
Это задача управления входным потоком данных. И это по сути всё!

Целесообразно ли ограничиваться алгоритмическими способами при решении задач по формированию такого управления?
Нет.

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

Собственно, развиваю тут тему, намеченную в предыдущем сообщении - какой DSL удобнее для пользователя.

Вот совершенно абстрактный пример, в котором вычисляются два индикатора, на основе которых генерируются сигналы торговой системе (на открытие позиции и т.п.).
Первая картинка - FBD. Без дидактического приукрашивания, просто скриншот одной из моих IDE (для моделирования динамических систем, программирования контроллеров и т.п. задач):

Изображение

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

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

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

Изображение

Очевидно, что над этим алгоритмом можно выполнять различные гомеоморфные преобразования - но зачем об этом знать пользователю?
Зачем вообще пользователю видеть алгоритм, а тем более его разрабатывать?!
Для него главное - логика. Что с чем сравнивать и как генерировать нужные сигналы.
А что наиболее удобно для проектирования логических схем? Логическая схема (на языке FBD)!

И где здесь программист? И зачем он вообще?
Программист в данной задаче столь же не нужен, сколь и алгоритмы!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН и Биржа
СообщениеДобавлено: Пятница, 09 Сентябрь, 2016 01:49 

Зарегистрирован: Четверг, 25 Август, 2016 14:35
Сообщения: 24
Alexey_Donskoy писал(а):
...Дополнительная сложность, вносимая инструментом, есть безусловное зло. Однако в когнитивном плане не всё так страшно - это разовые затраты.
Имеет ли здесь ДРАКОН преимущества? Не очень корректный вопрос, потому что непонятно, что именно и как сравнивать.

Оу нет. ))) Уж никак это не разовые затраты. Это вообще для бизнеса боль. Что значит разовые затраты? На нового ответственного, который во всем разберется? В ЮМЛ, ФБД или еще какой-то сложной системе трансляции логики? Или покупать специалиста, который разбирается и зависеть от него? Для чтения Дракон-схем ничего специфического не нужно. Только логика девятого класса средней школы.

Для чтения ВСЕХ других схем нужны весьма специфические знания, которые ко всему еще и НЕ ЭРГОНОМИЧНЫ для изложения. Мы с Вами можем переписываться азбукой морзе - клавиатура из точки и тире выглядела бы весьма правильной для специалистов начала 20-го века, и они бы в один голос твердили, что клавиатура из 102 клавиш - это больной бред сумасшедшего, который просто не умеет пользоваться простой и понятной всем морзянкой. )

Цитата:
Цитата:
ЮМЛ... Потом кодится... Переделывается...

Какое вообще отношение плохо организованный процесс имеет к вопросу? ;)


Эээ... Вы хотите сказать, что весь код в "православных" организациях пишется с нуля и сразу рабочий? Т.е., опыт моей работы QA в Apple коту под хвост, и вообще QA напрасно едят свой хлеб насущный? Я Вас в который раз ловлю на том, что Вы умудряетесь ставить оценки процессам, о которых мягко говоря ничего не знаете.

Цитата:
Но если мы говорим о user friendly софте, который позволяет пользователю решать специфическую задачу, не нужен UML, а нужен DSL (domain specific language), который в максимальной степени оберегает пользователя от дополнительной, не свойственной задаче сложности, выражается на понятном пользователю языке, направляет и поддерживает надёжный (безошибочный) процесс разработки.


Я даже не буду утруждать себя опровержением этого утверждения. DSL не менее сложен в чтении, чем тот же UML. Ну может чуток проще. В остальном - где правила построения и чтения? Где эргономика, которая не зависит от художественных способностей разработчика алгоритма, а ЧЕТКО ГВОЗДЯМИ прибита в правилах построения схем? Мне как руководителю индифферентны художественные способности алгоритмиста или программиста, как и его персональная способность к эргономичной логике - зачастую такая способность отсутствует. Я выдал ему листик А5 с инструкцией, и на выходе получаю читабельный с первого раза документ.

Цитата:
Цитата:
Если что-то в алгоритме не продумано до низкого уровня (вопрос - ответ да/нет), это видно сразу.
Агащаз.
Это в таблице решений непродуманные моменты видны сразу, а ДРАКОН тут практически ничего не даёт по сравнению с классическими блок-схемами.


Докажите. Я на опыте убедился в том, что обычная блок-схема прячет ошибки в виду того, что логика схемы строится произвольно. В Дракон-схемах логика просчитывается до никого уровня благодаря "квадратным" ЗАРАНЕЕ ИЗВЕСТНЫМ правилам ее построения.

Цитата:
Цитата:
Благодаря этому же принципу идеи и наработки появляются в процессе работы над БС, а не над кодом.
БС - это и есть код. Просто языки разные, перевод требуется.


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

Цитата:
Цитата:
и программист СРАЗУ написал РАБОЧИЙ ИЗНАЧАЛЬНО код.
См. выше. По-моему, совершенно неуместно восхищаться очевидным (почти) тождественным преобразованием.


Смотрите выше. Я не знаю как там у Вас, но в Apple очень редко все работает с первого раза. Очень редко. Я бы сказал никогда по опыту работы QA. Больше нигде по найму не работал, поэтому претендовать на истину не буду.

Цитата:
Но я таки опять не понял, о разработке чего именно здесь идёт речь? Конкретного торгового алгоритма, который в идеале надо бы строить из кубиков DSL и не заморачиваться с трансляцией в код и т.п.?


Кубики и код - разные средства под разные задачи. Сейчас я говорю о графическом построении алгоритмов. Превращать Дракон-схему в код пока что нет задачи. Я собственно ее и не поднимал как вопрос.

Цитата:
Цитата:
Обычное ПО статичное, квадратное. Его можно разработать на бумажке, и оно будет работать. Биржевое ПО имеет дело с постоянно меняющимися данными.
Это шутка, непонимание или некорректный пиар?
Никакого принципиального отличия биржевого ПО от "всего прочего" нет и быть не может.
Огромное количество софта, управляющее оборудованием, технологическими процессами, полётами, мобильной связью и т.д. и т.п. - всё это имеет дело с постоянно меняющимися данными.


Отличие есть. Со мной работал программист, который написал полную инфраструктуру обслуживания СМС-обмена для одного мобильного оператора. Система работает до сих пор. Так вот, с хранилищем тиковых данных он "воевал" пол года. Я не отрицаю и не отрицал, что есть системы и посложнее биржевых, но говоря о 90% программистов - они с большим трудом осваивают алготрейдинг именно ввиду специфики меняющихся данных. Под это дело сейчас два института разрабатывают AI. Не думаю, что забавы ради...
Цитата:
Цитата:
Это одна из проблем "евангелизации" - все думают, что ничего нового.
Нифига.
Просто есть специалисты, которые адекватно оценивают плюсы-минусы инструмента, а есть те, которые евангелия пишут ;)

Большинство таких "специалистов" не пригодны для использования. Потому что застревают в развитии, придерживаясь зачастую доисторических рукописей. Если бы все придерживались Вашей точки зрения как единственно верной, отвергая "евангелия", то мы бы по сей день пользовались клавиатурой из двух клавиш. Весь научный прогресс построен на евангелиях, за которые частенько предварительно сжигали авторов. ;)

Цитата:
Но вы постоянно говорите об алгоритмическом слое. А он вторичен.

Если не считать молекулярный или квантовый слой, то первичен. Скажем, тик невозможно описать алгоритмом. Как поделить на ноль нельзя. Но сложить два тика - это уже алгоритм. Из двух тиков вычленить время и объем - это уже алгоритм. Из массива тиков со временем и объемом выделить значение среднего объема на каждый момент времени - это уже алгоритм. Рассчитать отклонения средних значений - это тоже алгоритм. Логика торговых решений на базе полученных данных - алгоритм. Т.е., всё, кроме самого тика - алгоритм в той или иной мере. Можно думать об этом как о функции, с точки зрения программирования, но столкнувшись с реальными задачами и реальными программистами - сложить два тика вместе это не функция. ))) Сначала это будет алгоритм, который позже превратится в функцию.


Последний раз редактировалось facevalue Пятница, 09 Сентябрь, 2016 02:30, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Пятница, 09 Сентябрь, 2016 02:27 

Зарегистрирован: Четверг, 25 Август, 2016 14:35
Сообщения: 24
Alexey_Donskoy писал(а):
Продолжим.
Что есть биржевая задача (алготрейдинг)?
Это задача управления входным потоком данных. И это по сути всё!

Целесообразно ли ограничиваться алгоритмическими способами при решении задач по формированию такого управления?
Нет.


Очень внимательно прочитал весь текст, и осознал, что мы говорим немного на разных языках. Первое - говоря о разработке алгоритмов я вообще не имею ввиду программирование в голом виде. Второе - функции, которые заложены в кубики, и которые трейдеру не обязательно знать (как детально рассчитывается RSI, к примеру) действительно давно зашиты в визуальные индикаторы. Есть investopedia, где практически любая "функция" описана. Третье - я не говорю о том, чтобы программировать средствами Дракона (используя goto). Я говорю о графической разработке, которая унифицирует работу алгоритмиста и программиста по ЖЕСТКОЙ формуле. Один китаец, второй русский, но говорить оба должны на английском. Дракон - это "английский" язык для алгоритмиста и программиста.

Вернусь к истокам темы - для построения биржевых алгоритмов (а это не просто купи/продай) можно использовать что угодно. Собственно, как это сейчас и делают. Но беда везде одна - нет общепринятых правил построения и последующего чтения. Нигде. Каждый волен ваять свою статую. Дракон решает эту проблему. DSL и другие - нет. Возможно, решают уже на этапе разработки непосредственно программного кода. Но в поднятом мной вопросе не это было главной темой.

Дальше. Существует отдельная профессия "разработчик торговых алгоритмов", и зачастую это не программисты. Потому что особенность мышления программистов не позволяет им создавать биржевые алгоритмы. Редко когда программист "80-го уровня" способен разработать прибыльный алгоритм. Он может сделать супербыстрый код, который будет опережать "соседа" на пару миллисекунд (что бывает критично в нашем бизнесе), но алгоритм он не придумает. Это не камень в их огород. Это действительно связано со спецификой мышления. Это общепризнанный мировой факт. И это принципиальная задача, вызов, требование, которое стоит перед разработчиком алгоритмов - не код написать, а собрать из "кубиков" последовательность, которую потом программист превратит в исполняемый код. Главная линия раздела тут в одном - последовательность должна собираться так, чтобы ни во время ее сборки, ни во время "кодинга" не появлялась зависимость от специального человека в РАСШИФРОВКЕ полученных последовательностей. Расшифровка должна быть понятна on the fly моей помощнице. Все остальное - сложная, нечитабельная и нерабочая версия.

Повторюсь, Дракон выполняет роль английского языка для китайца и русского. Зачастую - и для двух китайцев, и для двух русских. )))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Пятница, 09 Сентябрь, 2016 09:07 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
Например, в результате кодогенерации мы можем получить вот такой вариант:

Изображение

Очень жёстко передёргиваете.
Это не кодогенерация, а интерпретация(upd: исходной FBD) для последовательного исполнителя. В общем случае одна из многих возможных.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Пятница, 09 Сентябрь, 2016 13:48 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Это не кодогенерация, а интерпретация(upd: исходной FBD) для последовательного исполнителя.
FBD - метаданные, модель. С которой можно делать что угодно (решать задачи совершенно разного типа).
В данном случае не интерпретация (как в смысле "выполнения кода", так и в смысле "трактовки"), а генерация программы для решения конкретной задачи на основе модели.

Цитата:
В общем случае одна из многих возможных.
Разве я там же не повторил это много раз? ;)


facevalue писал(а):
Только логика девятого класса средней школы
Здесь опять имеется смешение уровней и понятий (профессиональное использование vs. использование непрофессионалами).
Логика такая в общем случае ущербна.
Например, в первом классе всех учили писать ручкой, а потом уже осваивать компьютер. Апелляция к уровню "писания ручкой" сразу переводит дискуссию на уровень, простите, флеймоопасной пропаганды.

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

Цитата:
вообще QA напрасно едят свой хлеб насущный?
Я хочу сказать, что организация разработки, при которой программисты кодят по модели UML, а потом вносят изменения в код - это крайне плохая организация. И ваш опыт QA в Apple ровным счётом ничего в этой оценке не изменит, потому как в подобной ситуации это борьба со следствиями, а не с причинами.

Цитата:
Я даже не буду утруждать себя опровержением этого утверждения.
А вот это крайне напрасно. Тут как раз я вынужден в очередной раз ловить вас на немотивированной предвзятости, граничащей с пропагандой.

Цитата:
DSL не менее сложен в чтении, чем тот же UML.
Это очередная шутка такая?
Для электрика DSL - это электрическая схема. Вы тоже собираетесь её раскатывать алгоритмическим слоем и представлять в Драконе?! :facepalm:

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

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

Цитата:
Я на опыте убедился в том, что обычная блок-схема прячет ошибки в виду того, что логика схемы строится произвольно.
Естественно.
И очевидно, что Дракон со своими правилами вносит мощное организующее начало - по сравнению.
Но опять-таки по сравнению - с действительно адекватным и эргономичным DSL - вопрос повисает в воздухе.
Потому что сам по себе Дракон закрывает довольно узкую (хотя и важную) область.
А что во всех остальных делать? См. выше - правила разрабатывать!

Цитата:
если говорить о простых понятных вещах, то БС и программный код - это разные вещи.
А вот не надо "говорить о простых понятных вещах".
Говорить надо об эффективности решения задач, в том числе за счёт грамотной постановки, качественной матмодели и только в последнюю очередь - за счёт эргономичных инструментов.

Разумеется, узкие места надо расшивать в первую очередь. С этим никто не спорит.

Цитата:
они с большим трудом осваивают алготрейдинг именно ввиду специфики меняющихся данных
Ну дык, ёлы-палы. Очевидно, что такие штуки, как реалтайм-процессы, параллельность, AI и прочее - сродни новым парадигмам, в освоении которых 90% людей будут испытывать немалые трудности.
Однако ж это не даёт права говорить об одном подклассе задач из множества как о чём-то исключительном.

Цитата:
... - это уже алгоритм
А вот и нет.
Это прежде всего математика. Это именно функция.
А алгоритм - частное решение матмодели. Реализация функции (коих может быть много).
Несмотря на простоту (или сложность) обсуждаемых понятий, различие этих уровней всегда остаётся принципиальным и важным.

Цитата:
Дракон - это "английский" язык для алгоритмиста и программиста.
Это хорошо, но недостаточно.
Ибо программист здесь - лишнее звено.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Пятница, 09 Сентябрь, 2016 21:18 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
В данном случае интерпретация именно в смысле "трактовки"/"толкования" исходной FBD для последовательного исполнителя.
поскольку
Alexey_Donskoy писал(а):
FBD сама по себе не содержит информации о том, какой блок на схеме должен выполняться раньше, который позже.. По сути своей потоки постоянны, процессы параллельны.

и эта информация вносится на этапе того самого "толкования". Причём прямо противоречащая уже имеющейся в модели. :oops:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Пятница, 09 Сентябрь, 2016 23:49 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
и эта информация вносится на этапе того самого "толкования".
Ну дык, переход от аналога к цифре - от непрерывного к дискретному. Неизбежность.

Цитата:
Причём прямо противоречащая уже имеющейся в модели.
В каком месте?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Суббота, 10 Сентябрь, 2016 11:28 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Алексей Донской писал(а):
Просто есть специалисты, которые адекватно оценивают плюсы-минусы инструмента, а есть те, которые евангелия пишут

Алекс facevalue писал(а):
Большинство таких "специалистов" не пригодны для использования. Потому что застревают в развитии, придерживаясь зачастую доисторических рукописей.

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

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

1. Языку ДРАКОН нужны Евангелисты. Это задача номер 1. Потому что очень многие не понимают сути ДРАКОНа.

2. В Англоязычном мире сегодня единственным евангелистом является Stepan Mitkin.

3. Как евангелист, он получил хорошие результаты. Сегодня DRAKON language известен в мире (worldwide) благодаря Степану. Люди со всех континентов скачивают программу DRAKON Editor.

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

5. Я возлагаю большие надежды на Алекса facevalue. Он обещает стать прекрасным ДРАКОН-евангелистом. Но это непростой путь, нужно затратить много труда.

6. Когда Алекс facevalue выполнит эту историческую миссию, у многих откроются глаза и они поймут, что такое язык ДРАКОН.

Цитата:
Открылись вещие зеницы,
Как у испуганной орлицы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Суббота, 10 Сентябрь, 2016 12:36 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
Ну дык, переход от аналога к цифре - от непрерывного к дискретному. Неизбежность.
Очень конструктивно.
Но не важно в каком месте целевой платформы накладывается жёсткое ограничение на последовательное исполнение(ацп, проц и т.д..).

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

Alexey_Donskoy писал(а):
[В каком месте?
Когда на некорректно называемом этапе "кодогенерации" принимается решение о последовательной обработке "Индикаторов",
хотя модель:
Alexey_Donskoy писал(а):
FBD сама по себе не содержит информации о том, какой блок на схеме должен выполняться раньше, который позже.. По сути своей потоки постоянны, процессы параллельны.


Удаляясь от конфликта в терминологии, могу использовать термин "преобразование".
Так вот, опираясь на неотражённое на FBD априорное знание о характере данных, либо об особенностях целевой платформы, вы преобразовали некую запись, получаемую из FBD в запись, визуализированную с помощью BD(block diagram).

Иначе говоря,
запись с явным dataflow и скрытым controlflow
преобразована
в запись с явным controlflow и скрытым dataflow.
В ходе преобразования использована некая априорная информация(не содержащейся в исходной записи).
Попутно замечу, что никаких "алгоритмов" по ходу преобразования не появляется.
Преобразование, действительно, поддаётся автоматизации известными методами.

Где здесь источник ошибок?
Начнём с итоговой схемы, точнее с её записи. В ПРОТОНе.
Как утверждают математики и не отказывается подтвердить Касьянов В.Н., первое же найденное остовное дерево графа позволяет наиболее просто сгенерировать все остальные возможные остовные деревья. Тогда число возможных описаний графа будет равно удвоенному значению постоянной матрицы Киргофа.
В Вашем итоговом варианте - 92.
Т.е. в ходе преобразования мы равновероятно можем получить один из 92 вариантов. Чем же они отличаются, раз описывают один и тот же граф?

Исключительно side effects на границах остовного дерева и дополнений остова до исходного графа.
Например, забыли, что раз уж попали на вход этой программы, то сигнал на покупку должен быть сброшен незамедлительно.
Вот здесь и нужен программист. Он может тупо вставить один квадратик и все заработает.
А ведь есть ещё тысячи особенностей аппаратной платформы, о которых разработчик FBD понятия не имеет, его руководители - тем более.
А side effects от различных сортировок итоговой записи графа программы каждый раз разные.
И Вы говорите программист - лишнее звено :lol:

Можно ещё сначала прогнать всё преобразование, дополнив априорную информацию неучтённым существенным обстоятельством. Наиболее вероятно, что получим запись графа, переподвешенного за вершину "Сигнал на покупку =0". Но большиство топовых сотрудников( и те, на ком проектирование модели) никогда так не сделают. Благодаря возможности разделения ответственности.

Даже если кто-то опровергнет последний тезис про ответственность, следует учитывать, что может возникнуть ложное представление, когда максимально расширив априорную информацию, мы наконец всё сделаем правильно. Но существуют некоторые законы теории информации, которые сильно усложняют ситуацию. В качестве доступного примера приведу преобладающее расширение поисковой выдачи в ответ на увеличение числа параметров запроса. Попробуйте.., на гугле, яндексе :)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Воскресенье, 11 Сентябрь, 2016 10:48 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
параллельно на исходной и последовательно на конечной схемах.
Вообще-то дискретность не подразумевает перехода от параллельности к последовательности. Это действительно одна из возможных реализаций, не более того. О чём я и говорил.

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

Цитата:
side effects
Безусловно!

Цитата:
Например, забыли, что раз уж попали на вход этой программы, то сигнал на покупку должен быть сброшен незамедлительно.
Зачем? Он работал и должен работать до тех пор, пока схема принятия решений не выдаст противоположный сигнал.

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

Цитата:
большиство топовых сотрудников( и те, на ком проектирование модели) никогда так не сделают.
Им это и не нужно. И даже вредно. Ибо совершенно другой уровень.
Программист нужен, чтобы сделать инструмент (и исполняющую часть).
"Проектировщик модели" должен сосредоточиться на своей модели, которая есть чёрный ящик, сопрягаемый с исполняющей системой предоставленным ею интерфейсом. И заставлять его, проектировщика, каждый раз решать ЧУЖИЕ вопросы - категорически неверно.

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

Цитата:
Благодаря возможности разделения ответственности.
Именно. Причём в "хардварном" смысле ;)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Воскресенье, 11 Сентябрь, 2016 13:00 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
идеальный инструмент должен оставлять проектировщику параметризацию стандартных процедур плюс свободно программируемую логику
На больших системах это не работает.
Знаете специалиста, которому даже ярды денег не помогли пересилить математику и теорию информации? сбербанком нынче руковОдит.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Воскресенье, 11 Сентябрь, 2016 13:36 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Alexey_Donskoy писал(а):
идеальный инструмент должен оставлять проектировщику параметризацию стандартных процедур плюс свободно программируемую логику
На больших системах это не работает.
Работает в громадном количестве областей.
Если же side effects и программно-аппаратные особенности в жёсткой (не обязательно большой!) системе становятся критичными, то возвращаемся к вопросам, поднятым мною в теме "Что такое алгоритм". Тогда да, есть ситуации, когда алгоритм (равно как и прочие модели на DSL) становятся недостаточно эффективными, разделение уровней - нецелесообразным, и требуется "присутствие программиста".
Но именно в этом случае надежды ТС на один только алгоритмический слой становятся неуместными, не так ли? ;)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Воскресенье, 11 Сентябрь, 2016 14:46 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Не так.
block diagram хватит, но до определённого масштаба системы. Я это озвучил.

1. Для устранения side effects в малых системах хватит набора когнитивных правил из книг Паронджанова.
2. Для устранения side effects в средних системах хватит разбиения на остовное дерево и дополнение.
3. Для больших систем - всё это не работает. Использование FBD ситуацию не изменит, поскольку
BD и FBD - это двойственные модели и ни одна из них не является "метой" для другой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Воскресенье, 11 Сентябрь, 2016 17:26 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
block diagram хватит, но до определённого масштаба системы.
Опять скользкая дорожка игры терминами? Что значит "хватит"?
Для эргономичной работы разработчика - конечно, не хватит.
Для отображения кода - хватит по определению (потому как имеет однозначное обратное отображение - из кода в block diagram).

Цитата:
1. Для устранения side effects в малых системах хватит набора когнитивных правил из книг Паронджанова.
Сильный тезис. Как минимум, требует доказательства, а вообще (интуитивно до очевидности) неверен...

Цитата:
3. Для больших систем - всё это не работает.
Опять же таки - для чего? Что является критерием "работоспособности"?

Цитата:
BD и FBD - это двойственные модели и ни одна из них не является "метой" для другой.
А вот это категорически неверно.
Для доказательства берём простейшую динамическую систему (хоть 1 порядка), описываем её дифуром, рисуем FBD, которая однозначно отображает дифур (тождественно равна ему с точностью до языка представления). И имеем метаинформацию.
Никакая BD рядом не валялась.
Получить BD из FBD мы можем исключительно в рамках решения конкретной задачи над метамоделью FBD (в частности, рассчитать переходный процесс, рассчитать частотную характеристику, произвести сортировку блоков для сериализации исполнения и т.д. и т.п.).

Другими словами, FBD - это карта, с помощью которой можно решать разнообразные задачи (проложить маршрут из точки А в точку Б, вычислить площадь участка, измерить длину реки и т.д. и т.п.).
Так вот один вариант BD - это один из возможных маршрутов. Вариантов, разумеется, столько, сколько маршрутов можно проложить на карте.

Важно, что обратное преобразование из BD в FBD возможно далеко не всегда, потому как в BD есть новые постулаты (сериализация, например), но потеряна метаинформация о структуре системы.
И пусть вас не обманывает то, что некоторые из возможных маршрутов можно получить друг из друга путём строгих преобразований - в общем случае структура исходной системы всё равно необратимо потеряна.

Потому между FBD и BD существует вполне однозначное отношение "мета - производная".
Дифур первичен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Воскресенье, 11 Сентябрь, 2016 18:47 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
Опять скользкая дорожка игры терминами? Что значит "хватит"?
Там расшифровано. Хватит для устранения side effects.
Я считаю, что это может помочь ТС'у с применимостью методов. А пенять на неуместные надежды рановато.


Про дифуры здесь оффтоп полнейший.
О том, как эти конструкции проявляются в императивной программе обмен мнениями уже был. Давно. Неинтересно опять перетирать под сурдинку возвеличивания содержательности FBD.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Воскресенье, 11 Сентябрь, 2016 20:25 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Хватит для устранения side effects.
side effects носят семантический характер. Каким образом синтаксические правила помогут их устранить?
Сделать чуть более заметными - возможно. Не провоцировать ошибки - однозначно.
А дальше всё равно остаются семантические дебри, на которые инструмент разработчика повлиять никак не может...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Понедельник, 12 Сентябрь, 2016 10:29 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Вот зачем.
Alexey_Donskoy писал(а):
берём простейшую динамическую систему (хоть 1 порядка), описываем её дифуром, рисуем FBD, которая однозначно отображает дифур (тождественно равна ему с точностью до языка представления). И имеем метаинформацию.

вижу два варианта:
1. совершено открытие, о котором неплохо бы рассказать поподробнее в отдельной теме. О тождественном изображение дифуров на FBD.
2. здесь производится профанация общеизвестного понятия FBD с применением специальных познаний. Рядовым инженерам и студентам асутэпэшникам известно, что изображению на FBD подлежат блоки с определёнными передаточными функциями. Формально, FBD - это одна большая передаточная функция и наличие дифференцирующих звеньев не делает всю схему дифуром. И ничто на этом уровне представления не запрещает перерисовать FBD в императивную BD, с использованием внутри присваиваний выражений для передаточных функций.

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

any comments?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Понедельник, 12 Сентябрь, 2016 11:48 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Формально, FBD - это одна большая передаточная функция и наличие дифференцирующих звеньев не делает всю схему дифуром.
Передаточная функция и есть дифур, записанный в другой нотации. Никакого открытия тут нет.

Цитата:
И ничто на этом уровне представления не запрещает перерисовать FBD в императивную BD, с использованием внутри присваиваний выражений для передаточных функций.
Не мешает, но надо понимать, что "выражения для передаточных функций" - это сгенерированный из метаинформации продукт. Как минимум там обычно есть переход из аналогового описания в дискретное (с потерей информации, естественно). И преобразование это не тождественное.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Язык ДРАКОН и Биржа
СообщениеДобавлено: Понедельник, 12 Сентябрь, 2016 12:00 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Спасибо. Полагаю, что тезис о неуместных надеждах на BD можно снять.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 83 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB