Ангэ Эсэф

Norway. Bergen, mon amour

Tue, 14 Apr 2009 19:56:48 GMT

Из Ставангера в Берген я ехал автостопом, решил опробовать этот чудесный способ передвижения и в Норвегии. Водители, как и все остальные норвежцы, отлично говорили по-английски, рассказывали забавные истории и в целом были отличными ребятами. Особенно запомнился пирсинг/тату-мастер на пижонском красном Мерседесе, который завёз меня километров на 30 дальше, чем ему нужно было ехать чтобы подбросить меня до парома. А ещё -- парень-Пушкин, так я про себя его назвал, потому что у него был дед-эфиоп, и он рассказывал истории про то, как ездил в Эфиопию и что там есть классный вулкан.

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

Временами встречались прикольные, больше похожие на исландские пейзажи (по крайней мере по цветам):

Мост неподалёку от того места, где меня высадил тату-мастер:

Наконец под звуки Pantera "Walk" я приехал в пригород Бергена со странноватым названием Paradis, откуда уже решил просто на городском автобусе доехать до Бергена.

Берген -- очень атмосферный город. Говорят, что это "дождливая столица Европы", здесь очень много дождливых дней и недавно даже был поставлен рекорд, когда их было штук 90 подряд :) Наверное города, где много дождя мне особенно нравятся, потому что по приезду в Берген я испытывал нечто похожее на то, что было с Питером, вроде "Ууу, как же тут классно!". Но кстати дождя во время моего пребывания в Бергене почти и не было :)

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

Холм, теряющийся в тумане:

Очень часто на фотках Бергена появляется Бригген -- ганзейский торговый квартал. Берген был важным городом для Ганзейской лиги, одним из её центров. Немецкие купцы судя по всему жили там припеваючи, сконцентрировав в своих руках всю торговлю, в том числе торговлю рыбой с северными моряками. Сейчас Бригген -- это ряд деревянных домов и даже несколько деревянных улиц с полом :) Дерево отлично горит и Бригген сжигали и восстанавливали раз пятнадцать, в одноимённом музее Бриггена можно было посмотреть как плавно менялась линия берега и как менялось место, где стоял этот квартал.

Фотографии из Бергена мне очень уж нравятся, то ли действительно город такой фотогеничный, то ли я немного научился фотографировать после 5-6 дней практики. К тому же я провёл там четыре с лишним дня, потому успел многое увидеть.

А вот и целая деревянная улица в Бриггене:

и отдельностоящий домик в конце:

Из интересных жителей Бергена: известный композитор Эдвард Григ (наверное многие хоть когда-то слышали "В пещере горного короля"), а также целая плеяда известных блэк-метал музыкантов из групп Gorgoroth, Burzum (Варг Викернес), Immortal и других. Кстати, есть ещё группа "1349", я раньше не знал, что значит это число, но оказывается это год прихода чумы в Норвегию. Эпидемия началась, когда английский корабль с практически мёртвым экипажем причалил в бергенском порту. Чума уничтожила около половины населения Норвегии.

В первые дни в Бергене я останавливался у замечательной девушки Бенедикты, она наполовину креолка из Луизианы, наполовину норвежка, как она сама пишет: ethnicity: creole queen meets viking :) Учится в Бергене, куда приехала из США, готовится к марафону Midnight sun, который будет летом на севере Норвегии, в Тромсё, веселится и путешествует. В очередной раз убедился, что hospitality и couch surfing -- отличные сайты, т.к. все без исключения люди, у которых я останавливался были действительно приятными и часто интересными.

Конечно же в Бергене много тихих, уютных и узких улочек:

На один из холмов окружающих Берген -- Флёйен ходит фуникулёр:

Но я поднимался туда пешком -- так намного приятнее и интереснее. Поднимаясь всё выше -- видишь всё новые и новые виды, погода была отличная:

Сам подъём выглядит примерно так:

поднимаюсь всё выше:

и, наконец, один из видов, открывающихся с вершины:

довольно "геометрическое" озеро в центре:

а здесь необычный микс природы и хайтека в виде транспортной развязки на фоне сосен:

по дороге встречались всякие артефакты:

а на холмах лежит снег и живут тролли:

и волчицы:

несколько элементов церквей:

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

Антикварная лавка, где я хотел купить старую карту Норвегии, но пожадничал. Зато незаметно пофотографировал :)

Народ изобретательно шутит:

Рядом с Бриггеном:

Norway. Stavanger.

Sun, 22 Mar 2009 20:54:07 GMT

Сейчас Ставангер считается самым богатым городом Норвегии, главным образом из-за нефти. Когда в 1969-м году в Северном море обнаружили нефть (что положило началу богатству и процветанию Норвегии) — Ставангер был избран центром нефтебизнеса. Кстати, интересно, что нефтяные разработки в Норвегии национализированы и ими занимается главным образом государственная компания StatOil.

У города интересная история взлётов/падений и отраслей с ними связанных — вначале город был известен судостроительством, затем, уже в ХХ-м веке, на смену пришло консервное дело — в Ставангере делали консервы с сельдью в оливковом масле (даже есть музей консерв :)), которые, как я понимаю, экспортировались во многие страны. Ну а сейчас — эра нефти.

После такого вступления наверное представляется индустриальный город со зданиями из стекла и бетона, но здесь совсем другие символы достатка :)

Утренний Ставангер:

В ХII-м веке здесь построили весьма впечатляющий собор, Stavanger Domkirke, сейчас он — самый старый в Норвегии. Целиком его нормально сфотографировать мне не удалось, потому выложу не свою фотографию (да не испугает вас контраст моей ранней весны и лета с фотографии :))

А здесь несколько планов покрупнее, уже мои:

Вообще, тщательно там всё так сделано и красиво, кажется даже странным, что это только XII-й век:

И место хорошее — рядом озеро, много зелени, умиротворённо, люди птиц кормят, мне понравилось гулять рядом.

Внутри собор выглядит так:

В городе уютный старый центр, деревянные белые дома XVIII-го — XIX-го века, они принадлежат обычным людям (скорей всего не бедным), которые в них живут и поддерживают в отличном состоянии, автоматически сохраняя исторические здания:

Из-за этих домиков я и приехал в Ставангер :) Это одно из мест, где возникает чувство: "вот здесь я бы пожил" :)

Ставангер был европейской культурной столицей в 2008м году. Вся эта затея с культурными столицами принадлежит Евросоюзу и состоит в выборе прогрессивного города с целью привлечения внимания к его культурной жизни. При этом дополнительное финансирование позволяет городу обновить всяческие культурные ценности или построить новые. Всякие околокультурные штуки часто встречаются в Ставангере :) Например замечательные фото на стене дома:

Или такая антикультурная вывеска магазина одежды :)

А здесь, видимо, дань консервному прошлому и сельди в оливковом масле — симпатичный магазин, будто юг Европы:

В Норвегии любят троллей, правда как правило они весёлые. Я собрал довольно много разных их фотографий, эти — ставангерские:

Ещё несколько домов:

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

Внутри было полно любопытных экспонатов, много внимания уделялось детям: стояли игровые автоматы, в которых можно было поиграть во всякие викторины или компьютерные игры на тему энергии, нефтедобычи и т.д. Ещё мне очень понравилась модель "Реквиема" — творения какого-то скульптора, которого волнует проблема глобального потепления и прочие экологические беды. Как известно, из нефти делают бензин, а когда он сгорает — выделяется в том числе CO2, что не слишком хорошо. Так вот, "Реквием" представляет собой модель поверхности Земли, с чёрными континентами, плавающими в чёрной-чёрной воде (а-ля нефть) и каждый раз в двенадцать часов ночи вся эта Земля сгорает в пламени и погружается под воду. Выглядит довольно эффектно, даже на модели, там было написано, что реально такой памятник расположен где-то в бухте рядом со Ставангером, я его не видел.

Модель чего-то внушительного:

А это мост, который был виден из музея:

После музея я отправился обратно в центр и увидел таких замечательных девушек на тандеме (кстати никогда не видел тандемов в Киеве):

Потом я гулял по всяким паркам, радовало отсутствие снега, более или менее яркие краски и приятная погода.

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

Кладбище Содружества. Гулять там было одно удовольствие, меланхоличные, но сочные краски, здания в тумане, странные деревья, красота!

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

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

Norway. Oslo. Part 2.

Sun, 15 Mar 2009 19:27:05 GMT

После парка Вигеланда я отправился в Фольк-музей, что находится на полуострове Bygdøy, который, как потом оказалось, является довольно мажорским районом и в нём оочень красивые домики, прямо как с картинок журнала об элитной недвижимости.

По дороге к музею, на подходе к Bygdøy:

Folkmuseet состоял из городской и сельской составляющих, в начале я пошёл смотреть всякие старые домики из сельской части из разных времён и регионов Норвегии (немного похоже на наше киевское Пирогово).

Школа:

Какая-то комната с портретами людей, похожих на русских цариц, и прикольной печкой:

Bethlehem — это Вифлеем, город в Палестине, родина Христа. Не знаю почему такая вывеска на одном из домов, видимо какого-то религиозного назначения. Пример приятных шрифтов и ещё так называется некая метал-группа из Германии:

Здесь я увидел первую stavkirke, а также много всяких "хаток" и прочего краеведческой "стаффа". Жаль, что я пришёл поздновато, поэтому часть экспозиции была закрыта, но зато мне сделали скидку на билет. Cначала я думал, что stavkirke переводится как "деревянная церковь", но потом оказалось, что даже по-английски это слово будет "stave church", и stave — это те внутренние деревянные колонны, на которых держится церковь. По-русски эти церкви называются "мачтовыми" или "каркасными" или даже просто "ставкирками". Являют собой довольно уникальный пример скандинавского зодчества, когда-то были почти полностью уничтожены (сгорали, подгнивали, уничтожались населением), но при нарастании волны национализма в Норвегии, перед обретением страной независимости от Швеции, их стали охранять и реставрировать.

А вот и сама церковь:

Общий вид такой, раньше она стояла в городе Гол, а теперь её перенесли в этот музей (фотография не моя):

Выглядят они красиво и весьма даже по-язычески, жаль даже и удивительно, что Варг и прочие товарищи из black metal комьюнити Норвегии их жгли :)

Двери были украшены скандинавским орнаментом:

Вокруг церкви можно идти по такому коридорчику:

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

В городской части музея много зданий увитых плющом (или растением на него похожим):

Это пример старого магазина:

А это — мастерская и инструменты:

Наконец я отправился к самому краю полуострова Bygdøy, полюбовался видом с пристани:

Весной и летом здесь ходит водный транспорт к центру Осло, зимой же лёд и мне приходилось ездить на автобусе номер 30.

