Как поднять точность вычислений

Centuriones, 02.01.2004 22:01:29:

Может быть в трехтомнике "Искусстве программирования" что-нибудь есть? Сам я эту книгу не читал.

 

10 баллов!

Mishka, 02.01.2004 22:45:57:

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

 

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

А точность - это "проблемма" цифровой вычислительный техники в целом. Поэтому при решении задачи надо сделать анализ на допустимую точность вычислиений.

2 Centuriones:
не знаю насчёт остальных модификаций 390-ых (а их десятка три), но на 390/91 плавающая арифметика реализована аппаратно, поскольку именно на этой модификации был реализован динамический конвейер Томасуло в FPU.

Извиняюсь, я конечно имел ввиду 360/91.

Тот пример со сложением я привел только для демонстрации. В общем, постепенно прихожу к выводу что в определенных случаях точность выгоднее понижать, чем увеличивать - была бы сходимость к правильному решению.
Задача в принципе достаточно простая и связана с термообработкой стали - определение прокаливаемости в сечениях на реальных образцах. Для этого на каждом шаге рассчитывается температурное поле конечно-разностным методом, который для оценочных расчетов а также для студенческих задач вполне подходит. Также важно знать и среднемассовую температуру для определения времени охлаждения до температуры самоотпуска и для определения времени охлаждения до температуры среды. В последних случаях происходит полнейший бред при из-за особенностей реализации плавающей арифметики в процессорах intel. Возникает парадокс типа "Ахилл никогда не догонит черепаху" - решение начинает бесконечно приближаться к температуре среды. Самое интересное, что эта проблема возникла только тогда, когда я стал использовать ЭВМ с аппаратной реализацией плавающей арифметики. На ЭВМ с микропрограммной реализацией плавающей арифметики подобных проблем никогда не возникало.
Можно конечно использовать существующие коммерческие пакеты конечно-элементного анализа, но из доступных пакетов, имеющих "студенческие" бесплатные версии у меня есть только два - это Elcat российского производства и знаменитый ANSYS. К сожалению первый больше рассчитан на решение статических задач и не очень хорошо работает при низких градиентах расчетных величин, второй же слишком монстрообразен. В МГТУ его применяют для лабораторных работ но мне кажется что студент не в особом восторге. Без бутылки с его интерфейсом просто так не разберешься. Так что приходится "изобретать велосипед".

Centuriones, извините за возможно ламерский вопросик, но разве остывание/нагревания тела до температуры окружающей среды не происходит по бесконечно-асимптотичному закону? Я это к тому что при конечно-разностном решении (Ейлера, Рунга-Кутта) прирост (градиент) может быть настолько мал по мере приближения к асимптоте что его прибавление к аккумулятору не будет уже вызывать его изменения. Не это ли у вас происходит? Я просто хочу примерно понять вашу проблему.

Единственная разница между программной и аппаратной реализацией плавающей арифметики, с которой мне приходилось сталкиваться, заключалась в работе с младшим разрядом. Аппаратные сопроцессоры обычно просто обрезают его при операциях. А программные, бывает, округляют, что прибавляет полразряда точности. Было это, кстати, с Паскалевским 6-байтовым Real.

P.S. А всеми любимое 0.1 десятичное - вообще плохое число для двоичных машин. Оно у них записывается бесконечной дробью.

Аппаратные сопроцессоры обычно просто обрезают его при операциях.

 

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

Rada от 04.01.2004 23:48:02:

Centuriones, извините за возможно ламерский вопросик, но разве остывание/нагревания тела до температуры окружающей среды не происходит по бесконечно-асимптотичному закону? Я это к тому что при конечно-разностном решении (Ейлера, Рунга-Кутта) прирост (градиент) может быть настолько мал по мере приближения к асимптоте что его прибавление к аккумулятору не будет уже вызывать его изменения. Не это ли у вас происходит? Я просто хочу примерно понять вашу проблему.

 

