Отличная статья! Ещё было бы неплохо рассказать, почему на мелкой воде угол расхождения кильватерной струи не зависит от скорости судна, что "мелкая вода" - это до 3 км, и как вообще ведут себя волны на поверхности. Ни Бернулли, ни Коанд здесь вообще ни при чём.
Я вот и есть такой математик, умеющий программировать. Составив алгоритм решения очередной задачи, я, конечно, могу этот алгоритм запрограммировать. Но в обязанности программиста входит не только написание программы, но и её дальнейшая поддержка, а вот этим заниматься не хочу. Если изменилась постановка задачи, то в алгоритм я изменения с удовольствием внесу, а в программу — не хочу. Поэтому математик может заменить программиста только в одноразовых программах: написал, запустил и выбросил.
В одной программе, над которой я работал, надо было сохранять данные в двоичном виде. А что такое двоичные данные? Это набор массивов каких-то типов. Каждый тип имеет какую-то длину в байтах, например, тип int – 4 байта. Я разделил каждый массив поразрядно. В результате простой RLE сжимает типичные данные вдвое, потому что старшие разряды у полей — в большинстве случаев либо 0, либо FF.
Если натравить на результирующий файл стандартный архиватор, то он сожмёт ещё вдвое.
Если же сохранять массивы не поразрядно, то стандартный архиватор, всё равно сжимает только в два раза.
Странно. Почему оптимизирующий компилятор не превратил код
bool bad()
{
if (rand() == 0) {
return true;
}
}
в
bool bad()
{
rand();
return true;
}
Функция rand() имеет побочный эффект, поэтому выбросить её вызов нельзя, а вот возврат true — это разрешённый стандартом вариант неопределённого поведения. И результирующий код короче, и известное возвращаемое значение позволяет дальнейшую оптимизацию.
Если автор хотел напомнить про медлительность случайного доступа к памяти при больших объёмах данных, то ему это удалось. Например, я постоянно об этом забываю.
Если же задача реальная, но одноразовая: «слить все файлы в один, удалить дубликаты и отправить результат в архив», то пусть стандартные процедуры хоть час работают, а автор в это время может Habr почитать.
Но если с полученным файлом ещё надо будет работать, например, статистику собрать, или если такую работу надо выполнять часто, то исходные данные изначально неверно хранятся. Можно предложить для каждого дата-центра завести отдельный двоичный файл (то есть, организовать бор первого уровня), а в каждом файле хранить отсортированные 32-битные IP-адреса.
Например, во всех клетках ресурсы постепенно исчезают, но имеются оазисы, освещаемые солнцем, которое прибавляет ресурсы. Могут быть реки, прибавляющие ресурсы, тогда жизнь будет концентрироваться около них. Но будет ли заселено всё поле?
Одни виды могут питаться другими… Возможности модели безграничны.
Может просто автора, что не может правильно разграничить public/protected/private вообще не пускать к компьютеру? Думаю, это будет лучшее решение.
Если я за каждую ошибку перестану пускать программиста к компьютеру, то очень скоро останусь без программистов.
Бывало, что программист неправильно разграничил правила доступа — объявил публичным только то, что требовалось внешним процедурам на тот момент, а остальное закрыл. Программист уволился, а мне для новой функциональности потребовалось вызвать вполне безопасный метод его класса (на С++). Проверяю, что вызов безвреден, и перевожу его в публичные. А как ещё?
Согласен с автором поста. Вызов приватного метода должен выдавать не ошибку компилятора, а только предупреждение. Если человек предупреждён, то вся ответственность за последствия переложена на него. Но это я говорю как плюсист. Нельзя запрещать мне выстрелить себе в ногу, если мне это очень надо. Сторонники безопасности могут иметь иное мнение.
А зачем? Ну, переиграли Вы его на собеседовании, потешили своё самолюбие, но потом ведь Вам придётся работать вместе с этим хамом. Замечу, что со стороны начальства уважение к новым сотрудникам обычно больше, чем к давно работающим (например, насчёт зарплаты и организации рабочего места легче торговаться), поэтому если Вам хамят прямо на собеседовании, то берите ноги в руки!
А я вот считаю, что термин «комментарии» давно устарел. В языках ассемблера, FORT или APL надо было комментировать каждую строчку, а в современных ЯВУ комментировать необходимо условия (зачем), константы (почему именно такая) и хакерские приёмчики.
Но код должен быть документирован. Самодокументрованный код подобен атомной бомбе: как атомная бомба всегда падает в свой эпицентр, так и самодокументрованный код всегда соответствует своей документации, какие бы опечатки не содержал. А кто умеет писать без опечаток? Особенно, копипастить.
Поэтому, документация к коду нужна. Можно держать её в отдельном текстовом файле, можно – прямо в тексте программы. Я совмещаю оба подхода. Пишу алгоритм в текстовом файле, после тщательной проверки копирую текст в Visual Studio, превращаю его в комментарии, а уже под комментариями расписываю код программы.
Да, с годами код изменяется. Комментарии около кода всегда правлю, чтобы код им соответствовал, а вот исходный текстовый файл описания часто остаётся без изменений, увы.
Благодаря этому подходу одна из моих разработок развивается (и продаётся) уже тридцать лет. Поменялось несколько компиляторов и ОС, только разрядность ОС менялась дважды. Если бы я не комментировал алгоритмы, то не смог бы так долго поддерживать программу в рабочем состоянии.
Конечно же, к программам — однодневкам всё вышесказанное не относится.
Посмотрим на список рёбер с точки зрения локальных интересов каждого узла. Он, конечно, «хотел бы» обладать двумя самыми короткими рёбрами из этого списка. Если при этом не возникает конфликтов, т.е. каждый из желаемых соседей также «предпочитает» иметь своим партнёром по туру именно этот узел — задача решена, оптимальный тур найден: длина тура совпадает с альфа-границей, список интересных рёбер пуст, дальнейший перебор не имеет смысла, улучшить оценку невозможно.
Это не так. Вместо одного большого тура может получиться набор маленьких циклов.
Даже неудобно напоминать: чтобы найти экстремумы гладкой функции одной переменной (в данном случае, R), надо продифференцировать функцию по этой переменной и приравнять производную нулю. Сразу получаем единственный максимум при R = r.
А при очень маленьких или очень больших R мощность, отдаваемая в нагрузку R, будет около нуля.
Извините, пожалуйста, если я зря влез в обсуждение, обнаружив забавный факт. Просто, мне стало любопытно, а какая именно функция максимизируется при Q = 1. Оказалось, что кинетическая энергия груза.
Выбран крайне неудачный ГПСЧ. Дело в том, что rand() возвращает число в диапазоне от 0 до RAND_MAX = 32767.
Отличная статья!
Ещё было бы неплохо рассказать, почему на мелкой воде угол расхождения кильватерной струи не зависит от скорости судна, что "мелкая вода" - это до 3 км, и как вообще ведут себя волны на поверхности.
Ни Бернулли, ни Коанд здесь вообще ни при чём.
Книга Юдковского определённо понравится математикам. Жаль только, что конец жестокий.
Пусть Id 8-байтный, а пользователей меньше 4 миллиардов.
Среди Id с нулевыми байтами 4-7 найти пару байт 2, 3, встречающуюся меньше 2^16 раз. Пусть это пара XY.
Среди Id с байтами 2-7, равными 0000XY, найти не встречающуюся пару байт 0, 1.
Два прохода по списку Id и 4*2^16 = 256 kB дополнительной памяти.
Если натравить на результирующий файл стандартный архиватор, то он сожмёт ещё вдвое.
Если же сохранять массивы не поразрядно, то стандартный архиватор, всё равно сжимает только в два раза.
for (auto v = std::vector{1, 2, 3}; auto& e : v),если можно
for (auto e : {1, 2, 3})?bool bad()
{
if (rand() == 0) {
return true;
}
}
в
bool bad()
{
rand();
return true;
}
Функция rand() имеет побочный эффект, поэтому выбросить её вызов нельзя, а вот возврат true — это разрешённый стандартом вариант неопределённого поведения. И результирующий код короче, и известное возвращаемое значение позволяет дальнейшую оптимизацию.
Если же задача реальная, но одноразовая: «слить все файлы в один, удалить дубликаты и отправить результат в архив», то пусть стандартные процедуры хоть час работают, а автор в это время может Habr почитать.
Но если с полученным файлом ещё надо будет работать, например, статистику собрать, или если такую работу надо выполнять часто, то исходные данные изначально неверно хранятся. Можно предложить для каждого дата-центра завести отдельный двоичный файл (то есть, организовать бор первого уровня), а в каждом файле хранить отсортированные 32-битные IP-адреса.
Одни виды могут питаться другими… Возможности модели безграничны.
Но код должен быть документирован. Самодокументрованный код подобен атомной бомбе: как атомная бомба всегда падает в свой эпицентр, так и самодокументрованный код всегда соответствует своей документации, какие бы опечатки не содержал. А кто умеет писать без опечаток? Особенно, копипастить.
Поэтому, документация к коду нужна. Можно держать её в отдельном текстовом файле, можно – прямо в тексте программы. Я совмещаю оба подхода. Пишу алгоритм в текстовом файле, после тщательной проверки копирую текст в Visual Studio, превращаю его в комментарии, а уже под комментариями расписываю код программы.
Да, с годами код изменяется. Комментарии около кода всегда правлю, чтобы код им соответствовал, а вот исходный текстовый файл описания часто остаётся без изменений, увы.
Благодаря этому подходу одна из моих разработок развивается (и продаётся) уже тридцать лет. Поменялось несколько компиляторов и ОС, только разрядность ОС менялась дважды. Если бы я не комментировал алгоритмы, то не смог бы так долго поддерживать программу в рабочем состоянии.
Конечно же, к программам — однодневкам всё вышесказанное не относится.
Это не так. Вместо одного большого тура может получиться набор маленьких циклов.
А при очень маленьких или очень больших R мощность, отдаваемая в нагрузку R, будет около нуля.
Извините, пожалуйста, если я зря влез в обсуждение, обнаружив забавный факт. Просто, мне стало любопытно, а какая именно функция максимизируется при Q = 1. Оказалось, что кинетическая энергия груза.