Здесь недалеко находятся музей корабля Фрам. Fram (по-норвежски "вперёд") — корабль, на котором плавали в своих великих экспедициях сначала Фритьоф Нансен, а потом Руаль Амундсен — к Южному полюсу. Фритьоф Нансен — замечательный человек, учёный, путешественник, а затем и отличный дипломат, чтение его биографии как-то доставило мне массу удовольствия.

Рядом находится музей "Кон-Тики и Ра", посвящённый известному норвежскому путешественнику Туру Хейердалу. Он поддерживал идею, что индейцы Южной Америки могли поддерживать контакты с полинезийскими народами Океании и что 8000 км Тихого океана этому не помеха. Для подтверждения этой гипотезы он отправился в путешествие на плоту "Кон-Тики", построенному по образу плотов инков и через 101 день успешно прибыл к одному из островов Туамоту. Очень впечатляет, учитывая что этот плот — по сути такая себе большая деревянная доска с парусом :)

Ещё есть музей древних кораблей викингов, правда я в него не попал, потому видел только на фотографиях.

Затем у меня почти разрядились батареи, потому фотографии на тот день закончились :)

Norway. Oslo. Part 1.

Sun, 15 Mar 2009 16:35:36 GMT

У меня часто спрашивали: "Почему именно Норвегия и зимой?", потому я сразу отвечу. Причин несколько: я люблю север, люблю black metal, и Норвегия — слегка экзотическая страна, если выбирать из стран Европы. Мне хотелось посмотреть северное сияние, фьорды, красивую природу, наконец попробовать себя в получении шенгенской визы и также немаловажно, что WizzAir открыли дешёвый рейс Киев — Осло (билет в оба конца с багажом обошёлся мне всего 454 гривны). Так что вот — долгие и тщательные приготовления, сбор документов для визы, поиск хостелов и хороших ребят из hospitalityclub.org и couchsurfing.com (в итоге хостелы мне не понадобились вовсе), ранняя покупка билетов (я рискнул и заказал многие билеты даже до получения визы, и в итоге выиграл немало денег) и наконец виза получена и я улетаю в Осло!

Маршрут был выбран такой:

Киев - Осло - Ставангер - Берген - куда-то на фьорды - Осло - Тромсё - Осло - Киев.

Передвижение планировалось осуществлять на самолётах, поездах, автобусах и автостопом. Почти все билеты купил заранее: у норвежской железной дороги есть такая штука как Minipris, то есть в начале продажи можно купить любой билет за 199 норвежских крон (1 доллар = примерно 7 NOK), потом билеты за 199 заканчиваются и их продают уже за 299, а потом уже реальная стоимость — часто она бывает 700, а то и 1000 крон, таким образом миниприс очень выгоден, но заказывать билеты часто надо за месяц, а то и раньше.

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

Норвегия встретила не слишком дружелюбно — пришлось постоять в очереди на паспортном контроле и многих удивляли ворота безопасности при выходе, но я в этих делах не слишком опытен, потому особенно не заморачивался и не расстраивался. Впрочем на автобус до Осло я таки опоздал (а от аэропорта Сандефьорд Торп до Осло порядка 180 км). В итоге опоздал и на метро и шёл по ночному городу пешком с большим рюкзаком, что, однако, было неплохим приключением. Спасибо Андрею Сорокину, который доходчиво объяснил СМС-ками как добраться до его дома в студгородке на Согне, где я ночевал в первые дни. Первые впечатления: люди говорят по-английски, целые стада велосипедов в снегу и весёлый негр, едущий навстречу на велосипеде по ночному городу и распевающий песню на родном языке :) Ещё весьма понравились местные общежития и их жители. И наконец: часа два ночи и я могу отдохнуть и поспать.

Утро, Осло. В городе полно интересных музеев, однако, как и всё в Норвегии, стоят они весьма порядочно, потому тщательный выбор может помочь сэкономить. Имеется такая штука как Oslo Pass, он стоит 220 крон за одни сутки и позволяет бесплатный проезд на любом транспорте в пределах города и посещение кучи музеев. Однако напосещать музеев аж на 220 крон за одни сутки немного утомительно, потому я его не покупал.

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

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

Через некоторое время бродить надоело, потому я отправился в крепость Akershus, которая впрочем оказалось закрытой (довольно много интересных мест, увы, закрыты зимой, в том числе музеи Теодора Киттельсена, которые весьма хотелось посетить). Тут я встретил парочку русских туристов, после того как Wizz Air открыли свой рейс — много народу ездят смотреть Осло на выходные или что-то в этом духе, так например делали ребята, с которыми я познакомился в самолёте.

На улице развевался пятицветный "гейский" флаг, подошёл из интереса посмотреть, написано паб "Лондон" :) Кстати, Норвегия лояльно относится к меньшинствам, кажется даже разрешены однополые браки. А вот проституцию с января запретили.

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

Запомнившиеся из описания Лебедевым Осло два красных пешехода на каждом светофоре. Особенно прикольно, когда в некоторых местах сразу шесть светофоров и на них горит двенадцать красных пешеходов!

На следующий день меня пригласили на тусовку каучсёрферов (участников сайта couchsurfing.com) в местечке с финским названием Хаукето неподалёку от Осло, где я познакомился с множеством народу из разных стран мира (примерно пятнадцать стран, а человек было от тридцати до сорока в разное время) в том числе Японии, Бразилии, Малайзии и т.д. Народ приносил свою национальную еду, было много пива, снега и музыки, отличная получилась вечеринка. Чем дальше, тем больше веселья, и вот я уже прыгаю по танцполу вместе с парнем из Малайзии и румынской девушкой Андреа под Nirvana "Smells Like Teen Spirit" :) Party в разгаре:

Ещё я познакомился с прикольной молдавской семьёй, которая недавно переехала в Норвегию из Новой Зеландии, вот путешественники, блин! После полуночи народ плавно стал расходиться, а мы конечно же остались на афтепати, крепость напитков и интимность обстановки возросла, фотки стали немного crazy, а утром я обнаружил, что на моём фотоаппарате остались только несколько фотографий со мной, а все остальные, сделанные в Осло — загадочно исчезли :) Видимо, кто-то уничтожал компромат, а может и просто случайность :) В начале было жаль, но теперь понимаю, что те фото все равно были явно не самыми лучшими. Ещё запомнился норвежский парень с футболкой "Прокидайся, Україно, москаль вже годину не спить!" :) Оказалось, что он недавно был во Львове, где её и приобрёл. Надо будет непременно посетить такую встречу и в Киеве.

Заснеженный вид из окна дома Тригге в Хаукето:

В итоге на следующий день я проснулся с лёгким похмельем и провёл большую часть дня болтая с Тригге — хозяином вечеринки и Андреем (моим хостом), а вечером отправился гулять по Осло с новоприобретённой знакомой из Бразилии, с английским у нас обоих было не очень хорошо, потому наши разговоры были довольно незамысловатыми :)

На третий день моего пребывания в Осло я начал немного беспокоиться о том, что время идёт, а достопримечательности толком не осмотрены и ломанулся в Вигеланд-парк, там интересные скульптуры в большом количестве. В силу своей специфичности парк воспринимается жителями Осло двояко: его либо любят либо нет :)

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

Ещё там в центре есть так называемый Мегалит, высокий столб, состоящий из сплетения тел и символизирующий их единение и стремление вверх, к духовному и небесному :) Вырезали его три резчика в течение четырнадцати лет:

Особенно мне понравились решётки на воротах парка и тот эффект, который получается, когда через них смотришь:

На решётках не только обнажённые мужчины, но и женщины :)

А также непонятные комбинации:

Эта вот скульптура, видимо, символизирует детское иго :)

И ещё несколько девушек:

Огромное спасибо martreya за обработку фотографий!

Как я готовил презентацию. Часть 1. LaTeX.

Thu, 04 Dec 2008 06:51:16 GMT

Когда наступила надобность сверстать слайды для следующей презентации — я наконец решил воспользоваться LaТеХ-ом (это уже далеко не первый мой подход, но пока самый продуктивный). В процессе работы у меня возникали различные мелкие задачи: нарисовать диаграмму, нарисовать синтаксическое дерево, нарисовать несколько деревьев "в разных позах", раскрасить исходный код, ну и наконец всё это представить в виде более или менее симпатичных слайдов.

Поскольку часто полученные знания были достойны того, чтобы ими делиться, а весь этот подход по сравнению с традиционным WYSIWYG (в лице Open или Microsoft Office) весьма любопытный и просветляющий — я решил написать на эту тему несколько постов. Они не будут претендовать на роль учебных, т.к. я постараюсь быть кратким и выражать самую суть, чтобы позволить прочувствовать эту атмосферу, заинтересовать и дать толчок к дальнейшему изучению. Кроме того, я сам только изучаю LaTeX, потому не могу служить авторитетом в данной области.

Итак, начнём с LaTeX. Про него написано множество хороших статей и книг, как технического, так и идеологического характера (например почему WYSIWIG — это плохо, а разделение содержания и представления во время создания документа — хорошо). LaTeX — это некая большая надстройка над системой компьютерного набора ТеХ, разработанной не кем иным, как Дональдом Кнутом, знакомым многим по объёмному труду по анализу алгоритмов и другим хорошим работам и высказываниям (мне например нравится "Premature optimization is the root of all evil"). Интересно, что версия ТеХ-а сходится к π (например сейчас у меня latex --version выдаёт 3.1415926).

Основная идея LaTeX-а проста: разделение содержания и представления. TeX-файл представляет собой обычный текстовый файл, в котором к собственно контенту добавляется некие указания, относящиеся, в основном, к логическому структурированию текста — разбиение на главы, разделы, определение сносок, набор формул, таблиц и прочего. Таким образом, в процессе создания документа автор мало отвлекается на визуальное оформление — это за него потом сделает система, да ещё и с помощью весьма умных алгоритмов вёрстки (Кнут же их создавал! И обещает $327.68 за найденный баг в системе, но их вроде с 1995-го не находят). В принципе, можно сравнить этот подход с "контент в HTML + стили в CSS".

Кроме того, система позволяет расширять себя с помощью макросов, что привело к появлению огромного числа наборов этих самых макросов, собранных в пакеты, способных удовлетворить многие нужды пользователей. Собственно LaTeX — и есть большая сборка различных пакетов, значительно упрощающая создание документов, но не превосходящая по возможностям сам ТеХ (то есть, теоретически, всё то, что можно сделать в LaTeX-e можно сделать и в чистом TeX-e).

Касательно технических подробностей и "как же всё это попробовать": LaTeX является свободно распространяется вместе с исходниками по лицензии LPPL (LaTeX Project Public License), доступен для Linux, MacOS, Windows и прочих. Я пробовал только под Linux: нужно поставить пакет texlive (у меня в ArchLinux минимальная дистрибуция LaTeX содержится в пакетах texlive-core и texlive-bin, размер пакетов примерно 70 мегабайт).

