Интересное что-то
517 subscribers
2.72K photos
253 videos
138 files
4.51K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
PEP765: больше никакой грязи в finally

Ссылка на PEP: https://peps.python.org/pep-0765
Одна из самых сломанных частей питона была пофикшена в 3.14

В чем проблема?

Ранее такой код вел себя крайне странно:


>>> def some():
... try:
... return 1
... finally:
... return 2

>>> some()
2


Так как из функции может быть только один return, а код в finally всегда выполняется – то получаем, что получаем.

Или такой код:


>>> def other():
... try:
... 1 / 0
... finally:
... return 2

>>> other()
2


Тут вообще жесть. У нас подавляется исключение без except 🫠
Аналогично можно делать не только с return, но и с break / continue в циклах:


>>> def cycle():
... for i in range(2):
... try:
... i / 0
... finally:
... print(i)
... continue
... return 2

>>> cycle()
# prints: 0
# prints: 1
# returns: 2


Такой код позволял создавать ошибки на ровном месте.

Как исправили?

Теперь такой код генерирует SyntaxWarning в 3.14:


>>> def some():
... try:
... return 1
... finally:
... return 2
<python-input-14>:5: SyntaxWarning: 'return' in a 'finally' block


Скоро – будет SyntaxError, в будущих версиях.
Но, WPS, например, запрещал такое делать уже очень давно.

Как работает?

Сам патч очень маленький и простой:

1. Добавляет список текущего контекста _Py_c_array_t cf_finally; в ast_opt.c

Храним внутри структуры вида:


typedef struct {
bool in_finally; // мы в `finally`?
bool in_funcdef; // мы в `def` или `async def`?
bool in_loop; // мы в `for`, `async for` или `while`?
} ControlFlowInFinallyContext;


2. При обходе дерева, добавляет нужные данные в текущий контекст: находимся ли мы в finally, функции, цикле
3. Если находим return, break или continue, то выполняем проверку синтаксиса; вот код для return:


static int
before_return(_PyASTOptimizeState *state, stmt_ty node_)
{
if (state->cf_finally_used > 0) {
ControlFlowInFinallyContext *ctx = get_cf_finally_top(state);
// если нашли `return` в `finally`, но не во вложенной функции,
// то показываем warning пользователю:
if (ctx->in_finally && ! ctx->in_funcdef) {
if (!control_flow_in_finally_warning("return", node_, state)) {
return 0;
}
}
}
return 1;
}


4. Внутри control_flow_in_finally_warning используем специальное АПИ для SyntaxWarning:


static int
control_flow_in_finally_warning(const char *kw, stmt_ty n, _PyASTOptimizeState *state)
{
PyObject *msg = PyUnicode_FromFormat("'%s' in a 'finally' block", kw);
if (msg == NULL) {
return 0;
}
int ret = _PyErr_EmitSyntaxWarning(msg, state->filename, n->lineno,
n->col_offset + 1, n->end_lineno,
n->end_col_offset + 1);
Py_DECREF(msg);
return ret < 0 ? 0 : 1;
}


Готово!

Обсуждение: вы знали про такую проблему? Стреляли так себе в ногу?

P.S. Пока писал пост, нашел багу в питоне и важную опечатку :)

| Поддержать | YouTube | GitHub | Чат |
новая работа про токенизацию - SuperBPE - наводит на меня мысли о том, что история развивается по спирали; своим студентам я на первой лекции рассказываю про словосочетания (Multi-Word Expression), которые можно выделять из текста статистически; а потом использовать, например, для лучшего представления в TF-IDF (придуман в 1970-е)

прошло 50 лет, наши представления о токенизации сильно изменились, особенно в 2015 году, с адаптацией алгоритма сжатия ZIP к токенизации (это, собственно, и есть BPE), и теперь мы вышли на новый круг, чтобы снова учитывать словосочетания в токенизации...
Forwarded from DLStories
С 2022 по 2023 годы я вела в МГУ курс по основам AI. У курса был формат, где на каждом занятии был один jupyter notebook с теорией и практикой, и мы по нему шли. Курс я уже не веду, но ноутбуки у меня остались, и мне нравится, как я их сделала. И у меня была мысль перевести их на английский, немного дополнить, причесать и выложить на GitHub как открытый курс "DL Intro". И я даже потихоньку начала это делать, вот репозиторий, там уже есть первые два урока (Intro to NN, PyTorch, Backprop).

