#robots #sex

https://3dnews.ru/1082775/tesla-prodemonstrirovala-novie-vozmognosti-chelovekopodobnih-robotov-optimus

#chess

Гата Камский бы не поверил )

https://www.youtube.com/watch?v=VQfgclxxQyY&ab_channel=LevitovChess

#timeseriesforecasting #competition #electricityprice

Угадайте, чья модель из 4 дата-сайентистов пока что лучше предсказывает цену на электричество в Техасе на сл 24 часа? )

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

Кстати, про IDE - утащу из одного чатика инсайд от сотрудника Jetbrains:
> В JB было сделано внутреннее исследование, сколько кодят разработчики - и выяснилось, что почти по всем языкам это порядка 10 строк кода в день в среднем; потом это исследование решили не публиковать.

(Не знаю, насколько этому исследованию можно доверять, но сойдет как иллюстрация того, что не кодом единым).

Когда именно с этим парадоксом сталкивается конкретный IC, зависит от окружения. Эвристика простая: чем более ты сеньорный относительно прочих в своей команде/организации, тем меньше кода нужно писать. И потому на каком-то этапе карьеры надо либо осознанно перековываться в человеки-которые-[почти]-не-пишут-код, либо целенаправленно идти в такой орг, где личная максимальная полезность оказывается именно в написании кода, обычно это какие-то сложные специфические системы, и такого в индустрии маловато.

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

Data science в футболе

Наткнулся на интересный подкаст про использованию ds в футболе

https://www.youtube.com/watch?v=MsuLggu3hu4

#ссылки

#books #fantasy #zhelazny #donnerjack #tanatos

"Он обитал в Непостижимых Полях, но присутствие его простиралось и за их пределы, проникая в самые дальние уголки Вирту. И являлся он, в некотором смысле. Властелином Всего Сущего, хотя у других также имелись основания претендовать на сей титул. Впрочем, его права были ничуть не менее прочными и обоснованными, чем у остальных, поскольку никто не мог отрицать факта существования его владений.

Он двигался среди обломков разбитых фигур - в прошлом обитателей Вирту. Те приходили сюда, подчиняясь его призыву или по собственной воле, когда конец их существования становился неопровержимым фактом. Порой он использовал определенные части для своих целей, но многие оставались лежать, пока не сровняются с землей; впрочем, некоторые их компоненты сохранялись достаточно долго. И когда он шагал мимо, обломки поднимались - в человеческом обличье или каком-нибудь ином, - чтобы пройти несколько шагов,произнести какие-то слова, сделать характерный жест, а затем вновь превратиться в мусор и пыль. Порой - как сейчас - он шевелил груды хлама посохом и смотрел, что будет. Если ему удавалось натолкнуться на какой-нибудь фокус или обрывочную информацию, ключ или код, имеющие некий интерес, он забирал их в свою обитель-лабиринт. Он мог превратиться в мужчину или женщину, отправиться в любое место, но неизменно предпочитал черный плащ с капюшоном, скрывающий поразительно хрупкую фигуру - мельтешение белого в мрачных тенях.

Обычно в Непостижимых Полях царило величественное молчание. Иногда возникали диковинные, невнятные звуки, исходившие словно из самых глубин огромных куч мусора - стоны энтропии; а когда они затихали, тишина становилась еще глубже. Чаще всего он покидал свои владения, чтобы услышать что-нибудь осмысленное - музыку, например. Вселенная не знала подобного существа. Ему давали тысячи имен и прозвищ, однако самым распространенным стало Танатос."

http://lib.ru/ZELQZNY/donnerdzhek.txt

#ml #interpretability #shap #facet

Новая интересная идея над SHAP. Как известно, каждая фича в рамках SHAP по каждому примеру получает некоторое значение, сдвигающее прогноз от среднего. А почему бы не рассмотреть фичу как вещественный вектор этих значений по всем примерам? Тогда у нас появляется возможность делать матоперации над векторами/фичами: считать углы, к примеру, тем самым выявляя фичи синергичные, ортогональные, и избыточны. Это красиво реализовано в библе Facet (pip install gamma-facet). Мне только кажется, они упустили, что переобучение модельки даст уже другие SHAP VALUES (особенно при мультиколлинеарности), и нельзя закладываться на единственный fit.

