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

• рассматриваем «сложный» сценарий компоновки GNU ld;
• учимся использовать прерывания;
• наконец добираемся до hello world!

Предыдущие статьи цикла:

• ARM-ы для самых маленьких
• ARM-ы для самых маленьких: который час?
• ARM-ы для самых маленьких: тонкости компиляции и компоновщик

Примеры кода из статьи: https://github.com/farcaller/arm-demos

В ресторане заиграла почти забытая песня. Вы слушали её в далёком прошлом. Сколько трогательных воспоминаний способны вызвать аккорды и слова… Вы отчаянно хотите послушать эту песню снова, но вот её название напрочь вылетело из головы! Как быть? К счастью, в нашем фантастическом высокотехнологичном мире есть ответ на этот вопрос.

У вас в кармане лежит смартфон, на котором установлена программа для распознавания музыкальных произведений. Эта программа – ваш спаситель. Для того чтобы узнать название песни, не придётся ходить из угла в угол в попытках выудить из собственной памяти заветную строчку. И ведь не факт, что это получится. Программа, если дать ей «послушать» музыку, тут же сообщит название композиции. После этого можно будет слушать милые сердцу звуки снова и снова. До тех пор, пока они не станут с вами единым целым, или – до тех пор, пока вам всё это не надоест.

Мобильные технологии и невероятный прогресс в области обработки звука дают разработчикам алгоритмов возможность создавать приложения для распознавания музыкальных произведений. Одно из самых популярных решений такого рода называется Shazam. Если дать ему 20 секунд звучания, неважно, будет ли это кусок вступления, припева или часть основного мотива, Shazam создаст сигнатурный код, сверится с базой данных и воспользуется собственным алгоритмом распознавания музыки для того, чтобы выдать название произведения.

Как же всё это работает?

При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.

Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.

Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.

После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.

В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.

С некоторых пор фирма Segger предлагает технологию Real Time Terminal (RTT) для своих JTAG адаптеров J-Link. Суть ее в том, что программа на микроконтроллере может выводить и принимать отладочную информацию из JTAG/SWJ-DP порта, как это обычно делается через UART. И тогда нам больше не нужен реальный отладочный UART. Далее чуть подробнее о возможностях этой технологии.

Данная статья является продолжением цикла по программированию микроконтроллеров на базе ядра Cortex-M.
Первую статью можно прочитать здесь:
Начинаем изучать Cortex-M на примере STM32
Задачей статей является подробное описание особенностей, возникающих при программировании МК. Материал не предназначен для желающих за 10 минут запустить пример мигания светодиодом. Я постараюсь подробно описать то, что часто скрывают от новичков, чтобы их не напугать.

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

Основной акцент сделан на изучение документации на ядро Cortex-M и документации на конкретный контроллер.
На этот раз речь пойдет про прерывания, а так же будут затронуты некоторые вопросы архитектуры памяти и структуры прошивки МК.

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

Однако же, председатель совета директоров Google Эрик Шмидт на конференции по интернет-безопасности "Big Tent", прошедшей 18 мая, сделал любопытное заявление по этому поводу, довольно ясно очертив по крайней мере одну из тенденций развития своей компании.

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

Стоит напомнить, что помимо серьезных трудностей в Китае, Google постоянно сталкивается с обвинениями в свой адрес, суть которых сводится к тому, что сбор данных — например съемка улиц городов для сервиса Street View, сбор MAC-адресов точек доступа Wi-Fi, «умная» контекстная реклама — нарушает неприкосновенность личной жизни обывателей.

[Источник]

Всем привет!

Хочу представить вам свою разработку. Это минималистичное и удобное средство для ведения домашней бухгалтерии. Вот скриншот для затравки:




Подробности под катом.

Может быть, кто-то не знает, что у Dropbox есть «коллективный» пакет Dropbox for Teams (по крайней мере, на Хабре нет упоминаний). Он предусматривает совместное использование дискового пространство и некоторые дополнительные фичи. В стоимость $795 в год за 350 ГБ уже включена оптовая скидка (правда, совсем маленькая: примерно 5,3%).

Для сравнения, если брать 350 ГБ в виде персональных аккаунтов Pro 100 (100 ГБ, $19,99 в месяц) и Pro 50 (50 ГБ, $9,99 в месяц), то здесь 350 ГБ обойдутся в $839,52 за год, то есть немного дороже.

Но зато групповой Dropbox гораздо удобнее для команд разработчиков, где у каждого своя роль. Особенно для стартапов. Например, дизайнер может использовать 200 ГБ, а бухгалтеру достаточно 50 МБ.

Начнем издалека. Представим себе, что ученые девятнадцатого века неким волшебным образом получили современный компьютер. Они стали бы изучать его работу, создали бы целую науку, описывающую свойства операционной системы и установленных программ. Затем они вскрыли бы этот компьютер и попытались описать его основные узлы, понять их назначение. Потом они стали бы измерять напряжение в различных точках. Возникли бы различные теории о циркулирующих внутри компьютера потоках информации. Возникло бы учение о его кремниевой основе. Кто-нибудь получил бы Нобелевскую премию за открытие принципов работы полупроводникового вентиля. Но самое главное, что сложность устройства современного компьютера затруднила бы тем ученым, путь к пониманию достаточно простых принципов лежащих в основе любой вычислительной техники. Эти принципы были сформулированы в «машине Тьюринга» и не изменились по сей день, и неважно собран ли компьютер на лампах, транзисторах или микросхемах. Любой компьютер имеет память, систему команд, процессор, который умеет эти команды выполнять, программы, состоящие из последовательности команд и устройства ввода вывода, позволяющие взаимодействовать с внешним миром. Остальное «навороты», возникшие в результате эволюции вычислительной техники, хотя и многократно увеличивают возможности компьютера, не отменяют эти принципы.

