OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 21:21

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




Начать новую тему Ответить на тему  [ Сообщений: 386 ]  На страницу Пред.  1 ... 12, 13, 14, 15, 16, 17, 18 ... 20  След.
Автор Сообщение
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Понедельник, 02 Май, 2011 22:48 
Аватара пользователя

Зарегистрирован: Суббота, 10 Ноябрь, 2007 21:28
Сообщения: 584
Откуда: Хабаровск
Драконограф писал(а):
Кстати, что это за второе издание первой книги?


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Вторник, 03 Май, 2011 14:12 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
vvp писал(а):
Второе издание, это слишком громко сказано.
Корректор прошелся, значит, 2-е изд., испр.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Среда, 11 Май, 2011 13:07 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф в viewtopic.php?p=62955#p62955 писал(а):
... Вот если взять это оглавление -...
Кстати, об изложении программной инженерии в ББ. Если взять Фаронова - целый раздел у него посвящён библиотекам ТП-среды. В то же время по содержанию это описание библиотек - что в ББ хорошо сделано в докусах. Тогда как в книге надо описывать употребление этих библиотек для построения тексто-интерфейсных документов - организации их состава (в т.ч. в динамике), реализации конкретных функций переработки данных, создания эргономичного и практичного внешнего оформления и интерфейса с оператором и с другими документами (и приложениями). Примером в этом смысле может, пожалуй, служить статья из этого сообщения. Ну и эта книга в каком-то отношении - без приложений, которые есть, в сущности, те же докусы.

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


Последний раз редактировалось Владислав Жаринов Четверг, 16 Июнь, 2011 11:15, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Среда, 11 Май, 2011 13:23 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
vvp писал(а):
...
Третья книга о поиске решений. Ну о ней пока говорить рано, она в процессе
...
Да, здесь бы показать границы алгоритма и "эвроритма". Вот скажем, есть комплекс методик алгоритмизации - с одной стороны, конкретные процедуры работы алгоритмиста устанавливает. А с другой - что есть "сложная задача", "наиболее крупная операция", "наиболее крупный этап"? как формулировать метод решения и выделять в нём этапы, если структура решения неочевидна сразу? И на конкретных примерах показать, что вопросы эти и для одной задачи, быть может, можно решить по-разному...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Среда, 11 Май, 2011 15:28 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Коллеги! В свете обсуждения книг Виталия Валерьевича прошу обратить внимание на довольно интересную книжку, появившуюся в сети: Песни о паскале.
Адрес: http://oleg-derevenets.narod.ru/
Последнее обновление - от 20 апреля.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Среда, 11 Май, 2011 15:54 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
довольно интересную книжку, появившуюся в сети: Песни о паскале.
А что там, на Ваш взгляд, интересного? (у меня взгляд чего-то замылен)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Среда, 11 Май, 2011 16:32 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Цитата:
Тогда я мысленно приложил типовой учебник программиста к преподаванию
грамоты в первом классе. Следуя замыслу такого учебника, прежде чем нацарапать «мама мыла раму», первоклашка обязан не только выучить все буквы, но и постигнуть премудрости орфографии, синтаксиса, склонения, спряжения и так далее. Абсурд, не так ли? Ведь я отлично помню, что слово «мама» я вывел, освоив лишь две буквы. Полагаю, что русский язык не проще языка программирования. И если для первого удалось создать азбуку – чудесную вещь! – то нельзя ли чем-то подобным снабдить начинающих программистов? Явилась мысль сделать обратную проекцию, – создать «букварь» для программиста. На мой взгляд, такой «букварь» должен воплощать следующие принципы.

Постепенность.
Излагать материал следует мелкими, легко постигаемыми порциями. Высота одолеваемых учеником «ступенек» не должна вызывать ощущения тупика, – маленький успех окрыляет и придает уверенность!

Практичность.
Программирование – инженерная наука. Теория и практика здесь неразделимы и «пропитывают» друг друга, – ученик не должен ощущать границы между ними. «Букварь» программиста должен сочетать в себе учебник и хрестоматию. Примеры программ должны быть либо простыми, либо очень простыми (по крайней мере, на первых порах). Необходимо показать полные решения задач с разъяснениями, – «учились бы, на старших глядя».

