В первом случае 1. - число типа double (1.f - число типа float), во втором - (double)1 - целое, приводимое к типу double. Во втором случае приведение производится на этапе компиляции, так что записи эквивлентны.
((double)1/3) и (1/(double)3) - тоже эквиваленты ((double)1/(double)3), так как приведение одного операнда к double заставляет компилятора приводить к double другой операнд. Деление будет тоже призводиться на этапе компиляции - так, что писать лучше (1./3) чем 0,333333333333
В случае ((double)i/3); приведение типа и деление будут выполняться на этапе выполнения; 3 будет заменена на 3, на этапе компиляции.


Вычисление призводится с плавающей точкой, а не фиксированной. члены ряда не будут равны 0 очень долго, но будучи прибавлены к накопленной сумме (большей 1), будут сначала терять младшие разряды точности, а затем вовсе не изменять сумму.
Точнее свего алгоритм суммурования такой:
1. слагаемые записываются в вектор
2. вектор сортируется по убыванию абсолютной величины.
3. если в векторе не меньше 2 чисел, два последних складываются и заменяются на сумму ; переход к пункту 2;
Можешь попробовать на тесте (сложение без сортировки float; сложение c сортировкой float; сложение без сортировки double; сложение c сортировкой double) и сравнить результаты. Правда, сортировка будет происходить неоправданно долго.



В том то и дело, что не равноудалены. Поэтому практичнее считать СКО.
(1+-0.1) * (2+-0.1) = (0.9 .. 1.1) * (1.9 .. 2.1) = (1.71 .. 2.31) - середина 2.01, а не 2

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

Дело в том, что где-то мне попадалась на глаза фраза, что если тип приведения не указан явно, то компилятор может преобразовать такое число и к double и к float. Так что лучше наверное указывать тип явно, тем более, что преобразование состоится на этапе компиляции, а значит выполнение будет производиться быстрее.

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



Разве приведение будет на этапе выполнения?

Это сообщение отредактировал(а) FCM - 3.9.2012, 10:39

Немного оффтопный вопрос. Я раньше работал с float и не было проблем перевода float в строку и обратно (FloatToStr и StrToFloat). А что с double? Готовых функций нет? Надо самому писать, либо чьей-то самоделкой воспользоваться?

Добавлено через 7 минут и 51 секунду
Похоже FloatToStrF работает со значением long double. А строка в double похоже конвертируется функцией ToDouble.

Почему? Ведь при высилении погрешности оперируем крайне малыми числами, близкими к машинному епсилон. Очень вероятно, что относительная погрешность таких операций будет велика.

Погрешность хранится отдельно от числа, в виде с плавающей точкой - достаточно точно.
После прибавления к основному числу точность, да теряется.
Но ведь сравниваются же два числа так:

или если храним квадрат СКО, при нормальном распределении, с допуском 3 СКО:

Главное место где теряется точность - вычисление delta.
Нужно также следить, чтобы при вычислении квадрата не было переполнения и антипереполнения.