По ошибке это сообщение (новое) заменило собой старое, расположенное теперь
по этому адресу: viewtopic.php?p=52313#p52313Тут высказывалось пожелание выложить машобраз книги /Паронджанов, 2000/:
Уважаемые Владимир Паронджанов и модераторы форума, книгу "Занимательная информатика" от 2000 года было бы хорошо выложить в WIKI для скачивания.
Очевидно, это так никто и не сделал, т.к. при обсуждении подобных пожеланий справедливо указывалось, что произвольно выкладывать "для ознакомления" копии книг, на которые не истёк срок исключительных прав - значит входить в конфликт с правообладателями. В то же время закон нас не полностью ограничивает - см. в этом сообщении о Ст.1274 ГКРФ08.Познакомился с этой книжкой (в издании 2007 года) и возникли некоторые соображения. В результате публикую большую часть её содержания со своими комментариями
Итак, пойдём по темам (машобраз разбил по главам - иначе обработка цветного усложняется):
Вложение:
§1. Ну, тут всё понятно... только можно ввести понятие задачи как тройки <Дано, Надо, Решение> явно
§§2,6. Не знаю, как для школьников, я бы уточнил, что "однозначность" алгоритма надо связывать со свойствами исполнителя. Что для одного исполнителя "неточно" - для другого будет точным. На вершину здесь нужно поставить человека - он будет уточнять указания как раз путём рассуждений, что не под силу машине (и те же продукты купит такие, какие именно ему нравятся "в пределах отпущенных средств"

). Конечно, это вопрос тонкий, из области "искусственного интеллекта" - но сейчас об этом и в школьных курсах есть - а кроме того, дополнительно ориентирует на формализацию профессиональных знаний вообще, а не только того, "что завтра надо запрограммировать"
Существует и определение процедуры деятельности (неалгоритмической) как алгоритма, для которого не выполнено (ослаблено) требование детерминированности - квазиалгоритма. См. выдержку из Поспелова в этом сообщении.
§4. В запоминателях допущена "перетасовка" определений... это так задумано или редакционная ошибка?
§5. Быть может, стоит включить в состав исполнителей и человека... уточнив, что дракон-схема помогает ему выполнять какую-то работу "педантично" (всё к тому же, что для §2)?
§§8...10. Здесь интересно было бы ввести подразделение немаршрутной компоненты техноязыка (текстоэлементов) на командный и декларативный, понятие величины... и в дальнейшем выделять (стилем текста) имена сущностей (а равно их литеральные значения, которые только и употребляются здесь) - так юный сочинитель усвоит одну из составляющих "когнитивного стиля" визуализации и заодно наглядно познакомится с величинами.
§11...12. Можно упомянуть, что содержимое комментариев в данном случае - это основная часть состояния алгоритма. А состояние - это все данные, которые нужны исполнителю, чтобы правильно исполнить следующий оператор.
У формального (информатически - в смысле стадийности процесса моделирования/формализации, вводимой на этой странице) исполнителя в вектор состояния будет входить конечное число параметров с конечными областями определения.
Вложение:
§§14...16. Различие между линейными и нелинейными алгоритмами я бы пояснил так. Линейный получается, если сочинитель представляет исполнителя без обратной связи с окружающим миром (см. также Рис.53 из §26; в этом свете стоит его дать пораньше) - что бы ни получилось в результате исполнения очередного действия, мы всё считаем правильным для решения задачи. Нелинейный - это когда исполнитель должен при следующих действиях учитывать результат предыдущих; для этого он имеет обратную связь ("глаз"), и поступающие по ней (равно как и сформированные предыдущими преобразованиями по маршруту) данные используются для выбора маршрута. При этом стоит ввести понятие алгоритмической обстановки (представления сочинителя об исполнителе и окружающей его среде через набор свойств, каждое из которых может принимать одно из конкретных значений) и данных - этих самых значений, возникающих при конкретном исполнении алгоритма. По сути, в терминах кибернетики речь идёт о разомкнутом или замкнутом управлении.
Кстати, кибернетический подход проводится и в "Общей информатике" Симоновича (см. в этом сообщении)... тоже школьный учебник.
§18. Как бы нам убедиться, что алгоритм решает поставленную задачу?

