DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 16:23

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




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
СообщениеДобавлено: Вторник, 09 Декабрь, 2014 07:22 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Цитата из первого поста по теме "Критические замечания Владимира Ивановича Шелехова":
Владимир Паронджанов писал(а):
Владимир Иванович Шелехов проявил интерес к языку ДРАКОН, проанализировал мою книгу "Паронджанов В.Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации". И высказал большое количество очень ценных критических замечаний по тексту книги.

В этой теме я буду публиковать Замечания Владимира Ивановича.

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

(продолжение следует)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Декабрь, 2014 08:53 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Вопрос № 1. Текстовые и нетекстовые (визуальные) языки

Владимир Паронджанов писал(а):
Письмо В.И. Шелехова от 17 октября 2014 года
Цитата:
С 2001 г. новая тема - предикатное программирование.

Проблематика автоматного программирования, над которой я работаю последних три года, выросла из предикатного программирования. Метод разработки автоматных программ на базе спецификации требований появился в конце прошлого года.

Мои последние работы:
http://persons.iis.nsk.su/files/persons ... atProg.pdf
http://persons.iis.nsk.su/files/persons/pages/req_k.pdf
http://persons.iis.nsk.su/files/persons ... q_tech.pdf

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

Цитата:
Почти все языки автоматного программирования в России и в мире -- графические.
Мой язык -- текстовый. На конкретных примерах я пытаюсь показать, что он не уступает графическим языкам.

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

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

Тоже полезная обзорная сводка.

Но предлагается принять во внимание факт - не очень корректное общепринятое противопоставление:
текстовые языки и графические языки (программирования и алгоритмические языки).

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

Соответственно этому целесообразным является перевод обсуждаемой проблематики
относительно графического языка Дракон в его взаимосвязи с "текстовыми" языками
на концептуально корректные словесные (вербальные) выражения.
Это точно не повредит Дракону (особенно в его светлом будущем).

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

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

У кого какие могут быть сведения или предложения
по классификационному делению
алгоритмических и программных языков - по знаковой форме их представления?
Хотелось бы узнать.

------------------------
Для первичной затравки далее приводится классификация алгоритмических языков
автора этого поста
(тоже хромает по точности терминологии):

Алгоритмические языки:
литерные (буквы, цифры спец.знаки) языки и нелитерные языки - исходное деление.

Литерные языки:
формульные (аналитические) языки, например, структурные формулы алгоритмов
и вербальные (словесные) языки, например, псевдокоды алгоритмов.

Нелитерные языки:
графические языки (блок-схемы, граф-схемы и т.д.)
и аудиальтные языки (например, для устного ввода алгоритма в машину - ЭВМ, Робот и т.п.).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Декабрь, 2014 09:54 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 40
Откуда: г. Ярославль
andr писал(а):
У кого какие могут быть сведения или предложения
по классификационному делению
алгоритмических и программных языков - по знаковой форме их представления?
Хотелось бы узнать.
Не хотелось бы сильно влезать в эту тему, просто вспомнить замечание Э. Дейкстры о том, что ЯП это не язык, и называть языки программирования "языками" неправильно, потому что это затянет нас не туда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Декабрь, 2014 10:15 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Иван Кузьмицкий писал(а):
andr писал(а):
У кого какие могут быть сведения или предложения
по классификационному делению
алгоритмических и программных языков - по знаковой форме их представления?
Хотелось бы узнать.
Не хотелось бы сильно влезать в эту тему, просто вспомнить замечание Э. Дейкстры о том, что ЯП это не язык, и называть языки программирования "языками" неправильно, потому что это затянет нас не туда.

Скорее всего Вы как-то недопоняли Э. Дейскстру.

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

А что не устраивает уважаемого Дейскстру в отношении ЯП?
Конкретно - точная цитата со ссылкой (с точностью до страницы).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Декабрь, 2014 10:44 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 40
Откуда: г. Ярославль
andr писал(а):
А что не устраивает уважаемого Дейскстру в отношении ЯП? Конкретно - точная цитата со ссылкой (с точностью до страницы).
Дейкстру в отношении ЯП всё устраивает. Его не устраивает, как я понял, попытка вытащить понимание абсолютно новой для человечества технологии на уровень привычных аналогий.

Вот тут это дело обрисовано: http://www.beroal.in.ua/article/dijkstra/ewd854.html

А это оригинал: https://www.cs.utexas.edu/~EWD/transcri ... WD854.html

