1. Java / Говнокод #14541

    +174

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    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

    Запостил: 3.14159265, 11 Февраля 2014

    Комментарии (44) RSS

    • А нахрена нужен AtomicFloat? Особенно если его всегда инкрементят по 1?

      Тем более эффективно его не запилить... Разве что CAS'ом и циклом.
      Ответить
      • Когда числа большие надо инкрементить полагаясь на рандом в зав. от величины мантиссы.
        Иначе никак.
        Ответить
        • > Когда числа большие надо инкрементить полагаясь на рандом в зав. от величины мантиссы.
          Всмысле? Что-то не распарсил я эту фразу ;(
          Ответить
          • Ну когда флоат число over9000, то добавление 1 его не изменит.
            А добавление 1 к мантиссе это допустим добавление уже 1024 при соответствующей экспоненте.

            Значит нам надо добавить 1024 (+1 к мантиссе, при экспоненте равной 1024), но с вероятностью 1/1024.
            Ответить
          • В противном случае на очень больших флоатах инкремент не будет работать. Что можно видеть делая
            int max=100000000;
            float f=10000000000000.0f ;
            for (int i=0;i<max;++i)
               f+=1;
            System.out.println(f);
            System.out.println(f+max);

            http://ideone.com/t3zuGs
            Ответить
            • Да оно уже на 24 битном числе забагуется, не надо так много :)
              http://ideone.com/p2PmR8

              А вероятностный инкремент это интересная идея.

              UPD: Хотя если число только инкрементят, то long'а хватит на все мыслимые сроки ;) 68 лет при 4ккк инкрементов в секунду.
              Ответить
              • > А вероятностный инкремент это интересная идея.
                http://en.wikipedia.org/wiki/Approximate_counting_algorithm
                > long'а хватит на все мыслимые сроки
                Ждём сарказма от Тараса на тему fixed point
                Ответить
                • > сарказма на тему fixed point
                  Я думал это Царское дело.
                  Ответить
                  • Нет, я использую фикседы в движке, не знал?
                    Причины 3:
                    1. однородность поля (т.е. семантически лучше подходит)
                    2. детерминированность вычислений (про гарантии бит-в-бит одинаковых результатов от двух сопроцессоров я ничего не слышал)
                    3. на арм, что в моём планшете они быстрее плавучки (да-да, не поверите)
                    Ответить
                    • Знал. Многие пишут fixed-point реализацию по вышеозначенным причинам (портируемость, скорость).У нас есть strictfp :)
                      Но Царь отличался зашкаливающей радиКАЛьностью суждений.
                      Ответить
                      • Это он и вылечил Тарасю от флоатоблядства
                        Ответить
                    • >2. детерминированность вычислений (про гарантии бит-в-бит одинаковых результатов от двух сопроцессоров я ничего не слышал)
                      Эм а про strictfp в c# не слышал?
                      Ответить
                      • Ок, какие опции выставить в Студии и добавить в командную строну ГЦЦ, чтобы ехешник, скомпилированный студией для ПС, гарантированно давал тот же результат, что и АПКшник, скомпилированный гцц для ведроида на арм?
                        Ответить
                        • Я не сишник. Гугли strict IEEE floating point
                          Ответить
                          • стрикт в рамках двух запусков на одном компе, или стрикт в рамках всех сопроцессоров, существующих в мире и поддерживающих этот формат?
                            Ответить
                            • Всех поддерживающих strict ieee, емнип. Ну т.е. это всего лишь точное соответствие стандарту.
                              Ответить
                              • А сопроцессор первого пентиума тоже его поддерживал?
                                Ответить
                                • А хер бы знал.
                                  Ответить
                                  • Я намекаю на весёлую историю, связанную с сопроцессором первого пня.
                                    Ответить
                • Блин, так тут вообще одну экспоненту оставили ;)
                  Ответить
                  • Лажа флоатов (мантисса+экспонента), в том что они сильно нерегулярны. Из-за этого точность прыгает. Мы тратим много бит на маленькие изменения мантиссы, а потом размашисто прыгаем по экспоненте.
                    IEEE флоаты - срань, грубо говоря из-за того чисел начинающихся на 1, больше чем 2-9 вместе взятых.

                    Чисто экспонентные флоаты логарифмически равномерны и точны.
                    Ответить
                    • IEEE-флоат не срань, всему своё применение
                      Ответить
                      • <Кресты, буст, %любой популярный язык или технология%> не срань, всему своё применение.
                        Ответить
              • >Да оно уже на 24 битном числе забагуется
                Естественно.

                >Хотя если число только инкрементят, то 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-х тоже думали что для года достаточно джвух цифер.
                Ответить
              • >68 лет при 4ккк инкрементов в секунду.
                А если лонг знаковый:?

                Флоат же нам запросто даст нам 2^128 за 32 бита.
                Ответить
                • > А если лонг знаковый:?
                  68 это уже знаковый.

                  > Флоат же нам запросто даст нам 2^128 за 32 бита.
                  И дорогущий инкремент с генерацией порядок-23 бит рандома, операциями над флоатом (ну ок, прямо над его бинарным представлением) и т.п. А на тех же говноконгруэнтных ГПСЧ с 32 битным состоянием нужные для переключения биты могут вообще никогда не выпасть...

                  Тут как бы 128-битный счетчик не оказался более быстрым...
                  Ответить
                  • P.S. Ну хотя не такой уж он и дорогущий по сравнению со спинлоком, которым придется защищать большой счетчик.
                    Ответить
                    • http://en.wikipedia.org/wiki/100_Gigabit_Ethernet
                      С такой штукой даже беззнакового лонга ненадолго хватит.
                      Ответить
                  • Речь не скорее не о скорости, а о обратной совместимости и размере.
                    Вот напишешь long, а его из-за нового быстрого интерфейса передачи данных через 5 лет уже не хватит, придется всё перепиливать, а в коде и сигнатурах, которые использует клиентский код уже везде поставлен long.

                    Что делать? Вот float врядли переполнится... А точность около 1/2**24 во многих местах очень даже приемлима.
                    Тем более 128-бит не очень стандартны. Аппаратного CAS не припомню (по крайней мере в жабе и x86)
                    Ответить
    • Мне даже стало интересно, а можно ли так выебываться делать в шарпе. Пойду проверю
      Ответить
      • Там же мантисса, ему повезло что числа маленькие.
        Ответить
    • показать все, что скрытоХуй.
      Ответить
    • Да, junior совсем не понимает что творит.
      Ответить

    Добавить комментарий