Окей, посмотрим теперь как выглядит в TeX-e одна очень простая статья:

\documentclass[11pt]{article} %% type of document -- we want article
\usepackage[utf8]{inputenc} %% we use utf8, because it rules

% defines the title
\author{Ivan N. Veselov}
\title{Minimalism in \LaTeX art}
\date{\today}

\begin{document}

% generates the title
\maketitle

% insert the table of contents
\tableofcontents

\section{Some Interesting Words}
Well, and here begins my lovely article. I hope you enjoy it, but I'm a bit
hesitating because it is so short \ldots{}

\begin{itemize} %% some list
  \item Item A
  \item Item B
  \item Item C
\end{itemize}

\section{Good Bye World}
\ldots{} and here it ends.

\end{document}

Как видно, команды LaTeX-a начинаются со знака "backslash" \. Некоторые из них принимают параметры, которые заключаются в фигурные скобки (обязательный параметр) или в квадратные (опциональные параметры). Сам документ состоит из преамбулы и тела документа. В преамбуле указывается класс документа (статья, книга, презентация, письмо и т.д.), используемые пакеты макросов, собственные макросы, информация об авторе и т.д. В теле документа, которое начинается после команды \begin{document}, находится собственно содержимое документа с командами разметки.

В результате, после команды

pdflatex example1.tex

мы получаем отличную статью в формате PDF :) А здесь приведу пример, конвертированный в PNG:

Кстати, если собираетесь писать в документе по-русски — необходимо использовать пакет babel:

\usepackage[russian]{babel}

и доставить кириллические шрифты (если вы устанавливали какую-нибудь минимальную сборку — их может не быть, и LaTeX не замедлит об этом напомнить).

Отдельная приятность LaTeX-а — очень мощная поддержка вёрстки математических формул, которую я с радостью использовал в дипломе. Я начал использовать LaTeX именно в качестве генератора красиво выглядящих и удобно набираемых формул, которые я потом превращал в картинки и вставлял в диплом. Кто пробовал набирать более или менее сложные формулы в Офисе — весьма оценят эту возможность LaTeX-a. Конечно же для того, чтобы научиться их писать — нужно вначале почитать учебник (ссылки на них находятся в конце статьи), однако всё довольно понятно и быстро запоминается. Кстати, формулы в Википедии задаются именно в формате ТеХ-а.

Вот несколько формул на закуску.

Исходник в .tex:

\documentclass{article}
\usepackage{amsmath}
\begin{document}
All of us know that $sin^2 x + cos^2 x = 1$    % simple inlined formula

But what about calculating this?
$$
\frac{\pi}{\sum\limits_{m=0}^{\infty}{\frac{2}{(4n + 1)(4n + 3)}}}
$$

Continued fraction (with further formulae numbering):
\begin{equation}
\cfrac{1}{\sqrt{2}+
 \cfrac{1}{\sqrt{2}+
  \cfrac{1}{\sqrt{2}+\dotsb
}}}
\end{equation}

And something more advanced:
\begin{equation}
\Re{z} =\frac{n\pi \dfrac{\theta +\psi}{2}}{
        \left(\dfrac{\theta +\psi}{2}\right)^2 + \left( \dfrac{1}{2}
        \log \left\lvert\dfrac{B}{A}\right\rvert\right)^2}.
\end{equation}
\end{document}

Результат:

Итак, подытожим. Что мы получаем, изучив LaTeX?

возможность верстать сложные документы в любимом текстовом редакторе (например vim или emacs). Хотя если хочется каких-то специализированных графических редакторов — их тоже полно, например Kile

отличные, профессиональные шаблоны для вёрстки just for free

инструмент для удобной генерации математических формул любой сложности

знание формата, который является стандартом де-факто для публикации статей многих математических и computer science конференций, журналов и т.п.

инструмент для быстрого создания презентаций

возможность последующей конвертации в PDF, PostScript, DocBook, HTML и другие форматы

Какие же могут возникнуть проблемы?

потеря возможности легко "копипэйстить" из чужих вордовских документов в свои, что довольно актуально для студентов :)

как всегда в чём-то хорошем — требуется некоторое время на изучение

В следующих постах я собираюсь перейти ближе к делу и рассказать о том, как я делал презентацию с помощью пакета beamer, генерировал картинки разных графов и деревьев для последующей вставки в ТеХ-овский документ, а также о том, как можно рисовать деревья средствами самого LaTeX-а. Stay tuned!

Полезные ссылки:

Как всегда, Википедия [RU]

Один из основных базовых учебников ("Не очень краткое введение в LaTeX") [RU, PDF]

Часто рекомендуемая книга Львовского С.М. ("Набор и вёрстка в системе LaTeX") [RU, PDF]

Short math guide for LaTeX (довольно краткая сводка знаний о LaTeX, полезных для набора формул) [EN, PDF]

happy birthday!

Tue, 09 Sep 2008 09:25:31 GMT

Сегодня у martreya День Рожденья! Ура, ура, ура! :)

xmonad

Fri, 29 Aug 2008 08:07:29 GMT

Роман Чепляка выложил в HTML нашу статью о xmonad, весьма хорошем оконном менеджере, написанном на haskell.
Ранее она публиковалась в журнале Open Source, выпуски 27, 28, 29.
Можно смело сказать, что статья является самой подробной из всего написанного про xmonad на русском :)

On CS articles

Thu, 28 Aug 2008 20:17:09 GMT

Хотите написать умную статью, но не знаете о чём?

Вам поможет это! О правильном использовании написано в разделе Examples :)

P.S. Спасибо за наводку замечательному блогу http://www.defmacro.org, не перестаю получать удовольствие от тонкого юмора в статьях автора :)

P.P.S. А в материалах конференции WMSCI 2005 такие статьи даже печатают! Подробнее обо всей этой истории здесь.

Турция

Tue, 22 Jul 2008 08:31:36 GMT

Примерно неделю назад мы с Мариной (martreya) вернулись из двухнедельного автостопа по Турции. Поездка получилось отличной, полной ярких впечатлений и интересной. Турки - замечательные люди, спокойные, улыбчивые и дружелюбные. История страны невообразимо насыщена, кого здесь только не было: и хетты, и греки, и римляне, и турки-сельджуки, и турки-османы! Стамбул (Константинополь) - бывшая столица трёх империй: Восточно-Римской, Византийской и Османской. В общем, предварительно начитавшись статей и путеводителей мы двинулись в путь :)

Маршрут был такой:

Киев - Одесса - (1.5 дня на теплоходе) - Стамбул - Изник - Ассос - Эгейское море - Измир - Гюмюльдюр - Сельчук - Эфес - Конья - Гёреме (Каппадокия) - Невшехир - Стамбул - (1.5 дня на теплоходе) - Севастополь - Киев.

Карта:

В процессе путешествия удалось немного изучить турецкий язык :) Слов 70, которые часто нам были нужны, типа числительных, местоимений и т.д. Ещё я читал, что у него весьма логичная грамматика, и благодарен Ататюрку за введение латиницы вместо арабской вязи, ибо надписи на дорожных знаках так читать несравненно легче.

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

Вступление
Одесса
Стамбул (часть первая)
Изник
Ассос(Бехрамкале)
Гюмюлдюр
Эфес
Сельчук

UPD:
Конья
Гёреме, Каппадокия
Каппадокия (часть вторая)
Гёреме, музей
Стамбул (часть вторая)
Море

О букве Ё

Wed, 12 Mar 2008 10:06:03 GMT

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

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

Немного поисследововав этот вопрос, можно узнать следующие факты:

Ё была предложена в 1783, впервые использована в печати в 1795, однако формально вошла в алфавит только в советские годы

относительно названия надстрочного элемента (вот тех двух точек) нет единого мнения. Употребление слов "умляут", "трема" считается некорректным, поскольку относится к диакритике символа, а диакритика связана с произношением звука (и т.к. ё фонетически не связана с е (ё=йо, е=йэ), то две точки сверху - не диакритический символ)

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

в результате необязательности употребления буквы "ё", сейчас мы можем наблюдать множество исковерканных личных имён (Ришелье, Монтескье, Рентген, Рерих и т.д. - все они были с буквой Ё ;))

И что мне кажется более важным: появляются разногласия при написании слов типа "маневр", "желчь", "блеклый", "издевка" и т.д. Таким образом, когда мы видим букву "е" - мы должны задумываться о том как правильно прочесть это слово: с "е" или с "ё". Если бы "ё" было обязательным в этих случаях, разногласий бы не возникло.

Действующие правила орфографии не требуют написания буквы "ё", однако рекомендуют её написание в неоднозначных словах. Однако, задумываетесь ли вы например при написании очередного поста в ЖЖ, что слово "все" может быть прочитано как "всё"? Уверен, что нет. Увидев такое слово в неоднозначном предложении, приходится возвращаться к нему и переосмысливать прочитанное, что не менее важно, чем то, что взгляд "спотыкается о букву Ё", что например является одним из главных аргументов "против" в статье Лебедева про Ё из его книги "Ководство".

Для того, чтобы исследовать какой процент фрэндов моего ЖЖ использует букву "ё" в своих постах, я написал небольшой скрипт - ёметер :) Он извлекает список друзей, затем последние 25 постов каждого пользователя и проводит простой анализ. Для каждого пользователя затем выдаётся "yo-ratio" (отношение постов с "ё" ко всем постам), так же отношение фрэндов хотя бы раз употребивших "ё" ко всем фрэндам. У меня этот результат таков:

 total users = 106, significant users = 100,
 yo users = 64, ratio = 0.64

Таким образом 36 процентов моих фрэндов ни разу не употребило "ё" за последние 25 постов! К вам, собственно, и обращён этот мой пост :)

Ссылки:

- исходный код yometer.py (для использования необходим python и доступ в интернет)
- статья про Ё в русской википедии
- много ссылок в конце этой статьи
- параграф из книги "Ководство" А. Лебедева

UPD: Для поднятия насущности вопроса публикую под катом список фрэндов, не употребляющих "ё" :) (отредактирован после работы скрипта - вычеркнуты англоязычные и украиноязычные юзеры)

alexott, vrepets, andriyv, gogabr, uhzpm, dr_klm, dtim, japanspy, e_v_ches, fotoankh, frumich, zoodyzero, krlz, _denplusplus_, _elfik_, thesz, martreya, lyubkin, yury_lifshits, musta_auringon, natalie_ray, palm_mute, muha_elka, ironpeter, n_a_d_i_r, pericotera, kaktycnet

Вторая встреча SpbHUG

Sun, 18 Nov 2007 00:00:40 GMT

Сегодняшняя встреча SpB Haskell user group прошла просто замечательно - услышал много нового и интересного, да и сам что-то хорошее рассказал :)