Сам процесс объективно конечен, все дело в моделях и их реализации как программной, так и в компьютере. Раньше я не задавался этим вопросом, поскольку на старушке ИСКРА-1256 все было прекрасно (особенность этой машины - задаваемая разрядность вычислений от 4 до 12, по умолчанию - 8 значащих цифр, реализация плавающей арифметики микропрограммная). С учетом допущений результаты для одномерных схем прекрасно совпадали с реальностью. Так расчетное время охлаждения до заданной среднемассовой температуры для цилиндрических образцов совпадало с реальным с точностью до 0,5 - 0,2 с. Мы в то время занимались корректировкой времени охлаждения для толстолистовых рессор для КАМАЗа, а на заводе в эксперименты не поиграешь. После этого немного поиграв с коэффициентами чтобы получить более точное соответствие теории и эксперимента добились совпадения расчетных и экспериментальных данных с точностью до 0,1 с. Далее расчет для пластин, быстрая проверка расчетных данных в лаборатории и в командировку на завод. В конечном итоге попали "в яблочко" и уже первые серийные рессоры имели на выходе нужную температуру. В дальнейшем уже пользовались только результатами расчетов и не только для рессор, но и для подшипниковых колец и др. Все расчеты проводились с задаваемой точностью по умолчанию. Но далее появились ДВК-3 (LSI-11) и пошло-поехало. Достоверность результатов расчета в областях с низкими температурными градиентами резко снизилась, хотя возможность расчета охлаждения до температуры среды оставалась. При переносе алгоритма на РС пропала и она. И ведь это простейшая задача! Доцент с другой кафедры написал реализацию решения на Excel и был кране удивлен, когда начал получать подобные результаты. Аналогичные фокусы я заметил у программы Elcat - коммерческая программа российского производства для расчета двумерных моделей методом конечных элементов (www.tor.ru/elcut/index.htm). ANSYS ( http://www.adams.ru/ или ) "на вшивость" я еще не проверял. Тут, надеюсь, все в порядке, но слишком уж "тяжелая" программа.

Вот, кстати, сегодня написал. Красивый пример повышения точности. На целочисленной аритметике.

void COscCtrl[color=#808030; ]:[/color][color=#808030; ]:[/color]DrawSamples[color=#808030; ]([/color][color=#808030; ])[/color] [color=#808030; ]{[/color]     Clear[color=#808030; ]([/color][color=#808030; ])[/color][color=#808030; ];[/color]     if [color=#808030; ]([/color][color=#808030; ]([/color]m[color=#808030; ]_[/color]nBuffSize [color=#808030; ]

Но арифметика-то нужна плаваящая!

Centuriones, 08.01.2004 01:11:39:

Но арифметика-то нужна плаваящая!

 

ПОЧЕМУ?

Resurrector, 08.01.2004 13:10:12:

Centuriones, 08.01.2004 01:11:39 :

Но арифметика-то нужна плаваящая!

 

ПОЧЕМУ?

 

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

Алгоритм Брезенхэма для рисования окружности знаешь? Очень быстрый. Только вот, если его обобщать для эллипса, то целых чисел просто начинает не хватать (разрядности).

Mishka, 08.01.2004 18:16:24 :

Алгоритм Брезенхэма для рисования окружности знаешь? Очень быстрый. Только вот, если его обобщать для эллипса, то целых чисел просто начинает не хватать (разрядности).

 

Ну, у нас он аппаратно в ПЛИС реализован. Целочисленно, естественно. Рисует вроде без ошибок, и не такая-то там и большая разрядность.

Alesandro, 08.01.2004 18:21:02:

Mishka, 08.01.2004 18:16:24 :

Алгоритм Брезенхэма для рисования окружности знаешь? Очень быстрый. Только вот, если его обобщать для эллипса, то целых чисел просто начинает не хватать (разрядности).

 

Ну, у нас он аппаратно в ПЛИС реализован. Целочисленно, естественно. Рисует вроде без ошибок, и не такая-то там и большая разрядность.

 

Элипсы? И соотношение осей какое?

Да в общем любое соотношение полуосей. От 4 до 1024 точек каждая.

Alesandro, 09.01.2004 13:32:45:

Да в общем любое соотношение полуосей. От 4 до 1024 точек каждая.

 

А, понял, вы ограничились экраном, а не произвольные элипсы рисуете. Мы пробовали заэкранные траектории считать, а экран, как лупу двигать. Там проблемы и возникают.

Centuriones, 02.01.2004 18:01:29:

Может быть в трехтомнике "Искусстве программирования" что-нибудь есть? Сам я эту книгу не читал.

 

Только что просмотрел вышеназванный 3-х томник. У меня и старое советское издание, и современное (третье) российское и третье американское - так в 3-м издании, 2 том, глава 4 - дает неплохие начала анализа ошибок и кучу ссылок на литературу. Там и советы есть. Но автор честно предупреждает, что полная теория лежит за рамками книги.

Я так и предполагал, что там что-то есть. Осталось теперь только этот трехтомник купить. Беда только в том, что свободных ста баксов нет.

Centuriones, 10.01.2004 13:04:41:

Я так и предполагал, что там что-то есть. Осталось теперь только этот трехтомник купить. Беда только в том, что свободных ста баксов нет.

 

У-р-р-р.... а чего так дорого? у нас все три тома - 50 у. е. были...
Кормана я за 500 р. покупал

В Москве в основном тираж раскуплен. Когда этот трехтомник только вышел, то в книжных мангазинах стоил порядка 50 у.ё. На рынках он уже тогда стоил под 100 зелени.

Mishka, 08.01.2004 17:16:24:

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

Алгоритм Брезенхэма для рисования окружности знаешь? Очень быстрый. Только вот, если его обобщать для эллипса, то целых чисел просто начинает не хватать (разрядности).

 

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

Resurrector, 19.01.2004 13:01:30:

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

 

Угу. А C++ придумали, чтобы продавать средства программирования людям, которые ничего в машинных кодах не смыслят

Да ну. Язык Си тем и хорош - он очень близок к чисто машинной логике.

Resurrector, 19.01.2004 13:27:05:

Да ну. Язык Си тем и хорош - он очень близок к чисто машинной логике.

 

Тогда C#

Жалко, что практически все функциональные языки бесплатны, а то бы я какой-нибудь Haskell привёл