Какая чушь :)

← →
homm © (2007-12-21 23:25) [0]

http://www.yandex.ru/yandsearch?clid=9582&text=IEEE754
Первая ссылка.

Особенно понравилось:
В настоящее время используются приборы точности не выше класса 0.1%. Это соответствует 4-5 десятичным разрядам. Потому большая часть мантисс IEEE754-чисел, особенно в форматах двойной и расширенной точности, несодержательна, фактически, есть информационный шум. Отсюда следует, что современный IEEE754-процессинг есть процессинг, обработка преимущественно шумов.
Какая чушь…

← →
antonn © (2007-12-21 23:39) [1]

издержки "раскрутки", много всякого текста занимают верхние строки поиска хотя могут содержать всякую чушь :(

← →
Ins © (2007-12-22 00:43) [2]

> Какая чушь…

Ну не совсем чушь. У нас предприятие разрабатывает приборы для аналитической химии - pH-метры, иономеры и т.д. Приборы как раз имеют точность 4-5 десятичных разрядов, но по RS-232 передают все 10-15. Допустим, pH-метр измерил pH раствора, и у него получилось 6,73230484312. Но при точности плюс-минус 0,5%, скажем, уже после второго знака после запятой цифры не несут никакой информационной ценности, так как они лежат в пределах допускаемой погрешности. Их можно смело отбрасывать. Да, фактически - это информационный шум.

Так что для измерительной техники - это обычное явление.

← →
homm © (2007-12-22 07:14) [3]

> [2] Ins © (22.12.07 00:43)
> уже после второго знака после запятой цифры не несут никакой
> информационной ценности

Но и не делают обработку шумов преимущественной. Шум занимает младшие разряды.

> Их можно смело отбрасывать.

И таким отбрасыванием избавится от шумов? Это только с точки зрения интуиции так. Если включить здравый смысл, станет ясно что избавившись от цифр после запятой, мы избавимся от цифр после запятой, и просто дадим шумам другое значение. Пример:
Прибор с точностью 0,3% показал значение 22,21561. Это значит что цифры после второго знака после запятой можно отбросить: 22,2. Предположим, что реальное значение измеряемого параметра 22,2321. В первом случае шум был 0,01649, а необосновано отбросив младшие разряды мы увеличили его до 0,0321.

← →
J_f_S (2007-12-22 07:46) [4]

> homm © (22.12.07 07:14) [3]

Статистику в ВУЗе прогуливали?

← →
vrem_ (2007-12-22 09:11) [5]

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

← →
Ins © (2007-12-22 10:59) [6]

> И таким отбрасыванием избавится от шумов? Это только с точки
> зрения интуиции так. Если включить здравый смысл, станет
> ясно...

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

← →
homm © (2007-12-22 11:26) [7]

> [6] Ins © (22.12.07 10:59)
> большинство времени при расчетах с плавающей точкой занимает
> обработка бесполезных бит

Совершенно необоснованное утверждение.
procedure TForm1.Button1Click(Sender: TObject); var i, T: DWORD; s, r : XXX; begin T := getTickCount(); S := 0; for i := 0 to 99999999 do begin r := i; s := s + r; end; ShowMessage(inttostr(GetTickCount-T)); end;
вместо XXX:
Single — 2172
Double — 2187

Выбирайте тип под задачу. Почему то никто не возмущается что под Boolean нужна только 1/8 реально занимаемого им размера.

← →
Ins © (2007-12-22 11:39) [8]

> homm © (22.12.07 11:26) [7]

Я не совсем понял, что ты этим примером хотел показать? Можно мне убогому объяснить популярно?

← →
homm © (2007-12-22 11:52) [9]

> [8] Ins © (22.12.07 11:39)

Твое утверждение:
> большинство времени при расчетах с плавающей точкой занимает
> обработка бесполезных бит

Я увеличил количество «бесполезных» бит на много, и это НЕ заняло больше времени обрабоки. Отсюда прямым текстом следует, что «обработка бесполезных бит» НЕ «занимает большинство времени при расчетах с плавающей точкой». Т.е. доказывать целесообразность уменьшения мантисы, мотивируя это затратой рессурсов на вычисление, бездокозательно. Мотивируя занимаемой памятью — тоже не хоршо, просто потому что так есть, что минимальный размер плавающего числа равен 32 бита. Точно так же как есть то, что минимальный размер целово числа 8 бит.

← →
homm © (2007-12-22 11:56) [10]

> [4] J_f_S (22.12.07 07:46)

Неужели по статистике, изменяя значение, просто неоткуда решив, что нужно именно отбросить именни такую-то часть числа, мы приближаем значение к верному?

← →
Ins © (2007-12-22 12:09) [11]

> Я увеличил количество «бесполезных» бит на много, и это
> НЕ заняло больше времени обрабоки.

Да нет, ты видимо просто не знал, что все операции с плавающей точкой осуществляются в формате Extended. При загрузке числа типа Single или Double в регистр процессора он конвертируется в этот формат, затем происходят вычисления (с огромным числом бесполезных бит), а потом - результат обрезается до нужной точности. Именно поэтому результат примерно одинаковый по времени - работа идет с одним и тем же форматом Extended. :)

PS: Антон хорошие статьи пишет, рекомендую:
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=374

Удачи! :)

> [11] Ins © (22.12.07 12:09)
> Да нет, ты видимо просто не знал, что все операции с плавающей
> точкой осуществляются в формате Extended.

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

← →
vrem_ (2007-12-22 12:34) [13]

homm © (22.12.07 11:26) [7]
на ассемблере написаны примеры как умножение реализовано, деление - то есть mul, div. И там оптимизация всюду, если биты не используются, то они нулевые, в оптимизации это используется.

по теме ветки - лучше бы не отбрасывали не нужные биты, а заменяли их на не мешающие и одновременно нужные для оптимизации :)

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

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

> А запас точности пригождается при многократных операциях,
> которые, как известно, точности не прибавляют.

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

> Ins (22.12.2007 12:42:14) [14]

Что ты сексуально озабочен, а про секс ничего не знаешь.

> ...а про секс ничего не знаешь.

Про секс не знать надо, сексом надо заниматься ;-)

Какая чушь :) Найти похожие ветки