Носители языка — худшие коммуникаторы в мире
В комнате, полной людей, для которых язык не является родным, «нет никаких шансов на понимание». Возможно, это их язык, которым они владеют, но послание часто теряется.
User
Носители языка — худшие коммуникаторы в мире
В комнате, полной людей, для которых язык не является родным, «нет никаких шансов на понимание». Возможно, это их язык, которым они владеют, но послание часто теряется.
Привет! Меня зовут Константин Яковлев, я научный работник и вот уже более 15 лет я занимаюсь методами планирования траектории. Часто эта задача сводится к поиску пути на графе, для чего обычно используется алгоритм эвристического поиска A*. Этот алгоритм был предложен в 60-х годах XX века и с тех пор используется повсеместно. Скорее всего, юнит вашей любимой RTS бежит по карте с помощью той или иной вариации A*. Точно так же, под капотом беспилотного авто вы, наверняка, найдёте A*, хотя там, конечно, не только он.
A* — это хороший алгоритм, но его вычислительная эффективность сильно зависит от эвристической функции, которую должен задать разработчик. Основная проблема стандартных эвристик заключается в том, что они не учитывают расположение препятствий на карте и ведут поиск буквально напролом, тратя на это ресурсы (итерации поиска). Почему бы нам не воспользоваться современными нейросетями для решения этой проблемы, а именно попросить нейросеть посмотреть на карту и подсказать поиску как лучше обходить препятствия, чтобы быстрее (за меньшее число итераций) найти нужный путь?
Этот текст посвящен как самому алгоритму A*, так и попыткам повысить его эффективность с помощью методов искусственного интеллекта. Заодно я расскажу о том, какие новшества в этом направлении придумали мы с коллегами: научная статья на эту тему опубликована в сборнике конференции AAAI 2023.
Авторский обзор 90+ нейросетевых моделей на основе Transformer для тех, кто не успевает читать статьи, но хочет быть в курсе ситуации и понимать технические детали идущей революции ИИ.
В весьма впечатлившей меня книге «Информация. История. Теория. Поток» Джеймса Глика, о которой я уже упоминал ранее, страннейшим образом обойдён вопрос о том, как возник феномен «Big Data». В той же книге упоминается первый авторский словарь английского языка, составленный в начале XVII века неким Кодри, а далее развивается идея о том, что феномен концептуализируется в языке после того, как попадает в словарь – в английской культуре таким словарём является оксфордский.
Тогда я попробовал проверить, когда же в английском и русском языке закрепилось понятие «BigData» и, соответственно, «большие данные». Распространено мнение, что выражение «BigData» впервые было употреблено в 2008 году в статье Клиффорда Линча «Big data: how do your data grow?», опубликованной в журнале «Nature», но даже это небольшое исследование подсказывает, что всё гораздо сложнее.
Здесь собраны лучшие и самые полезные репозитории Github, которые будут служить вам долгое время.
Как определить неисправный электролитический конденсатор?
Наиболее частая причина поломки в радиоэлектронной аппаратуре - вышедшие из строя конденсаторы, и мультиметром далеко не всегда удается их идентифицировать.
Дело в том, что помимо емкости и рабочего напряжения, конденсаторы имеют ESR (или эквивалентное последовательное сопротивление) - один из самых важных параметров конденсаторов, характеризующий его активные потери в цепи переменного тока.
В норме ESR очень мало – от десятых долей ома до нескольких ом. Но когда конденсатор выходит из строя, оно возрастает, что может вызвать неправильную работу или неисправность остальных компонентов схемы.
Для измерения параметра ESR можно приобрести и готовый тестер, но я предлагаю вам собрать простой и надежный тестер ESR из доступных компонентов своими руками. Он отличается надежностью конструкции и возможностью измерений прямо на плате, без выпайки компонентов и риска повредить прибор.
На одном из форумов я нашел схему и решил повторить ее.
Профилирование — это неотъемлемая часть любых работ по оптимизации кода или производительности программ. Любой опыт, любые знания в сфере оптимизации производительности, которые уже у вас есть, не принесут особой пользы в том случае, если вы не знаете о том, где их применить. В результате оказывается, что поиск узких мест приложений может помочь в деле решения проблем производительности, поможет сделать это быстро и приложив не слишком много усилий.
В этом материале мы обсудим инструменты и методы работы, которые способны обнаруживать и конкретизировать проблемы с производительностью кода, связанные и с ресурсами процессора, и с потреблением памяти. Здесь же мы поговорим о том, как реализовывать (почти безо всяких усилий) простые механизмы, позволяющие бороться с проблемами производительности. Эти механизмы используются в тех случаях, когда даже точно просчитанные изменения кода больше не позволяют улучшить ситуацию.
Все мы тратим немало времени на отладку, копаясь в логах или читая трейсбеки (traceback, отчёты о трассировке стека). Любое из этих дел может оказаться сложным и длительным. Этот материал посвящён тому, как сделать трассировку стека и работу с исключениями как можно более простыми и эффективными.
На пути к этой цели мы узнаем о том, как реализовывать и использовать собственные перехватчики исключений (exception hook), которые позволяют убрать из трейсбеков весь «информационный шум». Мы поговорим о том, как улучшить читабельность отчётов о трассировке стека, как выводить в них лишь то, что нужно для решения проблем с Python-кодом и с возникающими в процессе его работы исключениями. Кроме того, мы посмотрим на несколько потрясающих Python-библиотек, в которых имеются готовые к использованию, хорошо сделанные перехватчики исключений. Их можно использовать без необходимости написания собственного кода перехватчиков.
Привет! Меня зовут Макс Матюхин, я работаю в SRV-команде Badoo. Мы в Badoo не только активно пишем посты в свой блог, но и внимательно читаем блоги наших коллег из других компаний. Недавно ребята из Dropbox опубликовали шикарный пост о различных способах оптимизации серверных приложений: начиная с железа и заканчивая уровнем приложения. Его автор – Алексей Иванов – дал огромное количество советов и ссылок на дополнительные источники информации. К сожалению, у Dropbox нет блога на Хабре, поэтому я решил перевести этот пост для наших читателей.
С 1988 года до наших дней открыто более пяти тысяч планет, обращающихся вокруг других звезд. Основной прорыв в поиске и классификации этих планет был связан с работой орбитального телескопа «Кеплер», функционировавшего с 2009 по 2018 год и за этот период открывшего более 3500 небесных тел, сочтенных «кандидатами в экзопланеты». Более 1000 объектов, найденных «Кеплером», действительно оказались экзопланетами. Рассмотрение этой миссии – тема для целой книги (кстати, такая книга уже написана и переведена на русский язык, называется «Фабрика планет»).
Как известно, убежденность в существовании обитаемых миров поблизости от «других солнц» была одним из ключевых положений философии Джордано Бруно, сожженного в 1600 году, когда еще даже не была официально осуждена теория Коперника, изрядно мозолившая глаза католической церкви (работа Коперника попала в «Индекс запрещенных книг» только в 1612 году). Со времен Бруно и до наших дней человек ищет именно обитаемые или хотя бы пригодные для обитания миры, вся остальная россыпь небесных тел и открытий в планетологии – не более чем побочный продукт этого процесса.
Поиск экзопланет значительно расширил наши представления о том, что такое «зона обитаемости», и какие планеты в нее попадают. Мы считаем потенциально обитаемыми такие планеты или спутники, на поверхности которых в значительном количестве существует жидкая вода (а значит – и плотная атмосфера, не позволяющая ей испариться). Оказалось, что созданию подобных условий на планете способствует не только близость к родительской звезде, но, в какой-то степени, и приливный захват. Именно об этом феномене и его потенциальном значении для обитаемости небесных тел пойдет речь ниже.
Автоматическое извлечение информации из деловых документов (счетов-фактур, квитанций, ID) все еще остается сложной задачей из-за отсутствия единого стандарта оформления: несмотря на то, что любой подобный документ содержит определенный набор полей, которые можно извлечь (дата, валюта, общая сумма), расположение элементов сильно отличается в зависимости от типа документа или компании. Также определенные трудности вызывают неоднозначное расположение границ документа, например, из-за смещения изображения на скан-копии. Этот фактор тоже может повлиять на положение искомых областей.
Использование словарей (кодовых книг) визуальных слов, аналогичных Bag-of-Words (BoW), раньше было довольно популярно для обработки изображений (к примеру, для поиска или классификации изображений документов). Мы решили создать принципиально новое решение для извлечения информации из документов, которое бы решало перечисленные выше проблемы предшествующих подходов и базировалось бы на построении и использовании оптимизированного словаря визуальных слов. При этом дополнительным достоинством нашей разработки является то, что обнаружение полей основано только на данных изображения и не требует больших размеченных наборов данных для обучения (fine-tuning) системы на стороне пользователя.
Подробно о том, как был создан словарь визуальных слов, его работе и результатах читайте тут, а переведенный сокращенный вариант — под катом.
Я не собирался писать на эту тему. Разговор неизбежно скатится к набившему оскомину IfisEvil. На самом деле это измусоленный вопрос и мне кажется, что вся проблема и шумиха вокруг него заключается лишь в том, что в документации нет последовательного ответа на корень этой проблемы. Поэтому сейчас поговорим про... наследование.
Наследование директив в nginx - это классная штука. Именно наследование позволяет писать простые и понятные конфиги. При слиянии конфигураций значение директивы и её функциональность переходит из вышестоящего контекста в текущий. Логично, что наследование не происходит от параллельных контекстов, например от соседнего location или if.
Вроде бы всё хорошо. Пока не возникают исключения.
N.B.: Здесь и далее описывается работа с nginx версии 1.21.1 (если не указано иное). Всё сказанное основывается лишь на опыте и ошибках автора. Вместе с тем автор не является разработчиком nginx и даже его маститым сварщиком, поэтому не стоит принимать слова автора как догму, а, наоборот, подвергать сомнению и самостоятельному тестированию.
Атма Мани, переводом статьи которого мы делимся к старту флагманского курса по Data Science, — ведущий инженер по продуктам ArcGIS API для Python в компании Esri. В этом материале он рассказывает, как при помощи ArcGIS и Python создать модель, выводящую короткий список домов в соответствии с потребностями и желаниями покупателя. Ссылку на репозиторий GitHub вы найдёте в конце статьи.
На рубеже четвертого и третьего тысячелетия до нашей эры на Земле возникли две первые цивилизации. В долине Нила после объединения верхнего и нижнего Египта образовалось Египетское царство, а в междуречье Тигра и Евфрата появились города-государства, объединенные общей культурой, которые мы сегодня называем Шумером. Одновременно с появлением этих цивилизаций возникли две системы развитого письма — египетские иероглифы и шумерское письмо, которое позже превратилось в клинопись.
Если древний Египет со своими памятниками всегда был на виду, то о существовании шумеров наука узнала только в середине XIX века. Проделав огромный труд и расшифровав аккадскую клинопись, историки внезапно столкнулись с неожиданной проблемой. Часть клинописных текстов никак не получалось прочитать. Знаки были те же, но смысл не складывался. Сначала грешили на тайнопись жрецов, но потом поняли, что на самом деле столкнулись с другим более древним языком, письменность которого совпадала с аккадской. Так начался новый виток расшифровки клинописи, который в итоге привел к открытию великой шумерской цивилизации.
Продолжаем разгадывать тайны списка шумерских царей. Тайны глиняной призмы с клинописным текстом, созданной четыре тысячи лет тому назад. В первой части было описание самой загадки и рассказ о тех астрономических инструментах, которые пришлось создать, чтобы подступиться к решению. Если вы пропустили начало, то можете читать сразу отсюда. Хотя я, конечно, рекомендовал бы заглянуть в первую часть, чтобы узнать историю самого списка и понять, почему его разгадка принципиально важна для понимания всей шумерской истории.
Итак, посмотрим на начало царского списка, на тех царей, что правили до потопа.
Это продолжение цикла статей о разгадке шумерского царского списка. В первой части было объяснение важности этой загадки для понимания всей древней истории и описание тех астрономических инструментов, что были созданы по ходу исследования. Во второй рассказ о вавилонском звездном каталоге MUL.APIN и предположение, что названиями звезд и созвездий в нем была зашифрована вечная, циклически повторяющаяся история борьбы смысла и закона. Но цепочка переводов аккадских имен, хотя она и создает стройный рассказ, не может быть доказательством сама по себе. Нужны дополнительные, более строгие подтверждения. В этой части мы их и рассмотрим.
Что вы знаете об астрологии? Название “астрология” происходит от древнегреческого ἀστήρ «звезда» и λόγος «мысль, причина». Сама астрология — это некая древняя практика, которая позволяет гадать по звездам. Дескать, звезды влияют на судьбы людей и по положению звезд можно предсказывать будущее.
Как вы относитесь к астрологии? Здравомыслящий человек понимает, что астрология — это, как и всякое гадание, шарлатанство. Положение Солнца, планет и созвездий выступает генератором случайных сочетаний, которым астрологи дают свои толкования. Люди, склонные к мистицизму, готовы платить за это деньги. Спрос рождает предложение. Все так?
Что такое знаки зодиака? Есть двенадцать созвездий, лежащих на годичном пути Солнца. То, в каком знаке родился человек, по мнению астрологов определяет его характер и судьбу. Зодиак придумали греки, поместив на небо героев своих мифов.
Information