Поправка на возраст.
Сюжеты задач в «букваре» должны учитывать психологию подростка, а он склонен учиться играючи. Хорошо, если примеры похожи на настоящие «взрослые» проекты (разумеется, упрощенные). Непоседу не увлечешь задачей в роде «посчитать по формуле такой то» или «найти сумму элементов массива». А вот «полицейская» база данных или экзаменующая программа – это серьезно! Разжечь аппетит юного инженера – едва ли не главная цель обучения.

Маловажное – за борт!
От изложения некоторых второстепенных деталей языка лучше воздержаться. Например, можно «забыть» о записях с вариантами и не вспоминать о типизированных файлах. Не отвлекая внимания на эти детали, сосредоточиться на главном. Усвоив главное, ученик доберет остальное из «взрослых» учебников.

Обратите внимание. Автор тоже считает программирование - инженерной наукой.
На сайте есть архив с заданиями на паскале. И ответы на задания "А слабо".
Еще важное замечание автора:
Цитата:
Итак, отойдя от общепринятого порядка изложения «теории», я стремился
вовлечь читателя в активное осмысление конструкций языка, делая его едва ли не
соавтором Никлауса Вирта. «Почему в языке сделано именно так, а не иначе?» –
ответ на этот вопрос то и дело ищет читатель. Решая задачи, он убеждается в том,
что элементы языка не «с потолка свалились», а придуманы для решения типовых
проблем. Отсюда следует порядок изложения: проблема, размышление, решение.
Сначала ставится задача. Затем обсуждается, как её решить уже известными
средствами языка, или почему её нельзя решить этими средствами. После этого
дается надлежащая порция теории, и приводится решение либо с новым
применением уже известных конструкций языка, либо с привлечением новой
конструкции. Напоследок подводится теоретический итог очередной главы. Так
теория с практикой следуют рука об руку.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Среда, 11 Май, 2011 16:37 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Новых идей не вижу, но подход, конечно, правильный. Хотя было бы еще правильней взять не старый Паскаль, а Компонентный.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Четверг, 12 Май, 2011 09:03 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Валерий Лаптев писал(а):
О. Деревенец писал(а):
...Итак, отойдя от общепринятого порядка изложения «теории», я стремился
вовлечь читателя в активное осмысление конструкций языка, делая его едва ли не
соавтором Никлауса Вирта. «Почему в языке сделано именно так, а не иначе?» –
ответ на этот вопрос то и дело ищет читатель. Решая задачи, он убеждается в том,
что элементы языка не «с потолка свалились», а придуманы для решения типовых
проблем. Отсюда следует порядок изложения: проблема, размышление, решение.
Сначала ставится задача. Затем обсуждается, как её решить уже известными
средствами языка, или почему её нельзя решить этими средствами. После этого
дается надлежащая порция теории, и приводится решение либо с новым
применением уже известных конструкций языка, либо с привлечением новой
конструкции. Напоследок подводится теоретический итог очередной главы. Так
теория с практикой следуют рука об руку.
Главное здесь - что удачно обращено внимание на один из базовых принципов обучения: "Всякий текст нуждается в редактировании" :) - правда, не совсем явно (словами о необходимости "соавторства с Никлаусом Виртом"). В сущности, принцип этот непосредственно следует из третьего и четвёртого требований Каверина, обсуждавшихся в этом посте... ;)
И вариантность "либо-либо" - тоже хорошо - как и Свердлов делал (показывая работу с гетерогенной очередью разными механизмами в Обероне и Обероне-2). То же имеет смысл делать и для библиотек ББ.
Валерий Лаптев писал(а):
О. Деревенец писал(а):
Тогда я мысленно приложил типовой учебник программиста к преподаванию
грамоты в первом классе. Следуя замыслу такого учебника, прежде чем нацарапать «мама мыла раму», первоклашка обязан не только выучить все буквы, но и постигнуть премудрости орфографии, синтаксиса, склонения, спряжения и так далее. Абсурд, не так ли? Ведь я отлично помню, что слово «мама» я вывел, освоив лишь две буквы. Полагаю, что русский язык не проще языка программирования. И если для первого удалось создать азбуку – чудесную вещь! – то нельзя ли чем-то подобным снабдить начинающих программистов? Явилась мысль сделать обратную проекцию, – создать «букварь» для программиста.
Только не следует забывать, что в среде родного языка человек находится по крайней мере с момента рождения (по некоторым современным данным, начинает слышать уже в утробе матери)... и уже "на слух" многое осваивает... а "мама" - это уже сопряжение речи с письмом (и на этой основе - формулирование явно правил языка, во многом "введённых" ранее неявно через слуховой опыт), а отнюдь не изучение языка "с чистого листа"... Прогязык же учится именно "с чистого" - по крайней мере, при современной неязыково-базированной концепции общего образования, когда формальные/искусственные языки не включаются в общий языковой контекст, а идут чисто как "приложение к информашинам", также не рассматриваемым как машины прежде всего языковые. В то же время насчёт букваря верно - только в букваре наряду со словами и картинки есть :) - и тут бы дать визуализации текстовых конструкций...


