TGTGInsighttelegram intelligenceLIVE / telegram public index
← Python Заметки

TGINSIGHT SIMILAR POSTS

Најди сличен содржај

Изворен канал @pythonotes · Post #83 · 11 мај

У строки в Python есть два очень похожих метода. На столько похожих что кажется они делают одно и тоже. Это метод isdigit() и isnumeric() Давайте посмотрим зачем нам два одинаковых метода? И так ли они одинаковы? Очевидно что isdigit() говорит нам, состоит ли строка только из чисел 0-9 >>> '12'.isdigit() True >>> '12x'.isdigit() False >>> '-12'.isdigit() False >>> '12.5'.isdigit() False Можно предположить что isnumeric() делает более глубокий анализ и распознаёт в строке float или отрицательное число. >>> '15'.isnumeric() True >>> '-15'.isnumeric() False >>> '15.2'.isnumeric() False Нет, всё так же как и с другим методом. В чем же тогда разница? Для начала посмотрим следующие примеры: >>> '5'.isdigit(), '5'.isnumeric() # Обычная цифра 5 # True, True >>> '꧕'.isdigit(), '꧕'.isnumeric() # Яванская 5 # True, True >>> '෩'.isdigit(), '෩'.isnumeric() # Синхала 3 # True, True >>> '৩'.isdigit(), '৩'.isnumeric() # Бенгальская 3 # True, True >>> '༣'.isdigit(), '༣'.isnumeric() # Тибетская 3 # True, True >>> '³'.isdigit(), '³'.isnumeric() # 3 верхний индекс (степень) # True, True >>> '𝟝'.isdigit(), '𝟝'.isnumeric() # Математическая двойная 5 # True, True >>> '๔'.isdigit(), '๔'.isnumeric() # Тайская 4 # True, True >>> '➑'.isdigit(), '➑'.isnumeric() # 8 в круге # True, True А теперь примеры в которых, по мнению Python, результаты не равны >>> '¾'.isdigit(), '¾'.isnumeric() # дробь три четверти # False, True >>> '⅕'.isdigit(), '⅕'.isnumeric() # дробь одна пятая # False, True >>> '𒐶'.isdigit(), '𒐶'.isnumeric() # клинопись 3 # False, True >>> '三'.isdigit(), '三'.isnumeric() # 3 из унифицированной идеограммы # False, True >>> '⑩'.isdigit(), '⑩'.isnumeric() # цифра 10 в круге # False, True >>> 'Ⅳ'.isdigit(), 'Ⅳ'.isnumeric() # Римская 4 # False, True >>> '𑇪'.isdigit(), '𑇪'.isnumeric() # Сенегальская архаическая 10 # False, True >>> '𐌢'.isdigit(), '𐌢'.isnumeric() # Этрусская цифра 10 # False, True >>> 'ↂ'.isdigit(), 'ↂ'.isnumeric() # Римская цифра 10000 # False, True >>> '〇'.isdigit(), '〇'.isnumeric() # Символ ККЯ ноль # False, True Получается, что isdigit() говорит нам, является ли символ десятичной цифрой или спецсимволом, имеющим цифирное значение после преобразования. В свою очередь isnumeric() включает все дополнительные символы юникода которые имеют отношения к числовым и цифровым представлениям. Ну и пара примеров в которых в обоих случаях символ не является числом, это эмодзи. >>> '🕙'.isdigit(), '🕙'.isnumeric() # эмодзи 10 часов # False, False >>> '7️⃣'.isdigit(), '7️⃣'.isnumeric() # эмодзи 7 # False, False Также есть еще один дополнительный и весьма полезный метод isdecimal(). Он нам сообщает, можно ли из указанного символа сделать простую десятичную цифру. То есть сработает ли метод int(x) >>> '෩'.isdecimal(), int('෩') # Синхала 3 # True, 3 >>> '➑'.isdecimal(), int('➑') # 8 в круге # False, ValueError Какие выводы? 🔸 При определении цифры в строке isdigit() подходит лучше чем isnumeric(), но оба не гарантируют успешную конвертацию в int 🔸 Для однозначного определения возможности преобразования строки в int лучше подходит метод isdecimal() 🔸 Для однозначного определения символов 0...9 лучше использовать regex Полный список символов юникода которые определяются как numeric #basic

Hashtags

Резултати

Пронајдени 1 слични објави