Но вот недавно я думала о том, какой рисерч делать дальше после недавней статьи (статья кстати вот, чуть позже о ней тоже напишу), и мне стало интересно исследовать многообразия, которые составляют векторы-выходы разных слоев диффузионной модели. Я начала читать статьи и думать над тем, как вообще такое делают, и в итоге залезла куда-то в дифференциальную геометрию. И тут ко мне пришла очень гениальная мысль: а что если спросить у GPT объяснить мне то, что я не понимаю? Или спросить что-то типа "вот я хочу вот это понять про многообразие, могу ли я это сделать и как?"
Тут если вам кажется, что эта мысль ничерта не гениальна и все делают так каждый день, то я до этого момента GPT не использовала вообще. Ну, 3-4 раза за все время, может, и по каким-то совсем отвлеченным поводам. Чувстсвую себя бабкой, честное слово))

Так вот, на мои эти вопросы GPT выдала очень классные саммари и предложения, и для некоторых вещей даже код написала (и даже почти совсем правильный). И если веруться к разговору про курс: теперь я думаю о том, что, возможно, с помощью GPT можно довольно быстро собрать неплохой такой курс по чему угодно. Так-то объяснения по диффгеому GPT выдавала понятные и достаточно развернутые, а если чего-то не хватает, то можно попросить пояснить. И теперь думаю о том, насколько усилия по составлению курсов людьми из головы становятся оправданы)

Думаю, что этот курс я все-таки доделаю и выложу (снова, вот ссылка, буду рада звездочкам 🙃), все же ноутбуки у меня в основном готовы, нужно их только причесать. Но в то же время пойду понимать, на что способна GPT, у меня теперь есть подписка на GPT и Claude, буду их мучить. Все-таки преподавание — это значительная часть моей работы, которую я люблю и хочу развивать, и хочется понимать, как делать эту работу лучше и быстрее. И не делать того, что можно не делать. Правда, в создании курсов я перфекционист, мне редко нравятся чужие объяснения, и я очень долго продумываю свои. Но посмотрим, может, GPT справится и удивит меня еще больше) Пока думаю, что, как минимум, в качестве помощника в составлении общей структуры курса и поиска дополнительных материалов GPT точно должна быть полезна.
Please open Telegram to view this post
VIEW IN TELEGRAM
Intuitive physics understanding emerges from self-supervised pretraining on natural videos
Quentin Garrido, Nicolas Ballas, Mahmoud Assran, Adrien Bardes, Laurent Najman, Michael Rabbat, Emmanuel Dupoux, Yann LeCun
Статья: https://arxiv.org/abs/2502.11831
Код: https://github.com/facebookresearch/jepa-intuitive-physics

Развитие темы про JEPA, world models и выучивание интуитивной физики из видео.

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

