Оператор for

[lalka]

Есть такой код:

#include <stdio.h>
#include <conio.h>
#include <math.h>
#include <locale>
int main()
{
setlocale (LC_ALL, "Russian");
float y,x;

for (x=0;x<=1.5;x=x+0.1)
{
y=(cos(x)*cos(x)-sin(x+0.5)-x*x*x)/(x+1) + sqrt(cos(x)/(x*x+0.1));
printf("y=%4.1f при x= %.1f \n", y, x);
}
getch();
}

почему не выводится значение у при х=1.5, нужно что бы работало именно с условием x<=1.5 а не x<1.6. Объясните пожалуйста в чем проблема.

[Stilet]

а не x<1.6.

А почему, если не секрет?

P.S. А интересно почему действительно <= не срабатывает на равенство. Неужели из-за костылей проца при работе с вещественными?

[Serge_Bliznykov]

Неужели из-за костылей проца при работе с вещественными?

имхо, 99.99% именно в этом!

см. пост (особенно статью Антона Григорьева рекомендую...)

Не знаю, конечно, как там в C, но, думаю, что общая логика машинного представления вещественных чисел одинакова хоть для Delphi, хоть для C!

[lalka]

Сообщение от Stilet

А почему, если не секрет?

P.S. А интересно почему действительно <= не срабатывает на равенство. Неужели из-за костылей проца при работе с вещественными?

Ну такое условие поставлено. И прикол в том, что при x<=0.5 подсчитывается и выводится у.

Сообщение от Serge_Bliznykov

имхо, 99.99% именно в этом!

см. пост (особенно статью Антона Григорьева рекомендую...)

Не знаю, конечно, как там в C, но, думаю, что общая логика машинного представления вещественных чисел одинакова хоть для Delphi, хоть для C!

Спасибо, статья помогла понять в чем проблема.

[8Observer8]

А я не могу прочитать статью. Пишет, что "404 - Компонент не найден"

Про "Загадки округления" интересно написано. Нужно будет прочитать. Спасибо за ссылку!

[Serge_Bliznykov]

ваша правда. умерла ссылочка...

но статью легко найти поиском.

Более того, доступен оригинал статьи на сайте королевства Дельфи:
Антон Григорьев. "Неочевидные особенности вещественных чисел"

[rrrFer]

вещественный числа вообще нельзя никогда сравнивать на равенство оператором == (а также <=, >=).
Вещественные числа всегда сравниваются с какой-то погрешностью.
Ну или вотъ: http://www.cplusplus.com/reference/cmath/islessequal/
но я этой штукой ниразу не пользовался, и не знаю как оно работает )
Там есть примечание:

In C++, it is implemented with function overloads for each floating-point type, each returning a bool value.

[SAMOUCHKA]

Почему то в литературе особо акцент на ото не делается. Была подобная проблема ни один день на это убил. Кто же знал что float нельзя сравнить с абсолютной точностью.
Пришлось использовать int а в теле цикла привел к float и умножил на нужный коэффициент.

[Stilet]

Почему то в литературе особо акцент на ото не делается.

Ну... Как-то не пришлась эта проблема по вкусу авторам.
Да и если честно она не такая уж и назойливая, т.е. она есть но ее в 100% случаев можно обойти описав код по другому.

[rrrFer]

Да про что тут писать то?
Если уж очень хочется почитать, ищи в книжках по теории автоматов (вроде бы в етих разделах описываются разные варианты хранения чисел в ЭВМ).
Вот другой пример: http://ideone.com/PRnt8Y

#include <iostream>

int main() {
  std::cout.precision(25);
  std::cout << std::fixed << 1e-10 << std::endl;
  std::cout << std::fixed << 1 + 1e-10 << std::endl;
  std::cout << std::fixed << 10 + 1e-10 << std::endl;
  std::cout << std::fixed << 100 + 1e-10 << std::endl;
  std::cout << std::fixed << 10e10 + 1e-10 << std::endl;
}

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