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

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

и эти три решения, если они известны, описываются с помощью трех чисел: решение 1, решение 2 и решение 3.
я утрирую, конечно, но общий смысл именно такой.

FR>Вообще то у нас нет цели именовать уже готовые решения, у нас цель получить эти решения.

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


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

Здравствуйте, DarkGray, Вы писали:

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

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

DG>сейчас мы говорим о задаче второго вида: допустим, что мы уже знаем как решать все проблемы, стоящие перед человечеством — сколько потребуется бит, чтобы закодировать данное решение.

Явно не 32 или там 128, нумерация это чистая уловка считать нужно не только номер, но и длину нумерованной программы тоже.

Здравствуйте, HrorH, Вы писали:

J>>ну это вам лучше знать, почему вы постоянно на одни и те же грабли наступаете Более другие человеки ваше "этое" делают
HH>Вот. Грабли — ключевое слово.
HH>Я писал не только о себе, но и вообще о том, как программисты пишут программы.

я таки не понял — это самокритика или вы знаете абсолютно всех программистов?

Резкий переход о Сенеки к программистам позволяет мне сделать заключение что я развеял ваши сомнений в истинности высказывания Сенеки, да?

HH>Идея номер два.
HH>Представьте, что Вы пишете какую-то нетривиальную часть программы.
HH>Скажем, ядро Вашей системы, которое должно работать как часы.
HH>Естественно, что Вы захотите все тщательно продумать.
HH>Выделить основные сущности, продумать основные операции, основные сценарии, просчитать все на несколько шагов вперед.
HH>Вполне вероятно, что Вы будете все это переписывать еще десять раз, но дело не в этом.
HH>Вот этот набор основных сущностей и основных операций между ними я и называю МОДЕЛЬЮ.

не, обычно этот набор сущностей и операций называют АТД — абстрактный тип данных, например АТД "вектор" в котором реализованы операции сложения и умножения векторов и операция умножения вектора на скаляр

HH>А будучи сформулированной на языке математики, она становится математической моделью.

что сформулировано на языке математики? Векторная арифметика? Она и без всякого программирования уже давно на нем сформулированна — что бы сложить два вектора надо,.. при сложении векторов получается вектор,.. и т.д.

HH>Что же мы имеем в реальности. Программисты пишут программу. Тестеры находят ошибку. Эта ошибка свидетельствует о том, что какая-то часть системы была не продумана.
HH>Программист эту ошибку исправляет.
HH>На чем все дело обычно и заканчивается. Никакого анализа обычно не делается, на это просто нет времени.
HH>В результате через некоторое время тестер находит другую, но в чем-то похожую ошибку в другой части системы.
HH>А третью и четвертую ошибку тестеры не находят, потому что их можно найти только с помощью скурпулезного анализа, а воспроизвести их случайно довольно маловероятно. Эти ошибки найдут заказчики, ведь там систему будут использовать тысячи людей.

если ошибку никто не находит, потому что воспроизвести ее маловероятно, то ошибки нет. (с) начальный курс "Технологии программирования"
если у вас криво построенный цикл разработки, когда программист кое-как исправляет ошибку без анализа (кстати, что это значит? Если функция при определенном сочетании значений переменных выдает 10 вместо 5, то ваш программист вставляет кусок if (сочетание параметров) return 5; ? ), то это ваши персональные грабли, не надо их обобщать.


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

Здравствуйте, DarkGray, Вы писали:

DG>и это может означать, что скурпулезный анализ требует проверки, например, 10^30 различных вариантов, что является на сегодня нерешаемой задачей.

DG>при поиске ошибок мы имеем дело с NP-задачей, которая нерешаема по определению.

Увы, на практике это скорее всего означает, что количество вариантов было равно десяти, но протестировать три из них просто не пришло тестеру в голову (т.к. он не знал внутренней логики системы). Зато программист мог бы продумать ВСЕ эти десять возможных вариантов.
На практике, есть части системы, которые наиболее важны, и где наиболее просто сделать ошибку.
Именно эти части обычно содержат очень небольшое количество вариантов.
Тут еще вопрос, как это количество считать, чтобы не плодить несколько вариантов там, где на самом деле вариант только один.

Здравствуйте, DarkGray, Вы писали:

DG>для создания решения сложной задачи используется алгоритм последовательной композиции: решение большей задачи A складывается из решений меньших задач A1-An. Самый широкий класс ошибок при этом, что не учтено какое-то влияние решения задачи Ai на решение задачи Aj, приводящее к сбою в решении Aj (или к сбою и в Ai, и в Aj): например, решение задачи Ai в процессе выполнения может эксклюзивно захватывать инструменты, которые необходимы для решения задачи Aj.

Мне кажется, что пример с захватом инструментов неудачен, т.к. такие вещи должны продумываться чуть ли не в первую очередь.
Более того, мне сходу даже не придумать пример, когда бы подзадачи мешали друг другу, и это не выявлялось бы еще на этапе проектирования.

