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



Выводится:


Вопрос: что с косинусом 90 градусов??? 
Почему программа выводит не ноль, а число, хоть и очень-очень маленькое, но бОльшее нуля?

Это сообщение отредактировал(а) PingWiN0x20 - 17.11.2009, 15:09

 это проктически ноль.

ИМХО.
Компьютер в отличае от человека считает с приблизительной точьностью, он получил значение которое соответствует этой точности.

ноль <> приблизительно ноль.



Такой код не выводит ничего. А должен бы.

P.S.: почему тогда синус 90 посчитался нормально... без приблизительной точности?

Опять таки ИМХО
Думаю попало удачно, в итоге остаток был так мал что отбросился, а у cos он был таков что был мал и соответствовал условию точности, но не достаточно мал чтоб быть отброшенным.

PingWiN0x20, просто округляй результат на величину, которая "проглотит" погрешность(одного разряда будет достаточно).

Только что проверил в Delphi ... такая же ерунда!

И вот еще что настораживает...


Если мне память не изменяет, на ноль делить нельзя (косинус 90 вся-таки нулю равен). Но приведенного выше выражения это не касается. В переменной Number будет вполне себе обыкновенное число.
Придется писать свою функцию Cos, которая, встретив значение угла 90.00 вернет ноль, а не 6,123031...E-17.

Спасибо всем за ответы   

Это сообщение отредактировал(а) PingWiN0x20 - 17.11.2009, 17:01

diadiavova забавная дилемма получаеться ввести новую погрешность чтоб устранить старую 

Добавлено @ 17:08
PingWiN0x20 Здесь то что предложил diadiavova по моему хорошо подойдёт. 
Но можно провести забавную на мой взгляд аналогию....



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


Вот что что а это думаю не стоит, лучше чем у тех ребят что их писали врятли получиться.



Это сообщение отредактировал(а) KuMa1104 - 17.11.2009, 17:08

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






Да нет, я не собираюсь переписывать саму функцию Math.Cos() 
Просто сделаю как-то так:



Это сообщение отредактировал(а) PingWiN0x20 - 17.11.2009, 17:28

Не ввести новую погрешность, а установить предельно-допустимую погрешность на таком уровне, в пределах которого возвращаемый машиной результат будет корректным. 
Когда ты пишешь

Ты практически говоришь о том же. Мой ответ от твоего отличается только тем, что он содержит практический совет.

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

Весёлая тема. 


Вот это вообще убило   

Попробуй вот такое посчитать:

Ноль не получится 
И что, на этот случай тоже собственную функцию умножения писать будешь? А таких случаев бесконечно много, все не перечислишь.

Смысл в том, что во-первых в форме числа с плавающей запятой (Float/Double) нельзя представить любое число -- количество представимых чисел конечно. 
Во-вторых могут быть проблемы с представлением десятичных чисел в двоичном виде. Это примерно как с обыкновенными дробями, сравни:
1/3 * 3 = 10
1/3 = 0.333333333(3)
0.333333333(3) * 3 = 0.999999999(9)
Парадокс, да? 

PS: О сколько нам открытий чудных готовит просвященья дух (почти по Пушкину).

Добавлено @ 17:46
Да, забыл. Вывод из всего это простой. Результаты вычислений с плавающей запятой нельзя сравнивать как a == b -- ничего не получится (как я уже писал 0.1 * 3 не равно 0.3). Надо вычитать одно из другого и сравнивать абсолютную разницу с заранее выбранным маленьким числом, которое ты принимаешь как допустимую погрешность, т.е. например так: Math.Abs(a - b) < 0.000000001

Это сообщение отредактировал(а) Дрон - 17.11.2009, 17:48

Console.WriteLine(0.1d * 3 - 0.3); // 0

  Это, пожалуй лучше всего. Эта маленькая величина - предельно-допустимая погрешность на данном этапе вычислений.

неа, не ноль .... 5,5511151...Е-17



Дрон, спасибо! Теперь до меня дошло что о чем    

Это сообщение отредактировал(а) PingWiN0x20 - 17.11.2009, 18:01

d? Ничего не меняет -- это же double, литералы и так double по-умолчанию.
Может всё-таки m? Тогда будет decimal, в нём всё гораздо лучше, таких погрешностей нет, но вот синусы и косинусы в нём не считаются.

Я так смотрю что у одних ноль а у других нет.
Хотя к теме не относиться но хотелбы поинтересоваться почему так?

Я так понемаю что компьютер просто отбрасывает все лишние знаки, а не округляет получаеться что у одних процессор считает с большей точностью чем у других???

Или причина не в этом?