- 1
- 2
- 3
- 4
- 5
Float f = 1.25f;
int i = Float.floatToIntBits(f);
i++;
f = Float.intBitsToFloat(i);
//I wanted 2.25, but got 1.2500001 instead.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+174
Float f = 1.25f;
int i = Float.floatToIntBits(f);
i++;
f = Float.intBitsToFloat(i);
//I wanted 2.25, but got 1.2500001 instead.
http://stackoverflow.com/questions/9921690/java-increment-through-float-floattointbits
Тем более эффективно его не запилить... Разве что CAS'ом и циклом.
Иначе никак.
Всмысле? Что-то не распарсил я эту фразу ;(
А добавление 1 к мантиссе это допустим добавление уже 1024 при соответствующей экспоненте.
Значит нам надо добавить 1024 (+1 к мантиссе, при экспоненте равной 1024), но с вероятностью 1/1024.
http://ideone.com/t3zuGs
http://ideone.com/p2PmR8
А вероятностный инкремент это интересная идея.
UPD: Хотя если число только инкрементят, то long'а хватит на все мыслимые сроки ;) 68 лет при 4ккк инкрементов в секунду.
Ждём сарказма от Тараса на тему fixed point > long'а хватит на все мыслимые сроки
Я думал это Царское дело.
Причины 3:
1. однородность поля (т.е. семантически лучше подходит)
2. детерминированность вычислений (про гарантии бит-в-бит одинаковых результатов от двух сопроцессоров я ничего не слышал)
3. на арм, что в моём планшете они быстрее плавучки (да-да, не поверите)
Но Царь отличался зашкаливающей радиКАЛьностью суждений.
Я чем-то болел?
Меня кто-то лечил?
Царь всех лечил.
Эм а про strictfp в c# не слышал?
IEEE флоаты - срань, грубо говоря из-за того чисел начинающихся на 1, больше чем 2-9 вместе взятых.
Чисто экспонентные флоаты логарифмически равномерны и точны.
Естественно.
>Хотя если число только инкрементят, то long'а хватит на все мыслимые и немыслимые сроки
Я бы брал 128-битное, как минимум. А 256 перебрать-то точно всей энергии вселенной не хватит.
Частота процов уже ~5 Ггц=5*(10**9) inc/sec.
Есть интерфейсы передачи 10Gbit/sec=10**10 inc/sec. Уже в планах 100Гбит/сек.
(10**10)*3600*24*365*30 лет>2**63.
Ну поломается код через 30 лет, а к тому времени или кодер сдохнет, либо ишак, либо шах поменяет работу, либо проект выбросят и перепишут, либо заказчика не будет.
В 70-х тоже думали что для года достаточно джвух цифер.
А если лонг знаковый:?
Флоат же нам запросто даст нам 2^128 за 32 бита.
68 это уже знаковый.
> Флоат же нам запросто даст нам 2^128 за 32 бита.
И дорогущий инкремент с генерацией порядок-23 бит рандома, операциями над флоатом (ну ок, прямо над его бинарным представлением) и т.п. А на тех же говноконгруэнтных ГПСЧ с 32 битным состоянием нужные для переключения биты могут вообще никогда не выпасть...
Тут как бы 128-битный счетчик не оказался более быстрым...
С такой штукой даже беззнакового лонга ненадолго хватит.
Вот напишешь long, а его из-за нового быстрого интерфейса передачи данных через 5 лет уже не хватит, придется всё перепиливать, а в коде и сигнатурах, которые использует клиентский код уже везде поставлен long.
Что делать? Вот float врядли переполнится... А точность около 1/2**24 во многих местах очень даже приемлима.
Тем более 128-бит не очень стандартны. Аппаратного CAS не припомню (по крайней мере в жабе и x86)
Безопасная жаба такая безопасная.