OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 42 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 30 Ноябрь, 2013 13:17 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Иван Кузьмицкий писал(а):
Дейкстра утверждает, что ни концепции сложности, ни полезной теории сложности нет. Это значит, что мы не можем формально сказать, где сложность излишняя, а где не излишняя. Стало быть, надо уходить от складывающихся ощущений и бесполезных чувственных образов в сторону формализации. И только оттуда начинать рассуждать про сложность.
(* выделение моё *). С одной стороны Вы утверждаете, что "мы не можем формально" детектировать излишнюю сложность. С другой стороны, что "нам надо уходить в сторону формализации" этого вопроса. Error detected.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Ноябрь, 2013 13:31 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Поправьте детектор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Ноябрь, 2013 13:45 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Иван Кузьмицкий писал(а):
Поправьте детектор.
Лучше бы Вы это не говорили :wink:

Вот Ваша сентенция, очищенная от всего, что не относится к логике:
Цитата:
А не может быть равно Б, стало быть нужно А сделать равным Б.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Ноябрь, 2013 13:52 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
igor писал(а):
Иван Кузьмицкий писал(а):
Дейкстра утверждает, что ни концепции сложности, ни полезной теории сложности нет. Это значит, что мы не можем формально сказать, где сложность излишняя, а где не излишняя. Стало быть, надо уходить от складывающихся ощущений и бесполезных чувственных образов в сторону формализации. И только оттуда начинать рассуждать про сложность.
(* выделение моё *). С одной стороны Вы утверждаете, что "мы не можем формально" детектировать излишнюю сложность. С другой стороны, что "нам надо уходить в сторону формализации" этого вопроса. Error detected.

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

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

Так что - все возможно.


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
igor писал(а):
Иван Кузьмицкий писал(а):
Поправьте детектор.
Лучше бы Вы это не говорили :wink:

Вот Ваша сентенция, очищенная от всего, что не относится к логике:
Цитата:
А не может быть равно Б, стало быть нужно А сделать равным Б.


Что есть А и что есть Б? Исходные положения у меня таковы: примем за А возможность формального определения сложности, и за Б - нормирование уровня сложности (только при наличии какой-то нормы можно говорить о излишней или недостаточной сложности). Так вот, я утверждаю, что: если не А, то и не Б. И вывод: если хотите Б, то надо сначала А.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Ноябрь, 2013 18:08 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Иван, уверен что Вы мыслите правильно, просто немного неудачно выразились вот в этом сообщении. Как бы то ни было с недоразумением вроде бы разобрались (не без помощи Валерия Лаптева).


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Я подозреваю, что просто Вы неудачно прочитали мой текст :) и некоторая недопонятость остаётся. Мне хотелось сказать, что при отсутствии формализма сложности, оценки типа "излишняя сложность" являются опасными, ибо порождают ложное ощущение понимания вопроса.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:12 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Иван Кузьмицкий писал(а):
...
Дейкстра утверждает, что ни концепции сложности, ни полезной теории сложности нет. Это значит, что мы не можем формально сказать, где сложность излишняя, а где не излишняя. Стало быть, надо уходить от складывающихся ощущений и бесполезных чувственных образов в сторону формализации. И только оттуда начинать рассуждать про сложность.
...

Валерий Лаптев писал(а):
...
Требуется формализовать определение сложности хоть как-то...

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

Сложность есть мера неоднородности (C) А. Седов (отсюда и сюда):
А. Седов писал(а):
...

ТЕЗИС 2. Основная проблема программирования
-------------------------------------------

2.1. Сложность есть МЕРА НЕОДНОРОДНОСТИ. Чем более разнообразны составляющие
нечто части, чем более разнообразны образуемые между частями связи - тем
выше сложность этого нечто. Сложность вселенной, состоящей из одинаковым
образом сложенных одинаковых кирпичей равна сложности одного кирпича и
образуемых им с соседями связей (теорема редукции сложности). Таким образом,
сложность выражает не масс-энергетические характеристики мира (см.
E=m*c**2), а СТРУКТУРНЫЕ его свойства, причем весьма емкО и общО.