Возможно, стоит для старших школьников всё-таки что-то сказать о логическом выводе алгоритма с наглядными примерами (имея целью - показать, что можно сочинять алгоритм как результат проверки его правильности, и в комментариях прежде всего фиксировать доказательства этой правильности)?
§20. Возможно, стоит уточнить (как в /Паронджанов, 2001/), что одинаковым текстам (однотипных вершин) на схеме соответствуют одинаковые буквы?
§22. Возможно, для старших школьников стоит сказать и о допвходах?
§§23...24. Можно уточнить, что исправление ошибок, связанных с неточным описанием, может заключаеться и в постепенном уточнении всех действий и условий, возникающих при решении задачи, до соответствия "репертуару" и "багажу" выбранного исполнителя (заданному стандарту представления знаний), т.е. допустимым для него предписаниям и типам аргументов этих предписаний.
То, что с самого начала решение задачи описывается на алгоязыке, само по себе не проясняет его смысла - ведь обстановка изначально остаётся такой же неопределённой - не показать ли, что выбор точной формы описания упрощает диалог сочинителя с исполнителем (и/или человеком-экспертом в решении данной задачи) и выявление сути?
§§25...26. Можно уточнить, что состояние - это все данные, которые нужны "мозгу робота" (хранятся в нём), чтобы правильно исполнить следующий оператор. В этом состоянии находится исполнитель между вершинами; при исполнении очередной вершины что-то в этом состоянии меняется (хотя бы положение "дракон-поезда").
Вложение:
§33. Можно и об эквивалентных алгоритмах рассказать... здесь или при обсуждении подстановки. В частности, о том, что можно заполнять вершины текстом на разных языках и получать алгоритм решения той же задачи на языке, понятном исполнителю (я имею в виду гибридизацию техноязыка).
Далее (до следующей откомментированной темы) всё описано в /Паронджанов, 2001, с. 105-110/.
§40. Общий принцип упорядочения - "все побочные вертикали вправо от главной" - не только удобен эргономически, но и формализует редактирование схемы (удобно вводить "оси порядка"). Впрочем, это для специалистов... но кто знает, может, прочитает школьник книгу и захочет реализовать дракон-редактор?
§§41...42. Иной раз при программировании мы нуждаемся и в разъединении (об общем правиле развёртки нелинейного алгоритма в командную модель говорил Илья Ермаков
в этом сообщении.)... не знаю только, нужно ли это школьникам (вне программистских "профильных классов")?
§43. Хотелось бы ввести понятие для системы алгоритмов, получающейся в результате подстановок (то, что я называю "дракон-модель").
§44. Вообще-то для меня, например, вставка - это сразу и команда вызова процедуры и метка для возврата из неё, т.е. место, откуда совершается прямой "акробатический прыжок" и куда совершается обратный. Поскольку возврат связан с восстановлением контекста вызывающего алгоритма (с учётом возможных побочных эффектов от вызываемого, о чём школьникам, наверное, знать пока не обязательно

); только после этого мы можем идти по звену к следующему оператору (у нас уже есть состояние, соответствующее завершению вставки).
При таком взгляде и Рис.91 будет другим. Возможно, он должен учитывать сказанное о БП с возвратом здесь - а для "совсем старших школьников" также и здесь.
§45. Здесь "по-детски" объясняется переключение контекста процесса. Возможно, стоит прямо сказать, что в разных процедурах исполнитель играет разные "роли" - так можно объяснить смысл контекста - и по вставке переходит от роли, названной именем текущего визуала к роли, названной именем вставки - при этом запоминая, "с какого места играть" оставленную роль.
Вообще "командир" и "солдат" - это пример для двух процедур, а можно упомянуть, что из вставки можно "прыгнуть" и к другой вставке (т.е. о вложенности вызовов процедур) - и соответственно в названиях алгоритмов, составляющих эту цепочку, отразить возникающую иерархию (так сказать, от "солдата" до "главнокомандующего" - т.е. неподчинённой процедуры в дракон-модели).
Вложение:
§48. Даже не знаю... м.б. стоит при раскрытии этой темы рассказать о предусловии, постусловии и инварианте цикла... конечно, подбирая слова? И вообще об инварианте алгоритма (который мы в Обероне или Promela можем проверять по assert при переходе к любому оператору) - ведь и в "школьной" алгонотации assert имеется (в виде НАЧ/УТВ/КОН)...
Дальнейшее описано в /Паронджанов, 2001, с. 126-129/
§§55...56. На конференции неоднократно указывалось (напр. Ильёй
в этом сообщении), что нужно уметь выводить цикл, а не подбирать его логику досрочными выходами/возвратами. Думаю, что учить этому хорошо бы со школы; посему не показать ли алгоритмизацию описанных задач с выводом условий циклической структуры?
Здесь подошёл бы цикл Дейкстры (конечно, "для детей" его можно назвать и иначе - скажем, "цикл-матрёшка"
); дабы не дезавуировать перед детьми самого себя
, можно объявить приведённые в вышедшей книжке визуализации "приблизительными", а потом показать переход от них к "точным".
§§57...58. Цикл в цикле также полагал бы возможным представить как цикл Дейкстры; имеет смысл дать преобразование в ЦД приведённых примеров.
Конечно, без формул-"лягушек" здесь не обойдёшься
в то же время, возможно, удастся показать логический вывод частично посредством "развилочной логики" техноязыка - так наглядней. А в целом стоило бы показывать связь с математикой - тем более здесь всё вроде оказывается в рамках школьного её курса и даже может в чём-то иллюстрировать его положения - быть может, это неплохой способ внедрять "когнитивную письменность" в математику, о чём говорилось в /Паронджанов, 2001, Гл.19/?
Вложение:
§§61...63. Хотелось бы акцента, что "акробатический прыжок" по имени ветки - не то же самое, что по вставке - здесь нет "командира" и "солдата", т.е. не происходит смены контекста алгопроцесса - просто для удобства расположения на плоскости мы делим шампур на веточные участки по определённым правилам и связываем эти участки петлёй силуэта. Возможно, стоит и показать, что можно обратно перейти к примитиву (как сделано
в этом примере); запись получается неэргономичной, но исполнитель-машина именами веток не обязательно пользуется.
§64. Здесь разбирается силуэт только с одним ВЦ. Неплохо было бы указать, что веточных циклов м.б. и два и больше, и соответственно дать иной синтаксис пометки ВЦ - напр., предложенный в /
Паронджанов, 2001, Рис.105-107/ и развитый, напр.,
в этом подпункте Д2М-определения техноязыка. См. также замечания по концептуализации дракон-моделей
в этом сообщении.
И уместны примеры, иллюстрирующие разные случаи вложения (без совпадения границ; с совпадением по начальной ветке; по конечной; по обеим - уже говорил
в этом сообщении) - это скорее для старших школьников, конечно...
Далее описано в /Паронджанов, 2001, с. 86-95/
§69. Здесь у нас снова описаны состояния и инварианты алгоритма. Наверное, хороший повод вернуться к этому "для закрепления".
§70. Здесь мы по сути разбили основное содержание алгоритма на ряд веток (в данном случае на две) для удобства компоновки дракон-силуэта на диосцене (критерий эрговыделения веток, или "правило Я. Романченко"). Хорошо бы остановить внимание читателя на этом как на допустимом приёме сочинения (наряду с подстановками в тела веток).
§71. Неплохо было бы перед обсуждением этой темы ввести цикл ДЛЯ; тогда здесь показать, что такой цикл в дракон-силуэте можно располагать только целиком внутри одной ветки, иначе также возникают "сиамские близнецы", только "против шампура" - из ветки с концом цикла ДЛЯ в ветку с его началом (предшествующую по правилу "чем правее, тем позже").
См. также замечания по визуальному синтаксису цикла ДЛЯ в этом примере.
Вложение:
§72. Очень удачно (хотя и неявно - через комментарий на Рис. 130) показано, что с областями определения условной переменной в сложном ветвлении нужно быть внимательным; то же самое (проблема выбора по "любому другому" значению) явно обсуждалось где-то на конференции, по-моему, а также
в конце этого пункта - возможно, стоит акцентировать внимание читателя.
§74-75. Пожалуй, смысл "застывшего условия" шире - это "риторический вопрос", обсуждавшийся, в частности,
в этом подпункте. И было бы уместно, считаю (если не для 5-х, то для 9-х классов наверняка), показать переход от "риторического вопроса" к зацикливанию алгоритма - и визуализацию этого зацикливания посредством силуэтных БП (удалением конечной ветки). Объяснить, что это необходимо для реагирующих систем (в смысле теории взаимодействующих процессов), т.е. для любой программы, поддерживающей диалог со внешней средой (объектом управления).
В целом показ альтернативных подходов к той или иной сущности должен послужить развитию творческого воображения, и не только применительно к алгоритмике - юный сочинитель постепенно будет понимать, что уместность решения порой зависит от постановки проблемы, что возможны разные точки зрения на одно и то же и что между внешне разными сущностями м.б. глубинные внутренние связи.
Конечно, всё сказанное стоит понимать как "информацию к размышлению"