Последний раз редактировалось Владислав Жаринов Четверг, 28 Июль, 2011 09:27, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Суббота, 18 Июнь, 2011 10:48 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
(На второй книге Виталия Валерьевича почему-то нет надписи "Информатика-21" на обложке...)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Воскресенье, 19 Июнь, 2011 14:11 
Аватара пользователя

Зарегистрирован: Суббота, 10 Ноябрь, 2007 21:28
Сообщения: 584
Откуда: Хабаровск
Илья Ермаков писал(а):
(На второй книге Виталия Валерьевича почему-то нет надписи "Информатика-21" на обложке...)

Да это так. Я обложку увидел только в уже напечатанном варианте.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Четверг, 23 Июнь, 2011 09:48 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
vvp писал(а):
Илья Ермаков писал(а):
(На второй книге Виталия Валерьевича почему-то нет надписи "Информатика-21" на обложке...)
Да это так. Я обложку увидел только в уже напечатанном варианте.
В издательстве всё делается по накатанной колее: автор, название. Доп. надпись возникает в результате доп. телодвижений, для которых должна возникнуть возможность и повод. Если случится допечатка и будет желание у ВВ, то нужно просто сообщить издателю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Август, 2011 10:54 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф в viewtopic.php?p=62834#p62834 писал(а):
По результатам общего знакомства с "Искусством..." впечатление следующее.
...
Недавно стал читать "Решение сложных задач". :) Весьма интересна вводная часть:
Вложение:
Комментарий к файлу: Позиция автора о поиске решений задач и подготовке в сфере программирования.
Потопахин-РешСложЗадач-извл(ВД+Огл+Введ+Гл1,2).djvu [121.26 КБ]
Скачиваний: 466
Простым языком и кратко изложен ряд базовых вещей. Общие вопросы, обсуждённые для "Искусства...", имеют смысл и здесь - но глубина материала рождает и новые темы.
Так, это:
В.В. Потопахин на с. 1 писал(а):
Основной метод, действие которого проявляется на каждом шагу - это метод борьбы с неопределённостями.
- удачно ориентирует, что задачу можно поставить неопределённостно, стохастично и детерминированно. И каждая постановка отражает понимание смысла задачи, предметной области со своей стороны.
    В то же время и детерминистская постановка должна учитывать вариативность значений тех или иных величин, когда они представляют реальные параметры. Т.к. она может влиять на решение уже при математической формализации. Можно видеть это у Одинцова (где для вычисления фиксированных и приближённых значений выводятся разные формулы) - а что получается, если игнорировать это, показано Петровым.


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

