с#
Отлицательное - это NEGATIVE_INFINITY или как его
-Double.MAX_VALUE :cool
Size: a a a
2020 November 16
AN
-Double.MAX_VALUE :cool
нет, вот так нельзя
с#
а, там же разные границы из-за нуля могут быть
AN
а, там же разные границы из-за нуля могут быть
Да и не только из-за нуля. Там еще из-за специфики отрицательных чисел и плавающей точки. Я даже не могу сходу сказать, что там.
RE
Можно. В FP там просто битик для знака и, в отличие от целых чисел, относительно нуля всё симметрично.
AN
positive: 0x7ff0000000000000L
negative: 0xfff0000000000000L
А MAX_VALUE - это вообще другое число. В принципе должно работать и с минусом, но я бы не стал так делать
negative: 0xfff0000000000000L
А MAX_VALUE - это вообще другое число. В принципе должно работать и с минусом, но я бы не стал так делать
M
Решил глянуть -0 == 0, выдает true🤔, даже idea подсказывает, что можно просто заменить на true. Разве они должны быть равны?
RE
Да. Этого требует IEEE 754
AM
positive: 0x7ff0000000000000L
negative: 0xfff0000000000000L
А MAX_VALUE - это вообще другое число. В принципе должно работать и с минусом, но я бы не стал так делать
negative: 0xfff0000000000000L
А MAX_VALUE - это вообще другое число. В принципе должно работать и с минусом, но я бы не стал так делать
Так бесконечности ж совершенно особая штука, с которой арифметика, к примеру, работает иначе. В зависимости от того, что нужно в конкретной задаче, ±MAX_VALUE -- полезные штуки.
AN
Так бесконечности ж совершенно особая штука, с которой арифметика, к примеру, работает иначе. В зависимости от того, что нужно в конкретной задаче, ±MAX_VALUE -- полезные штуки.
Не спорю. Но там есть нюансы. Я вот тут объявил войну NaN-ам.
M
Да. Этого требует IEEE 754
Он ведь стандартизирует числа с плавающей точкой, а там просто int.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
с#
Он ведь стандартизирует числа с плавающей точкой, а там просто int.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
будет странно, если дабл и инт будут себя по-разному вести с нулём
AM
Он ведь стандартизирует числа с плавающей точкой, а там просто int.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
Тут выше флоатинг поинт обсуждался, я тоже подумал, ты о них же, а не об интах :)
AN
Решил глянуть -0 == 0, выдает true🤔, даже idea подсказывает, что можно просто заменить на true. Разве они должны быть равны?
Там опять же есть нюанс, что если 0 - это точно ноль то да, а если это что-то, от чего десятый знак сожрал стринг форматтер, то не факт.
RE
Он ведь стандартизирует числа с плавающей точкой, а там просто int.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
Дополнительный код этих чисел одинаковый. Тогда если -0 записывать в памяти в виде дополнительного кода, то он будет равен +0.
В int-то, да 0 и -0 это просто одно и то же значение. Int (в отличие от FP) вообще не может отличить 0 от -0.
AN
По всем этим причинам, в тестах в частности делать assertEquals на даблы - это опасная вещь.
D
По всем этим причинам, в тестах в частности делать assertEquals на даблы - это опасная вещь.
Это один раз натыкаешся, а потом test with precision используешь. :)
(
(
или почему котлин считает вправе в переменную более узкого типа присвоить значение более широкого