Особо важным является вопрос точности вычислений. При использовании сопроцессора все стандартные математические операторы и функции языка, возвращающие обычно значения Real, начинают возвращать значения типа Extended. В связи с этим имеет смысл опираться именно на этот тип как базовый. Тем не менее вполне возможно, что в программе будут участвовать переменные разных типов. В таких случаях при необходимости будет производиться преобразование значений, а значит, потеря точности. При вычислении значений правых частей операторов присваивания результат имеет точность, совпадающую с наиболее точным из типов членов выражения (или, что то же самое, с наиболее емким типом). Это означает, что в присваивании
VAR
e1, e2 : Extended;
e3 : Double;
result : Single;
...
result := e1*e2/e3;
- 184 -
значение выражения справа будет вычислено как тип Extended. Но при присваивании его переменной result «малого» типа Single будет произведено усечение, и резко уменьшится число значащих цифр после десятичной точки. Подобные ситуации надо предвидеть и стараться избегать их. Особенно неприятны они в циклах суммирования:
VAR
е : Extended:
Sum : Single;
i : Word;
...
BEGIN
e:=1.23456e-12;
Sum:=0;
for i:=32767 to 65535 do Sum := Sum + i/e;
...
END.
Здесь подобные потери будут повторены тысячи раз, и накопленная ошибка может быть соизмерима с самой суммой. Исправить ситуацию легко: надо ввести дополнительную переменную eSum точного типа Extended для сумматора, и переписать цикл:
eSum:=0;
for i:=32767 to 65535 do eSum := eSum + i/e;
Sum:=eSum;
Теперь потери будут значительно меньше.
По той же причине (из-за усечения точности) некорректной является операция сравнения двух разнотипных вещественных переменных или переменной с выражением (последнее, как уже отмечалось, может быть вычислено в типе Extended). Так, сравнение в примере:
VAR
e : Extended;
d : Double;
...
e := Cos( Pi/8 );
d := e;
{==>} if d=e then ...
при формальной правильности и очевидности даст результат False — ложно, так как d имеет меньше значащих цифр, чем e. Обычно при сравнении вещественных значений проверяют не их совпадение, а степень расхождения. Если эта степень соизмерима с точностью представления наиболее грубого числа, то значения можно считать
- 185 -
равными. Так, условие if в последнем примере следовало бы переписать так:
if Abs(d-e) < 1.0Е-15 then ...
Здесь 1.0Е-15 — точность для типа переменной d (Double).
Продолжим перечень особенностей применения сопроцессора. Его наличие в ПЭВМ и использование сильно влияет на работу функции округления Round: она начинает округлять полуторные значения в сторону ближайшего четного целого числа (это называется «банковским способом»)! Например:
без сопроцессора с сопроцессором
Round(0.5) --> 1 Round(0.5) --> 0
Round(1.5) --> 2 Round(1.5) --> 2
Round(2.5) --> 3 Round(2.5) --> 2
Round(3.5) --> 4 Round(3.5) --> 4
С остальными значениями (без '.5') функция работает нормально.
Некоторые неприятности могут поджидать любителей рекурсивного подхода к написанию функции. Возможны, в принципе, ситуации, когда рекурсивные вызовы переполнят внутренний стек данных сопроцессора, рассчитанный на восемь уровней рекурсии, и возникнет сбой программы. Возможным решением будет разнесение сложнорекурсивных выражений типа Fn:=Fn(N-1)+Fn(N-2) по локальным переменным, например, f1:=Fn(N-1); и f2:=Fn(N-2). После этого выражение Fn:=f1+f2 будет безопасным для сопроцессора.
Завершая тему использования сопроцессора, напомним, что и расширенные вещественные типы, и тип Real при работе с сопроцессором 80X87 выводятся на печать операторами Write и WriteLn с 4 цифрами в показателе степени:
при $N- WriteLn(123.4) выдаст 1.2340000000Е+02,
но при $N+ WriteLn(123.4) выдаст 1.234000000000000Е+0002.
Этот факт надо учитывать при форматированном выводе и при преобразовании чисел в строку процедурой Str.
- 186 -
Системная библиотека Турбо Паскаля содержит набор средств для анализа расположения программ и данных в памяти ПЭВМ. Широко поддерживается работа с адресами данных и кодов. В этой главе дается обзор этих средств и способы их применения.