Справедливо критикуется метод "проб и ошибок" в выборе способа решения - по крайней мере, с позиций современной ТРИЗ. Тем более, что содержательную классификацию всех возможных задач и логически сомнительно построить. В то же время, скажем, у М.А. Орлова можно видеть и критику ряда методов организации творчества (хотя объектами выступают материальные системы). Можно предположить, что наряду с физическими противоречиями существуют и логические - относительно идеальных систем. И их выделение наряду с логическими эффектами даст возможность эффективнее организовать решение задач "на идеальное" - в частности, программистских. Хотя это не "предписания, как надо мыслить" - скорее возможное направление мышления ;) для придания решению задач более инженерного характера.

Интересно обсуждение декомпозиции и формализации. В то же время формализация м.б. понята более широко - как не отдельный этап, но процесс получения любого знания, отчуждаемого (по Фридланду - Гл. 6; см. также на этой странице) или "отслаиваемого" (по Леонтьеву) как совокупность данных, документированных и/или сообщённых непосредственно.

Также это:
В.В. Потопахин на с. 11 писал(а):
Можно без всякого преувеличения сказать, что запись алгоритма — это отдельная наука, требующая специальных навыков, средств и подходов.
— перекликается с идеями Паронджанова. А наука о записи (не только алгоритмической части знания о задаче) - это ИП и когнитивная эргономика как её часть.
Идея о записи на прогязыке (изначально детерминированном), но с допущением ЕЯ-формулировок (фиксирующих недетерминированную часть понимания решения) - одна из тех, что положены в основу графит метода. На примере это показано прежде всего для этой задачи оформления визуалов, - особенно при деклар-моделировании (см. этот рисунок в графчасти и о деклар-модели в текстовой части)
    И желательно владение изоморфными средствами записи именно для развития творческого мышления. Это и потому, что «разнорукость» в этом деле не мешает — и потому, что тип мышления в отношении базовых представлений для восприятия/оперирования/отчуждения у разных людей разный. Хотя большинство занимающихся сейчас информоделированием (и у Вас программированием, в частности), видимо, представляют тип «литераторов» - но это м.б. и следствием как раз «барьера вхождения» для «живописцев» при доминировании в литературе текстовой записи. Кроме того, предметники и аналитики тоже не все «литераторы» - м.б. скорее и наоборот. А программисту работать в команде (триаде) с ними — и надо бы уметь специфицировать задачи не только текстом.
В своё время В. Лаптев приводил в этом посте пример, как визуализация задач помогла и при обучении программированию — и п. Непрофессиональная визуализация этого примера показывает то же самое.