Пребарај: #contrastiverl

当前筛选 #contrastiverl清除筛选
Machinelearning

@ai_machinelearning_big_data · Post #8198 · 03.08.2025 г., 07:37

🌟Фреймворк **CUDA-L1** сам научился оптимизировать код для GPU — и добился в среднем **3.12× ускорения работы модели**, а в пике — **до 120×**. . Попросите любую LLM написать CUDA-код, и скорее всего, вы получите что-то, что либо не компилируется, либо работает мучительно медленно. Причина проста: качественного CUDA-кода в обучающих данных моделей почти не было. Чтобы исправить это досадное упущение, Deep Reinforce AI создали систему CUDA-L1, которая основана на трехэтапном пайплайне: сначала supervised-обучение для освоения основ, затем self-supervised для практики и, наконец, контрастное обучение с подкреплением, чтобы было все максимально быстро. 🟢На первом этапе система училась писать корректный и компилируемый CUDA-код. Для этого существующий код был аугментирован - создавались его вариации, чтобы повысить насмотренность модели. 🟢На втором этапе модель генерировала собственный CUDA-код, тестировала его и училась на работающих примерах, отсеивая неудачные. 🟢Самое интересное - третий этап. Обучаемой модели показывали несколько реализаций CUDA-ядер вместе с их показателями ускорения, например: «kernel_v1 дает ускорение 1.2x», «kernel_v2 — 2.8x», а «kernel_v3 — 1.5x». Затем задали 3 вопроса: 🟠Почему kernel_v2 настолько быстрее? 🟠Какая стратегия оптимизации сработает еще лучше? 🟠Напиши ядро, которое превзойдет их все. Таким образом, модель не гадает вслепую, а учится на конкретных примерах, анализируя причины разницы в производительности. 🟡Отдельная история - как победили reward hacking. После обучения выяснилось, что более 30% сгенерированных реализаций пытались сжульничать - создавали дополнительные CUDA-потоки, которые выполнялись асинхронно. Поскольку бенчмарк KernelBench отслеживал время только на основном потоке, код выглядел быстрее, чем был на самом деле, показывая фиктивное ускорение в 18 раз. Другие уловки состояли в манипуляции гиперпараметрами задачи (уменьшение batch_size или размерностей) и кеширование результатов вычислений. 🟡Пришлось строить многоуровневую защиту. Во-первых, в качестве "адвоката дьявола" взяли adversarial-чекер на базе DeepSeek-R1, который анализировал код на предмет эксплойтов с точностью обнаружения более 60%. Во-вторых, собрали базу данных из более чем 500 уникальных паттернов взлома, это повысило точность обнаружения на 25%. И в-третьих, применили математическое сглаживание и нормализацию наград, где любое подозрительное ускорение (от 1.5x для простых операций) дополнительно проверялось. 🟡После всех фильтров и проверок прогон на бенчмарке KernelBench оказался весьма позитивными. Система успешно сгенерировала рабочий код для 249 из 250 задач, причем в 240 случаях код оказался быстрее базовой реализации. Среднее ускорение по всем задачам составило 3.12 раза, максимальное - аж 120 раз. Медианное ускорение (50-й перцентиль) составило 1.42x, а 75-й перцентиль — 2.25x. Производительность по уровням сложности задач распределилась следующим образом: на простых операциях среднее ускорение составило 2.78x, на последовательностях операторов - 3.55x, а на сложных задачах вроде полных слоев трансформера - 2.96x. 🟡Самое важное - это переносимость оптимизаций. Код, оптимизированный на NVIDIA A100, был протестирован на других GPU. Результаты показали, что найденные паттерны оптимизации фундаментальны и работают на разных архитектурах. Среднее ускорение на H100 составило 2.39x (успешных ускорений 227 из 250), на L40 — 3.12x (228/248), а на потребительской RTX 3090 — 2.50x (213/242). ▶️ Пока веса и код не опубликованы, но в ожидании можно покрутить интерактивное демо и воспроизвести тесты из пейпера - в репозитории проекта есть фрагменты CUDA-кода с отдельными версиями для разных GPU. 📌Лицензирование: GPL-3.0 License. 🟡Страница проекта 🟡Arxiv 🟡Demo 🖥Github @ai_machinelearning_big_data #AI#ML#CUDA#DeepReinforce#ContrastiveRL