А чего непонятного? Число с плавающей точкой состоит из 3-х частей: знак (-1 или +1), мантисса (от 0 до 1) и экспонента (от -128 до +127). Фактическое число получается так: s * m * 2 ^ e. Подробнее в  вики

Не знаю. Я помню, что в fortran'e тогда были float, и double precision, и все равно не хватало, стали вводить huge.
Но с huge слава богу дело так и не пошло, сейчас глянул, там есть extended precision c 16 байтами под число.

Добавлено через 10 минут и 35 секунд


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

Просто прими как данное, что для универсальности в С/C++, да и не только есть много вещей, которые, создавайся язык прямо сейчас, были бы не нужны 15-20 лет назад чуть ли не байты считались, чтобы уменьшить размер исполняемой программы. Поэтому, imho, тогда и была введена разница между int и long, например. Но остались и старые программы кое-где и старый код. Остаётся либо жертвовать обратной совместимостью и универсалностью, либо сейчас думать, зачем нужно такое конкретное разделение между целочисленными int и long, когда на современной технике возможная разница между ними уже ничего не значит. Почти не значит. 

Вот скрин страницы учебника:

Как выше обсуждалось, неявное приведение типов отрабатывается в случает надобности, если того требует ситуация (наличие переменные разного типа в выражении).
Тут то ли перевод нечёткий, то ли автор не так выразился. Решил я переспросить. Там сказано, что:

Но точность переменных типа float 7-8 знаков, а значит 1000.0 и .05 вполне потянет тип float, а значит не разумно производить неявные преобразования и расчёт с данными переменными в таком виде... Я прав?
Ведь 1000.0 - тут порядок мантиссы 1, а у .05 - 2. Как раз float тут самое то, т.к. по скорость расчёта, так и потому, что он поддерживает данную точность. А автор учебника утверждает, что типа нет судя по контексту.

"Структура for"? В смысле "управляющая структура кода" (или "структурный оператор")? Почему не просто "оператор цикла for" - получилось бы два раза рядом стоящих слова "оператор"?



Потянет.



Наверное, он всё-таки хотел иметь в виду другое. Математические функции, определённые в заголовке math.h, практически все работают с double, в том числе и pow. Особого смысла (в данном примере) преобразовывать float-аргумент к double, а затем результат из double во float, нет. Поэтому будем работать с double:
А то, что дальше 

мне видится как копипаст от предыдущего утверждения.


Какие проблемы. Пробуйте с float. Потом сравните результаты с double. Для большого числа лет результат должен заметно отличаться... Для 10 - незначительно...

Как это пробывать? Ведь сказано же тут, что:

Получается, преобразование происходит даже когда нет необходимости.. Я вот заметил, что это не разумно. Потому и спросил.
Ведь если не требуется высокая точность, а расчёт её учитывает, как это иначе понимать?

  На самом деле сопроцессор можно настроить на точность вычислений. Можно сделать так, чтобы он считал даблы с точностью флоатов (библиотеки DirectX так и делают) . Вообще, преобразование операция простая, так что можно не париться.

Напишите свою fnpow  



Необходимость есть, и связана она с типом аргумента функции pow. Вот если была бы библиотечная функция fpow(float,float), тогда другое дело. Но что есть, то есть.

Мне всё же не понятно возмущение по поводу double. Ныне (если не брать в рассмотрение особые случаи) это стандартная единица для представления чисел с плавающей точкой. Современные (со)процессоры работают именно с double (хотя Вам кажется, что с float). То есть даже если вы будете пользоваться float, процессор всё равно преобразует float в double (а то и в long double), и уже потом будет складывать, вычитать, умножать, делить etc. Даже printf не умеет печатать float, минимум double (хотя scanf умеет работать с float).

Получается тут "виновник торжеств" не функция pow, а аргументы... Автор выразился видимо не особо внятно, по крайне мере я так подумал. Теперь понял.
Хотя проще же было сделать по дефолту, чтоб типы данных в аргументах функции pow были пользовательскими. Это же логично..


Получается, опять же float как тип уже не востребован, что и требовалось доказать. Если уж его игнорят современные процы.



Это сообщение отредактировал(а) hoz - 17.7.2013, 14:26

  Это давнее заблуждение. То что регистры двойной точности еще не значит, что вычисления выполняются одинаково быстро. Арифметические плюс минус умножить делить, возможно, да и то деление и умножение наверняка с флоатми заметно быстрее. А если перейти к тригонометрическим функциям, то картина меняется кардинально. Время вычисления тригонометрических функций растет значительно быстрее чем точность. В некоторых компиляторах отсутствуют функции sinf, точнее они реализуются через sin , поэтому там нет разницы float/double, но это нифига не правило. На отдельных алгоритмах с использованием функций типа sin/arctan/sqrt у меня получалась разница в 50 раз и больше. Это небо и земля. 