2.2. Все разработчики программ имеют дело ИСКЛЮЧИТЕЛЬНО со сложностью.
Программы не имеют ни массы, ни энергии (если отвлечься от параметров
исполняющего их hardware). Программы - это ЧИСТЫЕ СТРУКТУРЫ, и сложность
является одним из основных интегральных параметров этих структур. Борьбе
со сложностью и посвящают программисты свою жизнь. Эта борьба обычно
вполне безнадежна для программистов, поскольку они не понимают законов
мира, в котором пытаются оперировать структурными конструкциями, иерар-
хиями классов или словарями. Программисты - герои "невидимого фронта"
боев с колоссальными объемами незнания; герои, которых вооружают
негоднымы погремушками вместо настоящих инструментов постижения истины.
Настоящие профессионалы быстро понимают, что разработчики языков
программирования типа C/C++ или Pascal/Modula/Oberon и фирмы-производители
таких инструментов просто морочат им голову, предлагая вместо серьезных
средств всего-лишь генераторы случайных блужданий в пространстве состояний
задачи. В поисках выхода некоторые пытаются создавать собственные инстру-
менты (обычно - безуспешно), но большинство открывают для себя НЕязыковые
(в смысле ЯВУ) средства программирования типа Forth. Само по себе это уже
хорошо, поскольку глупости вроде приоритета значка ++ не застилают теперь
им глаза на СУЩЕСТВО дела. Хотя даже Forth сам по себе (и он - прежде
всего!) не дает поначалу никаких преимуществ в работе, кроме реального
осознания "размеров бедствия". Но осознание проблемы - уже половина
решения...

2.3. А существо дело крайне просто сформулировать: основная проблема
программирования -- это проблема управления сложностью программы; это
проблема "размазывания" сложности вдоль текста программы "ровным слоем"
(не слишком толстым, но и не очень тонким - как масло на бутерброде);
не допускать "сгущений" сложности важно просто потому, что именно в
таких местах сложность легко "перепрыгивает" ограниченные человеческие
способности к одновременному восприятию множества взаимосвязанных вещей
и в программе появляются не описки, а настоящие ошибки (ограниченность
НА ЛЮБОМ УРОВНЕ ПОЗНАНИЯ понимания задачи НЕЛЬЗЯ считать ошибкой - это
просто ИМАНЕНТНАЯ особенность познания, процесс которого, как известно,
бесконечен).

2.4. Если попробовать пересказать "своими словами" (без формул) учебник
матанализа, то можно обнаружить, что пересказ занимает на порядки больший
объем текста, чем "первоисточник", а также НЕПРИГОДЕН к использованию
на практике по причине неспособности дать краткие и внятные РЕЦЕПТЫ
действий в типовых ситуациях. Этот феномен объясняется с помощью понятия
"метрика текста", в которое здесь не хотелось бы углубляться. Достаточно
отметить, что современные средства программирования являются
КВАЗИматематическими, поскольку метрики порождаемых ими текстов по
мощности не слишком серьезны по сравнению с метриками обычных
математических текстов. В чем причина? Причина в том, что математический
текст всегда строится В ТЕРМИНАХ РЕШАЕМОЙ ЗАДАЧИ. А вот средства програм-
мирования представляют собой всегда некую жесткую "систему команд", в
рамках ограниченной и жесткой семантики которой приходится записывать
постановки и решения задач. Процесс "трансляции" содержательной постановки
задачи в тексты средств программирования выполняется в подавляющем
числе случаев "вручную" и состоит в переводе терминов исходной задачи в
термины целевого языка. Этот процесс и есть первопричина всех проблем,
а его исключение -- цель НОВОЙ технологии программирования.

2.5. Не вдаваясь в детали реализации инструмента, решающего эту
задачу, можно отметить лишь одно непременное условие: новая технология
должна представлять собой формализм, НЕМАШИННЫЙ АЛГОРИТМ (но понятный
и простой для человека!), позволяющий ВСЕГДА записывать постановку
задачи и методЫ ее решения в терминах ТОЛЬКО самой задачи с привлечением
одного-единственного автоматизма: АВТОМАТИЗМА РАЗДЕЛЕНИЯ И КОНТРОЛЯ
СЛОЖНОСТИ. Цель такого автоматизма -- дать ПОЛНЫЙ контроль над любой
частью постановки или решения задачи НЕПРОГРАММИСТУ, "активное поле
внимания" которого может не превышать обычных 4-7 чанков.