В программе было три доклада:

"Комбинаторы сериализации" (слайды) - мой доклад.

"Свободные теоремы" (или "Теоремы нахаляву" - вольный перевод Theorems for free) (слайды) - доклад deni_ok

"Функциональные структуры данных (часть вторая)" (слайды) - доклад antilamer

(чуть позже возможно появятся фотографии и аудиозапись)

Я получил свой первый опыт чтения докладов широкой (да ещё и весьма интеллектуальной) публике, получив при этом массу fun-a. Смею надеяться - первый блин не вышел комом :)

Остальные доклады тоже весьма порадовали - и интересные результаты, получающиеся в результате вывода этих самых "халявных" теорем, и полезные и интересные техники, описанные Женей, вместе с его замечательными иллюстрациями :) и последующая мини-лекция о realtime-вычислениях и проблемах, с этим связанных, рассказанная Иваном Тарасовым (_navi_), так сказать, в кулуарах.

Что же, с нетерпением жду следующих встреч! :)

SPJ "The implementation of functional programming languages"

Fri, 09 Nov 2007 22:08:48 GMT

Сегодня, просматривая свою коллекцию книжек и paper-ов по функциональному программированию, решил посмотреть, что там пишет Simon L. Peyton Jones в своей книге "The implementation of functional programming languages". И был приятно удивлён - как же классно он пишет! Хотел всего лишь прочесть вступление и зачитался! :) Меньше чем за 30 первых страниц книги получаем чёткое, сжатое, понятное и хорошо иллюстрированное описание таких тем:

синтаксис лямбда-исчисления (в дальнейшем ЛИ)

карринг

операционная семантика ЛИ

бета-редукция, альфа- и эта-преобразования и что они значат

порядок редукции, его оптимальность

нормальный порядок редукции

теоремы Чёрча-Россера

пример выражения, у которого нет нормальной формы

как выражать рекурсивные функции в ЛИ

Y-комбинатор

денотационная семантика ЛИ, отличие денотационной семантики от операционной

bottom _|_

строгость и ленивость функций

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

В качестве анонса попробую написать свой вольный пересказ/перевод вступления к книге.

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

А теперь подробнее.

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

1. Преобразование программы из функционального языка высокого уровня в промежуточный язык, базирующийся на ЛИ.
2. Имплементация промежуточного языка.

После описанного в начале поста обзора классического лямбда-исчисления вводится некое надмножество ЛИ (enriched lambda calculus), которое облегчает трансляцию в него языков высокого уровня.
Оставшиеся главы первой части книги раскрывают такие аспекты преобразования в промежуточный код:

трансляция простых программ на Miranda (который является примером языка высокого уровня в книге и в некотором роде одним из прообразов Haskell)

сопоставление по образцу (pattern matching), его формальная семантика

эффективная трансляция pattern matching выражений (эта глава, как и некоторые последующие, написана Филипом Вадлером)

преобразование обогащённого лямбда-исчисления в обычное

list comprehensions

проверка типов, полиморфизм

реализация type-checker-а

Вторая часть.
Вторая и третья части книги посвящены имплементации лямбда-исчисления с помощью техники редукция графов (graph reduction).
Кратко суть этой техники можно описать на примере выполнения простой программы

 f x = (x + 3) * (x - 1)

Предположим, нам нужно посчитать f 2:

 f 2 = (2 + 3) * (2 - 1)

Это выражение можно представить в виде дерева:

     *
    / \
   +   -
  / \ / \
 2  3 2  1

применяя последовательно сложение и вычитание (в любом порядке), мы получим такое (редуцированное) дерево:

     *
    / \
   5   1

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

Проведя вышеописанный процесс, можно сделать следующие наблюдения:

1. Выполнение функциональной программы состоит в вычислении выражений.
2. Естественным представлением функциональной программы является дерево (или более обще - граф)
3. Вычисление происходит посредством выполнения последовательных простых шагов называемых редукциями. Каждая редукция представляет собой простое локальное изменение в графе - редукцию графа.
4. Редукции могут проводиться в различном порядке, а также параллельно, поскольку часто они не влияют не взаимодействуют друг с другом.
5. Вычисление считается завершённым, если не осталось выражений, которые могут быть редуцированы.

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

представление программы в виде графа

порядок редукций

собственно проведение редукций

суперкомбинаторы

полная ленивость

SK - комбинаторы (техника альтернативная суперкомбинаторам)

сборка мусора

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

концепция и описание G-машины

различные оптимизации её работы

анализ строгости

оценка сложности функциональных программ

параллельные реализации редукции графов

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

Неисповедимы пути википедии

Sat, 20 Oct 2007 22:40:47 GMT

Весёлая, однако, штука - википедия! Читал статью про метасинтаксические переменные, а буквально через два-три перехода по ссылкам внутри статей - уже попал на статью про куннилингус! :) При этом узнал, что и до него, и после нежелательно чистить зубы и есть чипсы и сухарики :)

А в дополнение выпуск xkcd на эту же тему:
[xkcd.com - The problem with Wikipedia]

QuickCheck

Sat, 06 Oct 2007 15:05:13 GMT

Вчера, с подачи antilamer (спасибо за вдохновляющий поток эмоций! :)), поразбирался с QuickCheck - средством для тестирования функционального кода, которое основывается на проверках неких свойств, которые задаются относительно определённых функций и проверяются на случайно сгенерированных данных.

Классический пример: есть функция reverse для обращения списков. Тогда можно придумать такие достаточно ярко её характеризующие свойства:

propReverseUnit x       = reverse [x] == [x]                             
-- (то есть, обращая список из одного элемента - получаем тот же список)

propReverseAppend xs ys = reverse (xs++ys) == reverse ys ++ reverse xs
-- (обращая конкатенацию списков, получаем конкатенацию обращений частей 
-- в обратном порядке)

propReverseReverse xs   = reverse (reverse xs) == xs
-- (обращая обращение списка - получаем тот же список)

Теперь из-под ghci запускаем QuickCheck:

Main> quickCkeck propReverseReverse
OK, 100 tests passed

и - вот он, момент истины! - QuickCheck сгенерил 100 случайных списков, на которых проверил данное свойство и поскольку оно всегда выполнилось - выдал OK.

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

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

На предстоящей встрече Spb Haskell User Group , как раз ожидается доклад по QuickCheck от Дмитрия Тимофеева (dtim), который, думаю, будет весьма интересно послушать, при этом уточнив пока неясные для меня моменты.

В общем, весьма любопытная штука и немного необычный (по крайней мере для меня) подход к тестированию, который отлично работает в условиях отсутствия побочных эффектов и превращает процесс тестирования в весьма увлекательный процесс размышления над свойствами своей программы. Изначально QuickCheck был написан для Haskell и активно там используется, но поиск в гугле выдал и порт для Erlang .

Котята в Киеве :)

Tue, 24 Jul 2007 11:18:52 GMT

У меня вот родились котята с месяц назад (мама - наша Маська, папа - некий сторонний перс), теперь ищем им хозяев.
На эту тему сделал здесь пост:

Пост про котят с фото

Там есть и фотки, и небольшое описание, и контакты.
А ещё сделаю превью одного котёнка здесь:

Был бы очень благодарен за помощь в раздаче, ибо в воскресенье утром (29.07) возвращаюсь в Петербург, и было бы весьма неплохо их к тому времени раздать. Котята весьма позитивные, игривые и пока неизбалованные, так что рекомендую :)
Спасибо!

Киев - СПб

Sun, 08 Jul 2007 09:38:46 GMT

Вчера благополучно переехали в Санкт-Петербург, буду теперь некоторое время здесь жить :)
Старый номер телефона можете смело удалять, теперь контакты такие: +7 921 3782469.

У нас тут есть чукотские сказки, шахматы, автомобильная сирена по утрам и новый нескрипящий диван!
Все желающие повидать меня в СПб are welcome! :)

Кроме того, примерно 15 июля ещё вернусь на несколько дней в Киев.

Пример изоморфизма

Wed, 20 Jun 2007 13:38:29 GMT

Наткнулся на прикольный пример изоморфизма. Есть игра для двух игроков: каждый по очереди называет число от 1 до 9. Повторяться нельзя. Выигрывает тот игрок, который первым назовёт числа, сумма которых равна 15.
Спрашивается: какой известной игре эта игра изоморфна?
Комментарии пока скрываются :).

P.S. Изоморфизм - это по сути взаимно-однозначное соответствие между двумя множествами, которое сохраняет структуру этих множеств - то есть какой-то набор правил (аксиом), соответствующий множеству, будет выполняться в обеих множествах.
Например есть колода карт с зелёными рубашками и колода карт с синими рубашками. Между ними можно провести взаимно-однозначное соответствие, при этом каждой из них можно всё так же играть (то есть соблюдается определённый набор правил, которому соответствует каждая колода). Таким образом, это соответствие сохраняет структуру и потому может называться изоморфизмом.

UPDATE (ответ)
Более половины комментариев были верными - ответом является игра в крестики-нолики на магическом квадрате 3х3 (сумма чисел в котором по вертикалям, горизонталям и главным диагоналям которого равна 15).
Выглядит он вот так:

2 7 6
9 5 1
4 3 8

При этом я немного некорректно поставил условие: действительно, как справедливо отметили некоторые из отвечавших, следует ограничить условия победы тем, что суммировать можно три и только три числа из названных игроком (что соответствует победе тремя крестиками или ноликами, поставленными в ряд).

Спасибо всем за ответы, было интересно!

Белорусский арабский алфавит

Mon, 28 May 2007 22:00:55 GMT

Захотел я почитать в Википедии статью про DSL (domain specific languages) и не пожалел :) Набрал не в той раскладке "dsl", и по запросу "выд" английская Википедия достаточно неожиданно выдала мне с релевантностью 9,9% интересную статью про белорусский арабский алфавит. Поначалу я подумал, что это очередной википедийный вандализм (а-ля недавняя байка про МГУ), но нет.

Как оказалось, белорусский язык записывался в XVI-м веке арабскими буквами местными татарами, которые почти в абсолютном большинстве забыли родной язык, но не хотели терять свою религию и нашли такое решение: пересказать Коран на белорусском и записать его с помощью арабской письменности. Возникли проблемы с некоторыми звуками, которых изначально не было в арабском ("ж", "ч", "п", "дз", "ц", а также "у краткое"), но они были решены введением новых символов. Таким образом, возникли "китабы" (kitabs) - целые книги, записанные подобным образом - преимущественно религиозные и фольклорные.

Сейчас китабы хранятся в библиотеках АН Беларуси, АН Литвы, Вильнюсского, Петербургского и Казанского университетов, а также в частных коллекциях.
Такой вот интересный пример транслита.

Ссылки по теме:
Статья на русской Википедии
Более подробная статья о кетабах (англ.)