Кстати, если вернуться к творчеству, представлению знаний и противоречиям. Пожалуй, кое-что можно видеть в данной выдержке. Прежде всего - сказанное на с. 9 о разнице между реальными объектами и структурами данных, их представляющими. Между необходимой в информатике конечностью структур данных и бесконечностью (в т.ч. и в силу непрерывности изменения) реальных величин. Противоречие, видимо, проявляется и в «утечках» памяти при работе с произвольными (указательными) структурами.
Есть и разница в выразительных возможностях разных форм записи; так, в этой книге на с. 11-12 приводится пример возможности конечного графового описания ЛИСП-структуры данных - и невозможности конечно описать такую структуру скобочными выражениями.
Сказанное о точности вычислений тоже, видимо, можно поставить в этот ряд. Возможно, целесообразными именно при инженерном программировании будут решения, основанные на отказе от вещественных чисел в пользу целых (конечно, необходимой разрядности). Это даст устойчивость к накоплению ошибок, как говорилось в этом посте (для чего Штернберг предлагал специальные алгоритмы — но, видимо, только для вещественных вычислений). Тем более, что на это указывалось и в критике Оберона в этом посте, и при рассмотрении формальной верификации в этой работе.
    О творчестве в формализации много говорят - но и тут позиции не всегда плодотворные - что видно на той же Компьютерре. Произвольно рассуждая о "художественности" программирования (что особенно удобно применительно к прогязыкам с неформальным синтаксисом и undefined behaviour ;)) - отдельные граждане кое о чём забывают. Тут говорилось (Фёдором Васильевичем, кажется), что программер зачастую мало что другое знает и не всегда хочет знать - и искусства это также касается. Потому что людей искусства образуют не витанием в облаках, а по методу. И методы эти принципиально таковы же, как методологии формализации знаний в других профессиях - и зафиксированы чаще всего усилиями личностей-формализаторов, подчас великих. Во всём мире признаны методы наших сотечественников: в театральном деле - Константина Станиславского (и альтернативный - Михаила Чехова), в балете - Агриппины Вагановой. В архитектуре (материальной :)) также сложились методы отчуждения и передачи знаний, начиная с Витрувия. Менее известно, что и в живописи выработаны методы формализации, и в прикладном искусстве (на основании которых образуют мастеров и в Палехе, и во Мстёре, и в Вологде)... Видели мы это и для литературы - хотя бы у Каверина.
    И специфика художественной формализации в сравнении с технической - прежде всего в том, что: А) многое нужно передавать через личность наставника, состоявшегося в деле; Б) объём "базовых техник", подлежащих передаче, в разных делах м.б. существенно различен (в той же литературе это прежде всего грамотность и первичное владение языком, которое всё-таки прерогатива общего образования).
    Почему я тут об этом? Потому, что у многих "художественность" в информатике - это отрицание и возможности целенаправленной подготовки по информоделированию, и необходимости качества ИТ-работы. Тогда как у Виталия Валерьевича неформальность творчества не отрицает ни методичности подготовки к нему, ни требований к качеству его результата. А сказанное здесь:
    В.В. Потопахин на с. 2 писал(а):
    Обратите внимание на правила, выведенные в процессе анализа хода решения. Этих правил немного, и они не представляют системы. ...подобная система скорее всего привела бы не только к повышению эффективности мыслительного процесса, но и к ограничению Ваших творческих возможностей. Поэтому сформулированных правил немного и они не носят характер предписаний, как надо мыслить, это скорее небольшие советы, корректирующие направление мышления.
    - обнаруживает сходство с методом актёрской игры. Имеются в виду игровые "приспособления" - которые при формальном использовании могут стать "штампами". Хотя есть и различие - преодоление "заштампованности" игры происходит в т.ч. и через расширение круга "приспособлений" (часто они берутся из жизненных наблюдений - и здесь прямая аналогия с выводом правил на конкретных задачах). А гениальные лицедеи обычно ничем вроде бы не пользуются - и создают реальный характер (вспомним Смоктуновского или Леонова). Но как и у них результат "проходит контроль качества" зрительским восприятием - так и у гениальных программистов (как и у остальных :)) должно получаться то, что выдерживает контроль на соответствие требованиям к изделию - в т.ч. и к определённости поведения.
Конечно, в отличие от искусства, требования эти сегодня уже формальные - на сегодня хотя бы метод проверки моделей или автоматное программирование. И думаю, Виталию Валерьевичу будет под силу в работе по инженерии показать, как это делать на КП и в ББ. Некая попытка показать "проверяемую модель" в графит-форме предпринята в этом примере - но это всё же эскиз "предметника", требующий развития (как и сама форма записи)...

В общем, этот материал, думаю, также должен занять своё место в новых книгах автора.


Последний раз редактировалось Владислав Жаринов Суббота, 03 Декабрь, 2011 07:48, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Август, 2011 12:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Теперь замеченные невязки и ошибки (ежели ещё чего найдётся - наверное, сюда же добавлю):

Гл.1: Завершающая главу фраза, очевидно, предназначалась для завершения Гл.2 (ибо именно она заканчивает "общие места" и после неё идут 20 глав с конкретными задачами).

Гл.7: При определении координат вершин текущего отрезка относительно переданных вершин предыдущего следует говорить "координаты левого и правого концов пусть отличаются друг от друга на величину длины." (с. 50). А не "от координат центра" (как в книге) - т.к. тогда длина текущего отрезка будет такой же, как предыдущего (сначала уполовинили её - а теперь дважды откладываем от этого центра в разные стороны).
Прогтекст повторяет логику, описанную в тексте. Чтобы при сохранении её восстановить соответствие условию задачи, достаточно делить длину (величину l) не на 2, а на 4. Тогда откладывание текущей длины в стороны от центра даст половинную предыдущую длину.

