usual test set
https://x.com/openaidevs/status/1915097067023900883
cost $5.66

Science-T2I: Addressing Scientific Illusions in Image Synthesis https://arxiv.org/abs/2504.13129

Short remarks on shallow unitary circuits https://arxiv.org/abs/2504.14005

SycEval: Evaluating LLM Sycophancy https://arxiv.org/abs/2502.08177

CombiBench: Benchmarking LLM Capability for Combinatorial Mathematics https://moonshotai.github.io/CombiBench/

Quantum circuit lower bounds in the magic hierarchy https://arxiv.org/abs/2504.19966

The Leaderboard Illusion https://arxiv.org/abs/2504.20879

https://github.com/deepseek-ai/DeepSeek-Prover-V2/blob/main/DeepSeek_Prover_V2.pdf
via @seeallochnaya

Discrete time crystals detected by time-translation twist https://arxiv.org/abs/2504.21461

MathConstruct: Challenging LLM Reasoning with Constructive Proofs https://arxiv.org/abs/2502.10197

Wasserstein Policy Optimization https://arxiv.org/abs/2505.00663

TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks https://arxiv.org/abs/2412.14161

via @neuralshit

Bulk excitations in ultraclean α-RuCl3: Quantitative evidence for Majorana dispersions in a Kitaev quantum spin liquid https://arxiv.org/abs/2505.00971

Accents in latent spaces: How AI hears accent strength in English (Score: 150+ in 7 hours)

Link: https://readhacker.news/s/6u2rd
Comments: https://readhacker.news/c/6u2rd

SWE-rebench: A Continuously Evolving and Decontaminated Benchmark for Software Engineering LLMs

Сегодня стандартом для оценки SWE агентов является SWE-bench Verified. Его задумка очень понятная и как-то приближена к разработке чего-то большего, чем генерация кода: мы запускаем агента на настоящих задачках из GitHub, проверяем в конце прохождение отложенных тестов и смотрим на их результат. Но с SWE-bench Verified есть несколько проблем:

- Изначальный датасет был публично выложен в конце 2023 года. Последние модели может и неявно, но с очень высокой вероятностью захватили все эти данные в обучении, отчего рост чисел на бенче на какую-то часть связан с контаминацией. Да и без этого многие используют Verified как валидацию для экспериментов с агентом, неявно переобучаясь под него. По этой же причине в свое время появился LiveCodeBench для решения обычных задач для кодинга.
- Самые первые релизы на лидерборде хорошо описывали структуру агента и параметры запуска так, что было понятно, что вот это решение докинуло за счет перевода с gpt4o на sonnet-3.5, а вот это — просто промпты потюнили или тулы сделали лучше. Сейчас же лидерборд превратился в солянку, по которой просто непонятно, что происходит: best-of-N запуски, верификация доп тестами, MCTS, миллион разных скаффолдингов, уже даже непонятно, какая модель используется внутри, тк многие сабмиты на лидерборде — это закрытые решения компаний.

Мы попробовали закрыть часть этих пробелов и сегодня релизим SWE-rebench! Для борьбы с потенциальной контаминацией, мы будем регулярно обновлять лидерборд с замерами на свежих задачах. Скаффолдинг агента при этом везде фиксирован, чтобы запуски с разными моделями были сравнимы между собой. Так как наш пайплайн сбора данных позволяет автоматически контролировать сложность задач, то в будущем мы будем использовать это для борьбы с насыщением бенчмарка.

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

AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms https://deepmind.google/discover/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/

Size based vector

https://discourse.llvm.org/t/adding-a-size-based-vector-to-libc-s-unstable-abi/86306

Мы тут в Гугле экспериментировали с тем как репрезентовать вектор. Существует два способа:

1. Указатель на начало, конец и указатель на конец вместимости

2. Или указатель на начало, размер и вместимость

Оба варианта имеют свои особенности и слабые места. Первый вариант плох тем, что когда вы хотите посчитать size(), то вы вычитаете два указателя: end - begin. Вычитание указателей в численном представлении эквивалентно формуле (end_as_num - begin_as_num) / sizeof(T), где T -- тип вектора. Вот это деление на константу порой выбешивает, например, когда sizeof(T) не является степенью двойки. Компилятору приходится это деление переводить в умножение и теперь когда вы вызываете size(), то у вас откуда-то страшные конструкции вида https://godbolt.org/z/zKGz7nEE6

Но первый вариант неплох, когда вы итерируетесь и надо просто сравнивать с концом. Почему? Во втором варианте вам надо при вызове .end() загружать два регистра -- начало и размер, чтобы сложить. В итоге у вас баланс между двумя опциями

.size() выливается в умножение при sizeof(T) не степень двойки

.end() загружает два регистра

Остальные операции чуть чуть поменяются, но в основном размен происходит у этих двух.

Оказалось, что .end() чаще вызывается один раз, а .size() намного чаще в том числе и внутри циклов, потому что... Ну потому что программистам удобнее работать с числами, а не указателями. Или по каким-то ещё причинам.

В итоге мы увидели улучшение перфа всего прода на 0.12% с особенно важными серверами с исправлениями на 0.5-0.6%, о чем и поделились в discourse.llvm. Понятное дело, что кто-то слишком сильно пользовался репрезентацией вектора, но мы всех их починили и выкатили. Теперь хотим выкатить и в unstable ABI в libcxx.

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