Список матюков

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

И мы узнали, что, оказывается, самые разнообразные матюки можно найти в Steam.

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

Для особо пытливых другие языки можно найти в Windows в Steam, в папочке resource.

#edu

#wisdom

Here’s Mark Twain:

“There’s no such thing as a new idea. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope. (…) We keep making new combinations indefinitely, but they are the same old pieces of coloured glass that have been in use through all the ages”.

#python #codegems #yan

Юджин Ян показывает интересные лучшие практики Питона при разработке своих библиотек.

Кратко - используйте super().init() в методе init базового класса, чтобы работало множественное наследование.

class BaseAdapter:
    """The Base Transport Adapter"""

    def __init__(self):
        super().__init__()

Почаще используйте миксины для модульности добавления функционала к объектам.
Используйте относительные импорты from .utils.validation import check_X_y.

__init__.py можно использовать, если провели рефакторинг кода и вынесли что-то в отдельный модуль, а ломать совместимость не хочется.

conftest.py можно использовать для хранения глобальных фикстур (к которы можно обращаться из разных тестовых модулей).

https://eugeneyan.com/writing/uncommon-python/

#yan #leadership #management #psychology

Советы, как эффективно продвигать свою точку зрения в коллективе.

https://eugeneyan.com/writing/influencing-without-authority/

#chess

Анализ целесообразности игры в режиме берсерка

https://dzen.ru/a/YnCwK4frN3lFX-U_

#mlstories

Эту работу можно рассматривать как антипример ) Взяли метрикой R2, нет CV, вместо него единичное разбиение на train/test, нет нормального FS, вместо него какой-то странный неясно по какому датасету выполненный отбор из 500+ 7 признаков с наивысшей (линейной?) корреляцией с таргетом. Veery fishy!

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

#cuda #c_plus_plus #thrust #codegems

Показывают, как оптимизировать куда-ядро (расчёт гистограммы и блок внимания).

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

#mlstories #nevergrad

Интересно использование пост-оптимизатора и разрешение конфликта моделей. Проект с 3+ дата-сайентистами окупился за полгода.

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

#featureselection #featureextraction

Простенькое, но приятное интро в FS/FX.

https://www.youtube.com/watch?v=rxiORUw-nKs&

Правильный HPO: Vizier

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

Надеюсь, опен-сорсная версия окажется такой же полезной, как и внутренний продукт. К слову, он продается в Google Cloud, и теперь не совсем понятно, как эти два продукта будут сосуществовать (classic Google).

#games #returntomoria

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

#astronomy

https://youtu.be/XcqHnF293C4?si=ivTtozd3bZ3Ldnn0

#biology #neurons #brain #conciousness #ethics

"Некоторые люди в коме находятся в сознании и ученым даже удалось установить контакт, задавая вопросы и получая ответы "да-нет". Это пугающее открытие ставит новые этические дилеммы - что, если человек в коме испытывает постоянную боль, может ли он принимать решение об отключении систем жизнеобеспечения?"

https://www.youtube.com/watch?v=K7czo-edP2w

Жутковатая статья [1] вышла в последнем номере The New England Journal of Medicine. Большая группа медиков сразу в нескольких крупных медицинских центрах выяснила, что значительно больший процент пациентов в коме, которые, как кажется, не реагируют на внешние раздражители, на самом деле находятся в сознании. Настоящее, блин, «Черное зеркало».

Используя функциональную магнитно-резонансную томографию и электроэнцефалографию, ученые обнаружили, что минимум четверть (25%) пациентов в так называемом вегетативном состоянии демонстрируют отчетливую мозговую активность в ответ на просьбы представить, как они играют в теннис или открывают и закрывают ладонь. Причем активность эта наблюдалась ровно в тех зонах мозга, в которых она должна наблюдаться, если вы действительно делаете это или представляете, что делаете. Иными словами, результаты означают, что пациенты не только поняли, чего от них хотели врачи, но и выполнили просьбу.

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

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

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

PS Для полноты впечатлений, вот ссылки [2], [3] на автобиографические произведения, описывающие ровно это состояние [3] и похожее на него [2].

Ссылки:

[1] - https://www.nejm.org/doi/abs/10.1056/NEJMoa2400645
[2] - https://ru.wikipedia.org/wiki/%D0%A1%D0%BA%D0%B0%D1%84%D0%B0%D0%BD%D0%B4%D1%80_%D0%B8_%D0%B1%D0%B0%D0%B1%D0%BE%D1%87%D0%BA%D0%B0_(%D0%BA%D0%BD%D0%B8%D0%B3%D0%B0)
[3] - https://www.livelib.ru/author/405339-anzhel-libi

#wisdom #fun

Синтаксический сахар вызывает рак точек с запятой.
– Алан Перлис

#hardware #google #tpu

"В этом году у Google выйдет шестое поколение TPU Trillium; кроме того, в минувшем апреле компания анонсировала и Axion — свой первый центральный процессор, который появится в конце года. И здесь Google уже не первая: Amazon выпустила свой Graviton в 2018 году, китайская Alibaba последовала её примеру в 2021 году, а Microsoft представила чип Cobalt 100 в ноябре прошлого года. Все они основаны на архитектуре Arm, более гибкой и энергоэффективной, чем x86, которой привержены Intel и AMD."

https://3dnews.ru/1109922/modeli-ii-gemini-i-apple-intelligence-obuchayutsya-na-sobstvennih-tenzornih-protsessorah-google

#chess #fun