2.6. Сегодня уже известно много способов реализации автоматического
разделения сложности. В частности, это логико-матричные методы
(например, расширенные таблицы решений), специальные логики (темпоральные,
нечеткие и т.п.), методы факторизации, событийно-ориентированные протоколы
взаимодействия процессов и т.д. Вопрос представляет не ВОЗМОЖНОСТЬ
реализации такой системы, а ее ФОРМА и конкретный набор используемых
средств.
...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:15 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Иван Кузьмицкий писал(а):
...
Ну вот, теперь встаёт вопрос - как бороться со сложностью? Мы не знаем, что такое сложность, но у нас зато есть формальные знаковые системы (языки программирования) и эффективное воплощение формальной системы (компьютер).

Если программист при решении задачи пытается выразить проблемы с помощью некоего формализма, то можно подумать, что чем больше всяких ништяков напихано в этот формализм, тем круче. Замыканий, итераторов и дженериков нет в Обероне, но значит ли это, что формализм Оберона не подходит для выражения проблем? Может так оказаться, что проблема в самом программисте, который привык итераторами мерять всё подряд.
...
Вопрос лишь в том, сколько надо ништяков ввести в язык, чтобы смочь победить сложность окончательно. Поскольку комбинаторные взрывы никто не отменял, то можно предположить, что количество проблем растёт в прогрессии. А значит, и формальную систему надо усиливать до бесконечности, вводя в неё всё новые, условно говоря, итераторы.

А если не до бесконечности, тогда надо знать предел. Кто его знает? Дейкстра не знает, он откровенно сказал. Значит, будем опираться на практический опыт, запихивая в какой-нить питон всё новые и новые отработки.
...

Не Дейкстра, конечно, но философская концепция гораздо глубже, подробности в оригинале, а сжато основная суть:
А. Седов писал(а):
...

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

Чтобы обучиться современному проектированию, ничего воровать не нужно.
Нужно заплатить $40-$60 и купить книжку с CD-ROM впридачу, где будут
РАЗЖЕВАНЫ на сотнях страниц и SDT, и IDEF*, и CASE-методы. Да вот беда-то
какая: НЕ НАЙДЕТЕ Вы там серьезных ответов на самые кондовые (они же и
посконные) вопросы постылого программерского бытия:

1. Как писать программы БЕЗ хотя бы логических ошибок?
2. Как делать это ОЧЕНЬ быстро?
3. Как получать ЭКСТРЕМАЛЬНЫЕ по оптимальности решения?
4. Можно ли писать программы БЕЗ программирования?
5. И т.п., и т.д.

И будет это совсем не случайно. Как можно отвечать на такие вопросы,
НЕ ИМЕЯ ТЕОРИИ ПОСТРОЕНИЯ ПРОГРАММНЫХ СИСТЕМ? Есть хорошие работы по частным
аспектам, масса инсайтов, догадок, гипотез, а теории - НЕТ. Теория ЕСТЬ,
когда можно подставить в нее параметры своей задачи, слегка напрячь мозги
и получить РУТИННЫЙ результат. Теории нет, когда программы пишут потом и
кровью (если учесть, сколько лет жизни КРАДЕТ фонящая-излучающая аппаратура
компьютера у своего хозяина), срывая все мыслимые и немыслимые сроки,
вылезая из самых оптимистичных смет, и сплошь и рядом НЕ МОГУТ довести
работу до конца. Когда Microsoft (!) СРЫВАЕТ выпуск Вынь'95 НА ГОД!
И выпускает полуработающего урода! Что еще нужно, чтобы Вы поверили --
НЕТ теории?!!
...
За прошедшие годы я наблюдал смену нескольких
технологий программирования. То, что я видел, не оставляет сомнений:
мы имеем дело с обманом, точнее, с самообманом творцов этих технологий.
Нет НИКАКИХ шансов на то, что в рамках парадигмы ЯВУ мы получим вообще
когда-либо что-то отличное от "торговли пустыми надеждами" просто потому,
что идеология ЯВУ не содержит никаких "идей", кроме парадигмы потока
исполняемых команд. Это парадигма для машины, а не для человека. Путь
"подстройки" человеческих возможностей под убогий "машинный интеллект"
имеет очевидные физиологические и психологические ограничения и потенциал
этого подхода был почти полностью исчерпан с появлением языка ФОРТРАН.
Все последующее движение в этом направлении реально было бегом по
кругу. Об этом еще в 60-70-х говорили и Кнут, и Мур, и другие корифеи.

