Точность double

https://en.cppreference.com/w/cpp/numeric/math/cos

If the implementation supports IEEE floating-point arithmetic (IEC 60559),

if the argument is ±0, the result is 1.0

Ну это понятно. Ну а для углов отличных от нуля?

ЕМНИП в double 52 бита отводится на мантиссу, ну значит и точность на вскидку 2**-52 ну или по-нашему 10**-17, у меня нули в вычислениях примерно такого порядку во всяком случае.

А ежели брать числа с одинарной точностью, то там будет где-то 10**-6 всего лишь.

Но почему во втором случае я получаю точно 1.0 , а не 1.0000…чтототам ?

Округление. Вообще, зависит от того, что за процессор у тебя, и каким транслятором ты пользуешься.

1. вещественные числа на ПК имеют запас точности и все операции выполняются с некоторой степенью точности(грубо говоря по числу знаков) и могут в дальнейшем ещё и округлятся

2. как пример сложение 6.1232339957368e-17(мой результат косинуса) с нулём то совершенно логично получим 6.1232339957368e-17, но если мы будем складывать с 1.0, то прежде всего 6.1232339957368e-17 будет выровнено по порядку(степени) под 1.0, но из-за этого оно будет терять знаки после точки грубо говоря будет такая последовательность переходов

6.1232339957368e-17
0.6123233995736e-16
0.0612323399573e-15
0.0061232339957e-14
0.0006123233995e-13
...
0.0000000000006e-04
0.0000000000000e-03
...
0.0000000000000e-00 -> готово, число того же 
порядка что и 1.0e00 и вот теперь складывая с ним мы получим 1.0, логика отброса состоит в том, чтобы отбрасывать наимение значащие части числа

Т.е. вся веселуха произошла из-за ограниченной точности double и арифметики, которая по сути требует для например сложения и вычитания приравнивать порядки и уже после выполнять действия, в остальном как уже рекомендовали стоит посмотреть статьи на данную тему или как вариант кусочек главы по этой теме из книги «Игровой движок» 3-е издание

Получается для sin результат тоже получился не точно 1.0 Просто значение после точки получилось дальше и соответственно отбросились.

Да. Именно так. При выполнении арифметики чисел сильно отличающихся порядков, выравнивание порядков может сносить порядочную часть мантиссы(значащей части), вплоть до её обнуления.

Скорее всего потому, что

cos(pi/2+eps) = eps + …,

sin(pi/2+eps) = 1 - eps^2 / 2 + …

…Если еще подробнее, то если для косинуса (в окрестности pi/2) погрешность в 16-естнадцатом (десятичном) знаке аргумента даст погрешность в 16 знаке результата, то для синуса – даст ошибку в 32 знаке, т.е. уже за пределами хранимой мантиссы.

man 0.1 + 0.2

Получается для sin результат тоже получился не точно 1.0 Просто значение после точки получилось дальше и соответственно отбросились.

Кто тебе мешает сравнить Math.sin(Math.toRadians(90)) с 1.0??????????????????????????????????????????????????? Чё ты гадаешь как цыганка?????????????????????????????

«A computation is a temptation that should be resisted as long as possible.»

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

Если тебе реально интересно, глянь вот сюда как типы float и double устроены в железе: http://datasheets.chipdb.org/Intel/x86/808x/datashts/8087/205835-007.pdf

Емнип первый IEEE стандарт для чисел с плавающей точкой был сделан на основе i8087.

Там правда тоже есть проблема с округлением: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c70

Так у меня и получилось в итоге 1.0

https://0.30000000000000004.com/

Способ округления хвоста настраивается, в цпп есть соответствующий интерфейс, должен настраивать фпу. Т.е это не обязательно отброс. https://en.cppreference.com/w/cpp/numeric/fenv/FE_round

Интересно, если на ЛОРе спросить про расходимость интегрирования по Эйлеру, то в ответ тоже предложат почитать про машинную арифметику?

ТС, овладей рядами Тейлора! Только матан научит правильно считать трансцендентные функции.