https://www.youtube.com/watch?v=0NIjbaRsakw

#python #codegems #typing #cleancode

Пример применения всратых средств типизации Питон.

Предположим, что требуется создать функцию top(it, n), которая возвращает n наибольших элементов из итерируемого объекта it:

>>> top([4, 1, 5, 2, 6, 7, 3], 3)
[7, 6, 5]
>>> l = 'mango pear apple kiwi banana'.split()
>>> top(l, 3)
['pear', 'mango', 'kiwi']
>>>
>>> l2 = [(len(s), s) for s in l]
>>> l2
[(5, 'mango'), (4, 'pear'), (5, 'apple'), (4, 'kiwi'), (6,
'banana')]
>>> top(l2, 3)
[(6, 'banana'), (5, 'mango'), (5, 'apple')]

как же такую функцию "правильно" аннотировать?

Казалось бы, можно сделать через TypeVar так:

from typing import TypeVar
T = TypeVar('T')

def top(series: Iterable[T], length: int) -> list[T]:
    ordered = sorted(series, reverse=True)
    return ordered[:length]

Вопрос в том, как ограничить T. Это не может быть Any или object, потому что series должен работать с функцией sorted.
Правильное, типа, решение - объявить протокол, поддерживающий операцию сравнения (для сортировки):

from typing import Protocol, Any
class SupportsLessThan(Protocol): 
    def __lt__(self, other: Any) -> bool: ...

и уже потом ограничить TypeVar этим протоколом:

LT = TypeVar('LT', bound=SupportsLessThan)
def top(series: Iterable[LT], length: int) -> list[LT]:
    ordered = sorted(series, reverse=True)
    return ordered[:length]

Ну и типа сидишь такой, думаешь: а стоит ли прохождение проверок типов mypy этих усилий, дополнительного кода, введённых несовместимостей? Я, честно, ХЗ.

#python #books #typing #cleancode

В книжке Fluent Python пишут:

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

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

Ложноотрицательными результатами
Инструмент не сообщает об ошибке в заведомо неправильном коде.

Кроме того, требуя проверять типы всего на свете, мы утрачиваем часть выразительности Python:

некоторые удобные возможности нельзя проверить статически, например распаковку аргументов вида config(**settings);

программы проверки типов в общем случае плохо поддерживают или вообще не понимают таких продвинутых возможностей, как свойства, дескрипторы, метаклассы и метапрограммирование;

программы проверки типов не поспевают за выходом новых версий Python, отвергают код, содержащий новые возможности, или даже «падают» – и иногда это продолжается больше года.

Самые простые ограничения на данные невозможно выразить в системе типов. Например, аннотации типов не могут гарантировать, что «величина должна быть целым числом > 0» или что «метка должна быть строкой длиной от 6 до 12 символов ASCII». Вообще, аннотации слабо помогают отлавливать ошибки в прикладной логике.

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

Рассматривайте программы статической проверки типов как один из инструментов в современном конвейере непрерывной интеграции (CI) наряду с автоматизированными тестами, линтерами и т. д. Цель конвейера CI – уменьшить количество программных ошибок, а автоматизированные тесты находят многие ошибки, выходящие за рамки возможного для аннотаций типов. Любой код, который можно написать на Python, можно на Python и протестировать – с аннотациями типов или без них."

"Я сам большой поклонник тестирования, но при этом часто занимаюсь исследовательским кодированием. Во время экспериментов тесты и аннотации типов не особенно полезны. Они только тормозят работу."

"Если кодинг – не ваша профессия, а лишь полезный инструмент, применяемый в профессиональных занятиях, или нечто такое, что вы изучаете ради удовольствия, то, пожалуй, аннотации типов нужны вам не больше, чем жесткие ботинки и металлические набойки большинству велосипедистов.
Просто кодируйте."

"Я согласен, что пользователи большинства API выигрывают от наличия аннотаций типов. Но Python привлекал меня – среди многих других причин – тем, что предоставляет чрезвычайно мощные функции, способные заменить целые API, и, более того, мы сами можем писать такие функции.

Рассмотрим встроенную функцию max(). Она мощная, но понять ее легко. Однако, как будет показано в разделе «Перегрузка max», чтобы ее правильно аннотировать, нужно 14 строчек аннотаций типов, и это не считая typing.Protocol и нескольких определений TypeVar, необходимых для поддержки этих аннотаций.

Я боюсь, что если библиотеки будут строго требовать аннотирования типов, то программисты раз и навсегда зарекутся писать такие функции."

#python #typing #cleancode

Ну и вдогонку.

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

Настаивая на вставке аннотаций везде и всюду, мы теряем часть выразительности Python. Такие замечательные средства, как распаковка аргументов - например, config(**settings), – выходят за пределы возможностей программ проверки типов.

Если вы хотите подвергнуть вызов вида config(**settings) проверке типов, то должны будете выписать каждый аргумент. Это наводит меня на воспоминания о Turbo Pascal, на котором я писал 35 лет назад.

Библиотеки, в которых используется метапрограммирование, трудно или даже невозможно анотировать. Конечно, метапрограммирование можно употребить во вред, но одновременно это вещь, благодаря которой со многими Python-пакетами так приятно работать.

Спасибо Гвидо за факультативную типизацию. Давайте будем использовать ее так, как она задумана, и не пытаться аннотировать все вокруг в строгом соответствии со стилем кодирования, напоминающим Java 1.5."

В общем, нужно найти баланс между всратостью и разумностью )