Функция pow () int C ++

Question

Функция pow () int C ++

0

У меня проблема, когда я пытаюсь умножить целое число 3 pow (67, 1). Он возвращает 200 вместо 201. Вот мой код в C:

int x = 3;
x = x * pow(67, 1);
printf("%d\n", x);

→ 200

Может ли кто-нибудь объяснить мне. Благодарю!

I Love Coding 26 май 2014, в 05:45

Источник

0

Это 201, когда я компилировал локально.
coder hacker 26 май 2014, в 02:49
1

201 здесь также (VS2013). Какой компилятор / система?
Inisheer 26 май 2014, в 02:49
0

Я получаю 201 компиляции с GCC 4.7
shuttle87 26 май 2014, в 02:50
0

Просто предположение. Вы случайно используете Turbo C ++?
Yu Hao 26 май 2014, в 02:50
0

Единственное объяснение, которое я могу придумать, состоит в том, что 67 при передаче в pow теряет некоторую точность в представлении с плавающей запятой и в итоге получается чуть меньше 67 .
R Sahu 26 май 2014, в 02:51
0

@RSahu Я тоже так думал ... но для этого нужен какой-то странный компилятор.
Inisheer 26 май 2014, в 02:52
0

@RSahu Но это не так. Предположение, что pow () возвращает 66.9999999, имело бы больше смысла, но это также трудно поверить.
user207421 26 май 2014, в 02:53
2

@OP Почему вы вычисляете 67 в степени 1?
user207421 26 май 2014, в 02:55
0

@YHHao Я скомпилировал с Turbo C ++. Не проблема.
Rikayan Bandyopadhyay 26 май 2014, в 03:04
0

«больше нельзя воспроизвести или просто опечатка» - учитывая, что проблема заключается в приближении с плавающей запятой и не будет воспроизводимо согласовываться на разных платформах, несколько человек, попробовавших это и пришедших к выводу, что это не воспроизводимо, не требуют закрытия вопроса.
Tony Delroy 26 май 2014, в 08:35
0

@TonyD, правда, что деталей недостаточно. Какой компилятор, какая платформа? Единственный способ решить эту проблему - надеяться, что это не опечатка, и попробовать когда-нибудь компилятор / платформу под солнцем.
Paul Draper 26 май 2014, в 20:46
0

@PaulDraper: не правда ... это не вопрос воспроизведения или "решения", это вопрос наличия опыта и понимания, чтобы объяснить, почему существует этот класс проблем и - необязательно - каковы обычные подходы к решению этой проблемы (например, значения epsilon, nextafter , округление перед использованием и т. д.). Используя вашу логику, мы не сможем задавать вопросы, ответ на которые будет «X - неопределенное поведение», если мы не сможем воспроизвести тот же UB ...! ;-)
Tony Delroy 27 май 2014, в 01:58
0

@TonyD, вы делаете некоторые хорошие замечания о других проблемах, которые могут быть решены с помощью логики и опыта, но я бы сказал, что этот вопрос не является одним из них. В любом случае, это не может быть «простой опечаткой», но ей определенно не хватает информации, подходящей для решения этой проблемы, что является другой близкой причиной, но все же близкой причиной.
Paul Draper 27 май 2014, в 02:11
0

@PaulDraper: так, вы говорите, что ответы Флориса и Альфа бесполезны или не имеют отношения к этому вопросу? С моей точки зрения, этого вопроса было достаточно, чтобы дать достоверный ответ. Я не понимаю вашу позицию ....
Tony Delroy 27 май 2014, в 02:13
0

@TonyD, их ответы могут быть полезны, хотя никто не может сказать (даже они). Моя позиция заключается в том, что вопрос низкого качества (и должен быть закрыт), потому что ОП не предоставил достаточной информации.
Paul Draper 27 май 2014, в 02:16
0

Еще один вопрос для ОП ... вы #include <math.h> ? Ваш компилятор генерировал какие-либо предупреждения?
Floris 28 май 2014, в 13:20

Показать ещё 14 комментариев

Теги:

c++

c

types

2 ответа

Ещё вопросы