Люди делали разные подходы к снаряду. Есть структурированные модели с вручную закодированными правилами про репрезентации разных объектов и их отношений. Есть пиксельные генеративные модели, занимающиеся реконструкцией будущих сенсорных входов по прошлым. Текущая работа исследует третий класс моделей, являющихся срединным путём между первыми двумя — собственно Лекуновскую JEPA, Joint Embedding Predictive Architectures (https://openreview.net/pdf?id=BZ5a1r-kVsf).

JEPA мы так и не разобрали, но в двух словах её идея в том, что предсказание надо делать не в пиксельном или ещё каком финальном пространстве, а в выученных внутренних абстрактных репрезентациях. В этом она близка к структурированным моделям. Но в отличие от них, ничего не кодируется, всё выучивается. В JEPA входные данные x (например, пиксели изображения) кодируются энкодером во внутреннюю репрезентацию Enc(x), далее предиктор делает предсказание репрезентации будущего входа y, возможно учитывая какую-то латентную переменную z, влияющую на предсказание (например, выбранное действие какого-то объекта в случае видео), и этот результат сравнивается с реальной репрезентацией следующего входа, Enc(y). Это, кстати, довольно сильно перекликается с другими моделями, например BYOL (https://t.me/gonzo_ML/562), там наличие отдельного предиктора тоже было очень важным для предотвращения коллапса. Энкодеры для x и y могут быть и разными. Преимущество в том, что не надо предсказывать каждую деталь выходного объекта y (с точностью до пикселя), ибо на этом уровне может быть очень много вариантов, разница между которыми не так важна.

JEPA не генеративная модель, она не может легко предсказывать y из x. У JEPA есть несколько развитий: Hierarchical JEPA (H-JEPA, тоже из оригинальной статьи), Image-based JEPA (I-JEPA, https://arxiv.org/abs/2301.08243), Video-JEPA (V-JEPA, https://arxiv.org/abs/2404.08471) и её свежий вариант Video JEPA with Variance-Covariance Regularization (VJ-VCR, https://arxiv.org/abs/2412.10925) — помните VICReg (https://t.me/gonzo_ML/590)?

В текущей работа исследуется V-JEPA, расширение модели на работу с видео и предсказание замаскированных частей кадров. В такой модели можно проверять выучивание интуитивной физики через фреймворк violation-of-expectation, получая меру несоответствия между предсказанием и реальным видео через измерение полученного “сюрприза”. Так же оценивают это и у живых существ (например, они дольше задерживают взгляд на неожиданных исходах).

V-JEPA точно так же как и обычная JEPA включает в себя энкодер и предиктор, оба нейросетевые. Энкодер строит репрезентацию видео, предиктор предсказывает репрезентацию искусственно замаскированной части видео.
Forwarded from This is Data
Прежде чем искать подвох в данных, стоит понимать работу собственного процессора. Когнитивные искажения — это систематические ошибки в восприятии и мышлении во время обработки информации. Они ведут к ложным суждениям, основывающимся на личных предпочтениях и эмоциях, а не на объективных данных.

Одним из искажений мозга называют предвзятость подтверждения (Confirmation bias). Это склонность замечать доказательства собственной точки зрения и игнорировать данные, которые ей противоречат.

Допустим, дата-аналитик берется за задачу определить, какой канал привлечения клиентов наиболее эффективен. Он считает, что это соцсети. Убеждение искажает изначальную гипотезу в голове аналитика. Неосознанно он ставит задачу доказать, что соцсети эффективнее других каналов.

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

Реальность многогранна. Мозг не в состоянии обработать всю информацию о мире. Чтобы не сойти с ума, он научился на основе кусочков данных формировать обобщающие убеждения. Они работают как фильтры, через которые информация попадает (или не попадает) в мозг на обработку. Предвзятость — не бага, а фича, экономящая время и энергию. Но то, что помогает выживать, мешает анализировать данные.

Чтобы быть менее предвзятым, попробуй:

1️⃣ Четко сформулировать вопрос бизнеса, гипотезу и цель сбора данных. Выработай привычки всегда допускать, что твои убеждения повлияли на результат.

2️⃣ Растождествить себя с точкой зрения. Задай себе вопросы: почему я так считаю? Основываюсь ли я на фактах?

3️⃣ Сыграть в игру: если бы я был не прав, какие факты могли указать на это? Ищи доказательства, опровергающие твое убеждение. Можно позвать коллегу-оппонента и выслушать его доводы.

#искажения
Forwarded from topdatalab (Roman Zykov)
Про AI автоматизацию в кодинге!
Моя задача проста — писать код меньше, а делать больше.

Что использую я:
1. Github Copilot Pro — очень удобно быстро что-то поправить.
Доступны разные модели, в том числе Sonnet 3.7.
2. CLINE + DeepSeek API — дешево, у меня даже получалось что-то сделать в полностью автоматическом режиме.
Потом DeepSeek стал очень популярным, и его API временно перестало работать.
Сейчас всё вернулось, но API работает медленно.
3. Мой бот дата инженера:
https://chatgpt.com/g/g-67dbef1047b48191951a514758f9ffc5-data-engineer-topdatalab

Думал про популярный Cursor, пока не прочитал сравнение:
👉 Сравнение Cursor vs CLine на Reddit

Кратко:
— Окно контекста больше у CLINE
— Нет API ограничений
— Но стоит дороже



Сейчас изучаю:
📘 Прокачка промптов в CLine

Хочу добиться ещё большей автоматизации в больших проектах! 🚀
Недавний пост про джоины набрал много просмотров и репостов. Значит такая информация интересна.
Продолжим наваливать базу 🤝

Популярные вопросы с собесов (lvl junior):

1) В какой последовательности БД на самом деле выполняет команды запроса:

select distinct
from
join
where
group by
having
order by
limit

Ответ:
Порядок выполнения SQL-запроса:
1. FROM (и JOIN) – выбираются таблицы и соединяются
2. WHERE – фильтруются строки
3. GROUP BY – группировка данных
4. HAVING – фильтрация групп
5. SELECT – выбор полей (включая вычисляемые)
6. DISTINCT – удаление дубликатов
7. ORDER BY – сортировка результатов
8. LIMIT / OFFSET – ограничение вывода

Более удобный вид:
FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT


2) UNION ALL vs UNION - в чем разница?


UNION ALL:
• Не удаляет дубликаты
• Работает быстро (простое объединение)
• Сохраняет исходный порядок строк
• Используется, когда важна скорость и нужны все данные

UNION
• Удаляет повторяющиеся строки
• Работает медленно - требует сортировки (ресурсозатратно)
• Может изменить порядок строк
• Используется, когда нужны уникальные записи


Также могут дать простую задачку:

Даны таблицы T1(col1, col2), T2(col1, col3).
Наполнение таблиц:

T1
(13, 15)
(13, 15)
(13, 15)

T2
(13, 15)
(13, 14)

Будет ли работать запрос? Если будет работать, то сколько строк вернет?

SELECT * FROM T1
UNION
SELECT * FROM T2


Ответ:
Будет работать если тип полей в таблицах одинаковый (но возможно некоторые СУБД итак могут сделать неявное преобразование).
Вернется 2 строки:
13 14
13 15

3) Отличие UPDATE TABLE от ALTER TABLE.