DG>>для создания решения сложной задачи используется алгоритм последовательной композиции: решение большей задачи A складывается из решений меньших задач A1-An. Самый широкий класс ошибок при этом, что не учтено какое-то влияние решения задачи Ai на решение задачи Aj, приводящее к сбою в решении Aj (или к сбою и в Ai, и в Aj): например, решение задачи Ai в процессе выполнения может эксклюзивно захватывать инструменты, которые необходимы для решения задачи Aj.

HH>Мне кажется, что пример с захватом инструментов неудачен, т.к. такие вещи должны продумываться чуть ли не в первую очередь.
HH>Более того, мне сходу даже не придумать пример, когда бы подзадачи мешали друг другу, и это не выявлялось бы еще на этапе проектирования.

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

как много ты видел кода, который корректно обрабатывает нехватку памяти или нехватку свободного места на диске, и не приводит при этом к порче данных? не считая БД, которая под это специально проектируется

ярким примером того, что в коде редко учитывается влияение подзадач друг на друга — являются DDOC-атаки: повышение нагрузки на подзадачу Ai (например, многократной загрузке главной страницы) приводит к отказу всей задачи A (отказу всего сайта). в данном случае не учитывается, что для обработки всех страниц используются одни и те же инструменты.

Здравствуйте, FR, Вы писали:

FR>

FR>Из неприводимости числа Ω следует, что всеобъемлющей математической теории существовать не может. Бесконечное множество битов Ω составляет бесконечное множество математических фактов (является ли каждый выбранный бит единицей или нулем), которые не могут быть выведены из каких бы то ни было принципов, более простых, чем сама последовательность битов. Значит, сложность математики бесконечна, тогда как любая отдельная теория «всего на свете» характеризуется конечной сложностью и, следовательно, не может охватить все богатство мира математических истин

FR>Очень большая часть реальных задач именно такого "не упрощаемого" типа. Модели в их решении почти бесполезны.

Не могу проследить логическую цепочку в Вашем ответе.

Здравствуйте, DarkGray, Вы писали:

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

Да, Вы правы. Я имел в виду свои ресурсы, а не ресурсы ОС.
Ваши рассуждения, как мне показалось, касались взаимодействия подмоделей внутри модели, и вдруг такой низкоуровневый пример.
Это слегка сломало мне мозг.

HH>Да, Вы правы. Я имел в виду свои ресурсы, а не ресурсы ОС.
HH>Ваши рассуждения, как мне показалось, касались взаимодействия подмоделей внутри модели, и вдруг такой низкоуровневый пример.
HH>Это слегка сломало мне мозг.

при чистом построении моделей узким местом становятся такие инструменты, как: операции, понятия и т.д.

возьмем, например, базовую операцию 'разделить':
какая-то подзадача может считать, что результат деления необходимо округлять до целого:
какая-то — что округлять необходимо до машинной точности,
какая-то — что до определенного эпсилона,
какая-то — что округление должно делаться вверх,
другая — вниз,
третья — что до ближайщего,
четвертая — что до ближайщего, но округление ...5 дожно делаться вверх, если предыдущая цифра нечетная, и вниз — если четная,
пятая — что для отрицательных чисел правила округления должны быть такими же, как для положительным,
шестая — что для отрицательных чисел правила округления должны быть зеркальным (относительно 0) отражением правил для положительных чисел,
седьмая — что есть специальные числа: +/- бесконечность, nan и т.д.,
восьмая — что нет специальных чисел
и т.д

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

дальше есть три варианта:
1. все эти нюансы специфицируются для каждой минимальной подзадачи => приводит к комбинаторному взрыву, и невозможности строить сложные модели за разумное время
2. нюансы операции "разделить" жестко однозначно фиксируются для всех подмоделей => модель выхолащивается, и становится применимой только для решения узкого круга задач
3. делается допущение, что подмодели являются устойчивыми к данным нюансам (поведение сильно не меняется, если операцию деления брать чуть другую), и что нюансы операции "разделить" можно брать произвольные => приводит к необходимости отслеживания, как нюансы одной подзадачи (в частности, выбор операции деления) влияет на поведение других подзадач.

HH>Увы, на практике это скорее всего означает, что количество вариантов было равно десяти, но протестировать три из них просто не пришло тестеру в голову (т.к. он не знал внутренней логики системы). Зато программист мог бы продумать ВСЕ эти десять возможных вариантов.

ты сейчас берешь, в качестве примера, какие-то вопиющие ошибки, при этом оставляя за бортом вопрос — а что делать с невопиющими ошибками?
или другими словами: все задачи можно упорядочить по кол-ву тестов, которые необходимо сделать для их тестирования: при этом кол-во тестов будет плавно расти от 1 до 10^(10^(10^10)).
что приводит к вопросам:
1. сколько тестов мы себе можем позволить сделать?
2. что делать с задачами, для которых кол-во необходимых тестов превышает то кол-во, которые мы можем позволить себе сделать?
2.1. если кол-во необходимых тестов превышает то кол-во, которые можно сделать, то нужно ли делать хоть какие-то тесты?
2.1.1. все ли тесты одинаково полезные? или какие-то тесты необходимо делать в первую очередь?
2.1.1.1. все ли ошибки одинаково вредны? или какие-то более вредны, чем другие?