И ещё немного о том, что такое компьютер, можно обнаружить здесь: https://www.cs.utexas.edu/users/EWD/tra ... WD667.html


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Декабрь, 2014 14:36 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Иван Кузьмицкий писал(а):
andr писал(а):
А что не устраивает уважаемого Дейскстру в отношении ЯП? Конкретно - точная цитата со ссылкой (с точностью до страницы).
Дейкстру в отношении ЯП всё устраивает.

Тогда отпадает возражение:
Иван Кузьмицкий писал(а):
Не хотелось бы сильно влезать в эту тему, просто вспомнить замечание Э. Дейкстры о том, что ЯП это не язык, и называть языки программирования "языками" неправильно, потому что это затянет нас не туда.

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

Цитата:
Его не устраивает, как я понял, попытка вытащить понимание абсолютно новой для человечества технологии на уровень привычных аналогий.

Вот тут это дело обрисовано: http://www.beroal.in.ua/article/dijkstra/ewd854.html
Вот это совсем другой вопрос.
Большое спасибо за наводку.

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

Потом (позже) оказываются, что некоторые аналогии попадают в точку (в суть дела),
например: шампур и силуэт - отлично, годится.
Можно потом уточнять их смысл, но термины хорошие - точные метафоры.
Как например, термин "кэш" - заначка и т.п.

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

------------------
Можно согласиться также с тем, что часто изначально
усиленно пропагандируются и почти-что прямо рекламируются гипотетические еще надежды на новые успехи.
Так было с Коболом:
вместо "x + y" можно было писать типа "икс плюс игрек" - изначально сомнительное достоинство.
Так было с Явой:
ужасно напористое расписывание достоинств языка - на слабонервных и слабоумных.
И ведь был массовый стадный энтузазизм (но им простительно).
А потом все улеглось - и оказалось, что в общем и в целом здорово, но не все так ужасно здорово.
Например, примитивное и громоздкое отображение параллелизма потоков - через конструкции порождения и отлавливания исключительных ситуаций.
-------------------------

А вот возражения против "инженеризации ПО", как бы по привычной метафоре технарей - это ужасно.
И достаточно одного выражения:
"информатика как раздел математики" - в начала 3-го абзаца снизу.
Особенно новые информационные 3D-технологии, роботизированные информационные технологии и т .п.,
когда информация порождается из материальной среды и в конечном счете так или иначе материализуется.
Все это, конечно, разделы математики.

Это аналогично тому, что можно упорно продолжат говорить и, главное, свято верить:
-- алгоритм - это математическое понятие;
-- теория алгоритмов - это математическая теория.
В 21-м веке:
актуальности формирования самостоятельной (самодостаточной) технической теории алгоритмов.

---------------------
Но все это отвлекает от поставленного вопроса № 1
Цитата:
потому что это затянет нас не туда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Декабрь, 2014 15:36 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 40
Откуда: г. Ярославль
andr писал(а):
Тогда отпадает возражение:
Это вряд ли.
andr писал(а):
Но аналогии (метафоры) очень необходимы
на начальных этапах принципиально новых разработок, когда суть дела еще не ясна.
Какого дела?

P.S. Имею в виду дело, порождающее вопросы о классификации ЯП. Суть этого дела, судя по Вашим словам, ещё не ясна. Возможно, стоит пересмотреть базовые конструкты? Например, считать программу не текстом, а механизмом (это уже какой-то приём ТРИЗ получается :)). Ведь, рассуждая о формальных знаковых системах и построенных текстах, мы упускаем из виду абсолютного исполнителя, который будет с этими текстами что-то делать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Декабрь, 2014 07:48 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Иван Кузьмицкий писал(а):
andr писал(а):
Тогда отпадает возражение:
Это вряд ли.
andr писал(а):
Но аналогии (метафоры) очень необходимы
на начальных этапах принципиально новых разработок, когда суть дела еще не ясна.
Какого дела?

P.S. Имею в виду дело, порождающее вопросы о классификации ЯП. Суть этого дела, судя по Вашим словам, ещё не ясна. Возможно, стоит пересмотреть базовые конструкты? Например, считать программу не текстом, а механизмом (это уже какой-то приём ТРИЗ получается :)). Ведь, рассуждая о формальных знаковых системах и построенных текстах, мы упускаем из виду абсолютного исполнителя, который будет с этими текстами что-то делать.

Какого дела?

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

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

А по поводу метафоры инженерного (инженеризации) программирования - это вовсе не метафора, а реальная насущная потребность.
Дейкстра (при всем к нему уважении за прежние заслуги) к сожалению все еще пребывает в 20-м веке,
и не понимает, что информатика 21-го века:
это уже не раздел математики, но еще и не полноценная техническая (инженерная) информатика - она еще только формируется.
И инженерное программирование - это не метафора, а суть современного программирования,
хотя в целом это пока больше разговоры и декларации, но есть и большие подвижки.
Сам термин технологии (техн...) в составе "информационные технологии" - это изначально технический термин,
хотя учебные информационные технологии (в школе и в вузе) пока еще сильно не дотягивают, например,
до технических (инженерных) информационных технологий машиностроения или приборостроения.