Гл. 14: на с. 105 промежуточный результат вычисления во второй форме 4 5 * (ибо 2 3 + даёт 5, а не 6 :)). Отсюда и итог 20 (а не 24).

Гл. 16: фактически в математической части мы приходим к кусочно-линейной аппроксимации законов с квантованием по времени (как в АЦП). Вот эта цитата, однако, наводит на некоторые размышления:
Потопахин на с. 131 писал(а):
Если бы мы были профессиональными математиками, то внешне всё было бы проще. Была бы записана система дифуров, а затем выбран численный метод её решения. Получение хорошего результата было бы гарантировано всей мощью математического аппарата, но тогда сущность перехода от непрерывности к дискретности оказалась бы скрыта, а это, как вы видите, совсем не тривиальная вещь.
Как показано в Математике-2, вся мощь аппарата непрерывной математики-1 может и спасовать... именно когда нужно учитывать погрешности численного решения. И учням надо знать об этом. Возможно даже, что в рассуждениях Виталия Валерьевича есть зерно того же, что привело Петрова к открытию нарушения корректности решений при вариациях данных... но об этом судить опытным математикам...

И ещё одно требует обсуждения:
Потопахин на с. 133 писал(а):
Далее, представьте, что в вашей программе моделируется два процесса, для каждого созданы свои циклы, в теле которых выполняются некоторые вычисления, и предположим, что вычисления, моделирующие первый процесс, существенно сложнее, чем вычисления, моделирующие второй процесс. Из этого автоматически следует, что скорость течения времени первого процесса отличается от скорости течения времени второго процесса, и если при этом моделируемые процессы взаимодействуют друг с другом, напр., обмениваются энергией, то модель будет сильно искажена.
Первая часть вывода вопросов не вызывает. А вот вторая - думаю, смешение datamation и automation-подходов к информатическому моделированию/формализации. Короче, мы смотрим на виртуальный объект (массив данных в памяти исполнителя модельных алгопроцессов) как на реальный (физическую систему или её натурную модель).
    Несколькими страницами ранее Виталий Валерьевич вводил дискретное время. А при нём и все взаимодействия привязаны к шагам моделирования. Напр., обмен модельными параметрами (ессно, необязательно характеризующими энергию) м.б. реализован как рандеву-обмен собщениями (описанный здесь) на каждой итерации. Тогда либо накапливаются необработанные сообщения (если рандеву-каналы с памятью), либо сразу стопорится вычисление "быстрого" процесса до получения данных очередной итерации от "медленного". Но это не искажает результаты моделирования - раз данные попадают туда, куда и должны (а это и обеспечивает механизм взаимодействия). Тут есть свои тонкости - попадания на шаг в зависимости от возможностей механизма нужно программировать по-разному. Но от времени вычислений они не зависят - только от логики механизма, предоставляемой языком.
Вот если представить моделирование на АВМ... скажем, на АВК-6... то там надо выбирать масштаб времени правильно. Но это натурное моделирование, "аналоговое вычисление" в непрерывном времени (и с постоянными связями между реализациями модельных процессов).
А для автоматизации работы по модели в дискретном времени (когда часть процессов реальные), как известно, способ один - выбираем исполнителя с запасом по быстродействию, чтобы синхронизация его вычислений со внешними процессами (напр, методами, описанными здесь), была гарантирована. А проверить это формально на сегодня опять-таки можно лишь методами верификации - но это скорее к ИТ-инженерии, чем к поиску решения...

Гл. 22: Как-то сомнительно, что алгоритм в записи на с.191, содержательные действия которого сводятся к уравнениям (<то>=<этому>), при исполнении над исходной таблицей может дать пребразованную... да ещё с такими быстрорастущими значениями... :)


Последний раз редактировалось Владислав Жаринов Понедельник, 22 Август, 2011 12:43, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Воскресенье, 07 Август, 2011 15:46 
Аватара пользователя