Это 201, когда я компилировал локально.
201 здесь также (VS2013). Какой компилятор / система?
Просто предположение. Вы случайно используете Turbo C ++?
Единственное объяснение, которое я могу придумать, состоит в том, что 67 при передаче в pow теряет некоторую точность в представлении с плавающей запятой и в итоге получается чуть меньше 67 .
@RSahu Я тоже так думал ... но для этого нужен какой-то странный компилятор.
@RSahu Но это не так. Предположение, что pow () возвращает 66.9999999, имело бы больше смысла, но это также трудно поверить.
@OP Почему вы вычисляете 67 в степени 1?
@YHHao Я скомпилировал с Turbo C ++. Не проблема.
«больше нельзя воспроизвести или просто опечатка» - учитывая, что проблема заключается в приближении с плавающей запятой и не будет воспроизводимо согласовываться на разных платформах, несколько человек, попробовавших это и пришедших к выводу, что это не воспроизводимо, не требуют закрытия вопроса.
@TonyD, правда, что деталей недостаточно. Какой компилятор, какая платформа? Единственный способ решить эту проблему - надеяться, что это не опечатка, и попробовать когда-нибудь компилятор / платформу под солнцем.
@PaulDraper: не правда ... это не вопрос воспроизведения или "решения", это вопрос наличия опыта и понимания, чтобы объяснить, почему существует этот класс проблем и - необязательно - каковы обычные подходы к решению этой проблемы (например, значения epsilon, nextafter , округление перед использованием и т. д.). Используя вашу логику, мы не сможем задавать вопросы, ответ на которые будет «X - неопределенное поведение», если мы не сможем воспроизвести тот же UB ...! ;-)
@TonyD, вы делаете некоторые хорошие замечания о других проблемах, которые могут быть решены с помощью логики и опыта, но я бы сказал, что этот вопрос не является одним из них. В любом случае, это не может быть «простой опечаткой», но ей определенно не хватает информации, подходящей для решения этой проблемы, что является другой близкой причиной, но все же близкой причиной.
@PaulDraper: так, вы говорите, что ответы Флориса и Альфа бесполезны или не имеют отношения к этому вопросу? С моей точки зрения, этого вопроса было достаточно, чтобы дать достоверный ответ. Я не понимаю вашу позицию ....
@TonyD, их ответы могут быть полезны, хотя никто не может сказать (даже они). Моя позиция заключается в том, что вопрос низкого качества (и должен быть закрыт), потому что ОП не предоставил достаточной информации.
Еще один вопрос для ОП ... вы #include <math.h> ? Ваш компилятор генерировал какие-либо предупреждения?

Cheers and hth. - Alf · Answer 1 · 2014-05-26T01-53-00.000Z

pow(67,1) не следует компилировать как C++ 03, но, как отмечает Тони в комментарии, ¹ C++ 11 §26.8/11 делает его действительным снова в C++ 11. Visual C++ 12.0 отклоняет код как C++, очевидно, играя по правилам C++ 03. Однако компилятор g++ версии 4.8.2 принимает код. С Visual C++ появляется диагностика о неоднозначном вызове, так как существует много перегрузок.

В C или в C++ 11 аргументы преобразуются в double а pow выполняет возведение в степень. Хотя эти числа могут быть представлены точно как double, операция экспоненции не гарантирует получение точного целого числа. Например, это может быть выполнено как ⁿ= e ^{n * ln (a)}.

Следовательно, результат может быть немного больше или меньше точного 67.

Выражение умножения преобразует целое число 3 в double, точно, и умножение выполняется как double. Если результат pow меньше 67, вы получаете результат, например, 200.9999999..., если он точнее, чем вы получите 201.0, и если он немного больше, вы получите что-то вроде 201.0000001...

Наконец, присваивание обратно x преобразуется обратно в ближайшее значение int, которое в первом случае равно 200, а во втором и третьем случае - 201.

² Я могу только заключить, что заявленный результат 200 должен (скорее всего) быть неправильным; что он неправильно сообщил.

^{¹⁾ C++ 11 §26.8/11: "Кроме того, должны быть дополнительные перегрузки, достаточные для обеспечения: 1. Если любой аргумент, соответствующий double параметру, имеет тип long double, тогда все аргументы, соответствующие double параметрам, эффективно передаются в long double. 2. В противном случае, если любой аргумент, соответствующий double параметру, имеет тип double или integer, тогда все аргументы, соответствующие double параметрам, эффективно преобразуются в double. 3. В противном случае все аргументы, соответствующие double параметрам, эффективно переводятся в float. ".}
^{²⁾ См. Комментарий к удаленному тексту.}

Не правда: 198 невозможно. Умножение также является плавающей точкой, поэтому результат будет похож на 200,9999 или 201,0001 до усечения.
@ david.pfx: ты прав. Благодарю. нет «преобразования в int», о котором я говорил. вероятно, пришло от меня усталость. исправление ...
я думаю это все если все еще есть ошибка, не стесняйтесь исправить. :)
"pow (67,1) не должен компилироваться как C ++" - в соответствии с 26.8 / 11 "дополнительные перегрузки достаточны для обеспечения" .2 ", если какой-либо арифметический аргумент, соответствующий double параметру, имеет тип double или целочисленный тип, то все арифметические аргументы, соответствующие double параметры эффективно приводятся к double . " Я считаю, что это применимо, и GCC является правильным.
@TonyD: спасибо! опять я не видел. Это не там в C ++ 03, хотя. Поэтому поведение Visual C ++, отклоняющее код как C ++, было правильным для C ++ 03, если я не пропускаю еще больше. Исправляя еще раз ...

Floris · Answer 2 · 2014-05-26T01-41-00.000Z

Предварительное объяснение: функция pow, выполняемая с двойной точностью, не "понимает", что мощность 1 означает "вернуть точное число" и возвращает 66.9999. (Множество 9, но не точно 67). Умножение на 3 дает что-то вроде 200.99997. Наконец, поскольку результат присваивается int, он округляется (усекается) до 200.

Когда я пытаюсь напечатать ("% f", pow (67, 1)), я получил 67.00000003, а не 66.99999. Можете ли вы показать мне, почему?
@ILoveCoding: это на том же ПК, компилятор, настройки оптимизации? Вы также распечатали свой x из вопроса, чтобы узнать, сообщал ли он сейчас 200 или 201?
Попробуйте printf("%e\n",pow(67,1)-67); - число с двойной точностью имеет много значащих цифр!
Спасибо вам. Я думаю, что это как ура и hth. - сказал Альф ниже. Может быть возврат 66.99999 или 67.000003