Это очень хорошой case для оптимизации. Алгоритм крайне прост и его знают все. Но сколько можно сделать!

И снова к старой теме. В старой статье я сделал два предположения:

Гипотезы

Первая гипотеза касается окончания 'движухи' - в широком диапазоне изначальных плотностей p от 0.1 до 0.7, после окончания 'движухи' 'пепел' имеет одну и ту же плотность, около 0.27

Так как ружья накачают 'вселенную' глайдерами при сколь угодно малой изначальной плотности, и снова начнется 'движуха', то вторая гипотеза сильнее:

В пределе при любой плотности p (кроме вырожденных случаев p=0, p=1) получается 'пепел' плотности 0.027

На Julia, имея теперь огромные мощности, я решил проверить обе. Вас ждет красивое видео

В одной из своих прошлых статей по эволюции случайной конфигурации в игре жизнь я выдвинул гипотезу: Первая гипотеза касается окончания 'движухи' - в широком диапазоне изначальных плотностей p от 0.1 до 0.7, после окончания 'движухи' 'пепел' имеет одну и ту же плотность, около 0.27

Рассчитывая фрактал Римана, я был вынужден пересесть с Python на Julia из-за скорости, и не пожалел об этом. Однако теперь я мог на Julia быстро обрабатывать огромные конфигурации, например, 10k x 10k, и я решил повторить численные эксперименты на новом уровне. Как всегда, вас ждет и видео.

В своей последней статье я попытался создать фрактал, порожденный простыми числами. Но он меня не очень устроил эстетически. Поэтому я решил воспользоваться zeta функцией Римана для создания фракталов.

Будет много картинок и мало формул!

Фракталы, как правило, управляются довольно простыми правилами, порождая математическую красоту. Однако я не встречал способов построения фракталов, основанных на простоте чисел. Фрактал, который получился у меня, быть может не так красив, как фрактал Мандельброта, и не содержит явного самоподобия (self-similarity), но также имеет бесконечно сложную структуру.

Полезная программка ведь не обязана быть большой, правда? Пусть у нас есть процессы, для которых известны времена их начала и завершения. Таких в любой системе пруд пруди. Тот же ExecutionLogStorage в MS SQL Reporting Server, SQL server Profiler Trace, плюс куча кастомных метрик, которые есть у каждого.

Как выполняются эти процессы? Спокойно, один за другим, их хотят маршировать все в ногу? Какова средняя и максимальная степень параллелизма выполнения этих процессов? Хотелось бы получить что-то такое (процессы показаны черточками вверху):

В совсем раннем превью MS SQL мне вежливо отказали. И вот, наконец вышел публичный evaluation релиз! Давайте посмотрим, как MS SQL отнесется к самому неприятному - values with irregular selectivity. У меня про это даже была статья.

Эта статья не даст вам советов, ехать или не ехать. Принять решение вы должны сами, однако, я попытаюсь систематизировать аргументы ЗА и ПРОТИВ так как сам жил и работал за границей по 3 года дважды - в Америке и Франции.

После известных событий нас временно релоцировали в Индию (Hyderabad). Не всех, а часть, кто хотел, просто чтобы все яйца не находились в одной корзине (в Питере). Я не претендую на лавры трэвэл блоггера, а просто хочу рассказать о впечатлениях с точки зрения айтишника и современных реалий.

Это не первый мой визит в Индию, первый раз я был в Гоа в 2019 году, когда еще был теплый ламповый доковидный мир, потому я примерно представлял себе, что увижу. тем более, Индия у меня не вызывает отторжения - в Гоа я чувствовал себя уютно, как дома, как будто жил там в предыдущей инкарнации.

Это крик души. Речь пойдет не о usability в классическом понимании этого, а в легкости работы со средами для самого ITшника. Здесь все плохо, и, по моему, становится все хуже.

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

А в чем, собственно, проблема состоит? Теория Большого Взрыва - это не теория о Большом Взрыве, а о том, что было после него. Сам Большой Взрыв математически выглядит как математическая сингулярность, а это плохо - физики очень не любят бесконечности. Поэтому забота всех теорий о Большом Взрыве - от этих бесконечностей избавиться.