Haskell: комбинаторные парсеры Parsec.

Thu, 24 May 2007 12:20:35 GMT

Что же, в прошлый раз мы вспомнили формы записи операторов и рассмотрели написание простого вычислителя постфиксных выражений на Haskell. Следующим шагом является создание транслятора выражений из инфиксной формы - в префиксную. Однако, перед этим нам необходимо улучшить разбор выражения на токены, поэтому в данной статье мы рассмотрим монадические комбинаторные парсеры на примере модуля Parsec, а также использование их на практике.

Haskell postfix: часть вторая. Комбинаторные парсеры Parsec.

Как мы уже убедились, постфиксная форма предоставляет массу преимуществ, которыми было бы неплохо пользоваться. Хотя в реальной жизни чаще используется инфиксная форма, существуют несложные алгоритмы для преобразования. Наиболее известным их представителем является алгоритм "сортировочная станция", предложенный Дейкстрой. Алгоритм получил своё название из-за сходства его операций с действиями, происходящими на железнодорожных сортировочных станциях. Подробно приводить его здесь я не стану, ибо он хорошо описан в указанной выше статье. Работает алгоритм на основе стека, в процессе работы используется входная и выходная строки, в стеке находятся символы, ещё не выведенные в выходную строку. Из входной строки считывается очередной символ и в зависимости от его типа (оператор, операнд, функция, скобка, запятая и т.д.) производятся определённые действия по манипулированию со стеком и выходной строкой.

Вернёмся к программированию.
Поскольку "сортировочная станция" работает не только с операндами и операторами, но и c функциями со списками аргументов, нам необходимо расширить наше описание токена:

data Token = Atom String | Op String | LParen | RParen | Comma | Func String deriving (Eq, Ord, Show)

Данный типа реализует и скобки, и запятые, и специальный токен функции Func String.

Очевидно, что для проведения парсинга такого рода функции типа parseToken из предыдущей части будет недостаточно, поскольку требуется некий предпросмотр (lookahead) для того, чтобы определить будет ли строка функцией или же простым идентификатором, а также хотелось бы не разделять токены пробелами во входной строке, как это было сделано в предыдущей версии программы.

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

1) Каждый парсер представляется в виде некоторой функции.

2) Эта функция принимает на вход некоторую строку, которую надо обработать. Подумаем, что является результатом разбора. Вообще говоря, это может быть почти всё, что угодно - к примеру результатом парсинга строки "23" вполне может быть число 23, результатом разбора строки "2 + 3" может быть некое дерево с корнем (+) и листьями 2 и 3. Поэтому назовём тип результата просто a. Получим следующий тип:

type Parser a = String -> a

где a - параметр типа Parser, показывающий, что именно мы хотим от него получить. Например, парсер целых чисел будет иметь тип Parser Int, а парсер деревьев - Parser Tree.

Однако, парсер может обработать не всю строку, а только её часть и вернуть остаток. К примеру, если мы подадим на вход парсеру целых чисел строку "2s", то он обработает только "2" и должен бы вернуть "s". Поэтому было бы неплохо расширить возвращаемый тип до пары (a, String), получив следующее:

type Parser a = String -> (a, String)

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

type Parser a = String -> [(a, String)]

Причём возврат пустого списка будет свидетельствовать о неуспешном разборе, а возврат списка с более чем одним элементом - о неоднозначном разборе. Наиболее удачный вариант - возврат в точности одного элемента в списке.

Таким образом мы определились с типом парсеров-функций.

3) Определяются функции высшего порядка (комбинаторы), которые определённым образом сочетают парсеры, позволяя производить такие операции определения грамматик, как последовательное распознавание двух символов грамматики (sequencing), параллельное - то есть выбор из двух альтернатив (choice) или же более сложные конструкции расширенной нотации Бэкуса-Наура вроде повторов (repeating).

Рассмотрим данные конструкции более подробно на примере правила грамматики для идентификатора некоторого языка программирования. Предположим, что первым символом идентификатора может быть любая буква, а последующими символами буква или цифра. Тогда правило будет выглядеть так:

identifier = letter (letter | digit)*

где последовательная запись означает последовательное распознавание (то есть сначала необходмо распознать letter, а затем (letter | digit)*,
| - означает выбор между альтернативами,
* - означает возможность повтора любое количество раз.

Для всех описанных конструкций существуют аналоги в Parsec. Последовательное выполнение парсеров записывается с помощью операции связывания >>, выбор с помощью комбинатора <|>, а повтор - с помощью комбинатора many. Таким образом парсер индентификаторов в Parsec будет выглядеть так:

identifier = letter >> many (letter <|> digit)

Затем на основе элементарных комбинаторов строятся более сложные комбинаторы и так далее. Рассматривать подробно этот процесс я не стану, ему посвящены целые отдельные статьи, ссылки на которые будут даны в конце статьи.

4) Как оказалось, комбинаторы и парсеры формируют некую абстрактую структуру, называемую "монадой", пришедшую в Haskell из теории категорий. Монаду можно представить как некий контейнерный тип, в котором элементы контейнера могут быть связаны друг с другом некоторой стратегией вычислений. В данном случае, каждой составляющей контейнера является конкретный парсер, а под их связыванием подразумевается последовательное выполнение двух парсеров с промежуточной передачей результата разбора первым - второму. "Упаковка" парсеров в монаду помогает сокрыть такие вещи, как явную передачу промежуточного состояния парсинга, а также позволяет записывать парсеры в более компактной и удобочитаемой форме.

Таким образом, можно отметить, что использование комбинаторных монадических парсеров является типичным функциональным подходом к разбору, позволяет избежать специфических языков, изучение которых необходимо для написания грамматик (как при работе с yacc, ANTLR), кромего того, в случае Parsec - парсеры являются first-class citizens языка, что позволяет значительно ускорить процесс их создания.

Попробуем продемонстрировать сказанное на нашем примере. Задача стоит следующим образом: создать парсер, которые превращает строки вида "4 * (f(1, 2) + 3)" в список токенов, то есть осуществляет лексический анализ строки. Проверять синтаксическую корректность выражений мы пока не станем, этим займётся будущий транслятор в постфиксную форму.

Начнём с самых простых токенов - LParen, RParen, которым соответствуют символы открывающейся и закрывающейся скобок.
Поскольку мы хотим чтобы парсер возвращал токен, то его типом будет Parser Token.

lparen :: Parser Token
lparen =  char '(' >> return LParen

Мы воспользовались стандартным парсером char, уже определённым в Parsec. Несложно догадаться, что он распознаёт один заданный символ, в данном случае '('. В случае успешного распознания нам нужно вернуть токен LParen. Это можно сделать с помощью специальной монадической функции return, которую необходимо связать с парсером char. Делается это с помощью оператора связывания >>. В данном случае связывание означает последовательное выполнение, то есть в начале выполняется распознавание скобки, а затем возвращается токен LParen. Если скобка не будет распознана - возникнет ошибка, о которой Parsec незамедлительно сообщит.

Попробуем протестировать наш парсер левой скобки. Сделать это можно в интерпретаторе GHCi. Запишем наше определение типа токен (data Token) и новосозданный парсер. Ключевое слово deriving в определении типа означает, что данный тип автоматически имплементирует некоторые классы. Если тип имлементирует класс Show - он может быть отображён, то есть существует некоторая функция, которая преобразует этот тип в строку, в данном случае (при употреблении ключевого слова deriving) эта функция генерируется автоматически.

module Main where

import Text.ParserCombinators.Parsec

data Token = Atom String | Op String | LParen | RParen | Comma | Func String deriving (Eq, Ord, Show)

lparen :: Parser Token
lparen =  char '(' >> return LParen

Теперь можно сохранить и загрузить в GHCi. Тестировать парсеры можно с помощью стандартной функции parseTest, которая принимает в качестве первого параметра парсер, а в качество второго - входную строку:

*Main> parseTest lparen "("
LParen

Как видим, тест успешно пройден, парсер распознал токен LParen и вывел его. Попробуем теперь следующее:

*Main> parseTest lparen "a"
parse error at (line 1, column 1):
unexpected "a"
expecting "("

Здесь Parsec выдал вполне информативную ошибку. На формат выдачи ошибок, вернее описание того, ожидалось можно немного влиять с помощью комбинатора <?>
Достаточно написать

char '('  "left parenthesis" >> return LParen

как описание ошибки станет таким:

*Main> parseTest lparen "a"
parse error at (line 1, column 1):
unexpected "a"
expecting "left parentheses"

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

rparen =  char ')' >> return RParen
comma  =  char ',' >> return Comma

Парсер для токена Atom (то есть переменной или числа), выглядит следующим образом:

atom :: Parser Token
atom = do
  a <- many1 alphaNum <?> "atom"
  return (Atom a)

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

do 
  a 
  b

аналогична записи:

a >> b

Стрелка <- означает, что результат выполнения парсера помещается в некоторую переменную a, которая затем может использоваться далее внутри do-выражения. В частности, здесь мы используем полученную в результате строку a для того, чтобы сконструировать токен Atom. Комбинатор many1 - производит из парсера alphaNum (который различает одну букву или цифру) новый парсер, который различает одну и больше букв или цифр.
<?> "atom" - как и в прошлом примере влияет на вывод ошибок парсинга, делая его более информативным.
return (Atom a) - возвращает токен Atom c лексемой a, полученной в результате работы many1 alphaNum.

operator представляет собой альтернативу между несколькими символами и возвращает токен Op.

operator :: Parser Token
operator = do
  c <- char '-' <|> char '+' <|> char '*' <|> char '/' <|> char '^' <|> char '.' <?> "operator"
  return $ Op (c:[])

Попробуем теперь определить парсера для токена Func. Его можно отличить от других токенов с помощью последующей скобки, то есть при входной строке вида "f(1) + 2", f - будет токеном Func "f", а если входная строка имеет вид "f - 1", то f - это Atom "f". Таким образом в процессе парсинга нам необходимо "заглянуть вперёд" (lookahead) , чтобы определить каким будет следующий токен. Данное действие можно реализовать с помощью комбинатора lookahead, который не поглощает символы из входной строки, а лишь проверяет успешность работы своего парсера-аргумента.

func :: Parser Token
func = do
  Atom a <- atom
  skipMany space
  lookAhead lparen
  return (Func a)

В начале распознаётся Atom, затем с помощью skipMany комбинатора пропускается свободное место (парсер space распознаёт пробелы, табуляции и т.д.), затем проверяется успешно ли отработает парсер lparen и, наконец, возвращается токен Func со строкой а, которую уже распознал парсер atom.

Теперь объединим все парсеры токенов вместе - в едином парсере токенов tok:

tok :: Parser Token
tok = do
  t <- try (func) <|> atom <|> operator <|> lparen <|> rparen <|> comma
  skipMany space
  return t

