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

    −54

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    9. 9
    public class BigDecimal extends Number implements Comparable<BigDecimal> {
    ...
        public double doubleValue(){
    	if (scale == 0 && intCompact != INFLATED)
    	    return (double)intCompact;
    	// Somewhat inefficient, but guaranteed to work.
    	return Double.parseDouble(this.toString());
        }
    }

    Чуваки решили не париться

    Запостил: stokito, 25 Сентября 2015

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

    • Но нахуя? В жабе же и так есть БольшоеДесятичное...

      P.S. Или это в стандартной либе так и есть?
      Ответить
    • Ну, в общем-то, не так страшен чёрт, как его малюют. Этот doubleValue() там скорее для полноты, чем для использования - BigDecimal в дабл не так и часто приходится конвертить... Сразу начинаются вопросы в духе "а нафиг было в BigDecimal'ах считать, если всю точность просрём на касте в дабл" и т.п...
      Ответить
      • К сожалению это очень даже частая операция. Особенно в тестах пока не было этого комита https://github.com/junit-team/junit/issues/95
        Там ещё много приколов есть
        http://thomas-eichberger.blogspot.com/2011/12/some-hints-for-calculations-with.html
        Ответить
        • Хороший тред. Отмечусь

          > Be aware that 0.1 is an infinite decimal number, 0.5 is not, so new BigDecimal(0.5) is fine, but not new BigDecimal(0.1). And if you do not want to think about the difference every time, do not use new BigDecimal(...) at all.

          И тут они поняли насколько не хватает рациональных, чтобы представить бесконечные периодические дроби. Или еще не поняли:?
          Ответить
          • Ага, я по этому поводу когда-то накатал статейку
            https://stokito.wordpress.com/2014/01/05/%D0%BA%D0%BE%D1%80%D0%BE%D0%B7%D0%B8%D1% 8F-%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D1%81%D1% 82%D0%B8/
            Ответить
          • И насколько же их не хватает?
            Ответить
    • >>> Double.parseDouble(this.toString())
      так вот откуда это пошло
      Ответить
    • Справедливости ради, нужно отметить что это УЖЕ немного улучшеный вариант по перформансу https://bugs.openjdk.java.net/browse/JDK-6274390

      Кстати в 8ой JDK ещё немного подтюнили http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/math/BigDecimal.java#BigDecimal.doubleValue%2 8%29

      А вот тут тоже чуваки удивляются этому говнокоду https://stackoverflow.com/questions/14739823/improve-performance-on-bigdecimal-to-double-conversion там даже патчи какие-то есть

      Кстати попутно интересную тему нашёл http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/
      но это уже оффтоп
      Ответить
      • Да там во всей стандартной либе 100500 возможностей для оптимизации.
        В первую очередь алгоритмической. Вон в 7ой жабе наконец-то приличную сортировку массивов сделали по заветам дедушки Кнута. В 8ой наконец worst case по хэш-мапе починили.
        Может когда-нибудь дело до строк и буферов дойдёт, и мы увидим хотя бы КМП.
        Ответить
        • > мы увидим хотя бы КМП.
          А что это, не в курсе.
          По поводу строк то там Шипилёв кажись на конфе говорил что они в этом направлении сейчас активно работают. Проанализировали кейсы использования и у них их оказалось ограниченное число, так что они сделают какие-то там оптимизации. Не вникал ещё в тему.
          Ответить
          • https://en.wikipedia.org/wiki/Knuth–Morris–Pratt_algorithm
            Ну думал раз завсегдатаи в курсе, то и старожилы тоже. Суть в том что стандартный indexOf фейлит в сложности когда надо в "aaaaaaaaaaaaaaaaaa....a" искать "aaaaaaaaaaaaab"
            Ответить

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