В самом популярном фрагменте кода за всю историю StackOverflow ошибка! 

Original author: Andreas Lundblad
  • Translation
Недавнее исследование «Использование и атрибуция сниппетов кода Stack Overflow в проектах GitHub» внезапно обнаружило, что чаще всего в опенсорсных проектах встречается мой ответ, написанный почти десять лет назад. По иронии судьбы, там баг.

Давным-давно…


Еще в 2010 году я сидел в своём офисе и занимался ерундой: развлекался код-гольфингом и накручивал рейтинг на Stack Overflow.

Моё внимание привлёк следующий вопрос: как вывести количество байт в удобочитаемом формате? То есть как преобразовать что-то вроде 123456789 байт в «123,5 МБ».


Старый добрый интерфейс 2010 года, спасибо The Wayback Machine

Неявно подразумевалось, что результатом будет число между 1 и 999,9 с соответствующей единицей измерения.

Уже был один ответ с циклом. Идея простая: проверять все степени с самой большой единицы (ЭБ = 1018 байт) до самой маленькой (Б = 1 байт) и применить первую, которая меньше числа байт. В псевдокоде это выглядит примерно так:

suffixes   = [ "EB", "PB", "TB", "GB", "MB", "kB", "B" ]
magnitudes = [ 10^18, 10^15, 10^12, 10^9, 10^6, 10^3, 10^0 ]
i = 0
while (i < magnitudes.length && magnitudes[i] > byteCount)
    i++
printf("%.1f %s", byteCount / magnitudes[i], suffixes[i])

Обычно при наличии правильного ответа с положительной оценкой его трудно догнать. На жаргоне Stack Overflow это называется проблемой самого быстрого стрелка на Западе. Но здесь у ответа было несколько недостатков, поэтому я всё равно надеялся его превзойти. По крайней мере, код с циклом можно значительно сократить.

Это ж алгебра, всё просто!


Тут меня осенило. Приставки кило-, мега-, гига-,… — ни что иное, как степени 1000 (или 1024 в стандарте МЭК), так что правильную приставку можно определить с помощью логарифма, а не цикла.

Основываясь на этой идее, я опубликовал следующее:

public static String humanReadableByteCount(long bytes, boolean si) {
    int unit = si ? 1000 : 1024;
    if (bytes < unit) return bytes + " B";
    int exp = (int) (Math.log(bytes) / Math.log(unit));
    String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp-1) + (si ? "" : "i");
    return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
}

Конечно, это не очень читабельно, и log/pow уступает по эффективности другим вариантам. Но никакого цикла и почти нет ветвлений, так что результат получился довольно красивым, на мой взгляд.

Математика тут нехитрая. Количество байт выражается как byteCount = 1000s, где s представляет степень (в двоичной нотации база 1024.) Решение s дает s = log1000(byteCount).

В API нет простого выражения log1000, но мы можем выразить его в терминах натурального логарифма следующим образом s = log(byteCount) / log(1000). Затем преобразуем s в int, так что если у нас, например, более одного мегабайта (но не полный гигабайт), то в качестве единицы измерения будет использоваться МБ.

Получается, что если s = 1, то используется размерность килобайт, если s = 2 — мегабайт и так далее. Делим byteCount на 1000s и шлёпаем соответствующую букву в префикс.

Оставалось только подождать и посмотреть, как сообщество воспримет ответ. Я подумать не мог, что этот фрагмент кода станет самым тиражирумым в истории Stack Overflow.

Исследование по атрибуции


Перенесёмся в 2018 год. Аспирант Себастьян Балтес публикует в научном журнале Empirical Software Engineering статью под названием «Использование и атрибуция сниппетов кода Stack Overflow в проектах GitHub». Тема его исследования — насколько соблюдается лицензия Stack Overflow CC BY-SA 3.0, то есть указывают ли авторы ссылки на Stack Overflow как источник кода.