Здесь нам придётся использовать комбинатор try, который "пробует" распарсить функцию с помощью парсера func, и если у него "не получится" - нужно продолжить разбирать альтернативы. Если этого не сделать, то в случае входной строки "f + 1" парсер func начнёт парсить функцию f, однако не обнаружит скобки и выдаст ошибку, что неверно, поскольку f - в данном случае Atom. Таким образом, в случае сбоя парсера func - необходимо продолжить парсинг с другими альтернативами, например atom.

Наконец сформируем парсер для всего выражения:

expression :: Parser [Token]
expression = do
  skipMany space
  ts <- many1 tok
  eof
  return ts

Здесь из нового - только парсер eof, который распознаёт конец файла.

Теперь нужно правильно вызывать парсер и обработать возможные ошибки:

parse' :: String -> [Token]
parse' s = case (parse expression "expr" s) of
  Left err -> error (show err)
  Right x -> x

Делается это с помощью функции parse, первый параметер которой - парсер, второй - название строки (можно оставить любым), и третий - сама строка.
Результат её типа Either ParserError a - то есть либо ошибка парсинга (ParserError), либо тип возвращаемого парсером значения (то есть - некий любой тип a).
Вообще, тип Either представляет значения с двумя возможностями - значение типа Either a b может быть либо Left a, либо Right b (то есть data Either a b = Left a | Right b). Иногда тип Either используется для представления значения которое является либо ошибкой, либо правильным значением. Обычно, конструктор Left используется для представления ошибочного значения и конструктор Right для правильного (можно легко запомнить поскольку "right" означает ещё и "правильный").

Затем с помощью case of мы определяем правильное или ошибочное значение получено: в случае ошибки - выводим её с помощью функции error, которая выводит сообщение и останавливает вычисления, а в случаего успешного парсинга - выводим его результат.

Можно сказать, что код получился вполне читабельным и несложным. Следует отметить, что в статье продемонстрированы лишь базовые возможности Parsec.
Если говорить о его возможностях более серьёзно, то можно отметить следующее:
- Parsec может обеспечивать разбор грамматики с бесконечным предпросмотром (lookahead) с помощью комбинатора try, который обеспечивает так называемый синтаксичечкий предпросмотр, но лучше всего работает с LL(1)-грамматиками;
- как заявляет автор Parsec, он обеспечивает достаточно неплохую скорость разбора, в особенности в сравнении с другими комбинаторными парсерами;
- выбор стандартных библиотечных парсеров весьма богат;
- простота разработки и читабельность кода парсеров - на высоте;
- парсер может работать на любых данных, необязательно строках. Таким образом синтаксический разбор можно производить на списках токенов, а не списках символов;
- возможность быстрой реализации лексических анализаторов, использующих готовые схемы языков (например схема для языка Haskell или Java);
- достаточно хорошая документация.

Полезные ссылки:
Parsec
G.Hutton, E.Meijer "Monadic parser combinators" [PDF]
G.Hutton, E.Meijer "Monadic parsing in Haskell" [PDF]

В качестве приложения стоит привести полный код парсера.

module Main where

import Text.ParserCombinators.Parsec

data Token = Atom String | Op String | LParen | RParen | Comma | Func String deriving (Eq, Ord, Show)

parse' :: String -> [Token]
parse' s = case (parse expression "expr" s) of
  Left err -> error (show err)
  Right x -> x

-- operator token
operator :: Parser Token
operator = do
  c <- char '-' <|> char '+' <|> char '*' <|> char '/' <|> char '^' <|> char '.' <?> "operator"
  return $ Op (c:[])

-- atom token
atom :: Parser Token
atom = do
  a <- many1 alphaNum <?> "atom"
  return (Atom a)

-- 1-char tokens
lparen =  char '(' >> return LParen
rparen =  char ')' >> return RParen
comma  =  char ',' >> return Comma

-- func token
func :: Parser Token
func = do
  Atom a <- atom
  skipMany space
  lookAhead lparen
  return (Func a)

-- one token
tok :: Parser Token
tok = do
  t <- try (func) <|> atom <|> operator <|> lparen <|> rparen <|> comma
  skipMany space
  return t

-- all expression
expression :: Parser [Token]
expression = do
  skipMany space
  ts <- many1 tok
  eof
  return ts

Exaile и opensource

Wed, 09 May 2007 14:53:03 GMT

В очередной раз убеждаюсь, что хорошая штука opensource :)

Я пользуюсь Linux Ubuntu и недавно сменил основной аудио-проигрыватель с Amarok на Exaile, поскольку Amarok, будучи KDE-приложением, несколько тормозил при запуске в моём Gnome. Exaile - является некоторым подобием Amarok под Gnome, вполне приятный плэйер, в котором есть интеграция с last.fm, неплохой менеджер артворков, нотификации, работа с мультимедийными клавишами out of the box, приятный внешний вид и т.д. После перехода я обнаружил, что некоторых мелочей мне не хватает и решил сделать их сам.
Что же, получаем исходный код для разработчиков:

svn co svn://exaile.org/usr/local/svn/exaile/trunk trunk

и вперёд! :) Заодно познакомлюсь с Python и GTK.

Захожу на канал #exaile в IRC, знакомлюсь с одним из двух разработчиков Exaile - sjohannes, пытаюсь задавать какие-то вопросы. В принципе ребята на вопросы отвечают, но помогать в разборе кода особенно не хотят. Что ж, посмотрю сам.

Поначалу я реализовал простенькую фичу. Заключалась она в добавлении возможности "Load", которая параллельно очищала плэйлист и добавляла в него выбранный трек или альбом: добавил menu item "Load" в контекстное меню, навесил на него обработчик. В итоге всё вылилось в такой вот ticket с патчем.
Особого успеха у sjohannes этот патч не имел - сказал, что не думает что это особенно нужная функциональность, но, тем не менее, на следующий день пришло письмо от некоего благодарного пользователя, так что хоть кому-то он да понадобился :)

Вторая же возможность, которую я добавил, была навеяна похожей функциональностью Eclipse IDE и сразу понравилась разработчикам. Я говорю о возможности "Show in collection", которая может быть полезна при желании быстро перейти от трека в плэйлисте к соответствующему треку в коллекции (это важно при прослушивании случайных треков, при этом иногда хочется послушать полностью ту группу, которая только что играла и, как следствие, нужно искать её в коллекции, что возможность делает автоматически). В Eclipse этой возможности соответствует переход от текущего редактируемого файла к его ноде в дереве проекта. В итоге, я сделал ещё один патч.

Эта идея и её реализация уже гораздо больше впечатлила sjohannes, и он сказал, что непременно включит её в следующий релиз (см. UPDATE). Что ж, буду рад :)

Хочется отметить, что Python, как и обещалось многими, оказался действительно интуитивно понятным языком, с хорошим синтаксисом. Практически все вещи, что я делал почти наобум - работали именно так, как полагалось. Мне кажется, что это весьма важное качество языка - works as expected. Насчёт GTK и биндингов под Python - pyGTK, тоже ничего плохого сказать не могу, хорошая документация, поработал с деревом и его моделью без особенных проблем. Хотя здесь, конечно, моё мнение весьма поверхностно и сравнивать мне не с чем, ибо я никогда не занимался разработкой GUI под Linux.

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

UPDATE: Функциональность "Show in collection" добавили в Exaile в ревизии 2358 ("svn log -r 2358").

Haskell Postfix: часть первая. Операторы. Вычислитель постфиксных выражений на Haskell.

Thu, 03 May 2007 12:27:11 GMT

Недавно я встретил упоминание ещё об одном сайте, предлагающем разные математические и программистские задачи. Это Sphere Online Judge (http://spoj.pl). От популярного нынче "Проекта Эйлера" (http://projecteuler.net) отличается тем, что вводятся не ответы на задачи, а на сервер загружается сам код, который там компилируется и запускается на тестовых примерах. Решение одной из задач этого контеста привело к довольно интересным для меня результатам, о которых я решил написать небольшой цикл статей.

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

Содержание статей будет примерно таким:
1. Формы записи операторов (инфиксная, префиксная, постфиксная). Реализация на языке Haskell простого вычислителя арифметических выражений, записанных в постфиксной форме.
2. Преобразование инфиксной формы в постфиксную. Алгоритм "сортировочная станция" Дейкстры. Транслятор на Haskell. Использование комбинаторных парсеров Parsec для разбора выражения.
3. Реализация более полного эвалуатора, вычисляющего как арифметические выражения, так и функции.
4. Переход от вычисления значения выражения к вычислению типа выражения. Последствия в виде использования в реальной жизни для вывода типов выражения в ActionScript 3.

Тех, кому интересно - прошу к прочтению первой части :)

Haskell Postfix: часть первая. Операторы. Вычислитель постфиксных выражений на Haskell.

Формы записи операторов представляют собой способ для записи математических выражений в виде линейной последовательности токенов (самих операторов и их операндов). Можно выделить такие основные формы записи:

префиксная, оператор записывается перед своими операндами, например "+ 1 2".

постфиксная, оператор записывается после своих операндов, например "1 2 +". Такую форму ещё называют обратной польской записью или "полиз" (сокращение от "польская инверсная запись"). Польской она называется потому, что впервые была предложена польским математиком Лукасевичем.

инфиксная, оператор записывается между своими аргументами, например привычное "1 + 2". Здесь стоит отметить, что инфиксная запись может применятьcя не только с бинарными операторами, пример тому - запись тернарного оператора (?:) из С.

Рассмотрим постфиксную нотацию. Она удобна тем, что на момент появления операции все операнды уже определены, поэтому остаётся лишь применить операцию. Вычисления проводятся с помощью стека, то есть операнды достаются из стека и затем результат операции помещается в стек вместо них. Например, предположим, что надо вычислить выражение 4 1 - 2 * , то есть (4 - 1) * 2 в обычной инфиксной записи. Действия и состяние стека в процессе выполнения алгоритма показаны в таблице:

Входной символ	Действие	Стек
4	Кладём в стек	4
1	Кладём в стек	4 1
-	Извлекаем из стека два операнда, применяем операцию "-", кладём результат обратно	3
2	Кладём в стек	3 2
*	Извлекаем из стека два операнда, применяем операцию "*", кладём результат обратно	6
	Входные символы закончились, берём из стека ответ и выдаём его

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

Запишем реализацию этого простого алгоритма с помощью Haskell. Для простоты предположим, что все токены отделены разделены пробелами, то есть входная строка представляется в виде "6 1 3 - 4 * +".
Подумаем, что нам нужно сделать для написания программы:
1. Определить тип токена, который мы будем использовать для представления операндов и операторов.
2. Преобразовать входную строку в список токенов.
3. Вычислить выражение, определённое данными токенами.
4. Обеспечить операции ввода-вывода.