Немного странный вопрос, но в этом и прикол. Некоторые джуны на нем тупят 😄

UPDATE TABLE:

• Изменяет сами данные в таблице (строки)
• Пример: UPDATE users SET age = 30 WHERE id = 1;
• Тип операции - DML (Data Manipulation Language). Поэтому операции нужно COMMIT-ть или при необходимости можно откатить - ROLLBACK
• Блокирует строки (зависит от СУБД). *Про блокировки сделаю отдельный пост, тема непростая.

ALTER TABLE:
• Изменяет структуру таблицы (добавить/удалить/изменить поле, ограничение, партицию, переименование таблицы и тд.).
• Пример: ALTER TABLE users ADD COLUMN email VARCHAR(100);
• Тип операции - DDL (Data Definition Language). Авто COMMIT, откатить нельзя (но есть нюансы, зависит от СУБД)
• Может блокировать всю таблицу


Подскажите плз вам интересна эта тема? Предлагайте свои варианты почему можно навалить базы?


#Вопросы_с_собесов #база #sql #jun
Please open Telegram to view this post
VIEW IN TELEGRAM
Основные алгоритмы джойнов

Next level для тех, кто освоил типы джойнов, и теперь готов к оптимизации своих запросов 😎

Ниже приведены ключевые алгоритмы джойнов, используемые в реляционных СУБД и распределенных системах (Spark, Hadoop). Каждый из них решает определенные задачи в зависимости от объема данных, их структуры и инфраструктуры.