Зарегистрирован: Суббота, 10 Ноябрь, 2007 21:28
Сообщения: 584
Откуда: Хабаровск
С книгой о решении сложных задач вышла неувязка. Замах был богатырский и есть много идей которые, как я уже знаю кажутся интересными не только мне. Но книга вышла сырая. Там много содержательных ошибок, некоторые тексты написаны исключительно корявым языком. Сейчас я работаю над книгой "Поиск решения" которая я думаю будет усиленным вариантом той книги.

Правда как это не глупо но сейчас мне приходится тратить время и энергию не войну с гоблинами. У меня два года назад поменялось руководство. Сейчас у меня в начальниках два бывших завуча профтехобразования и один филолог. И эти женщины не понимают чем я занимаюсь. Объяснить не получается. На все следует один тупой вопрос. А что вы делаете на край как методист. Ваши книги печатаются в Москве, а что вы делаете на край. Трудно разговаривать с идиотами. Правда сейчас разговоры закончились. В ближайшее время либо я их поставлю на место, либо меня уволят по статье. Когда разрешится проблема так или иначе, продолжу работу. окончательно решил, что по иженерии будет отдельная книга. Уже более менее ясно, как лично я гляжу на этот предмет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Воскресенье, 07 Август, 2011 17:10 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
vvp писал(а):
... У меня два года назад поменялось руководство. Сейчас у меня в начальниках два бывших завуча профтехобразования и один филолог. И эти женщины не понимают чем я занимаюсь. Объяснить не получается. На все следует один тупой вопрос. А что вы делаете на край как методист. Ваши книги печатаются в Москве, а что вы делаете на край. ...Когда разрешится проблема так или иначе, продолжу работу. ...
Удачи!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Ещё один вопрос инженерии
СообщениеДобавлено: Воскресенье, 07 Август, 2011 17:28 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
vvp писал(а):
...окончательно решил, что по иженерии будет отдельная книга. Уже более менее ясно, как лично я гляжу на этот предмет.
Вот ещё такая штука по этой тематике. На Паскале организация сложных программ может выглядеть, как показано здесь:
Вложение:
Видно, что средствами Турбо-диалекта получается весьма сложно обеспечить сокрытие и параметризацию передачи по типам (на это указывает и сам автор). Как я понимаю, у Свердлова на примере гетерогенной очереди здесь (во второй выдержке) показано решение той же задачи средствами Оберонов. Наверное оно более элегантно (можно передавать разные типы данных на обработку одним и тем же процедурам без усложнения структуры). Очевидно, взаимодействие структурных элементов архитектуры и его зависимость от средств языка - это одна из базовых проблем инженерии. Которую полезно разобрать.
    Как я понимаю, в силу сказанного на ТП строительство каркасов показать для начинающих не так-то просто... не говоря уже о реальном их ведении. :) Удачно, что к моменту возникновения желания писать об этом Вы перешли на КП. ;)
Кстати у Круза интересное построение описания языка (Приложение D).


Последний раз редактировалось Владислав Жаринов Понедельник, 08 Август, 2011 07:10, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хабаровский учебник по КП
СообщениеДобавлено: Понедельник, 08 Август, 2011 06:46 
Аватара пользователя

Зарегистрирован: Суббота, 10 Ноябрь, 2007 21:28
Сообщения: 584
Откуда: Хабаровск
Есть такая идея. Надо показать, что минимализм языка не ограничивает возможностей программиста. Если этот минимализм выстроен грамотно и найден минимальный и в то же время логически завершенный язык, то это дает процедуру построения строгой, хорошо проверяемой архитектуры программы. А это и есть главная цель. Язык в моем понимании это не средство выражения любых мыслей, это средство приведения набора неопределенностей к строгому формализму. Инженерия это система методов устранения неопределенностей. В этой системе есть общий методологический принцип - структурное программирование/нисходящее проектирование (я эти два термина всегда использую в паре). все остальное есть техническая реализация основного принципа. Модульность, ООП это все ребята обслуживающие этот основной принцип.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Август, 2011 08:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ага :) И Круз как раз показывает, что в ТП состав средств языка неоптимальный для выстраивания архитектуры. Тогда как Свердлов - что в Оберонах минимализм в этом смысле оптимальный.
Вот насчёт проверяемости "вручную" - это в любом случае непросто... поэтому и появилась автоматическая верификация (но с сопутствующими информатизации процесса ограничениями - вроде только целочисленных типов). Визуализация архитектуры - один из путей интенсифицировать ручную ("мозговую") проверку. Но в "кризисных" задачах я всё-таки считал бы правильной автоматическую - скажем, ту же проверку моделей. А "исходные чертежи" нужными просто как более удобную форму представления информодели (в частности, программного проекта). Но не отменяющей текстовую. А может, и как форму представления всей задачи - о чём далее.