Для начала назовём нашу программу и импортируем полезные модули. IO - для ввода/вывода, Data.Map - ассоциативный массив, Maybe - для представления результатов вычислений, которые могут не вернуть ожидаемый результат - например поиск по ключу в Map.

module Main where
import IO
import Maybe
import qualified Data.Map as M

Теперь определим тип токена - Token, который обладает двумя конструкторами типа - Atom Int (принимает на вход целое число) для представления чисел и Op (Int -> Int -> Int) (принимает на вход бинарный оператор, то есть функцию с двумя параметрами, работающую с целыми числами). Таким образом токены можно будет создавать таким образом: Atom 7, Atom 0, Op (+), Op (-) и т.д.

data Token = Atom Int | Op (Int -> Int -> Int)

Определим теперь соответствие между текстовым представлением поддерживаемых операторов и токенами. Сделаем это в виде карты (Map), где ключом будет строка, а значением - соответствующий токен:

operatorsTable :: M.Map String Token
operatorsTable = M.fromList [
  ("+", Op (+)),
  ("-", Op (-)),
  ("*", Op (*)),
  ("/", Op div),
  ("^", Op (^)) ]

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

Теперь попробуем получить список токенов из входной строки. Поскольку мы предложили, что токены будут разделены с помощью whitespace, то мы можем воспользоваться стандартной функцией words, которая разбивает строку на список строк используя в качестве разделителя whitespace. Затем применим к каждой полученной строке функцию parseToken, которая парсит отдельно взятый токен. Сделать это можно с помощью функции map, которая принимает на вход два аргумента: некую функцию и список, и затем применяет указанную функцию к каждому элементу списка. Например получить квадраты первых трёх натуральных чисел можно так:

  map (^2) [1, 2, 3] = [1, 4, 9]

Точка же означает композицию функций , т.е. (f . g) x = f (g x)
Почитать о map и других базовых функциях для работы со списками немного более подробно можно здесь.
Таким образом, мы применяем map parseToken к результату полученному от words.

parse :: String -> [Token]
parse = map parseToken . words

Сама функция parseToken работает так: мы смотрим (lookup) в нашу таблицу операторов в поисках оператора по строке. Если мы находим его ('Just op'-ветка case-выражения), то возвращаем, если же нет (Nothing), то считаем что это число и создаём новый токен Atom и заносим туда число, которое преобразуем из строки функцией read.

parseToken :: String -> Token
parseToken t = case (M.lookup t operatorsTable) of
  Just op -> op
  Nothing -> Atom (read t)

Теперь нам необходимо реализовать главную часть алгоритма - вычисление выражений на основе стека. Реализуем это в виде функции evaluate, которая принимает на вход список токенов, который может быть получен от функции parse и выдаёт результат - целое число.

Для вычисления будем использовать промежуточную функцию evaluate'. Кавычка, которая часто читается как "штрих", является обычным символом языка, часто используется для того, чтобы показать что одна функция является вспомогательной функцией другой, или что две функции выполняют похожие действия.
У функции evaluate' появляется дополнительный параметр - стек, представленный в виде списка целых чисел. Таким образом тип этой функции [Token] -> [Int] -> Int
[Token] - список токенов, которые ещё нужно "посчитать"
[Int] - стек, в который кладутся числа
и возвращает она результат вычислений - Int.

В начале стек пуст, потому изначально мы вызываем evaluate' с пустым списком в качестве второго параметра.

evaluate :: [Token] -> Int
evaluate tokens = evaluate' tokens []

Теперь нужно производить различные действия в зависимости от того какой токен поступает на вход. Можно, конечно, реализовать это обычным if-ом, но в Haskell есть гораздо более мощный и изящный инструмент - сопоставление с образцом (pattern matching). Работает он так: мы пишем несколько определений функции (pattern-ов) для различных наборов параметров и, сопоставив, компилятор сам сможет определить какой из вариантов подходит (matching).

Например safe функцию деления можно определить так:

 myDivision x 0 = error "division by zero!"
 myDivision x y = x / y

При вызове myDivision 4 2, компилятор выберет второе определение (поскольку сопоставление x = 4, 0 = 2 не подходит), а сопоставление (x = 4 , y = 2) - вполне. Кроме того, при сопоставлении производится и означивание параметров, то есть x станет равным 4, а y = 2. В качестве образцов для параметров можно применять и более сложные конструкции, например рассмотрим классическое рекурсивное нахождение длины списка:

 myLength [] = 0
 myLength (x:xs) = 1 + myLength xs

здесь мы пытаемся сопоставить параметр сначала с пустым списком, если это так - то его длина равна 0, а затем с непустым, при этом в x - помещается голова списка, а в xs - его хвост, и длина будет равна длине хвоста + 1. Операция (:) в (x:xs) означает "сцепление" головы с хвостом. Конечно, вторую строку можно записать и так:

 myLength list = 1 + myLength (tail list)

где tail list - определяет хвост списка, но такой вариант гораздо менее изящен :)

Что же, вооружившись знаниями о pattern matching, можно весьма эффективно записать функцию evaluate'. Нас интересует несколько случаев:
1) входной список токенов завершился
2) во входном списке - оператор Op
3) во входном списке - число Atom

В первом случаем нам необходимо вернуть вершину стека как результат:

evaluate' :: [Token] -> [Int] -> Int
evaluate' [] [x] = x

Во втором - необходимо взять два операнда из стека, произвести операцию op над ними и результат снова поместить в стек. Извлечение из стека можно сделать с помощью pattern matching, второй параметр имеет вид (x1 : x2 : s), таким образом в x1 и x2 - попадут нужные нам два верхних аргумента, а в s - будет находиться остаток стека. Затем мы производим операцию над ними (op x2 x1) и добавляем результат к стеку. Затем снова вызываем функцию evaluate' для остатка входного списка токенов и с модифицированным стеком.

evaluate' ((Op op ) : xs) (x1 : x2 : s) = evaluate' xs ((op x2 x1) : s)

В третьем случае - нужно просто переместить число из входного потока в стек:

evaluate' ((Atom n) : xs) s = evaluate' xs (n : s)

Во всех остальных случаях - выдаём ошибку, они значат, что выражение было неправильным (заданы не все операнды, остаток в стеке после выполнения всех операций и т.д.). Для того, что механизм pattern matching обязательно попал в этот образец можно воспользоваться "ничего не значащей" переменной "подчёркивание" _, которая матчится в любом случае.

evaluate' _ _ = error "Error in evaluating: incorrect expression"

Теперь ввод-вывод. Сделаем мы его с помощью магической функции interact, которая работает следующим образом: считываем из stdin ввод, применяет к нему некоторую функцию и выводит результат в stdout. Таким образом, например, для того чтобы просто вывести ввод можно сделать так:

 main = interact id

где id - функция которая просто ничего не делает со своим аргументом.
Нам же надо кое-что сделать, а именно: разбить ввод на строки стандартной функцией lines, каждую из строк распарсить нашей функцией parse, затем вычислить с помощью evaluate, отобразить результат с помощью show. Затем все строки скрепить воедино функцией unlines, а потом можно и выводить. Весь этот набор реализуется такой вот строчкой:

main = interact (unlines . map (show . evaluate . parse) . lines)

Программа готова. Можно сохранить её как pf-eval.hs и запустить в интерпретаторе Haskell с помощью

ghci pf-eval.hs

или же скомпилировать командой

ghc --make pf-eval.hs

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

Пример работы программы:

sphynx@behexen:~/haskell$ ghc --make pf-eval.hs
[1 of 1] Compiling Main             ( pf-eval.hs, pf-eval.o )
Linking pf-eval ...

sphynx@behexen:~/haskell$ ./pf-eval
1 2 +
3
2 5 1 - ^ 2 * 3 +
35
1 + +
pf-eval: Error in evaluating: incorrect expression

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

Ваши замечания, вопросы и пожелания - приветствуются!

Полезные ссылки:
Механизм pattern matching
Постфиксная запись операторов
Сайт языка Haskell
Неплохой учебник по Haskell

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

module Main where

import IO
import Maybe
import qualified Data.Map as M

data Token = Atom Int | Op (Int -> Int -> Int)

operatorsTable :: M.Map String Token
operatorsTable = M.fromList [ 
  ("+", Op (+)), 
  ("-", Op (-)), 
  ("*", Op (*)), 
  ("/", Op div),
  ("^", Op (^)) ]

parse :: String -> [Token]
parse = map parseToken . words

parseToken :: String -> Token
parseToken t = case (M.lookup t operatorsTable) of
  Just op -> op
  Nothing -> Atom (read t)

evaluate :: [Token] -> Int
evaluate tokens = evaluate' tokens []

evaluate' :: [Token] -> [Int] -> Int
evaluate' [] [x] = x
evaluate' ((Op op ) : xs) (x1 : x2 : s) = evaluate' xs ((op x2 x1) : s)
evaluate' ((Atom n) : xs) s = evaluate' xs (n : s)
evaluate' _ _ = error "Error in evaluating: incorrect expression"

main = interact (unlines . map (show . evaluate . parse) . lines)

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

module Main where

import IO

data Token = Atom Int | Op (Int -> Int -> Int)

parse = map parseToken . words 

parseToken "+" = Op (+)
parseToken "-" = Op (-)
parseToken "*" = Op (*)
parseToken "/" = Op div
parseToken t   = Atom (read t)

evaluate ts = case foldl foldF [] ts of
	[x] -> x
	_   -> error "incorrect expression!"

foldF (x1:x2:stack) (Op op) = (op x2 x1) : stack
foldF stack (Atom n) = n : stack

main = interact (unlines . map (show . evaluate . parse) . lines)

Равны ли 0,(9) и 1? Периодические дроби.

Tue, 27 Mar 2007 20:53:33 GMT

Отвечавшим на мою анкету и думавшим над вопросом про 0,(9) посвящается :)

Как-то сидели мы с martreya, iiryna и deadvom в пиццерии и мне почему-то пришёл в голову вопрос, который я позже задавал в анкете:

Равны ли числа 0,(9) и 1?

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

Как мы знаем, число - это одно из основополагающих понятий математики, мир чисел постоянно пополнялся на протяжении развития человечества. В первом классе мы изучали самые первые числа: 1, 2, 3... Эти числа называются натуральными, и их множество обозначается буквой N. В рамках этих чисел можно отлично выполнять операции сложения и умножения. Если же мы захотим применять вычитание, то из подсознания выплывает фраза вроде "Из 2 яблок нельзя вычесть 4" или что-то в этом духе. Таким образом, мы получаем какие-то ограничения, которые расширяются введением отрицательных чисел. Множество всех отрицательных и положительных чисел называется множеством целых чисел и обозначается буквой Z. В рамках этих чисел отрицание уже выполняется без всяких проблем (2 - 4 = -2).

