nan ind c что это

NaN в C ++ — что это такое и как это проверить?

Что такое NaN?
NaN, аббревиатура «Not a Number» — это исключение, которое обычно происходит в тех случаях, когда выражение приводит к числу, которое невозможно представить. Например, квадратный корень из отрицательных чисел.

// C ++ код для демонстрации NaN-исключения
#include
#include // for sqrt()

using namespace std;

// печатает число (1.41421)

// Печатает исключение «nan»

Как проверить на NaN?

// C ++ код для проверки на исключение NaN
// используя оператор «==»
#include
#include // for sqrt()

using namespace std;

// Возвращает true, a является действительным числом

// выводит «Это реальное число»

a==a? cout «Its a real number»

b==b? cout «Its a real number»

Способ 2. Использование встроенной функции «isnan ()».
Другой способ проверить NaN — использовать функцию «isnan ()», эта функция возвращает true, если число сложное, иначе возвращает false.

// C ++ код для проверки на исключение NaN
// используя «isnan ()»
#include
#include // for sqrt() and isnan()

using namespace std;

// Возвращает ложь как

isnan(a)? cout «Its NaN»

cout «Its a real number»

isnan(b)? cout «Its NaN»

cout «Its a real number»

Эта статья пополняемая Manjeet Singh Если вы любите GeeksforGeeks и хотела бы внести свой вклад, вы также можете написать статью с помощью contribute.geeksforgeeks.org или по почте статьи contribute@geeksforgeeks.org. Смотрите свою статью, появляющуюся на главной странице GeeksforGeeks, и помогите другим вундеркиндам.

Пожалуйста, пишите комментарии, если вы обнаружите что-то неправильное или вы хотите поделиться дополнительной информацией по обсуждаемой выше теме.

Источник

Nan ind c что это

Even though representation of π on a computer system has limitation, it can NOT be treated as a DEN. As said in the article CPU flags-off a floating point value as DEN when its value reaches close to zero but not zero.

On the other hand, representation of π is limited by available number of bits in the exponential part. As we know, integer part of π is finite but fractional part of π is infinite. Hence we can say that the fractional part of π goes towards infinity. Sign In· View Thread

Re: Good article.

SL099

28-May-15 17:39

OK.Thank you for your reply,Now I think I get it

Good article

prasanth_mv

7-Oct-14 2:25

Good article. Thank you for sharing
Sign In· View Thread

Re: Good article

Nisamudheen

7-Oct-14 19:16

Thanks for the comment

Comparison and optimization

BugDigger

5-Oct-14 22:29

> D. Properties of NaN

Does it mean that compiler always must insert code for comparison even on high levels of optimization? Is this part of C++ standard?

Re: Comparison and optimization

Nisamudheen

6-Oct-14 0:33

Thats a good question.

Answer to your first question depends on what kind of Floating Point Model (FPM) is specified for your project. In VS2012, you can see this option in «Property Pages->C/C++->Code Generation->Floating Point Model»

This («http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx») Microsoft page says that if the FPM chosen is /fp:precise then expression optimization will NOT be applied for special values such as NaN. It clearly says the following.

So a compiler must insert code for comparison even on high levels of optimization.

As for your second question, I don’t know whether C++ standard specifies various floating point optimization strategies. I think it is more a compiler-optimization dependent thing.

Re: Comparison and optimization

BugDigger

6-Oct-14 1:10

Thank you for information (I don’t use VS but anyway).

> I don’t know whether C++ standard specifies various floating point optimization strategies.
> I think it is more a compiler-optimization dependent thing.

Yes, it looks like this but this is strange IMHO: stadard contains a lot of NaN things but says nothing (at least I can not find anything) about guarantees of evaluation (taking into account cross-platform issues) of statements in question.

Re: Comparison and optimization

peterchen

29-Jan-15 6:34

While this option affects the code generated, it’s not necessarily *additional* code.

A simple comparison

Will generate the same code, independent of the /fp setting.

Under the hood, to make comparison with NaN etc. work like specified in the standard, floating point exceptions must be masked (i.e. the FPU must be configured not to raise exceptions when operands are NaN etc.), and the test for the FPU status word must be done in a certain way. This, by itself, does not result in extra code.

The /fp:fast option relaxes some requirements, so the optimizer is free to reorder some expressions (such as replace a*b + a*c with a*(b+c) ). It can be assumed that some of these transformations may also break that expected NaN handling.

Also, in my understanding of the standard, the at least some of the optimizations enabled by /fp:fast (such as exploiting associativity and commutativity) are allowed by the standard, even though they are commonly understood to be dangerous for numeric precision.