Показан реальный пример из строительной индустрии с CV и HPT. Очень интересны и красивы их симуляционные графики.

https://www.youtube.com/watch?v=fTQhfxZxavQ&ab_channel=PyData

https://3dnews.ru/1082821/mozgovie-implanti-ilona-maska-neuralink-zapretili-testirovat-na-lyudyah

#neuralink

"Объясняя своё решение, FDA обозначило десятки проблем, которые компания должна решить перед тестированием на людях, что является важной вехой на пути к созданию конечного продукта. Одна из важнейших претензий FDA — возможность того, что крошечные электроды могут мигрировать в другие области мозга. Такие провода могут вызывать воспаление, нарушать функцию в критических областях мозга и разрывать кровеносные сосуды, что может привести даже к смерти.

Также не лишены оснований опасения FDA по поводу системы дистанционной зарядки литиевых батарей импланта — при перегреве и выходе батареи из строя может быть повреждён мозг. Само устройство в процессе работы тоже может перегреться, что приведёт к поражению тканей мозга. FDA также подняло вопрос о том, будет ли возможность удалить устройство, не повредив мозг.

Neuralink занялась исправлением проблем, обозначенных FDA. Однако имеются серьёзные сомнения, что компания сможет быстро их решить, и осуществить обещание Маска начать испытания на людях весной. По статистике FDA, агентство одобряет в среднем только 66 % заявок испытаний на людях с первой попытки, после повторной заявки количество одобрений достигает 85 %. Компании, получившие разрешение на тестирование на людях, обычно предварительно проводят не менее двух раундов испытаний, прежде чем подавать заявку на одобрение FDA. Но такая неторопливость не устраивает Маска.

«Я мог бы имплантировать устройство Neuralink прямо сейчас, и вы бы даже не узнали», — уверен Илон. Недавно он заявил, что настолько уверен в безопасности устройств, что готов имплантировать их своим детям. Он также обещал, что Neuralink восстановит полную подвижность парализованным пациентам."

#забавно
Есть такая старая картинка с колодой карт, на которой изображены математики. Интересно, что есть и другие подобные колоды в интернете, довольно качественно оформленные.

#series #yourhonor #weekendmovie

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

https://www.youtube.com/watch?v=oYqjcyRkqD4&ab_channel=Amediateka

#ml #python #antipatterns

Я впервые вижу технически валидный, но НАСТОЛЬКО бездарный ML-код. Писавший не понимает совершенно, что делается, зачем, почему так, что такое fp64 vs fp32, feature engineering, early stopping, pipeline, cv, baseline, timeseries, transformed target. Не понимает даже языковых конструкций.

При этом, что удивительно, его код компилируется и набирает лайки. И типа проблема решается. Датасайентист, чо уж там. Вроде модельку зафиттил, графички нарисовал, выводы хорошие сделал, а в башке - пустота. Это, безусловно, жемчужина. Рекомендуется к изучению и разбору, как не надо делать. Меня удивляет, где они подобное копипастят, везде же говорится, что это антипаттерны и так делать не надо. Они как-то сами до этого доходят, избирательно читая доку?

P.S. Стало немного понятнее. Это оказалось "копипастой копипасты". Но всё равно, как мог оригинальный автор так накривить?

https://www.kaggle.com/code/rodsaldanha/stock-prediction-pytorch/notebook

Я думал, что повидал уже многое. Но этот шедевр говнокодинга "превосходит ожидания".

#games #saturnalia

"События Saturnalia развернутся в вымышленной итальянской деревне Гравой, после проведения древнего ритуала оставшейся почти без жителей. Игрокам предстоит выяснить тайну случившегося, решая головоломки и избегая монстров.

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

https://youtu.be/v1qGfWjlv8s

Робопсы Boston Dynamics приняли участие в модном показе Coperni в Париже

#robotics #BostonDynamics