Когда мы говорим "время закончилось" или "время истекло", то имеем в виду окончание времени какого-то процесса. После этого процесса будут и другие, позже. Но может ли быть так, что "позже" не будет? Может ли закончиться само время?

Конечно, мы могли бы придумать игрушечную вселенную, где время бы было бы обрезано по какому-то моменту, например, 24 февраля. Однако, это математически не элегантно, более того, в специальной теории относительности нет единого момента времени - он зависит от наблюдателей. Обрубки непрерывных функций, сингулярности производных выглядят очень некрасиво и искусственно.

С другой стороны, по направлению в прошлое (Большой Взрыв) время обрывается, то есть было время, когда времени не было. Есть много космологических моделей Большого Взрыва, и все они стараются избавиться от сингулярности, сделать физические величины непрерывными. Об этом в отдельной статье.

Итак, если такое возможно в прошлом, то можем ли мы соорудить элегантный конец времен в будущем?

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

Но что, если мы будем прыгать не на одну клетку, а на очередную разницу между простыми числами - вначале 1 (3-2), потом 2 (5-3), снова 2 (7-5), потом 4 (11-7) итд. А вот направление мы будем 'вращать', например, для плоскости это будет вверх-вправо-вниз-влево? Сразу скажу, будет очень красиво.

Допустим, мы дождались, и физики с математиками достигли святого грааля - Теории Всего. Фанфары, нобелевские речи, единение гравитации и квантовой механики, но... Я утверждаю, что есть еще одна задача, столь сложная, что открытие TOE может показаться легкой разминкой. Более того, есть еще и вторая задача, куда сложнее первой.

Как известно, в военное время значение косинуса может достигать трех. К счастью, это не касается простоты чисел - как ни бейся лбом об стену, число 17 простое и ни на что не делится, кроме себя и 1.

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

Про время в физике известно многое, но один фундаментальный вопрос так и не раскрыт. Более того, прогресс в этой области почти нулевой. Что такое "сейчас"? Да, есть куча уравнений, где фигурирует буквочка t, символизирующая время, но нигде, нигде в физике нет ни намека на то, что момент времени "сейчас" какой-либо особенный.

Посмотрим, что нам говорят интуиция, философия и физика, и где они друг другу противоречат.

Развитие происходит по спирали: когда-то люди не умели правильно индексировать, потом (в основном) научились, потом пришли noSQL и все снова забыли знание древних. Что вы будете делать, когда последние из старых DBA отплывут в Валинор?

Снова и снова и сталкиваюсь с полным набором антипаттернов индексирования. Я их перечислю, но! Для каждого антипаттерна есть исключение, когда именно это и стоит делать. Поэтому кликбейтно сформулированное правило верно в 95% случаях, но если вы хотите копнуть глубже, то прочитайте про исключения.

И в конце полезные скрипты для MSSQL, Postgres и MySQL.

Когда я был маленький, я думал, что математика - это очень формальная наука. Как бы не так! Когда о нас, математиках, говорят как о сухарях — это ложь! (с) 17 мгновений весны.

Приглашаю вас в путешествие по 6 уровням вселенной математики - от полностью формального до философско-поэтического, и заодно мы ответим на вопрос, является ли теорема Геделя теоремой или мета-теоремой.

Если вы разбираетесь "почему тормозит база" и у вас есть трейс, созданный MS SQL profiler, то что вы делаете первым делом? Правильно, сохраняете его в таблицу, чтобы поразбираться с ним с помощью родного SQL, а не в GUI.

Очень хотелось бы сделать group by TextData, но увы - так не получится из-за разных параметров у процедур и кверей. А выразительных способностей SQL не хватет, чтобы эффективно 'нормализовать' трейс.

Но ведь можно скрестить ежа и ужа, SQL и Python, и решить задачу в несколько строк! Полезные скрипты ниже.

Лётчик водит самолёты -
Это очень хорошо.

Повар делает компоты -
Это тоже хорошо.

Доктор лечит нас от кори,
Есть учительница в школе.

Ну а ваш покорный слуга сам не знает чем он занимается и полезен ли он человечеству.