Для анализа из дампа Stack Overflow были извлечены сниппеты кода и сопоставлены с кодом в публичных репозиториях GitHub. Цитата из реферата:

Представляем результаты крупномасштабного эмпирического исследования, анализирующего использование и атрибуцию нетривиальных фрагментов кода Java из ответов SO в публичных проектах GitHub (GH).

(Спойлер: нет, большинство программистов не соблюдает требования лицензии).

В статье есть такая таблица:



Этот ответ вверху с идентификатором 3758880 оказался тем самым ответом, который я опубликовал восемь лет назад. На данный момент у него более ста тысяч просмотров и более тысячи плюсов.

Быстрый поиск на GitHub действительно выдаёт тысячи репозиториев с кодом humanReadableByteCount.



Поиск этого фрагмента в своём репозитории:

$ git grep humanReadableByteCount

Забавная история, как я узнал об этом исследовании.

Себастьян нашёл совпадение в репозитории OpenJDK без какой-либо атрибуции, а лицензия OpenJDK не совместима с CC BY-SA 3.0. В списке рассылки jdk9-dev он спросил: это код Stack Overflow скопирован из OpenJDK или наоборот?

Самое смешное то, что я как раз работал в Oracle, в проекте OpenJDK, поэтому мой бывший коллега и друг написал следующее:

Привет,

Почему бы не спросить напрямую у автора этого сообщения на SO (aioobe)? Он является участником OpenJDK и работал в Oracle, когда этот код появился в исходных репозиториях OpenJDK.


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

Затем Себастьян написал мне, чтобы прояснить ситуацию, что я и сделал: этот код добавили ещё до моего прихода в Oracle и я не имею отношения к коммиту. С Oracle лучше не шутить. Через пару дней после открытия тикета этот код был удалён.

Баг


Держу пари, вы уже задумались об этом. Что же за ошибка в коде?

Ещё раз:

public static String humanReadableByteCount(long bytes, boolean si) {
    int unit = si ? 1000 : 1024;
    if (bytes < unit) return bytes + " B";
    int exp = (int) (Math.log(bytes) / Math.log(unit));
    String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp-1) + (si ? "" : "i");
    return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
}

Какие варианты?

После эксабайтов (1018) идут зеттабайты (1021). Может, действительно большое число выйдет за границы kMGTPE? Нет. Максимальное значение 263-1 ≈ 9,2 × 1018, поэтому никакое значение никогда не выйдет за пределы экзабайт.

Может, путаница между единицами СИ и двоичной системой? Нет. В первой версии ответа была путаница, но её исправили довольно быстро.

Может, exp в конечном итоге обнуляется, вызывая сбой charAt(exp-1)? Тоже нет. Первый if-оператор охватывает этот случай. Значение exp всегда будет не менее 1.

Может, какая-то странная ошибка округления в выдаче? Ну вот наконец…

Много девяток


Решение работает до тех пор, пока не приблизится к 1 МБ. Когда в качестве входных данных задано 999 999 байт, результат (в режиме СИ) — "1000,0 kB". Хотя 999 999 ближе к 1000 × 10001, чем к 999,9 × 10001, сигнификант 1000 запрещён спецификацией. Правильный результат — "1.0 MB".

В своё оправдание могу сказать, что на момент написания такая ошибка была во всех 22 опубликованных ответах, включая Apache Commons и библиотеки Android.

Как это исправить? Прежде всего, отметим, что показатель степени (exp) должен измениться с ‘k’ на ‘M’, как только число байт ближе к 1 × 1,0002 (1 МБ), чем к 999,9 × 10001 (999,9 k). Это происходит на 999 950. Точно так же следует переключиться с ‘M’ на ‘G’, когда мы проходим 999 950 000 и так далее.

Вычисляем этот порог и увеличиваем exp, если bytes больше:

if (bytes >= Math.pow(unit, exp) * (unit - 0.05))
    exp++;