Цитата:
P.S. Имею в виду дело, порождающее вопросы о классификации ЯП.
Суть этого дела, судя по Вашим словам, ещё не ясна.
Возможно, стоит пересмотреть базовые конструкты?
Например, считать программу не текстом, а механизмом (это уже какой-то приём ТРИЗ получается :)).
Ведь, рассуждая о формальных знаковых системах и построенных текстах, мы упускаем из виду абсолютного исполнителя,
который будет с этими текстами что-то делать.

Согласен.
Спасибо.
Бальзам на душу (тем более с ТРИЗ-ой вприкуску).

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

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

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

Тем не менее получилась некоторая подвижка по этому вопросу (№ 1).
Это большой плюс.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Вопрос № 2: Шампур и силуэт
СообщениеДобавлено: Понедельник, 15 Декабрь, 2014 14:42 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Паронджанов писал(а):
Письмо В.И. Шелехова от 17 октября 2014 года
Цитата:
От кого: Vladimir Shelekhov ⚁
Кому: Паронджанов Владимир

17 октября, 16:49
O1 файл.


Почти все языки автоматного программирования в России и в мире -- графические.
Мой язык -- текстовый. На конкретных примерах я пытаюсь показать, что он не уступает графическим языкам.

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

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

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

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

Нигде в мире я не обнаружил даже отдаленных аналогов применяемых эргономических методов, в частности, конструкций "шампур" и силуэт".


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

Не очень понятен смысл утверждения:
не обнаружено "даже отдаленных аналогов применяемых эргономических методов, в частности, конструкций "шампур" и силуэт""

По-видимому, здесь необходимы уточнения:
1) Впервые использованы термины типа Шампур, Силуэт и т.д.,
представляющие собой точные, наглядные и выразительные метафоры:
аналогии некоторых конструктивных схемных идей, существующие в общеизвестной жизненной практике.
Обеспечивается (или повышается) интуитивное понимание этих схемных идей.
2) Впервые, по-видимому, дается их систематическая методическая проработка,
причем с ориентиром на некоторую концепцию схемной эргономики.
3) ?
4) ?
...

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

Например:
аналог шампура заложен в схемные построения языков программирования
промышленных (логических) контроллеров
по международному стандарту IEC 61131-3 (МЕК 61131-3).
Далее справа показана блок-схема типа SFC
(Sequential Function Chart - Последовательностные функциональные диаграммы)
Вложение:
Шампур02.png
Шампур02.png [ 49.62 КБ | Просмотров: 12908 ]

Идея шампура так или иначе просматривается в схеме.

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

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

---------------------
При наличии так называемого встроенного (многоуровневого) параллелизма идея шампура "размножается":
на каждом уровне (кроме последнего) появляется свой шампур,
подвешенный к шампуру предшествующего уровня
(подвешивается - в горизонтальном исполнении схемы).
Например:
Вложение:
Шампур04.png
Шампур04.png [ 28.61 КБ | Просмотров: 12908 ]

Очевидно наличие 2-х шампуров:
второй наглядно подвешен к первому.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 26 Декабрь, 2014 15:02 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Паронджанов писал(а):
Письмо В.И. Шелехова от 17 октября 2014 года
Цитата:
Надеюсь, что проект дуального (текстового и графического) представления программы Вам также будет интересен.

Полезно обговорить термины:
дуальное (текстовое и графическое) представление программы;
дуальное (текстовое и графическое) программирование.

Есть вопросы:
1) Насколько они новые? и достаточно ли уже общепринятые?
2) Где они применяются? (и где они появились?)

В поисковиках удалось встретить только два применения термина:
1) Дуальное программирование в теории надежности:
параллельно применяются две сходные (или несколько разные) программы,
и результаты их работы оперативно сравниваются.
2) Индиви- дуальное программирование учебной деятельности:
оригинально, но ясное дело - ошибочка вышла.

Автор этого поста наткнулся на этот термин (дуальное программирование) недавно,
где-то в интернете и, кажется, даже в связи с Драконом, но уже трудно вспомнить, где конкретно.

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

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

------------------------
Автор данного поста выделяет 3 основные формы представления алгоритмов:

1) Две основные (собственно алгоритмические) формы представления алгоритмов:

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

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

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