Вообще о "Решении..." всё было сказано именно к тому, что ошибки - это мелочи. А книга интересная - и, в сущности, основная её часть как раз по теме поиска решения. Только проверить задачи, быть может, откорректировать/дополнить новыми, исходя из нового опыта - и перевести реализацию на КП.
А вот вводная часть, в сущности, в многом по теме ИТ-инженерии - по крайней мере, про формализацию и язык записи точно. И м.б. частично изложено до поиска решения - возможно, интегрировано уже в первую книгу "ядра".
Также и "правило наглядности" на с. 17 и его иллюстрация задачей - не только к поиску решения. Как раз здесь, исходя из понимания формализации/моделирования как сквозного, двуединого, стадийного/уровневого процесса выработки знания, доступного для передачи в этом пункте (базируемого на результатах Фридланда и И.Грековой), можно видеть кое-что. А именно - наглядное представление данных на качественной стадии формализации, чтобы найти математический формализм решения (от которого уже строить информатический, в данном случае - как программу). Тут как раз оптимально оказалось представление структуры в виде таблицы - но представляющей, в сущности, граф хода расчётов.

Попытка основывать поиск решения на выявлении и разрешении логических противоречий в данной предметке сначала потребует выявления типов этих противоречий. Что, возможно, увело бы в сторону от изложения Вашего опыта. По мере выявления и формализации их (а также "логических эффектов") так, как это изложено, скажем, у Орлова, этот путь поиска также не стоит сбрасывать со счетов. Но пока, конечно, у нас в распоряжении, IMHO, только два противоречия:
    * между неабстрагированностью типов сущностей на качественной (и часто в многом ещё на математической) стадии и необходимостью представить их на инфоорматической стадии через абстрактные типы (но имеющие в основе типы, поддерживаемые исполнителем - реальным или виртуальным);
    * между возможной бесконечностью значений реальных параметров моделирования и необходимой конечностью представляющих эти параметры величин информодели.
Может, и с этим можно кое-что сделать по модерн-ТРИЗ-методу - но это уже смотреть делающему. :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 15 Август, 2011 10:41 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Драконограф в viewtopic.php?p=64483#p64483 писал(а):
Теперь замеченные невязки и ошибки (ежели ещё чего найдётся - наверное, сюда же добавлю):
...
Добавил по некоторым главам.
Также два общих соображения:
    *возможно, стоит давать сноски по отдельным фактам и терминам. Скажем, что "польская" в названии записи - от того, что её автор - поляк Я. Лукасевич;
    * нужно будет перейти к "когнитивному стилю" идентификаторов, подобно этому, т.е. на русском, смысловым и с форматным выделением (что в основном сделано в "Искусстве алгоритмизации").
P.S. В целом интересна постоянная связь алгоритмов и структур данных - в полном соответствии с изначальной версией тезиса создателя Паскаля :) В то же время в "Решении" в отдельных главах виден учёт исполнителя - уже в соответствии с полной версией, введённой Виртом здесь. В Гл. 19 прямо вводится ограничение памяти, а в Гл. 16 - дискретность времени. Но по второму, как говорилось в замечании, нужна проработка представления о взаимодействии алгопроцессов (кстати, сам Вирт озаботился этим - см. в этом посте).


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 386 ]  На страницу Пред.  1 ... 12, 13, 14, 15, 16, 17, 18 ... 20  След.

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


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

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


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

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