С этим изменением код работает хорошо до тех пор, пока количество байт не приблизится к 1 ЭБ.

Ещё больше девяток


При расчёте 999 949 999 999 999 999 код выдаёт 1000.0 PB, а правильный результат 999.9 PB. Математически код точен, так что же здесь происходит?

Теперь мы столкнулись с ограничениями double.

Введение в арифметику с плавающей запятой


Согласно спецификации IEEE 754, у близких к нулю значений с плавающей запятой очень плотное представление, а у больших значений — очень разреженное. На самом деле, половина всех значений находится между -1 и 1, а когда речь идёт о больших числах, значение размером Long.MAX_VALUE ничего не значит. В прямом смысле.

double l1 = Double.MAX_VALUE;
double l2 = l1 - Long.MAX_VALUE;
System.err.println(l1 == l2);  // prints true

Подробнее см. «Биты значения с плавающей запятой».

Проблему представляют два вычисления:

  • Деление в аргументе String.format и
  • Порог для наращивания exp

Мы можем переключиться на BigDecimal, но это скучно. Кроме того, здесь тоже возникают проблемы, потому что в стандартном API нет логарифма для BigDecimal.

Уменьшение промежуточных значений


Для решения первой проблемы можем уменьшить значение bytes до нужного диапазона, где точность лучше, и соответственно настроить exp. Конечный результат в любом случае округляется, поэтому неважно, что мы выбрасываем наименее значимые разряды.

if (exp > 4) {
    bytes /= unit;
    exp--;
}

Настройка наименее значимых битов


Для решения второй проблемы нам важны наименее значимые биты (у 99994999...9 и 99995000...0 должны быть разные степени), поэтому придётся найти иное решение.

Сначала отметим, что существует 12 различных пороговых значений (по 6 для каждого режима), и только одно из них приводит к ошибке. Неправильный результат можно однозначно идентифицировать, потому что он заканчивается на D0016. Значит, можно исправить его напрямую.

long th = (long) (Math.pow(unit, exp) * (unit - 0.05));
if (exp < 6 && bytes >= th - ((th & 0xFFF) == 0xD00 ? 52 : 0))
    exp++;

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

Отрицательные значения на входе


Неясно, при каких обстоятельствах может иметь смысл отрицательное количество байт, но поскольку в Java нет беззнакового long, лучше обработать такой вариант. Прямо сейчас ввод вроде -10 000 выдаёт -10000 B.

Напишем absBytes:

long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes);

Выражение такое многословное, потому что -Long.MIN_VALUE == Long.MIN_VALUE. Теперь мы выполняем все вычисления exp, используя absBytes вместо bytes.

Окончательная версия


Вот окончательная версия кода, сокращённая и уплотнённая в духе оригинальной версии:

// From: https://programming.guide/the-worlds-most-copied-so-snippet.html
public static strictfp String humanReadableByteCount(long bytes, boolean si) {
    int unit = si ? 1000 : 1024;
    long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes);
    if (absBytes < unit) return bytes + " B";
    int exp = (int) (Math.log(absBytes) / Math.log(unit));
    long th = (long) (Math.pow(unit, exp) * (unit - 0.05));
    if (exp < 6 && absBytes >= th - ((th & 0xfff) == 0xd00 ? 52 : 0)) exp++;
    String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp - 1) + (si ? "" : "i");
    if (exp > 4) {
        bytes /= unit;
        exp -= 1;
    }
    return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
}

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

Для обновлённой версии продакшн-качества см. отдельную статью: «Форматирование размера байт в удобочитаемый формат».

Ключевые выводы


  • В ответах на Stack Overflow могут быть ошибки, даже если у них тысячи плюсиков.
  • Проверьте все граничные случаи, особенно в коде со Stack Overflow.
  • Арифметика с плавающей запятой сложна.
  • Обязательно указывайте правильную атрибуцию при копировании кода. Кто-то может вывести вас на чистую воду.