Если буквально отражать, не продумав содержание (и когнитивную эргономичность формы) - то как бы не получилась "Донимательная информатика"

В то же время, если какие-то предложения покажутся уместными, то их временное воплощение, думаю, в основном возможно даже без переработки книжки - можно просто составить взаимосвязанную "книгу для родителей/учителей", где показать, как трактовать те или иные параграфы при занятиях с ребёнком. Тем более, что так исключается психологический барьер "толстого тома" - перед его глазами по-прежнему будет небольшая книжка, а возникнет интерес - сам прочтёт и вторую, не довольствуясь разъяснениями взрослых.
Ну и "вкратце об остальном" (без машобразов). Насчёт того, должны ли "быть иконы не только в церкви" применительно к нашей культуре, некоторое замечание высказал Дмитрий_ВБ;
в этом сообщении замечание обсуждалось и учтено (предварительно) в Д2М-редакции стандарта техноязыка.
Ежели говорить о продолжении, которое я понимаю как расширенное и углублённое изложение визуализации деятельности "для отроков" (уж не знаю, планируется оно или нет

), то,
IMHO, имело бы смысл положить в основу гибрид с конкретным прогязыком, и лучше РВ... хорошо бы для начала Оберон взять, а потом перейти к чему-то вроде Promela/AO.
Так говорю, поскольку разделяю: * и мысли Ильи в Разд.5 этого доклада о нетенденциозном выборе прогязыка;
* и предложение Info21 о необходимости единого языка как сквозного при обучении программированию (в предисловии к АиСД-Оберон);
* и идеи о явном выделении состояний процесса для последующей верификации (у тех же Карпова и Шалыто).
Кстати, связь графит-метода с автоматным программированием использована в этом примере. А выдержки из новой книги по этой методологии теперь вложены в это сообщение.
При этом, пожалуй, следует проводить единый подход для материальных и датаматических процессов ("техпроцессов" и "алгоритмов"), подчёркивая, что отличие только в объектах предметной области - реальные или виртуальные - а информатическая модель строится по единым принципам, включая представление объектов типизированными структурами данных. И межпредметные связи наводить - на обсуждении постановок и алгообстановок для конкретных задач из разных "предметок".
В то же время в подобной книжке не стоит обходить уже и дискуссионные вопросы. В первую очередь это как раз упомянутая точность указаний - здесь интересным представляется мнение М.А. Орлова в связи с мета-АРИЗ, приведённое в п. 2 этого сообщения. У меня готовых ответов здесь нет; но хороший математик, думаю, сформирует мнение, которое можно высказать для "старшеклассников и младшекурсников". Далее, сказанное Фридландом о сущности и значении информатики (напр. в п/р 8.4 из учебника, вложенного в это сообщение) - здесь я бы скорректировал определение информатики, о чём говорил в этом пункте. И переопределение данных и знаний, введённое Фридландом в п/р 3.4, с чем согласен.
В целом такое продолжение должно подводить к "серийному производству" визуальных моделей профессионального знания (не только алгоритмических) на инженерной основе. Потому хорошо, если бы оно было увязано по примерам с теми же "Алгоритмами и структурами данных для Оберона" - и в то же время отражало то знание, которое должно этому предшествовать. Тут можно обсудить поподробнее (и визуально) как алгоритмику, так и датаматику, и... активионику, что ли?... не знаю, как назвать отрасль информатических знаний об исполнителях
В алгоритмике можно рассмотреть и "гвардейские команды" Дейкстры, и "роботы в стране Задач", т.е. алгоритмические обстановки. В датаматике - раскрыть и "герметизацию типов", и типизацию воообще. Если говорить об актив-знаниях - то стоит донести до читателя и реализацию алгопроцессов (структуры времени выполнения), и их взаимодействие (с основными механизмами синхронизации), и представление деятельности как программы в "клеточной стране Тьюрингии", т.е. внутри адресного исполнителя, другие базовые вещи
) - в общем, что-то вроде исполнителеориентированной части из Звенигородского, только на достойной "дракон-обероновской" основе
И в то же время чётко ориентировать на то, что:
Илья Ермаков писал(а):
в
viewtopic.php?p=48527#p48527: Алгоритмы - это только небольшая составляющая структуры программной системы.
в
viewtopic.php?p=48436#p48436: ...когда алгоритмизация выполнена, программировать тоже ещё рано. В программных системах большая часть решений сегодня ложится на архитектуру - структуру компонентов, их связей, структуру информационного обмена и т.п.
И только потом - программирование.
А это уже базируется на той ветви инфорзнания, которое я назвал обобщённым (о задаче в целом, её структуризации и модуляризации). Я бы сказал, что эти суждения относятся и к неавтоматизированной реализации трудовых процессов...

