Объясните зачем java.lang.Double.isNan?

>>Мы знаем, что зарплату в числах с плавающей точкой считают только идиоты.

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

Ламерки знают, что белки несут в ответ херню, никак не связанную с тем, на что они отвечают. ;)

Видимо, от тоски и уныния...

ура, хоть ктото вспомнил про пределы

_________

//wfrr

>Речь не обо мне, а о тебе убогом

Ну не скромничай, уникум, приведи аргументы, пока ты только набрасываешь тут своих соплей ничем не подтвержденных, тыж даже свою неубогость доказать не в силах 8)

_________

//wfrr

Ламерки такие ламерки что не знают почему для зарплаты придумали убогий fixed point ? ну что с ламерков то взять.

_________

//wfrr

>приведи аргументы

Например такие, как твое обосратушки про прикладное программирование?)) спасибо но таким не занимаюсь.

Белки такие белки, что по прежнему постят фигню, никак не связанную с тем, на что они отвечают. ;)

Милок, а шо в вашем третьем классе еще не проходили логику? То то ты какойто странный. Даже не знаешь что такое аргументы.

_________

//wfrr

У меня такое подозрения что белкой ты считаешь себя.

_________

//wfrr

Боюсь, это у тебя белочка началась. ;)

NaN это не объект

>Даже не знаешь что такое аргументы.

Не. Просто твой умишко распознает мои аргументы как NaN:D и пытаясь произвести над этим NaN какие-то операции, получает NaN. в итоге ему остается только набрасывать всякое г на вентилятор, так как по делу ничего выдать не может)

Комментарий ламерка:

Боюсь, это у тебя белочка началась. ;)

отлично подходит к твоему солипсистскому бреду.

_________

//wfrr

в java это значение примитивного типа, ну и что?

_________

//wfrr

даже сюда http://ru-java.livejournal.com/1043718.html проник

О, вспоминается старая добрая отладка фортрана!

ну скажем так, с этого все началось, с затейливого способа определения что перед нами NaN, по которому становится очевидно, что только один объект в яве ведет себя «особенным образом».

_________

//wfrr

> в java это значение примитивного типа, ну и что?

твоя проблема в том, что ты не понимаешь, зачем нужна математика в программировании, и всего-то =)

ну хочешь ты какой-то другой NaN, унаследуй его от Object'а и добавь в оберточные типы, делов-то

>твоя проблема в том, что ты не понимаешь, зачем нужна математика в программировании, и всего-то =)

Ох, щи Доктор в треде, он знает мои проблемы и хочет о них поговорить.

доктор у вас заберут, лицензию, вопрос про то «нахрена нарушать целостную и непротиворечивую концепцию всяким говном», хотя одно наличие примитивов - уже всю концепцию нагибает и неистово нарушает.

ну хочешь ты какой-то другой NaN, унаследуй его от Object'а и добавь в оберточные типы, делов-то

Ви, таки, путаете java с чем то другим.

_________

//wfrr

> вопрос про то «нахрена нарушать целостную и непротиворечивую концепцию всяким говном»

так она не целостная же) компромисс. Примитивный нан как бы намякивает на ситуацию с наном и в какую сторону был компромисс)

Вот гляди как реализован hashCode для MapEntry:

public final int hashCode() {
return (key==null ? 0 : key.hashCode()) ^
(value==null ? 0 : value.hashCode());
}

чуешь что случится, когда ключ и значение совпадут?

ты глянь чо щаз с ним будут в восьмой версии делать. Сначала сольют HotSpot с JRockit, а потом впилят функциональщину. Вот это уже кладезь для батхерта =)

> Ви, таки, путаете java с чем то другим.

why?

>чуешь что случится, когда ключ и значение совпадут?

ну ноль, что тут такого страшного то? В хешмап гораздо интересне поместить хешмап и заставить посчитать хешкод, ага, при этом все остальное кроме equals и toString будет работать, но причем при это v!=v?

Примитивный нан как бы намякивает на ситуацию с наном и в какую сторону был компромисс)

Там по ходу тупо реализовали http://en.wikipedia.org/wiki/IEEE_754-1985 со всеми его тараканами.