All compilers I worked with allow different optimization strategies for floating point. It’s one of the few places where compilers tend to default to being more restrictive than the standard allows.

peterchen

29-Jan-15 6:39

The C++ standard does not even mandate the existence of NaN’s.
Floating point optimization is tricky (since many mathematical equivalences do not hold for limited precision).

For x86 / x64 architecture, the compiler does not need to generate additional code to meet these requirements.

See also my other reply for some details

BugDigger

29-Jan-15 17:39

Good article

pani68

3-Oct-14 9:40

Re: Good article

Nisamudheen

3-Oct-14 19:45

Last Visit: 31-Dec-99 19:00 Last Update: 17-Dec-21 23:58

Refresh

General News Suggestion Question Bug Answer Joke Praise Rant Admin

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Источник

NaN все еще может немного удивить

Сначала, я подумал, что это очередной вопрос из тех, которые могут задаваться на собеседовании. Наверное, если как следует пораскинуть мозгами, то можно догадаться до того, каким будет результат. Откинувшись на спинку кресла, начал размышлять, включать логику, вспоминать что-нибудь, на что можно опереться в рассуждениях. Но тщетно! Вдруг стало совершенно очевидно, что найти ответ не удается. Но почему? В чем нужно разбираться, чтобы он был найден? В математике? В языке программирования?

Ответ должен быть NaN. Но почему я не уверен в этом? Всю дорогу была уверенность в том, что любые выражения, содержащие NaN, вернут NaN. Ну разве что только если поделить NaN на ноль — в этом случае будет вызвано исключение ZeroDivisionError. Сто процентов NaN!

Ввожу выражение в ячейку блокнота:

В самом деле? Постойте:

То есть, по какой-то причине, единица в степени NaN — это единица, а вот ноль и все остальные числа в степени NaN — это NaN. Где логика? В чем дело?

Так, давайте еще раз:

Может быть я просто из-за отсутствия какой-то практической надобности в глубоких познаниях о NaN, просто о чем-то не подозревал? А может я знал, но забыл? А может еще хуже — я не знал и забыл?

Заходим на Википедию. Там данный вопрос тоже обозначен как проблема, но почему все именно так устроено, никак не объясняется. Зато узнал что:

Хотя, в то же время:

Что, согласитесь, тоже немного странно.

Ладно, с Википедии отправляемся в C99 на 182 страницу и наконец-то получаем логическое объяснение, почему pow(x, 0) возвращает 1 для любых x, даже для x равного NaN:

Если функция возводится в степень и при этом стремится к 0, то в результате получится 1, вне зависимости от того, какое значение имеет .

А если результат не зависит от числового значения функции , то 1 — является подходящим результатом, даже для NaN. Однако это по-прежнему не объясняет, почему 1 в степени NaN равна 1.

Отыскиваем еще один C99 и на 461 странице не видим никаких объяснений, просто требование того, что pow(+1, y) должно возвращать 1 для всех y, даже равных NaN. Все.

С другой стороны, объяснение, почему pow(NaN, 0)=1 является более предпочтительным, чем pow(NaN, 0)=NaN все-таки наталкивает на мысль о том, что NaN не стоит воспринимать буквально, как Not-a-Number. Допустим, в результате каких- то вычислений мы получили число, превышающее размер памяти, выделенный под данный тип чисел, например:

В результате мы получили inf, что именно это за число мы не знаем, но все же это какое-то число. Затем мы снова что-то вычислили и снова получили слишком большое число:

Разность a и b вернет NaN:

Единственная причина, по которой мы можем считать c не числом, заключается в том, что мы использовали недостаточно точные вычисления. Однако, в c под NaN все же скрывается какое-то значение. О том, что это за значение, мы не знаем. Но все же это число, а раз это число, то нет ничего удивительного в том, что pow(1, NaN)=1.

Почему же тогда pow(0, NaN)=NaN? Дело в том, что если возвести 0 в любую степень, то мы действительно получим ноль. Кроме одного единственного случая — когда степень равна 0:

Из-за чего в выражении pow(0, NaN) появляется неопределенность с конкретным значением NaN. Конечно, вероятность того, что под NaN может скрываться 0 — исчезающе мала и можно было бы принять, что pow(0, NaN)=0. Но все же лучше перестраховаться, мало ли к чему это может привести. Возможно, так и рассуждали, когда создавались стандарты.

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

P.S. Поскольку NaN относится к числам с плавающей точкой, оно может быть ключом словаря:

Имеет ли смысл использовать такое на практике? Думаю, что лучше не стоит.

Источник