Евангелие от матана
В продолжение дискуссии отсюда.
Я знаю силу слов, я знаю слов набат. Убеждение, что слова имеют особую, мистическую силу - это, пожалуй, один из основных сохранившихся по сие время пережитков первобытной эпохи. Убеждение, что суть того или иного явления кардинально изменится, назови мы только его другим именем, нередко наличествует даже у людей, ( Read more... )
Я знаю силу слов, я знаю слов набат. Убеждение, что слова имеют особую, мистическую силу - это, пожалуй, один из основных сохранившихся по сие время пережитков первобытной эпохи. Убеждение, что суть того или иного явления кардинально изменится, назови мы только его другим именем, нередко наличествует даже у людей, ( Read more... )
Пока только этот момент прокомментирую, так как он моего примера касается:
>3. Они лучше тем, что экономят общественное рабочее время,
>затрачиваемое по милости "классических" преподавателей математики
>на отлов тупых ошибок, вроде упомянутых в одном из постов Алексея Ремизова.
Это совершенно неверно!
Именно тот реальный пример, который я привел, говорит прямо об обратном.
1. Отмечу прежде всего, что пример Гастрита (та программа на C, которую он написал) -- это пример чисто "математический", на практике такое не бывает, если только нарочно не создавать. Не знаю, кого как учили, но мне вот на 1-ом курсе на одном из первых занятий по ЭМВ В.В.Борисенко объяснил, что неустойчивые условия (типа равенств объектов double) проверять не следует. Вот и все! - замените одну строчку в программе, и какая экономия "общественного рабочего времени" выйдет! Так что свою пайку я давно отработал :)
2. Теперь о моем примере. Итак, считалась сумма слагаемых a_i / b_i, и числитель, и знаменатель имеют погрешность - как связанную с вычислительной ошибкой, так и с физической. О физической стороне дела: числа a_i, b_i получаются в результате обработки изображения с видеокамеры, которая снимает выращивание монокристалла кремния из жидкого расплава. Кристалл и расплав вращаются, вибрируют (иногда сильно, если пролетарий дядя Вася верхний шток криво завинтил), расплав "бликует" - на нем появляются яркие пятна, край кристалла неровный -- из-за граней кристаллизации и других причина и т.д. и т.п. Таким образом, числа a_i / b_i известы с ошибкой, слагающейся из как минимум двух частей: компьютерная (то, о чем говорит Гастрит) и физическая (о чем он не говорит). А теперь внимание: как вы думаете, дорогие мои радиослушатели, каков порядок этих ошибок? Компьютерная, допустим, порядка 10^(-7), а физическая имеет порядок 10^(-3) -- 10^(-4). И какой вывод отсюда? Поможет ли нам здесь КМ и правильное понимание числе вместо проклятых double? Ни фига она нам не поможет: ну, убьем мы компьютерную ошибку, так по сравнению с физической -- это пшик. А физическая никак не убивается, кроме как откидывать из суммирования заведомо порочные члены, то бишь те, у которых знаменатели малые, ибо при нормальных знаменателях вклад физической погрешности мал и не влияет.
Так что тут не "отлов тупых ошибок" нужен, а просто понять физику процесса. Никаких преимущество КМ по сравнению с обычной здесь не дает. И подозреваю, что нигде в реальном промышленном программировании тоже не дает. Именно из-за этого "подозреваю" я и просил Гастрита привести практические примеры. Но добился лишь вполне академического примера, который на вопрос мой не отвечает никак.
Reply
Снимите с глаз шоры: числа с плавающей запятой - это числа с плавающей запятой, совершенно самостоятельные объекты с абсолютно чёткими свойствами, а отнюдь не "приближённые издания" вещественных чисел "классического матана". Последних вообще не существует - "приближать", таким образом, нечего!
2. Что ж, давайте разбираться в физике процесса. А она такова: при правильно проведённом измерении у нас не бывает никаких физических ошибок. Потому что результатом правильно проведённого измерения являются два рациональных числа: верхняя и нижняя границы отношения измеренного значения к эталонному (говорить об одном "точном" значении, как это зачастую, увы, делают - сверхглупистика: ни эталон, ни измеряемый объект не идеальны; они изменяются даже в процессе собственно измерения!). Вариантом является пара из середины интервала и половины его ширины (но всё равно это два числа). Если мы про сей нюансик забыли и одно из чисел выкинули (без анализа допустимости такого выкидывания) - мы суть лохи безграмотные. И неча на погрешность пенять, коли мозги кривы. Читать пособия по интервальной арифметике, много думать. Для начала сгодится ориентированное на старшеклассников пособие Брадиса из первого тома "Энциклопедии элементарной математики" (это, разумеется, не Вам персонально - это общее замечание про "программеров" разбираемого пошиба). Это во-первых.
Во-вторых, "компьютерная погрешность" - это тоже фигня, её не бывает. Бывает переход от рациональных чисел к числам с плавающей запятой, каковые суть объекты различной природы. Если мы об этом забыли и не проанализировали условия допустимости такого перехода - мы опять же лохи безграмотные, и нечего кивать в сторону мифической "компьютерной погрешности".
В-третьих, программа должна решать поставленную задачу, и решать её абсолютно точно. Если требуется насчитать середину отрезка длины 10^-2, дающего интервальное значение некоего параметра - то длина этого отрезка должна быть именно 10^-2, а не 10^10. Как именно программист этого добьётся - его персональное дело, но добиться этого он обязан. Ссылаться в случае провала на "компьютерную" или "физическую" погрешность (а равно на магнитные бури: привет Билли Гейтсу) - это свидетельство профнепригодности.
3. А теперь некоторые итоги. Если бы время, потраченное на "доказательства" никчемных теорем Вейерштрасса, было бы использовано на изложение элементарных (и имеющих, в отличие от вейерштрассовского словоблудия, самое непосредственное прикладное значение) фактов вроде указанных выше, пользы было бы по-любому больше. Ибо меньше было бы распространено бредовое мнение о "приблизительности" происходящего в ЭВМ и связанное с этим убеждение, что программы можно писать только на авось. А тогда и описанные Вами "промышленные" ситуации (когда в настроченной на авось программе "вдруг откуда ни возьмись" выплыли глюки) встречались бы реже.
С уважением,
Гастрит
Reply
1. Ох... слово "неустойчивость" имеет до фига разных значений, даже больше, чем верхняя грань. В одних только диффурах есть как минимум три разных "неустойчивости": асимптотическая, ляпуновская и по Бендиксону. В данном конкретном случае под словосочетанием "неустойчивые условия" (посмотрите и проверьте, что там именно это словосочетание написано, а не "неустойчивость работы программы" или еще что-то) я понимаю проверку условия вида X=Y для данных типа double. Это условие взято из Вашего же (весьма искусственного, кстати говоря) примера, где X,Y -- постоянные. Если бы Ваша задача была из практики (не из практики шаманов али еще чего подобного, а действительно из какой-то промышленной ситуации), то проверка условия X=Y для данных типа double, где X,Y являются результатами некоторых технических процедур и содержат в себе влияние побочных факторов, измерить которое или получить хоть сколько-нибудь приемлемые оценки которого (об это еще будет ниже) невозможно, то проверка условия вида X=Y для данных типа double привела к еще большим сюрпризам. Правильно, правильно - это не Ваши проблемы, так как тип double - это не Ваш путь. Но объясняю повторно, что эти траблы снимаются в рамках стандартного программирования простым трюком: заменой условия X=Y условием |X-Y| < \epsilon. И все работает, и программе плевать, что Вы о ней думаете - она уже больше года работает вполне УСТОЙЧИВО (здесь - в том смысле, что Вы предполагали выше), не считая, разумеется, случаев, когда электичество вырубят или изображение пропадает. Это ли не Ваша практика -- критерий чего-там-говорится?
2. Это все очень правильно, но именно это и есть ТЕОРИЯ. И в журнале "Интервальные вычисления" так и нужно писать. А вот в данной реальной ситуации Вы не сможете получить чего-то вроде: "пары из середины интервала и половины его ширины", ежели тольно в качестве "половины его ширины" не взять 1 метр, или размер города Зеленограда, или радиус Земного шара. И поэтому Ваша программа не реализуема никак.
3. Оставлю все написанное на Вашей совести, но в качестве коды укажу, что, согласно Вашей же идеологии, я мог бы не писать пп. 1 и 2 -- достаточно было бы сослаться на год работающую программу и на практику -- критерий истины. Повторяю, что реально я закончил с ней работать больше года назад, в конце 2005, и с тех пор никто никаких глюков там не видал. И проверку она прошла очень простую: в течение выращивания кристалла она постоянно вычисляет его диаметр (через кадр видеокамеры, которая смотрит в окошко -- сунуть внуть нельзя ничего: закрыто герметично, внутри раскаленный аргон, температура около 1400 C), и вычисленные значения вполне хорошо (с точностью 1-2 мм) согласуются с измерение выращенного и остывшего кристалла, проведенным с помощью штанген-циркуля. Что Вас в этом не устраивает, акромя высокой теории и моей вопиющей безграмотности?
Reply
1. Для начала - откуда Вы вычитали, что "double - не мой путь"? В одном из предыдущих постов я ясно, кажется, высказал прямо обратное! Повторяю, тут Вы ломитесь в открытые ворота.
Что же касается "технических процедур" - да не в плавающей запятой тут дело! Если бы вместо double Вы использовали структуры вроде
struct racionalnoe_chislo {
long long int chislitel;
long long unsigned znamenatel;
};
то и для них проверка равенства с "технической" точки зрения была бы глупостью (хотя никакой плавающей запятой тут и рядом нет)! Причины я подробнейшим образом изложил в том самом посте, на который Вы отвечали - резонно напрашивается вопрос: а сколь внимательно читали Вы этот пост?
Так называемый "трюк" с \varepsilon - это на деле никакой не трюк. Это - адекватная реакция на суть дела, изложенную мной в предыдущем посте. Сие \varepsilon представляет собой пресловутую "ширину" и обязано появляться при обработке результатов измерений даже тогда, когда никакой плавающей запятой и в помине нет. Однако основной вопрос (откуда это \varepsilon брать) - Вы упорно замечать не хотите :(
2. "Ширина" результата обусловлена "шириной" начальных данных. И должна определяться (средствами теории) ещё до написания программы. Всё остальное - не относящееся к делу словоблудие, которым "кулхацкеры" маскируют свою некомпетентность.
3. Критерием истинности чего является, по-Вашему, практика в моей идеологии? Не задумывались? Так вот Вам ответ: практика является критерием истинности теории. Поэтому ссылаться на цитированную Вами максиму Вы имели бы право лишь в том случае, если бы эта самая теория у Вас была. А её у Вас нет: имеется лишь найденный "методом научного тыка" результат, который непонятно почему*, но "год как работает". Не к чему критерий прилагать - вот что меня не устраивает!
С уважением,
Гастрит
---
*Вспомнился, кстати, имевший место в одном из КРОМШ'ей разговор с одним весьма небезызвестным Вам профессором мехмата, каковой в ходе этого разговора старательно акцентировал внимание собравшейся публики на аристотелевском (кажется) положении, что назначение доказательства - понять причины явления. Очень, кстати, верная мысль - и как раз к Вашему случаю!
Reply
Я уже это ему писал (он, сколь я помню, не ответил вовсе): или это вообще не теория и не наука, а производственная инструкция, своя для каждого случая, или это всё равно будет абстракцией уровня "потенциальной бесконечности". А спорить бесполезно - как спорить, если он непременно желает одно и тоже называть только своими словами. Он же знает силу слов, он знает слов набат.
Reply
Leave a comment