_________

//wfrr

> ну ноль, что тут такого страшного то?

страшно, что это гарантированный hash collision, и волшебная сказка про «ожидание решения задачи hash collision достаточно большое, чтобы им пренебречь» резко испаряется. Все кто об этом не знал сядут в лужу, и поэтому...

но причем при это v!=v?

всем пох как отрабатывает стандартный hashCode, кому действительно надо - будет писать свой. То же и тут. Какая разница для кода, активно эксплуатирующего NaN, какая там стандартная реализация - все равно придется писать что-то свое :)

Там по ходу тупо реализовали http://en.wikipedia.org/wiki/IEEE_754-1985 со всеми его тараканами.

да ты эрудит. берем на заметку...

> Там по ходу тупо реализовали http://en.wikipedia.org/wiki/IEEE_754-1985 со всеми его тараканами.

Быстро схватываешь! Каких-нибудь пять лет - и ты уже знаешь законы арифметики, которыми пытался пользоваться.

По поводу арифметических операций с NaN. Если NaN это не число, а результат арифметической операции должен быть числом(с прикладной точки зрения), то тут должен выскакивать эксепшн. И должны быть все довольны. Программисты не влепят тупую ошибку, функциональность не пострадает...

На счёт NaN != NaN. Имхо должно быть равно для того чтобы не парить программистам мозг. Однако текущее поведение описано в спеках IEEE 754. В кратце, суть такая: nan != X каким бы X не было, даже если X это nan(скорее всего такое поведение проще в аппаратной реализации). Т.к. это крайний случай то вне зависимости от того равны ли nan или не равны кто-то всё равно останется недоволен поведением.

>страшно, что это гарантированный hash collision, и волшебная сказка про «ожидание решения задачи hash collision достаточно большое, чтобы им пренебречь» резко испаряется. Все кто об этом не знал сядут в лужу, и поэтому...

Охринеть какой бред, ты путаешь банальную хешфункцию и те грибы что зовут md5 и кричать что у них долгие как оргазм коллизии.

_________

//wfrr

>Если NaN это не число, а результат арифметической операции должен быть числом(с прикладной точки зрения), то тут должен выскакивать эксепшн. И должны быть все довольны. Программисты не влепят тупую ошибку, функциональность не пострадает...

На счёт NaN != NaN. Имхо должно быть равно для того чтобы не парить программистам мозг.

И я о томже.

Однако текущее поведение описано в спеках IEEE 754. В кратце, суть такая: nan != X каким бы X не было, даже если X это nan(скорее всего такое поведение проще в аппаратной реализации).

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

_________

//wfrr

для реализации этого изврата всеравно требуется писать костыли для операции сравнения. Хоть в софте, хоть вкорячивать ее в железе.

В софте типа легче...

Плюсану тебя и белку.

О, есть ещё адекватные люди на лоре :)

равны ли nan или не равны кто-то всё равно останется недоволен поведением.

Про объект известно, чем он не является. Имеется ещё один не являющийся тем же самым объект. С тебя пруф того, что эти объекты тождественны, решительно, быстро, люто, бешено.

>Имеется ещё один не являющийся тем же самым объект.

это [b]тотже[/b] самый объект, заруби тебе на носу. Если у нас есть два разных Nan и они друг друг не равны - то и хрен сним, но когда данный конкретный экземпляр [b]не равен самому себе[/b] то это уже программаразм.

_________

//wfrr

Кэп намекает, что NaN существует для возможности бросить исключение при некорректной операции (если бы NaN и inf не было, это бы не было возможным). Условие NaN != NaN должно выполняться для непротиворечивости алгебры, если NaN = NaN, то можно доказать, что одновременно с этим x != x для любого х (в том числе, из Nan = NaN следует и то, что NaN != NaN).

> это [b]тотже[/b] самый объект, заруби тебе на носу.

Согласно семантике языка, ни что не запрещает объекту быть неравным самому себе. = и != не проверяет условие «является ли x и y одним и тем же объектом», она проверяет условмие «равны ли x и y». Естественно, эти предикаты могут не совпадать.