"Когда в зале погас свет, в полумраке начали мигать зелёные глаза робопсов. Затем появились модели, которые демонстрировали новую коллекцию одежды, но, вероятно, внимание зрителей было приковано именно к роботам. Во время показа один из робопсов, оснащённый механическим манипулятором, взял из рук модели сумочку и помог ей донести её. Другой робот некоторое время как бы рассматривал модель, после чего помог ей снять пиджак.

По словам дизайнеров Coperni, концепция показа стала своеобразным переосмыслением произведения французского баснописца Жана де Лафонтена «Волк и ягнёнок», которое превратилось в представление об отношениях человека и робота. «Наш позитивный посыл заключается в том, что люди и технологии могут жить вместе в гармонии», — сказал представитель Coperni, отметив, что при первой встрече с роботом Spot ему было не по себе."

https://youtu.be/X67IwvYXHLU

Введение в logging на Python

Мы описывали концептуальные варианты поиска проблемы в коде, давали небольшой пример логирования и писали о разухабистом логировании.

Пора немного углубиться в детали логирования. Разберём модуль logging из стандартной библиотеки питона. В статье автор даёт пример лога своего проекта, подробно описывает сущность logger, после чего
– описывает уровни логирования debug-info-warning-error-critical, не забывает о методе exception, который работает как error плюс выводит информацию об исключении

– объясняет, что такое handler и разбирает некоторые варианты использования. К logger можно привязать несколько обработчиков, чтобы одновременно писать в несколько локаций. На наш взгляд, сейчас эта настройка потеряла актуальность – писать надо в стандартные потоки упакованного в докер приложения, а дальше собирать логи снаружи

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

– применяет Filter, чтобы перестать писать часть сообщений, или, наоборот, писать только определённые сообщения в лог. Бывает удобно, но на текущий момент чаще это решается снаружи путём поиска по логам

– применяет LoggerAdapter для внедрения дополнительной информации в лог-сообщение

– применяет extra для логирования сущностей или их частей, например, включения в лог текста запроса веб-сервера

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

– напоминает о наследовании логера, что позволяет упростить настройку логирования в модулях, указывая только индивидуальные настройки – общая часть будет взята из класса-родителя

В конце автор на примере бота для телеграм разбирает вариант конфигурирования логера. По каждому вопросу есть ссылка на офф документацию питона.

#python

Очереди – что сложного то?

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

Подождите, очередь – это когда с одной с стороны положили, а с другой стороны кто-то забрал? Почти, но всё немного сложнее. Особенно в распределённых системах, особенно когда сообщений десятки тысяч в секунду.

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

Начинается всё с базовых понятий, какие вообще бывают способы организации очередей: put/take, pub/sub, request/response.

Для применения очередей существует множество инструментов.
– Apache Kafka реплицируемый шардируемый лог сообщений для стриминга. Мы кафку очень любим, и о ней были отдельные посты (раз, два)
– RabbitMQ – традиционный pub/sub broker. В отличие от Kafka, у кролика нет ограничений на количество потребителей. Кролик часто используется как шина данных между сервисами
– NATS обеспечивает быстрый неперсистентный обмен сообщениями, высокую производительность и масштабируемость
– Tarantool – это in-memory db, которая может быть использована для организации очередей. Примечателен тем, что можно написать свою очередь на стероидах, со своим процессингом, логикой и приоритетами

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

Напишите в комментариях, какие системы очередей вы знаете или используете на практике. За что их любите или не любите?

Говоря о проблемах – они у очередей есть.
– на уровне алгоритма важно решить, что делать при отказе консьюмера, который уже взял сообщение. Best Effort – просто вернуть сообщение обратно. Но не во всех брокерах так можно. В таком случае можно настроить dead letter queue – отдельную очередь со своей логикой обработки таких сообщений.
– а ещё бывают проблемы приоритизации, когда из-за множества задач с высоким приоритетом консьюмер может никогда не добраться до задач с низким.
– на сетевом уровне существует undefined behavior, то есть сообщение отправлено, но мы не знаем, оно дошло и получено или потерялось
– помимо сети есть диск, который влияет на пропускную способность и задержку в обработке, которая может оказаться не предсказуемой