Support the author
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 78

    +26

    Оригинальный вариант кода, пусть и неправильный, был красив. А после всех перипетий получилось помóище.

      +8
      Не могу не спросить — вам шашечки или ехать?
        +16

        Мне кажется, этот комментарий на 100% можно развернуть в обратную сторону.
        Раньше код "ехал" — выполнял что должен выполнять в 99.9999999% случаев и если где-то проскакивало 1000КБ — то было это при выводе на экран и в общем никого не колыхало (ничего не могло сломать).
        Теперь это не только "ехать", но ещё и "шашечки", которые, как-бы, и не очень-то были нужны (для "ехать").

          +2

          Более того, всегда можно вернуться к циклу.

            +3
            Нельзя. Тут в дело вступают законы квантовой физики. Пока ошибка не найдена код можно использовать, как только ошибка найдена код не подлежит использованию.
            Вы же не будете пытаться играть с мертвым котом?
              0

              А если Вы биолог? Или некромант с наномашинами/испытатель экзоскелета...

            0

            Если знакомест было 3, а получили 4, то это могло ввести заблуждение 100 вместо 1000, например

              +2

              Там же в строку потом единица измерения приписывается. Скорее потеряется буква "б", чем нолик из середины строки.

                0

                Скорее уж, "1000." вместо "1000.0". Впрочем, учитывая, что возвращается строка вместе с единицей измерения, выше риск, что затрётся последняя буква. Или, что хуже, потеряется нулевой символ при использовании буфера фиксированного размера.

                  +1

                  Это ж Java, о каком нулевом символе речь?

            +7

            Красивый бажный код подобен помоищному бажному коду, только с красотой.


            Ну да, не хватает, например, кратких поясняющих комментариев, которые разобьют исправленный код на куда более легко воспринимаемые сегменты — и тем сделают его красивым. Но — он уже без бага, а исходная красота всё равно с оным.

              +19
              хуже. В этом коде захардкоджена борьба с протекшей абстракцией. И захаркоджено так, что если ты его не написал — не разберешься.
                +18

                Кстати, сам рассматриваемый в статье ответ на SO теперь тоже исправлен — и там вообще другая версия предложена, более грациозная:


                public static String humanReadableByteCountSI(long bytes) {
                    return bytes < 1000L ? bytes + " B"
                            : bytes < 999_950L ? String.format("%.1f kB", bytes / 1e3)
                            : (bytes /= 1000) < 999_950L ? String.format("%.1f MB", bytes / 1e3)
                            : (bytes /= 1000) < 999_950L ? String.format("%.1f GB", bytes / 1e3)
                            : (bytes /= 1000) < 999_950L ? String.format("%.1f TB", bytes / 1e3)
                            : (bytes /= 1000) < 999_950L ? String.format("%.1f PB", bytes / 1e3)
                            : String.format("%.1f EB", bytes / 1e6);
                }

                В статье же, таким образом, остался поучительный пример исправление красивого выглядящего правильным кода.

                  0

                  Самое смешное что с маттерн мачингом это выглядело бы куда более понятно, да еще и эффективно.

                    0

                    Главное чтобы long "вдруг" в 2 раза длиннее не стал :)

                    –4
                    А я искренне не понимаю чем цикл не устроил, там хоть и магнитуды автор рандомные указал, но исправить очень легко и работало бы без багов.
                    Оригинальный вариант с логарифмом ужасен, не настолько как в финале, но все же.
                    Предлагаю на собеседованиях если человек четко может дать определение логарифма — отсеивать, пусть математики вселенную изучают, а не код пишут.
                      +32
                      Предлагаю на собеседованиях если человек четко может дать определение логарифма — отсеивать, пусть математики вселенную изучают, а не код пишут.
                      А в биологи не брать тех, что знает число пи хотя бы до одного знака до запятой?
                      Неожиданное открытие биологов:
                      «В незапамятные времена участвовал в конкурсах работ МАН. Сам по математике, но однажды оказался зрителем на докладе в секции биологии. Работа была посвящена изумительному наблюдению, подкрепленному большим числом замеров: окружность любого муравейника примерно втрое длиннее его диаметра.»
                        +6
                        С иронией: замеряли-то небось в мирное время? :)
                          0

                          Вы про повреждения от попаданий снарядов и бомб?


                          Кстати, подобное исследование было бы действительно интересным — по какой именно математической формуле муравьи восстанавливают повреждённые муравейники — снова приводят их к круглому конусу, или же получается некая сглаженная пирамида с основанием в виде невыпуклого многоугольника?)

                            +3

                            Я думаю, имеется в виду бородатый анекдот:


                            В военное время число Пи может достигать четырёх.
                              0
                              Я помню этот анекдот, но вопрос поведения муравьёв после разрушения муравейника для меня более интересен оказался)
                          0

                          Справедливости ради, МАН — это школьная "академия". Для школьников такое "открытие" вполне простительно.

                        0
                        Да, тут сложно не согласиться.
                        На мой взгляд, достаточно было бы просто 10^n заменить на 2^n.
                          +7
                          Оригинальный вариант кода, пусть и неправильный, был красив. А после всех перипетий получилось помóище

                          Добро пожаловать в разработку библиотечного кода! Пишешь красивую реализацию чего-то, приходит 100500 человек, которые показывают тебе, что на вышедшем 100 лет назад железе, на Северном Полюсе, когда Луна в Водолее твой код не работает. И требуют исправлений. И ты исправляешь, потому что это же библиотека, должна работать везде.
                            –2
                            И что обидно, чаще такое оформляется не пулл реквестом, а исуей.
                            Так, что ребята аккуратнее с публикацией опенсорса. Люди по дефолту
                            считают, что Вы теперь обязаны пожизненно сопровождать свой код бесплатно.
                              +1

                              А как вы считаете, правильнее публиковать исправление очевидной и воспроизводимой (для тебя, на твоём железе) проблемы пулл-реквестом, или же иссуей + пулл-реквестом, фиксящим эту иссую и ссылающимся на эту иссую?


                              Я вот не так уж давно опубликовал 3 таких вот иссуи с фиксами в одну промышленную (!) библиотеку, но до сих пор ни один из пулл-реквестов не принят, а откомментирован разработчиками лишь одна из трёх иссуй, и ни один из реквестов.

                          +12
                          Я в этой статье увидел подтверждение своему отношения к коду с оверфлоу.
                          Вам дан только пример для идеального случая, который показывает суть как надо решать
                          задачу. И то, что его всегда надо допиливать тем, что автор вынес за скобки
                          для простоты понимания сути.

                          Не надо его в лоб копировать в свои проекты.
                            +5
                            А я в этой статье увидел подтверждение своему отношения к коду с оверфлоу.
                            Я бы сам написал код не лучше, чем первый вариант ответа, то есть тоже с багом. И уж точно хуже, чем текущий вариант, без ошибки. По сути использование кода со SO ничем не отличается использованием сторонних библиотек. Да, там могут быть ошибки, ну так они везде могут быть, даже в самом процессоре.
                            • UFO just landed and posted this here
                                +16

                                Осталось самая малость — правильный юнит-тест.
                                Со всеми кейсами типа 999 950 -> 1МБ и прочих 999 949 999 999 999 999.

                                  +6
                                  Не забудьте только взять unit-тест тоже со StackOverflow. Тогда точно-точно все будет работать. Всегда. Без вопросов. :)
                                  • UFO just landed and posted this here
                                      +1

                                      Ирония? Нет, не слышали.

                                      • UFO just landed and posted this here
                                          0

                                          Что "-3"?

                                +1
                                Интересная история
                                  –2
                                  я думал самый простой и эффективный способ это битовый сдвиг

                                      public static void main(String[] args) {
                                          int byteSize = 123456789;
                                          int mByteSize = byteSize >> 20;
                                          System.out.println(mByteSize); // 117МБ
                                      }
                                  

                                    +11
                                    Код не о делении на 2^20, а об определении той единицы измерения, при которой число станет удобно читаемым.
                                      0

                                      Однако так и считаем, тянем с собой последние значащие цифры и по последней определяем ""куда ближе", тут проблема скорее в варианте с десятичным представлением (кило с т.з. СИ), на java решить можно только преобразованием в цикле...

                                      • UFO just landed and posted this here
                                      +15
                                      Да, получилось реально помоище. Куча неявной математики и странных magic number'ов.
                                      Лучше бы кучу IF'ов написал.
                                        0

                                        В исходном исправленном комментарии SO именно куча троичных операторов устроена.

                                          –5
                                          Я видел, не слепой. И читаемость у них хуже, чем у IF'ов.
                                            +3
                                            В данном конкретном случае не хуже, а наоборот. Если раскорячить этот код в три раза, более понятным он не станет.
                                          0
                                          Так-то можно было перевести всё к интервалу 1-unit, а к логарифму поправочку прибавить (возможно, отрицательную — лень думать, простите) — получилось бы гораздо элегантнее, IMHO
                                            +6
                                            Вариант c циклом четкий, красивый, обозримый.
                                            Его корректность легко доказать.
                                            Я бы еще оттуда убрал вещественную арифметику, оставив только целые числа.
                                            И убрал выход за пределы массива при нуле байт :)
                                              +1
                                              StackOverflow уже больше десяти лет в обед, могли бы и пораньше сделать выводы о том, что «В ответах на Stack Overflow могут быть ошибки, даже если у них тысячи плюсиков.».
                                                –5
                                                … а в соседней теме пишут, что не только называть говнокод говнокодом, но и просто критиковать чужой код — является «токсичностью», противоречащей корпоративным нормам.
                                                  0

                                                  "Токсичность" — имхо, само определение этого слова противоречит изначальной сути Интернета. И очень многое в Интернете делается под эгидой борьбы с этой "токсичностью".
                                                  Пчёлы против мёда.

                                                  +11
                                                  :-O
                                                  Тут же всего лишь шесть шагов, зачем логарифмы считать?! Когда можно просто IF'ами сделать.
                                                  А если ещё и с середины сравнивать, то результат вообще за пару сравнений найти.
                                                    –2
                                                    В самом популярном фрагменте кода за всю историю StackOverflow ошибка! 

                                                    С удивлением узнал о таком коде. По тегу java вы легко найдёте гораздо более популярные вопросы и ответы. Похоже, автор имел в виду только свой популярный код.
                                                      +6
                                                      Популярность мерялась не плюсиками на SO, а появлениями этого фрагмента кода в коде проектов на Github.
                                                        –1
                                                        Т.е. автор статьи ни разу ни чем не померил, а утверждает, что это самый популярный фрагмент? Я выше писал, что в вопросах по Java гораздо больше плюсов, а это уже признак того, что код и в проектах на GitHub встретится чаще. Грубо говоря, исправление ошибок в memory allocate на языке C, сортировка и т.п. встретится в десятки раз чаще, чем некий мало кому нужный код по форматированию Мб.
                                                          0

                                                          В обсуждаемой заметке в разделе "Исследование по атрибуции" всё сказано — он увидел свой код на первом месте в исследовании, где был взят некий критерий популярности. Ссылки и картинка наличествуют.

                                                            +2
                                                            Т.е. автор статьи ни разу ни чем не померил, а утверждает, что это самый популярный фрагмент?

                                                            Тенденция «Я Пастернака не читал, но осуждаю», набирает обороты на хабре. Ведь буквально первое же предложение в статье содержит ссылку на исследование, где и пришли к выводу о популярности данного фрагмента кода.
                                                              –4
                                                              Вы можете говорить только за себя. Данный текст я читал и не заметил там указания, что данный фрагмент кода является самым популярным на GitHub. Я уверен, что это совершенно не так, скорее, это один из самых редких и мало кому нужных фрагментов кода из GitHub.
                                                                +2
                                                                Данный текст я читал

                                                                Прямо-таки купили за 35 евро? Я вот не покупал, всего лишь зашел в References исследования и увидел там ссылку на данный ответ на Stackoverflow. Единственный ответ с кодом со Stackoverflow во всех References, что как бы намекает, ведь исследование называется «Usage and attribution of Stack Overflow code snippets in GitHub projects».

                                                                не заметил там указания, что данный фрагмент кода является самым популярным на GitHub

                                                                Во-первых, вы все путаете. Все ещё. Не «самый популярный на Github», а «самый копируемый сниппет со Stackoverflow, встречающийся на Github». То есть у данного вопроса самая большая область пересечения этих двух плоскостей: «код с ответа на SO» и «фрагмент кода на Github». Он популярен в своем первозданном виде. На Stackoverflow есть множество популярных ответов, с которых не́чего копировать, потому что они, внезапно, не оформлены, как ready-to-use сниппеты.
                                                                Но для вас этот факт как будто личное оскорбление.
                                                                  –3
                                                                  Давайте рассуждать логически. Работа с файлами в репозиториях и вообще в среднем занимает примерно 1% кода, я думаю, даже меньше. При этом подсчёт размера файла нужен ещё примерно в 1% случаев от работы с файлами. Итого данный код нужен в исчезающе малом количестве случаев. Я вообще не припомню, чтобы он когда-то кем-то был использован или вообще упомянут. Этот код — пустышка, он фактически почти никому не нужен. Я убеждён, что это один из самых редких кусков кода, который вы только можете увидеть на GitHub. Никакого толкового исследования автор не мог провести, потому что у него нет таких инструментов. Он не может быть уверен, что код на GitHub взят с SO, а не наоборот, что этот код взят именно в таком виде, а не переделан. Фактически вся статья — полная профанация.
                                                                  На Stackoverflow есть множество популярных ответов, с которых не́чего копировать, потому что они, внезапно, не оформлены, как ready-to-use сниппеты.

                                                                  Это проблема тех, кто копирует код. Захотят — скопируют, захотят — напишут сами. Не вижу проблемы в том, что код не отформатирован.
                                                        0
                                                        Удивлен что этот код нейросеть не прикрутили =)
                                                          +6
                                                          Индивидуально конечно, но лично мне и первый вариант не кажется красивым и хорошим. Нагромождение конструкций, в котором сходу не поймёшь, как он себя ведёт в предельных случаях. Я бы предпочёл что-то вроде такого:

                                                          public static function humanReadableByteCount($bytes)
                                                          {
                                                              if ($bytes < 1024) {
                                                                  return $bytes .' b';
                                                              }
                                                          
                                                              if (($bytes /= 1024) < 1024) {
                                                                  return round($bytes, 2) . ' KB';
                                                              }
                                                          
                                                              if (($bytes /= 1024) < 1024) {
                                                                  return round($bytes, 2) . ' MB';
                                                              }
                                                          
                                                              if (($bytes /= 1024) < 1024) {
                                                                  return round($bytes, 2) . ' GB';
                                                              }
                                                          
                                                              return round($bytes/1024, 2) . ' TB';
                                                          }
                                                          


                                                          (просто иллюстрация, не обязательно соответствует всем стандартам)
                                                            0
                                                            <sarcasm>У вас код не соответствует идеологии структурного программирования!</sarcasm>
                                                              –1
                                                              В KB, MB, GB множитель 1000 а не 1024. Во всяком случае у НИХ. Хотя у нас на информатике детей по старинке учат, что в килобите 1024 бита :-(
                                                                +1
                                                                Не знаю где Вы взяли такое предубеждение. Каждый раз когда я пытался ввести стандартизацию на западном проекте (а один из них был конкурентом дропбокса) я получал дикую критику от западного менеджмента. Для конечного пользователя «к» — это 1024 и точка
                                                                  0
                                                                  Где я взял предубеждение что нужно соблюдать стандарт? Вы же сами пишете, что пробовали ввести стандарт и тут же называете стандарт предубеждением!
                                                                  Читаем Хабр habr.com/ru/post/193256
                                                                  Или на стандарт IEEE 1541/IEC 60027-2 можно не смотреть?
                                                                    0
                                                                    Предубеждением я назвал следующее предложение «Во всяком случае у НИХ». Я его читаю как «у НИХ КБ понимается как 1000 байт». Так вот — у них там считается что кб — это 1024.

                                                                    Я исключительно за стандарт. Именно поэтому я его пытался пропихнуть не смотря на полное непонимание со стороны команды и отрицание со стороны менеджмента. А потом и против своего же опыта. Ни разу не получилось. Менеджеры не хотят путать конечных пользователей.
                                                                  +1

                                                                  В предложенном мной варианте замена KB на KiB тривиальна.
                                                                  Как и вынесение делителя в переменную типа $divisor = isSi? 1000: 1024;

                                                                    –2

                                                                    Во всех операционных системах, во всём популярном софте в KB, MB, GB — множитель 1024 и никак иначе. Множитель 1000 стал использоваться там, где нет жёсткой привязки к степеням двойки. Ну и из соображений маркетинга.


                                                                    Да, опытные люди знают про существование приставок Ki, Mi, Gi, но вот в обиходе они практически не используются. Люди привыкли, что в отношении количества информации эти приставки обозначают множитель 1024.


                                                                    Кстати, вас не смущает использование фунтов, миль, баррелей? Эти единицы имеют разный размер в зависимости от контекста.


                                                                    Чтобы исправить ситуацию, нужно, чтобы

                                                                      0

                                                                      Эти килобайты по основанию 1000 пришли от производителей дисков (до этого гениального решения продавать 1000000 байт вместо 1024*1024 и началась эта история, до того(по крайней мере из того что я видео) никто ни о каких 1000^n и не задумывался…
                                                                      p.s. это как транСакции в финансах, когда гуманитарии добрались до ....

                                                                    +2
                                                                    Этот код еще не будет работать, если электричество отключили.
                                                                      +1

                                                                      Напомнило о баге, который я репортил в Гитлаб, когда на коммит, сделанный 14 декабря, 15 марта пишется "2 months ago". Тоже небось со StackOverflow взяли пример, где автор не учел несколько пограничных случаев…

                                                                        0

                                                                        Это классика, буквально недавно встретил серьёзный такой расчёт (финансовый) в котором количество месячных периодов считали делением на 30.5, ну ладно те кто в Экселе делал, они не it-ники, но это спокойно пролезли через весьма недешовых специалистов при переносе в пром...

                                                                        +3
                                                                        Ну и вишенка на торте: версия с циклом выполняется быстрее варианта с логарифмом, т.к. имеет асимптотику О(n), где n — количество цифр.

                                                                        en.wikipedia.org/wiki/Computational_complexity_of_mathematical_operations

                                                                          +1
                                                                          А не могли бы вы уточнить, как из утверждения об асимптотике сложности делается вывод о скорости в данном конкретном случае? Особенно, если вариант с логарифмом имеет сложность О(1)?
                                                                            0
                                                                            А разве логарифм вычисляется за О(1)?
                                                                              0

                                                                              Если под N понимать не разрядность числа, а количество возможных единиц измерения — то да.

                                                                            0

                                                                            Что выполняется быстрее показывают бенчмарки в конкретном окружении на конкретных данных, а не ассимптотика.

                                                                            –1
                                                                            Интересно, применение posit привело бы к необходимости перерабатывать алгоритм?
                                                                            habr.com/ru/post/467933

                                                                            Only users with full accounts can post comments. Log in, please.