▫️Nested Loop Join - для каждой строки левой таблицы сканируется вся правая таблица (вложенные циклы).
— подходит для очень маленьких таблиц (до 1 тыс. строк)
— используется в SQLite, PostgreSQL для простых запросов
— простая реализация
— не требует сортировки или индексов
— сложность O(N*M) → неприменим для больших данных.

▫️Hash Join - состоит из двух фаз:
Build Phase: создается хеш-таблица для меньшей таблицы.
Probe Phase: большая таблица итерируется, и ключи ищутся в хеш-таблице.
— используется, если одна таблица помещается в память (справочники, малые датасеты), например в PostgreSQL для джойна пользователей и заказов.
— быстрый поиск за счет хешей → O(N + M).
— не требует сортировки.
— требует много памяти.
— неэффективен для skewed-ключей.

▫️Sort-Merge Join - сначала обе таблицы сортируются по ключу джойна. Далее происходит слияние отсортированных данных (как в алгоритме двух указателей).
— подходит для больших таблиц, которые нельзя броадкастить, и если данные уже отсортированы (например, партиционированы по дате).
— стабильная работа на больших данных.
— минимизирует использование памяти.
— дорогая сортировка → O(N log N + M log M)
— не подходит для skewed data.

▫️Broadcast Join (Map-Side Join) - маленькая таблица рассылается на все ноды кластера. Джойн выполняется локально на каждой ноде без Shuffle.
— используется, если маленькая таблица ≤ 10% памяти ноды (справочники, конфигурации), например для джойна логов и справочника стран на spark.
— нет Shuffle → экономия сети.
— максимальная скорость для маленьких таблиц.
— риск OOM, если таблица слишком большая.

▫️Shuffle Hash Join - обе таблицы перемешиваются (Shuffle) по ключу. На каждой ноде строится хеш-таблица для одной из таблиц.
— подходит для больших таблиц, когда одна из них после фильтрации помещается в память.
— быстрее Sort-Merge для средних данных.
— риск spill на диск при нехватке памяти.

▫️Bucket Join - данные предварительно разбиваются на бакеты по ключу, затем джоин выполняется между соответствующими бакетами. Подходит для частых джойнов по одному ключу (ETL-пайплайны).

▫️Skew Join - добавление случайного префикса (соли) к «тяжелым» ключам для распределения нагрузки. Далее происходит динамическое разбиение: дробление партиций с skewed-ключами. Подходит для данных с сильным перекосом (например, 80% записей по одному ключу).

▫️Grace Hash Join - комбинация Hash Join и внешней сортировки. Если хеш-таблица не влезает в память, данные разбиваются на партиции и обрабатываются по частям. Подходит для очень больших таблиц, которые не помещаются в память.

Как выбрать алгоритм?
1 — смотрим на размер данных:
Небольшая таблица → Broadcast Join
Большие таблицы → Sort-Merge или Shuffle Hash
2 — смотрим на структуру данных:
Отсортированы → Sort-Merge
Skewed-ключи → Skew Join
3 — инфраструктура:
Spark → используйте хинты (BROADCAST, MERGE).
Реляционная СУБД → опирайтесь на планировщик и индексы.

Запомнить:
— Nested Loop и Hash Join - база для СУБД.
— Broadcast и Sort-Merge - основа для распределенных систем.
— Всегда анализируйте план выполнения (explain в SQL, df.explain() в Spark) + метрики (память, сеть).
3 ресурса для освоения GIT с интерактивными заданиями

https://learngitbranching.js.org/?locale=ru_RU - Learn Git Branching
Интерактивный тренажер, позволяющий визуализировать и отрабатывать команды Git в режиме реального времени. Подходит как для новичков, так и для опытных пользователей. ​

https://git-school.github.io/visualizing-git/ - Visualizing Git
Веб-приложение, которое наглядно демонстрирует, как различные команды Git влияют на структуру коммитов, помогая лучше понять внутренние процессы системы контроля версий.

https://ohmygit.org/ - Открытая игра, обучающая Git с помощью визуализации внутренних структур репозиториев в реальном времени. Имеет интерфейс в виде игровых карт для запоминания команд и интегрированный терминал для выполнения произвольных команд Git.