И пусть эти решения тоже получат визуальную основу (только не "всё как картинки" - по-моему, так порой трактуют визуализацию - а как и предлагает создатель техноязыка, "ГРАФИТно"

).
Такие вот мысли...
P.S. Также в продолжение имеет смысл включать передовые результаты, имеющие значение для инженерной формализации - такие, как существование погранично-корректного класса математических формализаций (см. работы Ю.П. Петрова, упоминавшиеся, скажем, здесь:
viewtopic.php?f=75&t=2219&start=20#p63721) и вопросы ограничения типов для автоматической верификации (отказ от нецелых чисел и соответственно от приближённых вычислений, от текстуально не конечных структурных типов - см. критику Оберона от Патрика Реали, которую упоминал здесь:
viewtopic.php?p=50800#p50800, работы по model checking).
P.P.S.
§47. Когда обобщаем операторы в теле цикла - нужно сохранять в величинах обобщённое состояние алгопроцесса. Конкретно для данного примера действие формулируется так: "Отрубить очередную голову Змея Горыныча". Тем самым сохраняются данные о том, что на каждой итерации имеем дело с новой алгообстановкой - возможно, отличной от предыдущей (здесь - новая голова, очевидно, расположена в пространстве иначе, чем предыдущая; за время после отрубания следующей Змей Горыныч мог переместиться; и т.д.) - и по необходимости сочинитель может детализировать состояние для учёта в алгоритме. Это, кстати, и к вопросу о детерминации точности указаний свойствами исполнителя - человеку-исполнителю указания "очередную" вполне достаточно