Чтобы обеспечить доступность (avalability) и надёжность (durability) применяются разные топологии:
– single instance – самый простой вариант. Один брокер, одна очередь, продюсер и консьюмер. Немасштабируемо, низкая доступность и надежность.
– multi instance – можно масштабировать и ставить столько очередей сколько нужно. С надежностью и доступностью получше, но если одна из очередей грохнется, то данные из нее потеряются.
– идём дальше и дублируем уже сами очереди
– автор не останавливается на этом и рассказывает о реплицировании, реплика-сетах, кворумах, кворумных очередях.

Познакомившись с различными сложностями понимаешь, что хорошо бы всё это мониторить. Существуют следующие метрики: размер очереди, время обработки сообщения, количество потерь и отказов.

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

Напоследок ценная мысель: если вы не знаете, как ваша система падает и поднимается, быстро вы её не поднимите.

#skills

#biglanguagemodels

"Хотя Google и Microsoft активно соперничают, пытаясь доказать превосходство своих чат-ботов, технология «человекоподобных» ИИ-инструментов — не единственная сфера применения машинного обучения и языковых моделей.

Наряду со слухами о планах представить более 20 инструментов на базе алгоритмов ИИ в ходе конференции I/O этого года, Google продолжает работать над языковой моделью, поддерживающей 1000 языков. В понедельник компания поделилась новой информацией о своей универсальной речевой модели, которую в Google описывают как «критический первый шаг» в реализации своих планов на этом поприще.

Ещё в прошлом ноябре компания анонсировала планы создания языковой модели, поддерживающей 1000 наиболее распространённых языков, рассказав об USM. Google описывает её как «семейство ультрасовременных речевых моделей» с 2 млрд параметров. При тренировке использовались 12 млн часов речи и 28 млрд предложений из более чем 300 языков.

USM уже используется Google для создания субтитров на YouTube, модель уже поддерживает автоматическое распознавание речи. Это позволяет автоматически определять и распознавать различные языки, от распространённых вроде английского или мандаринского диалекта китайского до амхарского или ассамского. По данным Google, уже сейчас USM поддерживает более 100 языков и послужит основой для строительства ещё более масштабной системы. Известно, что над аналогичной технологией ИИ-перевода уже работает Meta."

https://3dnews.ru/1082990/noviy-variant-rechevoy-iimodeli-google-usm-pozvolit-obrabativat-bolee-1000-yazikov

#hardware #cpu

А между тем полупроводниковый техпроцесс входит уже в зону 2 нанометров, кто бы мог подумать об этом десять лет тому? Разве что Мур.

"В рамках Intel 20A будет применена новая структура транзисторов RibbonFET с круговым затвором Gate-All-Around (GAA), а также новая схема питания Back Side Power Delivery (BSPD). Одновременное внедрение транзисторов меньшего размера, новой архитектуры транзисторов и новой схемы их питания является рискованным шагом со стороны Intel, однако компания ожидает, что техпроцесс Intel 20A позволит ей обогнать конкурентов в лице TSMC и Samsung. Компания Intel планирует начать использовать указанный техпроцесс уже в первой половине 2024 года. Последующий техпроцесс Intel 18A, как предполагается, будет внедрён до конца того же года и позволит поднять эффективность полупроводниковых устройств ещё на 10 %. Изначально компания планировала использовать для производства 1,8-нм полупроводников сканеры Twinscan EXE нидерландской компании ASML с оптикой, обладающей числовой апертурой 0,55 NA. Но поскольку она решила вывести указанный техпроцесс на рынок раньше, то ей придётся полагаться на менее передовые нынешние сканеры Twinscan NXE с апертурой 0,33 NA, а также на EUV-сканеры с последовательной сменой двух фотошаблонов. Intel считает, что её 1,8-нм техпроцесс производства станет самым передовым на рынке."

https://3dnews.ru/1082983/intel-zavershila-razrabotku-tehprotsessov-intel-18a-i-intel-20a