Здравствуйте, DarkGray, Вы писали:

DG>при чистом построении моделей узким местом становятся такие инструменты, как: операции, понятия и т.д.

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

DG>возьмем, например, базовую операцию 'разделить':
Дальше поскипано.
Пример с делением не помогает мне понять, что количество вариантов может зависеть от таких мелочей, как реализация деления.
Не очень понятно, почему я не могу пользоваться стандартными функциями округления, которых аж три штуки?
Но если не могу, то мы вспоминаем, что подразумевается под делением в теории групп и делаем соответсвующий интерфейс, и передаем его как аргумент везде где он нужен.

HH>Увы, на практике это скорее всего означает, что количество вариантов было равно десяти, но протестировать три из них просто не пришло тестеру в голову (т.к. он не знал внутренней логики системы). Зато программист мог бы продумать ВСЕ эти десять возможных вариантов.

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

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

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

Здравствуйте, DarkGray, Вы писали:

DG>ты сейчас берешь, в качестве примера, какие-то вопиющие ошибки, при этом оставляя за бортом вопрос — а что делать с невопиющими ошибками?
DG>или другими словами: все задачи можно упорядочить по кол-ву тестов, которые необходимо сделать для их тестирования: при этом кол-во тестов будет плавно расти от 1 до 10^(10^(10^10)).
DG>что приводит к вопросам:
DG> 1. сколько тестов мы себе можем позволить сделать?
DG> 2. что делать с задачами, для которых кол-во необходимых тестов превышает то кол-во, которые мы можем позволить себе сделать?
DG> 2.1. если кол-во необходимых тестов превышает то кол-во, которые можно сделать, то нужно ли делать хоть какие-то тесты?
DG> 2.1.1. все ли тесты одинаково полезные? или какие-то тесты необходимо делать в первую очередь?
DG> 2.1.1.1. все ли ошибки одинаково вредны? или какие-то более вредны, чем другие?

Я вообще не говорил о тестах.
Модели отлавливают ошибки, которые тесты сами по себе никогда не отловят.
Более вредные ошибки — это ошибки в ядре системы, ошибки в архитектуре.
И именно здесь могут быть полезны модели.

HH>Но если не могу, то мы вспоминаем, что подразумевается под делением в теории групп и делаем соответсвующий интерфейс, и передаем его как аргумент везде где он нужен.

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

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

Здравствуйте, DarkGray, Вы писали:

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

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

HH>Я вообще не говорил о тестах.
HH>Модели отлавливают ошибки, которые тесты сами по себе никогда не отловят.

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

Здравствуйте, HrorH, Вы писали:

HH>Не могу проследить логическую цепочку в Вашем ответе.

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

Здравствуйте, DarkGray, Вы писали:

DG>сами по себе модели не отлавливают ошибки. ошибки отлавляют доказательства корректности, которые могут содержаться в модели.
Многие ошибки будут отловлены на этапе продумывания модели, когда еще никаких доказательств нет.

DG>при этом кол-во доказательств коррелирует с кол-вом поведения кода примерно так же, как кол-во тестов.
Мне даже не надо доказывать, что функция f(x) = x не меняет свой аргумент. Но протестировать это я не могу, т.к. количество случаев бесконечно.
Кроме того, для известных математических объектов ничего доказывать не надо, это сделано до нас.
Conal Elliott называет это already payed for.

DG>соответственно, в моих тезисах словосочетание "кол-во тестов" можно заменить на "кол-во доказательств корректности модели" и смысл, и описываемые проблемы останутся теми же самыми.

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

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

Здравствуйте, FR, Вы писали:

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

Не понимаю, каким образом эта теория мешает мне делать модели?
Если есть бесконечное количество каких-то фактов, что мне мешает от них абстрагироваться?
И потом подсчет количества это коварная штука, f(x)=x это один факт, или бесконечность фактов?

FR>Если вернутся к практическому программированию то очень большая часть задач точно также "неприводима" или "немоделируема",
FR>вернее возможно чисто теоретически модель и возможна, но трудозатраты на ее построение и сложность получившийся модели
FR>слишком большие, что делает ее бесполезной, а скорее даже вредной, вместо кода который по сути (с тестами) конструктивное
FR>доказательство на формальном языке, получаем неформальную не проверяемую автоматически мат. модель.

Просто не надо пытаться моделировать все мелкие детали системы, надо сосредоточиться на основном.
Насчет тестов: тесты не отменяют продумывание. А результат продумывания — это как раз то, что я называю моделью.