Поэтому единственным способом разорвать порочный круг идеологем ЯВУ
является ОТКАЗ от ЯВУ как от средства работы ЧЕЛОВЕКА с машиной. Роль
ЯВУ должна быть "сужена" до их истинных границ -- служить промежуточной
формой между записью мысли человека и системой команд машины. Основным
средством работы человека с машиной должны стать системы, где ЯВУ
практически не будет виден конечному пользователю. ЯВУ неизбежно и в
скором времени будут вытеснены в свои "природные" границы разнообразными
системами записи, хранения, расширения, интерпретации и передачи ЧЕЛОВЕ-
ЧЕСКОГО ОПЫТА. С развитием технологии распространения данных на CD-ROM,
с появлением глобальных сетей стало ясно: надвигается революция в
технологии хранения и передачи знаний между поколениями, сравнить которую
в европейской истории можно только с распространением типографских методов
издания книг в Средние века (что и послужило источником последовавшей затем
промышленной революции, невозможной без "Возрождения", суть которого своди-
лась к массовому распространению и взрывному накоплению разнообразных
знаний, в основном, конечно, прикладных). ЯВУ для этих целей совершено
не подходят, а значит будут заменены принципиально иными системами,
например, вроде той, которую я пытался описать в своих заметках.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 20:00 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Сложность - мера неоднородности.
Это правильно.
Я это на интуитивном уровне понимал.
Хорошо, что сформулировано явно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 20:23 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Валерий Лаптев писал(а):
Хорошо, что сформулировано явно.
Пишут, что существует математический аппарат, призванный бороться с многообразием и сложностью. Более того, есть ненулевая вероятность существования софта на базе этого мат.аппарата. К сожалению, сайт http://spnikanorov.ru недавно перестал отзываться.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 22:52 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Ни разу не слышал.
Возможно, речь идет о синергетике?


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Нет, там в основе родовые структуры Бурбаки, как я понял, а сам аппарат - ступеней множеств.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 20 Декабрь, 2013 18:46 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Иван Кузьмицкий писал(а):
Пишут, что существует математический аппарат, призванный бороться с многообразием и сложностью. Более того, есть ненулевая вероятность существования софта на базе этого мат.аппарата...

Если говорить о борьбе со сложностью в области программирования, особенно а-ля мэйнстрим, то здесь ещё непаханое поле, причём для методик пока более чем достаточно начальной школьной элементарной математики и немного здравого смысла. Например, возьмём вот эту Р-программу для вычисления корней уравнения (из книги Вельбицкого, здесь). В качестве одного из вариантов на приемлемом ЯП она может быть задана примерно так:
Код:
type Результат(a) = ДРВК a, a | ДКК a, a | ДРК a | КО а | КН | КБМ

алгоритм = (a, b, c) ->
    | a != 0  =>  x = -b/2a
                  d = x^2 - c/a
                  дрвк(d, x)

    | b != 0  =>  KO(-c/b)
    | c != 0  =>  КН
    | _       =>  КБМ

    where дрвк = (d, x) ->
               | d > 0  =>  d' = sqrt(d)
                            x1 = x + d'
                            x2 = x - d'
                            ДРВК(x1, x2)
               
               | d < 0  =>  x2 = sqrt(-d)
                            ДКК(x, x2)

               | _      =>  ДРК(x)

do ->
    a = 12
    b = 34
    c = 56
    рез: Результат(float64) = алгоритм(a, b, c)
    case рез of
         ДРВК(x1, x2)  =>  writeln "два различных вещественных корня: $x1, $x2"
         ДКК(x1, x2)   =>  writeln "два комплексных корня: $x1, $x2"
         ДРК(x)        =>  writeln "два равных корня: $x"
         КО(x)         =>  writeln "корень один: $x"
         КН            =>  writeln "корней нет"
         КБМ           =>  writeln "корней бесконечно много"

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