Следующей общеизвестной арифметической операцией является деление. Если поделить 1 на 2, то получится число не из множества целых чисел. Таким образом, снова придётся расширять известные числа, чтобы вместить результаты и этой операции. Числа которые представимы в виде частного, то есть дроби m / n (m - числитель, n - знаменатель) - называются рациональными числами (множество Q). По своей сути, дроби - это как раз и есть рациональные числа, то есть обыкновенная дробь представляет собой частное, а результат деления числителя на знаменатель и есть рациональное число. Опять же, вспомнинаем школу и на ум приходят задачи типа "сложить треть яблока с половиной яблока" и некоторые проблемы, возникающие при сложении дробей. Проблема состояла в том, что их надо было приводить к общему знаменателю (то есть 1/3 + 1/2 = 3/6 + 2/6 = 5/6), поскольку складывать без проблем можно было только дроби с одинаковым знаменателем. Соответственно, для того, чтобы от этих проблем избавиться, и из-за того, что у нас принята десятичная система счисления, были введены десятичные дроби. То есть такие дроби, у которых знаменатель - какая-то степень 10, то есть 3/10, 12/100, 13/1000 и т.д. Записывают их либо с запятой как у нас - (2,34) , либо с точкой, как принято на Западе (2.34).

Возникает вопрос: "а как перевести обычные дроби в десятичные?". Вспоминая деление уголком, можно набросать нечто такое:

Если говорить формально - то задача перевода из обычной дроби в десятичную представляет собой задачу нахождения такой наименьшей степени десятки, которая будет делиться на знаменатель заданной обычной дроби. То есть например для перевода дроби 3 / 8: берём знаменатель 8 и перебираем степени 10 до тех пор, пока какая-то степень 10 не станет делиться на 8: 10 не делится, 100 не делится, а вот 1000 делится (1000 / 8 = 125), значит 3 / 8 = 375 / 1000 = 0,375.
Однако, что делать, если такой степени не находится или в случае деления уголком - процесс не заканчивается? Например, попробуем поделить 1 на 3:

Как мы видим - процесс через некоторое время зацикливается - то есть повторяются те же остатки, и мы точно знаем, что следующие цифры будут повторять предыдущие.
Таким образом имеем, что:

1/3 = 0.333333...

Терпение, мы уже близки к ответу на вопрос :) Для того, чтобы отразить тот факт, что тройка в десятичной записи числа 1/3 повторяется и не писать троеточий - было введено специальное обозначение 0,(3). Часть в скобках называется "периодом" дроби, то есть бесконечно периодически повторяющейся частью дроби, а сама дробь - периодической. Таким образом, запись дроби с периодом является лишь иной формой записи обычного рационального числа, возникающей при переходе к конкретной системе счисления (в нашем случае десятичной) и период появляется, если в разложении на простые множители знаменателя уже сокращённой дроби присутствуют сомножители, на которые не делится основание системы счисления (например 6 = 2 * 3, 10 не делится на 3, потому у дроби 1/6 есть период в десятичной системе счисления). Кроме того, можно показать, что любая периодическая дробь является рациональным числом (то есть числом вида m / n), всего лишь представленным в альтернативном виде.

Таким образом можно смело записать что 0,(3) = 1/3, поскольку это одно и то же число, записанное различным образом. Соответственно, умножив на 3 каждую из частей уравнения, мы получаем, что 0,(9) = 1. Такое доказательство немного напоминает магию, однако всё дело в том, что по сути не существует чисел, разделив столбиком которые, мы могли бы получить число 0,(9) так, как мы получили 0,(3) разделив 1 и 3. Так что можно и усомниться в праве на существования у этого числа. Однако было бы нецелостно и математически нестрйоно отказываться от периодической формы записи в том случае, если число в периоде - 9, то есть 0,(9) или 1,(9) и т.д.
Поэтому число 0,(9) в данный момент вполне признано и является лишь альтернативной, неудобной и ненужной формой записи числа 1.

Как мы видим, определение периодических дробей не имеет никакого отношения к рядам, анализу бесконечно малых величин, пределам и тому подобным вещам, преподаваемым в высшей школе.
Резюмируя, можно сказать, что данная форма записи является всего лишь артефактом, вызванным применением конкретных систем счисления (в нашем случае десятичной системы). Насколько мне известно, некоторые математики (которых цитировал в одной из своих статей весьма известный Д. Кнут) ратуют за упразднение таких двузначных и спорных представлений чисел как 0,(9) и некоторых других.

Полезные ссылки по данному вопросу:
Блог Ильи Бирмана, в котором он расcматривает похожий вопрос
Статья из Википедии о 0,(9) и 1 (англ., рус.)
Определение рационального числа на Википедии
О периодических дробях и их свойствах на MathWorld.com (англ.)
Описание процесса Decimal Expansion (представление дроби в десятичной форме) на MathWorld.com (англ.)

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

Hello, space dog

Tue, 27 Mar 2007 00:57:30 GMT

Грядущему дню космонавтики посвящается.

Узнал такие вот факты о собаках-космонавтах.
В СССР чаще всего в космос отправляли именно собак, так как считалось, что они лучше всего переносят длительную вынужденную неподвижность, именно бродячих собак - из-за того, что они лучше переносят стрессы, и именно самок (сук) - из-за их темперамента и того, что им не надо поднимать ногу для понятного процесса :)

Первым живым существом с Земли, попавшим на Земную орбиту была собака Лайка. Её нашли, бродившей по улицам Москвы, затем она прошла конкурсный отбор среди трёх других собак. В процессе тренировок их садили во всё уменьшающиеся клетки для того, чтобы приучить к тесноте спутника, крутили на центрифугах и помещали в специальные шумовые машины, имитирующие звуки, возникающие при запуске и работе спутника. Кроме этого, собак специально приучали есть специальный питательный гель, который стал бы им пищей в космосе. Лайка погибла из-за стресса и перегрева, после нескольких часов пребывания на орбите, что некоторое время скрывалось. Лайка является одним из персонажей Монумента "Покорителям Космоса" в Москве, а также персонажем многих песен и книг, в том числе группы The Cardigans и писателя Харуки Мураками.

Другими, не менее знаменитыми космонавтами были Белка и Стрелка:

Они отправились в космос в 1960-м году, в компании кролика, сорока мышей, всяческих растений и были первыми существами, успешно вернувшимися с орбиты обратно на Землю, проведя в космосе около суток. Через полгода у Стрелки даже родилось шесть щенков, одного из которых забрал себе Хрущёв и подарил его дочери президента США Джону Кеннеди. После смерти, тела Белки и Стрелки были сохранены. Тело Белки находится в каком-то музее в Москве, а Стрелки - является частью передвижной выставки и путешествует по миру.

А вот космонавты в космосе :)

Американцы же отправляли в космос преимущественно обезьян. Но это уже другая история :)

Geek-анкета

Sun, 18 Mar 2007 19:51:19 GMT

Вдохновившись начинаниями martreya в области анкетостроения, я тоже решил "вспомнить молодость", но при этом перейти на новый качественный уровень, вооружившись знаниями в области IT и околоайтишного юмора.
Итак, вашему вниманию предлагается небольшой окологикерский опросник. Я надеюсь, что ответы на вопросы принесут вам несколько минут радости и подтолкнут к интересным размышлениям :)
Отвечать желательно на большинство вопросов, однако если вопросы вызывают затруднение или непонимание - пропускайте без проблем.

Кроме этого очень welcome предложения по поводу улучшения структуры и содержания анкеты, например внесения в неё интересных элементов - рекурсий, замыканий и т.д. и т.п. :)

1. Кто вы? (можно писать несколько своих алиасов :))
2. Вы человек или робот?
3. Ваша любимая операционная система.
4. Куда деваются программы, когда их удаляют? Есть ли небесный сервер?
5. Что даёт вам Интернет?
6. Что для вас жизнь оффлайн?
7. Какая ваша любимая цитата с bash.org.ru (если есть)?
8. Как вы относитесь к учащению использования английских слов в русском языке в связи с компьютеризацией?
9. Самый значимый для вас человек в области информационных технологий?
10. Windows?
11. Какая ваша любимая числовая последовательность?
12. Вставьте то, что у вас сейчас в буфере обмена.
13. Что значит для вас слово "программирование"?
14. Верите ли вы в жизнь вне Земли?
15. Кто такой Ктулху?
16. Ваш любимый раздел математики.
17. Ваше отношение к свободному программному обеспечению?
18. Сколько компьютеров у вас дома?
19. Есть ли у вас любимый гаджет?
20. Каким браузером вы пользуетесь?
21. Любите вы решать задачи?
22. Равны ли 0,(9) и 1?
23. Считаете ли вы, что можно будет когда-либо полностью повторить работу мозга?
24. Сколько знаков числа "пи" вы помните наизусть?
25. Что вы знаете о танцах с бубном?
26. Доводилось ли вам заниматься сексом с человеком, с которым вы познакомились по интернету?
27. Какой ваш любимый сайт?
28. Пользуетесь ли вы ICQ (и другими IM-сетями)?
29. Участвовали ли вы в FIDO?
30. Ваша любимая цитата великих "компьютерщиков".
31. Что вы знаете о резиновых утятах?
32. Какие у вас есть замечания и пожелания к данной анкете?

Ванная, комбинаторы и волосы на лобке

Fri, 16 Mar 2007 23:06:57 GMT

Лёжа в ванной, думал о том, что ванная, в сущности, не очень удобное место для отдыха - здесь нельзя разместить ноутбук и нельзя даже взять с собой книгу (разве что ту, что совсем не жаль).
Здесь, конечно, доступны некоторые развлечения (обычно свойственные новорожденным), но лучше таки использовать её как надо - для расслабления :) Да, ещё там удалось попить джин-тоника из банки! :)

А, ещё задался там вопросом - зачем, интересно, волосы на лобке? Наверное можно занести куда-то в раздел "детские вопросы" :) Ответы и предположения - можно в комменты.

Ещё сегодня открыл для себя исчисление комбинаторов - вещь, которую мы совсем не изучали по дискретной математике, вполне интересно. Получается, что исчисление комбинаторов - это такое себе полупрограммистское исчисление без переменных. И комбинатор, по сути, представляет собой некий объект, который просто комбинирует свои входы (то есть те объекты, к которым он применён). А входы представляют собой те же объекты или комбинаторы. Они обычно обозначаются латинскими буквами и имеют названия а-ля "канцеллятор", "дупликатор" и т.д. В этом исчислении существует единственная операция - применение комбинатора. В общем, кому интересно - можно почитать здесь: http://en.wikipedia.org/wiki/Combinator (увы, в русской Википедии по слову комбинатор находится только Остап Бендер :) - что совпадает с большинством откликов на эту тему в реале :)