Как отличаются СДВГ люди от обычных людей? И зумеры — это СДВГшники или просто ленивые инфантилы?

Из личного опыта:

1. Музыка работает только без слов (инструментал), иначе отвлекаешься на попеть.

2. Достаточно часто при СДВГ кофе не приности проблем со сном, что позволяет пить его литрами и как-то справляться без отсутствия доступа к медикаментам.

Пишем плагины для Obsidian. Часть 1

Кстати, плагины, которые не опубликованы в community plugins, удобно качать через отдельный community plugin BART - он следит за гитхаб репозиториями и автоматически оповещает о новых версиях.

Как уменьшить использование памяти и ускорить работу кода на Python с помощью генераторов

Нет, это не так. При создании объекта внутри объекта никаких вычислений не производится, а впервые интерпретатор зайдет внутрь лишь при первом next. Именно поэтому требуется при создании корутин первым вызовом всегда делать next или send(None). И, соответственно, потому останавливается сразу ПОСЛЕ инструкции yield, а не до.

Этот ваш хаскель (не) только для факториалов и годен

Модуль array тоже, как и вообще основная реализация интерпретатора — CPython, так что тут вообще сложно говорить о том, что что-то можно написать на Python. :D

Еще немного более оптимизированных и исправленных реализаций:

Numpy

arr_v = np.zeros(shape=(n + 1), dtype=np.int64)

for k1 in range(1, int(math.floor(np.sqrt(n)) + 1)):
  x = np.arange(k1 + 1, (n // k1) + 1, dtype=np.int64)
  arr_v[x * k1] += k1 + x
  arr_v[k1 * k1] += k1

arr_v[0] = 0

Numpy + Numba (для тех, кто почему то на Python борется за миллисекунды)

@jit(int64[:](int64[:], int64[:], int64), nopython=True)
def internal(x_, arr_v_, k1_):
  arr_v_[x_ * k1_] += k1_ + x_
  return arr_v_

arr_v = np.zeros(shape=(n + 1), dtype=np.int64)

for k1 in range(1, int(math.floor(np.sqrt(n)) + 1)):
  x = np.arange(k1 + 1, (n // k1) + 1, dtype=np.int64)
  arr_v = internal(x, arr_v, k1)
  arr_v[k1 * k1] += k1

arr_v[0] = 0

Ноутбук с сравнением из предыдущего комментария обновил.

Этот ваш хаскель (не) только для факториалов и годен

Далеко не лучшим. Numpy шикарен своими векторными операциями и при их использовании (на моем процессоре) обгоняет данный код в 6 раз.
Реализация:

arr_v = np.zeros(shape=(n + 1), dtype=np.int64)
for k1 in range(1, math.floor(np.sqrt(n)) + 1):
    x = np.arange(k1, (n // k1) + 1, dtype=np.int64)
    indices_true = np.select([x != k1], [x]) * k1
    indices_false = np.select([x == k1], [x]) * k1
    
    arr_v[indices_true] += k1 + x
    arr_v[indices_false] += k1
    
arr_v[0] = 0

Пользуемся тем, что нулевой элемент массива будет == 0 и используем его как «отстойник» для лишней информации. Причем уверен, что данный код можно переписать еще оптимальнее.
timeit для обоих вариантов:
2.9 s ± 173 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) — первоначальный
469 ms ± 35.3 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) — Numpy

P.S. Кто нибудь может сравнить numpy с c++ на одном и том же оборудовании?

ноутбук: colab.research.google.com/drive/1e2A7OMm853gVN84mEIex7BLW7szyapLI

Разбор задачи с собеседования в Google: синонимичные запросы

Если уж пользоваться numpy, так там вообще просто есть rot90, который делает именно то, что нужно.
Более того, в numpy (во многих операциях, в документации заметно по «returns — view of m») используется именно идея с оберткой и отображением индексов, что позволяет не проводить фактически никаких операций с массивом на самом деле, но зато ухудшает работу кэша.
Итого, нам, на самом то деле, недостаточно данных: если из массива далее будут интенсивно последовательно читать данные, то лучше перенести на самом деле, иначе — можно воспользоваться отображением.

Как дата-центры меняются прямо сейчас: Энергоэффективность, хранение данных и «облака»

Здесь есть два аспекта:
1. Перенос сервиса в виртуальную среду позволяет очень гибко оперировать ресурсами для него: можно выделить ровно столько ресурсов, сколько необходимо, а не сколько встроено на сервере, позволяя на том же количестве железа уместить больше сервисов. А облака сейчас это в основном виртуализация.
2. Перенос сервисов в облака помогает опять таки сохранить ресурсы — один ЦОД гораздо энергоэффективнее и дешевле чем множество серверных аналогичной суммарной мощности. В ЦОДах используются более эффективные системы охлаждения, энергосбережения, банально обслуживание множества стоек за раз более экономично, нежели их разделение по разным местам.

Критичным местом здесь как раз становится доступность удаленных сервисов, задержки и ширина канала, но если их оптимизировать, то оно частенько стоит того.