Теперь подход мэйнстрима, скажем, Java. Конечно, всё должно быть в классах, никаких там "алгоритмов". Тот же тип "Результат" будет выстроен в цепочку наследования, введены "свойства", сплошные методы "Get"/"Set" и т.д. Сразу же написаны "тесты" и успешно "пройдены". Более того, должен же быть полиморфизм (!!!, мы же современны !), срочно нужны ещё "интерфейсы" и их "реализации" (написаны "тесты" и успешно "пройдены"). А как же Dependency injection ? Срочно ваяем "фабрики", ваяем XML-конфигурации (матерясь на этот XML) или втыкаем "аннотации" в код, и т.д. и т.п. (нужны или нет здесь "фабрики" - думать нельзя, так промстандарты постановили, обо всём уже подумали за тебя ...)
В результате, "уравнение" размазывается на кучу методов и классов, и на разные файлы, в коде технических слов (сплошной мусор, "организованный" далеко не самым оптимальным образом) больше, чем "решения".

Блин, сложно... Так ведь же нужен UML... Рисуют квадратики с лесом линий, смотрят на них..., между собой молча договариваются, что это якобы помогает, начальство отстало... Множатся диссертации про неимоверные успехи UML(ОПП)-методологии...

Всё-равно, сложно... Куча книг про "паттерны", диссертаций про метрики кода..., якобы разобраны все алго- и ООП-связи с точность до граммов. Мэйнстрим-строители "посчитали" и "взвесили" сложность да ужаснулись? Ага, щаз... Вон в Scala простор для диссертаций чуть ли не каждый день расширяется как Вселенная, новые метрики для оценки "явно неявного" ("implicit"-ы) - блеск! Есть методики, учитывающие плюсовые friend-классы, но почему-то нет метрик, показывающих их абсурдное противоречие самой же ООП-идеологии...

В общем, вся борьба со сложностью - "ништяки" "ништяками" погоняют...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Декабрь, 2013 15:18 
Модератор
Аватара пользователя

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


Кстати, уважаемые собеседники помнят про теорию сложности Колмогорова?
(вопрос на всякий случай)


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Цитаты из книги Никанорова:
Цитата:
Колмогоров проводил свои идеи осторожно, но это не спасло его начинание от
трагической неудачи. Настойчиво проводимая им реформа математического образования в
советской средней школе, в центре которой было преподавание школьникам теории
множеств, указывает на понимание им масштаба социального значения теории множеств
как единственной общезначимой математической теории и ее эвристического значения.
Необходимо предельно тщательное исследование жизни и творчества А. Н. Колмогорова,
учитывающее изложенные соображения, он, видимо, не был «просто математиком».


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


Никаноров-то учился у Колмогорова, как я понял. Он часто его упоминает.

P.S. Сайт http://spnikanorov.ru снова заработал.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Декабрь, 2013 17:30 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Илья Ермаков писал(а):
Валерий Лаптев писал(а):
Сложность - мера неоднородности.
Это правильно.
Я это на интуитивном уровне понимал.
Хорошо, что сформулировано явно.


Кстати, уважаемые собеседники помнят про теорию сложности Колмогорова?
(вопрос на всякий случай)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Декабрь, 2013 17:39 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
2Иван Кузьмицкий:

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

Также ряд учёных считает, что именно с Колмогоровской реформы начался кризис школьного математического образования - и что лучший сейчас выход - возврат на учебники Киселёва.

Причина - некоторый неучёт Колмогоровым специфики школьного образования и вообще психологии образования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 23 Декабрь, 2013 21:41 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Ряд учёных считает так, другой ряд считает эдак... Тот же Никаноров критикует Арнольда за непонимание "предметно ориентированной роли теории множеств". Пусть себе математики спорят, тем более что
Цитата:
...это замечательная наука - математика. Люди со столь противоположными мнениями, как мы двое, могут в ней сотрудничать, уважать друг друга, знать и использовать результаты друг друга, сохраняя при этом свои противоположные мнения... И, смотрите - мы оба остались живы..."
http://www.mccme.ru/edu/index.php?ikey=viarn_burbaki

Главное - практика, а с ней, насколько я понял, у теории ступеней множеств порядок :)


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

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Иван Кузьмицкий писал(а):
Пусть себе математики спорят, тем более что
Цитата:
...это замечательная наука - математика. Люди со столь противоположными мнениями, как мы двое, могут в ней сотрудничать, уважать друг друга, знать и использовать результаты друг друга, сохраняя при этом свои противоположные мнения... И, смотрите - мы оба остались живы..."
http://www.mccme.ru/edu/index.php?ikey=viarn_burbaki
Математика здесь ни при чём, всё дело в людях.


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

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


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

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


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

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