Машинное эпсилон для IEEE 08 float32: 2^-24 = 5.96e-08 , так что почему нельзя 1.000001eN, где 0.000 0001 = 1*10^-7 я не знаю.    
Для самообразования: http://en.wikipedia.org/wiki/Machine_epsilon

Это сообщение отредактировал(а) Wuffur - 17.7.2013, 14:40

Я написал: "к примеру"  Точное значение лень было искать. За ссылку спасибо)))



Ок)))



Ну почему. Если Вам критично использование памяти и не критична точность с расширенным диапазоном, тогда float является спасением (если, конечно, на Вашей платформе float "в два раза меньше места занимает"))).
Вот и Alexeis говорит, что кое-где весьма бережно относятся к float. И таки дают функции с float'ами.
Ещё выше писали про графику, SSE и т.д.

float используется, и используется активно)))

  У кого есть поновее компилятор под рукой проверьте следующий код


Старичок VS2005 выдал флоаты в 2 раза медленнее даблов, но есть подозрение, что у него нет sinf . С графикой я четко замечал влияние _control87(_MCW_PC, _PC_ХХ); Т.е. несмотря на 64х битность сопроцессора он вполне умеет считать и с пониженной точностью для флоатов.

 Тема разраслась, начались вещи писаться, который уже за гранью темы и моего понимания в частности.

Я выше уже спрашивал про то, как понять:

Например, берём числа:
123245.84,
457235.1,
235,6882347
У каждого из них будет фиксированная точность и изменяющаяся? Я сколько не читаю про это, что-то не въезжаю.

Давайте так. Кроме представления чисел в форме "числа с плавающей точкой" есть представление числа в форме "число с фиксированной точкой". С точки зрения точности представления чисел эти две формы являются противоположными:

Для чисел с фиксированной точкой

• постоянная абсолютная погрешность
• переменная относительная погрешность

Для чисел с плавающей запятой

• переменная абсолютная погрешность
• постоянная относительная погрешность

Поэтому на этих понятиях так акцентируется внимание. Теорию можно познать здесь.


Конкретное число x в машинном представлении (в силу ограниченности возможностей представления различных чисел на ЭВМ) может являться совсем другим числом X (округлённым до ближайшего "машинного" числа). Поэтому возникает погрешность машинного представления: вместо x имеем X. Задача: оценить эту погрешность. 

Погрешность можно оценить в лоб: |x-X| - насколько расхождение абсолютно. Можно более тонко - соизмерять с исходным числом: |x-X|/|x| - это уже относительная погрешность. К примеру: в корпорации "РосМама" счётная палата выявила финансовую отчётность на 99 млрд рублей из 100 млрд финансирования, а в компании "ВасяПупкин" смогли оправдаться за 300 тысяч из 400 тыс бюджета. Вопрос: кто из них больший растратчик?

Так вот с точки зрения относительной погрешности "РосМама" растратила всего 1%:а "ВасяПупкин" - целых 25% своего бюджета:. Следовательно эффективность усвоения бюджетных средств у "РосМама" значительно выше. В тоже время в абсолютных цифрах всё выглядит несколько иначе: 1 млрд рублей vs 100 тысяч.


Вот причём здесь конкретное число? И куда делись основополагающие термины "относительная" и "абсолютная"?


Для любого X в форме числа с плавающей точкой верно:

• постоянная относительная погрешность эпсилон (см. по ссылке Wuffur) (не зависит от X и его порядка)
• переменная абсолютная погрешность (X * эпсилон) - зависит от числа X (и его порядка)

Это сообщение отредактировал(а) feodorv - 18.7.2013, 08:51

Alexeis, так время измерять нельзя!
Оптимизатор там просто вообще выбрасывает холостые циклы, так как результат никуда не используюцца.
У меня ваш код выдавал крайне не стабильные результаты
При добавления накопления и вывода результата, время вычислений возросло на 2 порядка (~100 раз)!!!
(что явно свидетельствует что в вашем коде, оптимизатор просто выбрасывал не нужные вычисления)
И время, после коррекции стало примерно одинаковым (+/-2%).

Кроме того там есть и еще ошибки.

Если не ошибаюсь, вы здесь перепутали местами маску и значение.
То есть нужно писать наоборот:

проверьте здесь