Прочитав недавно опубликованную статью «Обзор современных проектов крупномасштабного моделирования мозговой активности», хотелось бы рассказать о другом подобном проекте, проводимом научной группой Манчестерского Университета в Великобритании под руководством профессора
Стива Фурбера (Steve Furber), создателя BBC Microcomputer и 32-битного ARM RISC микропроцессора, а также основателя компании ARM.

В предыдущем посте я писал о том, что такое морфологическая омонимия (пример со словом «стали») и упоминал о том, что для её разрешения используют скрытые Марковские модели (Hidden Markov Model, HMM).
Вначале немного о разметке теста (в английской литературе этот процесс называется «part-of-speech tagging» (POST)) – это ручной или автоматический процесс, в результате которого каждому слову текста приписывает атрибутивная информация (тэг), которая определяет какой частью речи является это слово: существительное, глагол, прилагательное, наречие, местоимение, частица, союз, междометие и т.д. Именно тут мы и наткнёмся на проблему «стали».

Данный пост возник как результат общения с одним наивным человеком и результат собственных размышлений о таком сложном и неоднозначном предмете, как язык (в данном случае русский).
О разговоре: суть заключалась в том, что (назовём его Некто) Некто заявлял, что процесс извлечения фактов из текста на естественном языке – вещь достаточно простая и легко реализуемая, мол, ищем глаголы (слова, заканчивающиеся «ет/ют/ел/…») и рядом стоящие существительные (слова длинной более 4 букв), составляем триплеты и загоняем в базу онтологий – вот и движок по извлечению фактов.
Тут же, по моей собственной системе классификации интеллекта, человек получил одну из самых наименьших оценок, но это заставило меня задуматься о некоторых аспектах представления информации в ЕЯ и сложностях, возникающих при извлечении информации из него.

Сегодня будет разговор о синонимии и омонимии.

(Первые части: 1 2 3 4 5 6 7 8 9). Как говорилось в известной рекламе, «вы не ждали, а мы пришли» :)

За время, прошедшее после публикации девятой части, я прочитал одну хорошую книжку по теме (в to-read списке ещё парочка), множество статей, а также пообщался с несколькими специалистами. Соответственно, накопился новый объём материала, заслуживающий отдельной заметки. Как обычно, знакомлю других, параллельно структурирую знания для себя.

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

(Первые части: 1 2 3 4 5 6 7 8). Да возрадуются минусующие, сегодня представляю вниманию читателей последнюю, по всей видимости, часть «Заметок». Как и предполагалось, мы поговорим о дальнейшем семантическом анализе; также я порассуждаюю немного о том, чем в принципе можно заняться в нашей области и какие есть трудности «научно-политического» характера.

(Первые части: 1 2 3 4 5 6 7). В этой части я расскажу о синтактико-семантическом анализаторе — как я его вижу. Обратите, кстати, внимание на часть 7 — она до главной страницы не добралась, так что не уверен, что все интересующиеся её видели.

(Первые части: 1 2 3 4 5 6). Как и обещал вчера, продолжаем обсуждать XDG и движемся к следующим темам. Возможно, мы двигаемся слишком быстро, и действительно имело бы смысл публиковать одну статью раз в два-три дня, чтобы оставалось время всё обсудить. Но, наверно, пока «бензин есть», я буду продолжать писать. А потом можно будет вернуться и обговорить ранее освещённые вопросы. Мне кажется, что в компьютерной лингвистике разные темы настолько тесно связаны друг с другом, что разговор об одной из них без связи с другими малопродуктивен. А мы ещё не обо всём беседовали, так что лучше охватить взглядом как можно больше аспектов компьютерного анализа текста, а потом уже рассуждать о конкретике в рамках общей картины происходящего.

(Первые части: 1 2 3 4 5). Надеюсь, разговор о естественном языке читателей ещё не утомил! По-моему, тематика действительно интересная (хотя популярность топиков явно идёт на убыль :) ). Что ж, посмотрим, на сколько частей меня ещё хватит. Думаю, экватор мы уже прошли, но три-четыре темы затронуть ещё можно.

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

Что ж, продолжим. (Первые части: 1 2 3 4). Долго выбирал, что будет лучше для следующей темы — пофилософствовать о прагматике языка или поговорить конкретно об алгоритмах разбора. Учитывая, что предыдущая часть была неформальной, решил всё-таки переключиться на конкретику, а там посмотрим.

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

(Начало: 1, 2) Что ж, подходим к самому интересному — разбору предложений. Тема эта многогранна и многоуровнева, так что подступиться к ней не очень просто. Но ведь трудности лишь закаляют :) Да и выходные, текст пишется легко…

Начнём с такого понятия, как синтаксический анализ предложений (по-английски parsing). Суть этого процесса состоит в построении графа, «каким-либо образом» отражающего структуру предложения.

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