Вложение:
ССА+ДИА.PNG
ССА+ДИА.PNG [ 82.4 КБ | Просмотров: 12843 ]

Вложение:
СФА-ССА.PNG
СФА-ССА.PNG [ 66.01 КБ | Просмотров: 12843 ]


2) Дополнительная вербальная (словесная) форма представления алгоритмов.
Разного назначения:

а) Псевдокоды алгоритмов - промежуточная вербальная (отчасти) форма связи
исходных кодов программ и (2-х) основных форм представления алгоритмов.
Она ориентируется на разные языки программирования - их синтаксис и лексику.
Причем, сколько существует разных языков программирования и их разновидностей,
столько может быть разных псевдокодов и, дополнительно, разных их модификаций
(в зависимости от целей и задач применения псевдокодов).
Вложение:
ПКА-02.png
ПКА-02.png [ 39.14 КБ | Просмотров: 12843 ]

Вложение:
ПКА-04.png
ПКА-04.png [ 31 КБ | Просмотров: 12843 ]

Вложение:
ПКА-06.png
ПКА-06.png [ 43.1 КБ | Просмотров: 12843 ]


б) И т.д.

Таким образом понятие дуальности основных форм представления алгоритмов
некоторым образом расширяется (пока не очень понятно как лучше).

--------------------------------
Кроме того возможные разные матричные формы представления алгоритмов:
это, как правило, отражение разных связей разных пар элементов алгоритмов
(в некоторой системе разложения структуры алгоритмов).

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


Последний раз редактировалось andr Пятница, 26 Декабрь, 2014 16:27, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 26 Декабрь, 2014 15:36 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Геннадий Тышов писал(а):
Туманно это все и далекое от потребностей практического программирования.

Неправда Ваша, Уважаемый Геннадий.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 26 Декабрь, 2014 15:56 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Ждем Драконовское представление и обсуждение параллельного программирования.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 29 Декабрь, 2014 08:16 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
Геннадий Тышов писал(а):
Туманно это все и далекое от потребностей практического программирования.

Неправда Ваша, Уважаемый Геннадий.

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

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

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

Пока я готовил ответ на пост Геннадия Тышова, он удалил его из данной темы.
Тем не менее я оставил этот ответ, поскольку для меня данный пост - это обратная связь большой ценности,
где от души высказаны два замечания:
1) Туманно все это
2) и далеко от потребностей практического программирования.

Все это не так, но это авторская недоработка,
поскольку по представленным (тремя постами выше) кратким выборкам трудно в этом убедиться со стороны.

------------------------
Во-первых, при небольших пояснениях к таким материалам, они получают индекс ДТ:
дитЯм понятно - принципе, конечно, еще не как систематическая подготовка.

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

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

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

------------------------
==== писал(а):
Ждем Драконовское представление и обсуждение параллельного программирования.

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

Это серьезная заявка.
Но ее можно решать параллельно с задачей на сравнение разных Драконовких схем:
Ильченко Эдуард писал(а):
Учитывая, что дракон-схема представляет собой достаточно упорядоченную структуру, представляется возможным организовать сравнение двух таких схем.

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

А предварительно надо все-таки добить поставленные вопросы:
andr писал(а):
Владимир Паронджанов писал(а):
Письмо В.И. Шелехова от 17 октября 2014 года
Цитата:
Надеюсь, что проект дуального (текстового и графического) представления программы Вам также будет интересен.

Полезно обговорить термины:
дуальное (текстовое и графическое) представление программы;
дуальное (текстовое и графическое) программирование.

Есть вопросы:
1) Насколько они новые? и достаточно ли уже общепринятые?
2) Где они применяются? (и где они появились?)
Накапливать такие неясности нам будет не с руки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 30 Декабрь, 2014 14:37 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
А предварительно надо все-таки добить поставленные вопросы:
andr писал(а):
Владимир Паронджанов писал(а):
Письмо В.И. Шелехова от 17 октября 2014 года
Цитата:
Надеюсь, что проект дуального (текстового и графического) представления программы Вам также будет интересен.

Полезно обговорить термины:
дуальное (текстовое и графическое) представление программы;
дуальное (текстовое и графическое) программирование.

Есть вопросы:
1) Насколько они новые? и достаточно ли уже общепринятые?
2) Где они применяются? (и где они появились?)
Накапливать такие неясности нам будет не с руки.

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

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

1) То ли это уже официальные, практически, термины, то ли это пока ситхийная терминология?
2) Инетересно знать, где и когда они появилсь? - посмотреть в каких обстоятельствах и в каком конкретно смысле.

У кого есть какая-то информация по этим вопросам?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

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


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

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


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

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