?

Log in

No account? Create an account

Предыдущий пост Поделиться Следующий пост
Современное программирование на примере словогенерации
lex_kravetski


Современное программирование на примере словогенерации

Говоришь людям, что в современном подходе к программированию всё уже не так, как раньше — не верят. Однако не только управление памятью, но и циклы отходят в прошлое. И что там циклы — даже условия, оформленные в виде «if-then-else», в хорошем коде теперь нечасто встретишь. И перехват ошибок при помощи «try-catch».

Разумеется, на это временами возражают не только прошаренные граждане, тридцать лет назад для интереса изучавшие программирование по первой попавшейся книге, но и даже некоторые вроде бы программисты. Которые заодно постоянно порождают код, полный контрпримеров к «отходят в прошлое», поскольку не подозревают, что можно как-то иначе.

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

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

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

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

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

И вот оттуда возникает идея поручить придумывание слов компьютеру. Ну а сами сценаристы потом из списка выберут наиболее прикольные.

Любой, кто пытался думать на тему того, как случайным образом сгенерировать слово, довольно быстро понимал, что для этого совершенно не подходит случайный выбор буквы для каждой позиции. Слова в этом случае получаются не просто некрасивыми, но и совершенно нечитаемыми. Конечно, вероятность генерации прикольного слова не нулевая, но довольно низкая, а потому придётся перерывать горы шлака, чтобы такое слово отыскать среди десятков тысяч «фдвлафлдывайу» и «ыйзукъчамвафкнйук».

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

В общем, единственный вариант — учитывать то, что не любая буква может идти после любой буквы. Вот «и» после «т» встречается, а после «ы» — нет.

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

Вдобавок, внезапно, всё равно генерируется множество нечитаемых слов. Да, каждая пара букв реалистична, но вот сочетание из трёх и более букв при этом может оказаться нереалистичным. Например, встречаются сочетания «тр» («трамвай»), «рн» («корни») и «нт» («грунт»). Если алгоритм пользуется исключительно разрешёнными парами букв, то сочетание «трнтрнтр» для него вполне допустимо. А для нашего фэнтезийного мира — обычно нет.

То есть желательно использовать более длинные цепочки. Однако количество возможных вариантов растёт как степенная функция от количества букв в них. Если возможных пар в русском языке 33*33 = 1089 (что, впрочем, не вполне так, поскольку в названиях городов ещё могут быть, как минимум, апостроф, дефис и пробел), то троек уже 33*33*33 = 35 937. Задолбаешься перебирать.

А четвёрок — 1 185 921. Тут ручное их перечисление уже за гранью реальности.

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

Отсюда напрашивается решение: надо взять список городов некоторой страны или региона и извлечь из них допустимые сочетания. А потом именно ими пользоваться для генерации названий — тогда эти названия будут в основном читабельными и нести в себе некий «колорит» этого региона.

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

Прошло время, и мне снова захотелось реализовать этот алгоритм. В том числе потому, что, например, в Mathematica есть возможность запрашивать названия городов по регионам, что изрядно упрощает составление списков.

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

Реально, смысл современных подходов именно в этом: примерно так же, как я описывал алгоритм на естественном языке, он должен описываться и на языке программирования. У нас есть некие множества, и мы их неким способом трансформируем.

Предположим, у нас уже есть «словарь» — множество имён собственных. Для простоты рассуждений, их пока что будет всего два.

words = {"Lond", "Lund"};


Для начала нам надо реализовать превращение слова в цепочки букв. Формат их описания будет максимально простой. Что-то типа

Lo → n

Lon → d


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

Если нам дано слово и номер буквы, для которой мы строим цепочку, то способ построения этой цепочки практически очевиден. Мы берём первые n–1 букву, добавляем стрелку, а после неё добавляем n-ную букву.

makeChain[word_, n_] := StringTake[word, n - 1]  →  StringTake[word, {n}]


Работает оно примерно так.

makeChain["Lond", 2]

L → o


makeChain["Lond", 4]

Lon → d


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

Возможно, кто-то на этом месте уже задумался о цикле. Однако цикл нам нафиг не нужен: нам ведь надо сконструировать список правил, а не повторить что-то там сколько-то там раз.

makeChains[s_] := Table[makeChain[s, n], {n, 2, StringLength@s}]


f@x в языке Wolfram — полный синоним f[x]

Да, тут есть что-то, напоминающее цикл: «n меняется от 2 до длины строки». Но я не думаю об данной подзадаче в такой терминологии. Я не думаю: «нам надо инициализировать переменную числом 2, а потом увеличивать это число на один, пока оно не станет равным длине строки». Нет, я думаю «нам надо создать список результатов функции makeChain для одной и той же строки, но для разных порядковых номеров буквы».

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

makeChains["Lond"]

{L → o, Lo → n, Lon → d}


Теперь надо проделать аналогичное для каждого слова из словаря и соединить результаты.

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

makeAllChains[dict_] := makeChains /@ dict


f /@ list — это краткая запись Map[f, list]. «Применить функцию f к каждому элементу списка, чтобы создать новый список — с результатами».

f /@ {1, 2, 3}

{ f[1], f[2], f[3] }


makeAllChains[words]

{ {L → o, Lo → n, Lon → d}, {L → u, Lu → n, Lun → d}}


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

Во-первых, нам нужен обычный список, а не набор вложенных.

makeAllChains[dict_] := makeChains /@ dict // Flatten


x // f — полный синоним f[x]

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

makeAllChains[dict_] := makeChains /@ dict // Flatten // DeleteDuplicates


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

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

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

Это — ещё одна трансформация: ко всем словам надо дописать символы начала и окончания (для этого я буду использовать один и тот же символ — подчёркивание).

stopSign = "_";
signs[dict_] := stopSign ~~ # ~~ stopSign & /@ dict

signs[words]

{ _Lond_, _Lund_}


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

makeAllChains[dict_] := makeChains /@ signs@dict // Flatten // DeleteDuplicates

makeAllChains[words]
{_ → L, _L → o, _Lo → n, _Lon → d, _Lond → _, _L → u, _Lu → n, _Lun → d, _Lund → _}


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

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

То есть нам было бы удобнее, если бы список правил сразу бы содержал списки вариантов следующей буквы. Сейчас, например, у нас есть два варианта того, что может идти после «_L»:

{ _L → o, _L →  u}


Но было бы удобнее, если бы оно хранилось в другой форме:

_L → {o, u}


Иными словами, нам нужна ещё одна трансформация: группировка правил по «ключу» — левой от стрелки части.

makeRules[dict_] := GroupBy[makeAllChains@dict, First@# &]


Вторым параметром GroupBy тут передана функция извлечения первой части выражения со стрелкой, созданная прямо на месте — без имени функции и имени параметра.

Но пока что получается не совсем то, что хотелось бы.

makeRules[words]

<|_ → {_ → L}, _L → {_L → o, _L → u}, _Lo → {_Lo → n}, _Lon → {_Lon → d} ,
_Lond → {_Lond → _}, _Lu → {_Lu → n}, _Lun → {_Lun → d}, _Lund → {_Lund → _}|>


Здесь действительно произошла группировка, но нам не нужно повторение «ключей» и стрелок в списках букв, возможных после данного сочетания. Благо, при группировке можно указать тот фрагмент, который следует оставить. Нам, в частности, нужна только вторая часть выражения — та, что справа от стрелки.

makeRules[dict_] := GroupBy[makeAllChains@dict, First@# &, Extract@{All, 2}]

makeRules[words]

<| _ → {L}, _L → {o, u}, _Lo → {n}, _Lon → {d}, _Lond → {_}, 
_Lu → {n}, _Lun → {d}, _Lund → {_} |>


На данный момент, вся программа занимает пять строк. И ещё одна строка понадобилась, чтобы как-то назвать символ подчёркивания.

При этом она делает уже практически всё, что нужно: берёт словарь и генерирует из него список цепочек с альтернативами.

Точнее, не список, а «ассоциацию» (её нам вернула функция GroupBy).

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

Делается это примерно таким образом:

myAssociation = <|"a" → 1, "b" → 2, "c" → 3|>

myAssociation[["b"]]
2


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

nextLetter[rules_, wordPart_] := RandomChoice@rules[[wordPart]]


Заметьте, сколь удобно рассуждать таким образом. Я просто формально записываю на языке программирования ровно то, что сказал на естественном языке: «Попросим у набора правил список букв, соответствующий уже сгенерированной части. А потом выберем из этого списка букву наугад». Я ведь в рассуждениях ничего не говорю про «циклы», «счётчики», «if-then» и так далее. Нет их и в написанной мной программе.

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

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

Так вот, теперь у нас есть генерация буквы и остаётся описать генерацию слова целиком.

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

proceed[rules_, wordPart_, letter_] := With[
{r = wordPart ~~ letter},
proceed[rules, r, nextLetter[rules, r]]
]


Окончиться процесс должен на генерации подчёркивания — конца слова. Тут, казалось бы, нужно условие, но мы обойдёмся без него — просто объявим частный случай proceed: уже не для произвольной буквы, а для подчёркивания, названного нами stopSign.

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

proceed[rules_, wordPart_, stopSign] := 
StringTake[wordPart, -(StringLength@wordPart – 1)]


Чтобы запустить процесс, нам надо вызвать proceed со знаком подчёркивания в качестве затравки.

rules = makeRules[words];
proceed[rules, stopSign, ""]


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

Вот вся содержательная часть программы.

stopSign = "_";
signs[dict_] := stopSign ~~ # ~~ stopSign & /@ dict

makeChain[word_, n_] := StringTake[word, n - 1] → StringTake[word, {n}]
makeChains[s_] := Table[makeChain[s, n], {n, 2, StringLength@s}]

makeAllChains[dict_] := makeChains /@ signs@dict // Flatten // DeleteDuplicates

makeRules[dict_] := GroupBy[makeAllChains@dict, First@# &, Extract@{All, 2}]

nextLetter[rules_, wordPart_] := RandomChoice@rules[[wordPart]]

proceed[rules_, wordPart_, letter_] := With[
{r = wordPart ~~ letter},
proceed[rules, r, nextLetter[rules, r]]
]
proceed[rules_, wordPart_, stopSign] := 
StringTake[wordPart, -(StringLength@wordPart – 1)]


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

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

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

cut[len_][wordPart_] := StringTake[wordPart, -Min[len, StringLength@wordPart]]


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

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

stopSign = "_";
signs[dict_] := stopSign ~~ # ~~ stopSign & /@ dict

cut[len_][wordPart_] :=  StringTake[wordPart, -Min[len, StringLength@wordPart]]

makeChain[word_, n_] := StringTake[word, n - 1] → StringTake[word, {n}]
makeChains[s_] := Table[makeChain[s, n], {n, 2, StringLength@s}]

makeAllChains[dict_] := makeChains /@ signs@dict // Flatten // DeleteDuplicates

makeRules[len_][dict_] := GroupBy[makeAllChains@dict, cut[len]@First@# &, Extract@{All, 2}]

nextLetter[len_][rules_, wordPart_] := RandomChoice@rules[[cut[len]@wordPart]]

proceed[len_][rules_, wordPart_, letter_] := With[
{r = wordPart ~~ letter},
proceed[len][rules, r, nextLetter[len][rules, r]]
]

proceed[len_][rules_, wordPart_, stopSign] := 
StringTake[wordPart, -(StringLength@wordPart – 1)]


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

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

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

gen[len_][dict_, size_] := With[
{rules = makeRules[len][dict]},
Table[proceed[len][rules, stopSign, ""], size]
]


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

Таким образом, количество сгенерированных слов будет отличаться от желаемого размера — size, — поэтому его следует рассматривать только как указание на порядок величины: сколько новых слов нам примерно нужно.

gen[len_][dict_, size_] := With[
{rules = makeRules[len][dict]},
Table[proceed[len][rules, stopSign, ""], size] 
// Select[! MemberQ[dict, #] &] 
// DeleteDuplicates
  ]


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

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

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

Однако уже в данном виде программа выдаёт ответ «мгновенно» — за столь короткое время, что кажется, будто бы ответ появился сразу же после запуска. Имеет ли смысл ускорять её ещё сильнее?

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

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

Для оптимального баланса между «стильностью» и отличием от исходных слов хорошо подходит длина буквосочетаний 3 (соответствие трёх предыдущих букв одной следующей за ними).

Попробуем это на примере городов Московской, Воронежской и Брянской областей.

gen[3][words, 100]

Шерелицыно, Грибаново, Нахабинка, Юбилка, Латная  Посад, Хорловорохол, Электрогоробьевский, Черноговая Чигла, Архановский, Вождь Пролёв, Вербино, Вересенский, Павловка, Быковск, Абрамон, Ореховицк, Землянец, Пирогорногожск, Бронки, Юбилейный Ткач, Фирсаново, Фирский, Вишняковохопёрск, Сход, Ватутинский, Шиловая Усмань, Средний Пойма, Галь, Купавловка, Черустиль, Лытка, Яково, Чеховохово, Ильича, Пречицы, Электростантемироголовка, Кубино, Щёлковка, Обуховица, Шерельский, Щёлковская, Яковский, Высокольский, Гальный, Эртильщик, Шерея, Хотьковский, Наровск, Пересвет, Куровка, Яхромайск, Елань, Мишеронеж, Пеский, Шиловка, Жуково, Щёлковорино, Кратовка, Пущиновское, Пречисточный, Зелешинское


Если же хочется более вычурных названий, то можно пользоваться длиной 2.

gen[2][words, 100]

Снеж, Купатовка, Фоминский, Углаховка, Желешие Стреский, Дорыбиновсковка, Шаточный, Уделево, Кальчиногорово, Ватутовский Тишерногинстань-Конскограсовский, Высогорлин, Углязинск, Эртовка, Фосенск, Уваный, Хоры, Фоммуно, Немячьевка, Ник, Елабиль, Песевск, Подренововсковомилесскиново, Ува, Щерно, Под, Бельщик, Лотьевка, Кашино-Архано, Юбино, Яхронна, Схово, Егорянец, Андезнарский, Узунь, Зверво, Щёлки, Мождедедокрезно, Черосталантилукий, Андеворки, Пиронеж, Химовка, Щердловопрупатино, Яхрогучково, Химонцовка, Андеденск, Фряные Дво, Элеск, Хорелезна, Узуно, Приатка, Чехово, Юбилёво, Прон, Рузалова, Долбы, Хорибангелободск, Внукий Голь, Дево, Увая Киский, Шерное, Элево, Икшальск, Шерестински, Ильчинов, Павна, Клинка, Пангелые Ворловск, Грибано, Кантилки Цюруднино, Эртошки, Лесногоронцов, Звенинск, Рождесски Восановоходедниново, Углесск, Шильчисоколенск, Зветарфинское, Речи, Увая, Фиринолектябряный, Удельинов, Элейны, Лобрязьма, Галоватурлинский, Завка, Яхрогоролесскраварбино, Щерберворолёво, Фирово, Галино, Видоково, Лик, Сычёв, Ашукий


Длина же 1 приводит к почти полной потере «стильности» названий. Хотя наверно тоже способна навести на какие-то идеи.

gen[1][words, 100]

Купаво, Аний, Хргльеборскинска, Юбагов, Ивовк, Вий, Невкахо, Уволбревки, Жа, Гаяняногицый, Щель, Протыноск, Ве, Фий, Чехома, Групана, Юбускалорая, Дугоерсковосковньсий, Пий, Нов, Бучнко, Ще, Щёвонскало, Крхоенскадеульший, Кеедря, Моруньскавоузвсконовкатиниродиново, Тк, Ний, Елёвоов, Увскореня Талонирая, Трстужний, Ро, Юбигохо, Рая, Ольерк, Яханининово, Нирич, Елолая Лухртнальёвиценовоме, Руд, Миноглнки, Искиновскорукод, Ренса, На, Ат, Шеро, Мы, Новстискикишекиц, Чевлинахононский, Новетеча, Иль, Повноволк, Узька, Эруха, Яхожд, Не, Элины, Гай, Лерины, Яко, Сежены, Льнье, Юбречий, Нашеротрха, Аня, Оло, Хилене, Яхо-Аль, Фоговой, По, Зукиго-По, Икзно, Зашежбов, Щёло, Эремкакало, Егопьщельк, Жингуч, Наязнскабины Внововск, Га, Ко, Путель, Фрово, Юбийсканозле, Юбихная, Схоро, Грыч, Аль, Па, Илутутвстый, Лытезиратино, Хреугининоший Ма, Щёвскиламчи


Далее всё генерируется с длиной буквосочетаний 3.

Фэнтезийные города Англии.

Quard, Kimby, Bigg, Mevagilpatrickley, Erskeardley Pysgow, Jarrow upon Thakeham, Pilston, Plymouthuntington, Polzeatlington, Jarryduffton, Falkyn, Kereloch, Gling, Fern, Queenfrew, Nafford, Quenilworth, Icklandrakewen, Armitagee, Eccleford, Redcaston, Ketter, Quartsmoreton, Billsingdon, Cleathaveliston, Midd, Ickland, Daven, Outwells, Spa, Tisborouglaston Hill, Nairnistore Vallode la Hayle, Lofthorpe, Athe Heley, Rigstol, Gnosallackleton, Keltham, Talgeley, Queenock, Axmin, Jarry, Prudhouse, Gourne, Fenwich, Vale, Chick, Kead, Codsallow, Quartford, Falkingwold, Ystablesen, Holkestewarty, Dyserbury, Falkerfossie, Fiskirknell Tunbarton, Eccleroeserth, Quart, Y Ferrel, Rhyd-y-coed, Queenham, Mullington, Vauxton, Hwlfford, Rath, Resowes, Nantry, Y Fell, Snai Bridgend, Eckington Tees, Swyreford, Glandovercards Heth, Ennislemerry, Queen, Fore, Usham, Capersfield, Yorkington, Wokington, Irth, Watley, Eaton Maltham, Tyneham, Mythe-Stree, Hwlffordan, Yorkardswich, Vallate, Fulbarch, Ickley, Crose


Фэнтезийные города Мексики.

Quetzan, Hala, Kana, Culia, Vega, Maltic, Xolorado, Sunlan, Xalomac, Vindaro, Rosas, Fuenas, Genez, Omealtenadales, Tolum, Dura, Bonfordia, Tzingo, Oyameca, Kilomaso, Xonapante, Olina, Coyocan, Tixtencon, Pablo Nuevo, Gometrociente, Juquitla, Vallenque, Axapula, Simojo, Kanaleranzala, Jarrazapones, Encada, Buctzoyoc, Unio, Alam Gordia, Vallac, Irimonfo, Ursulo Nueva, Refugio, Juarago, Ignacatitla, Luvian, Ciente, Gomerille, Gonza, Luviangama, Lazarenampalucaluca, Zictorral, Kantan, Granjo, Oxkutzcalche, Isla Mantlan, Domitlan, Copo, Autopainal, Xilianale, Joquixqui, Pistla, Playa, Kantala, Yuregollan, Vera, Nunkas, Forta, Magelistlan, Banos del Altamaro, Lampec, Treintas, Pemero, Nealtichuca, Viejo, Huamuinca, Queseca, Xadanindicuao, Tlaquichapu, Delgado, Yango, Jolapa, Ebanon Salvarez, Hosta, Ometrociente el Rios, Tzimoronanguilcalla Soltic, Alto, Dulco, Opichakan, Tasque, Hermos Rosa, Emilapimi, Zira, Domitl


Фэнтезийные японские города.

Gama, Mashimabarashima, Akasama, Ujiide, Ōkumi, Heki, Ibari, Ryugai, Nasuda, Munabae, Ofunami, Jimotsubama, Ōkumigawa, Zamatsu, Niigawa, Ōkumagata, Futtsuyama, Wata, Ureshi, Rumori, Itsuji, Fusonoichigenobu, Fuchioka, Bungota, Tsurumorozaki, Fuchima, Jimo, Sennuma, Kyotaketo, Otarumesaki, Natomigawa, Kajimi, Isahashiki, Ibigarai, Numa, Kukizawarazakiza, Odawa, Mima, Iyomiya, Esashikuzen, Hama, Ashi, Jimono, Bibara, Jimoda, Ebinoka, Gotegi, Zamachigauratano, Annan, Fuchi, Owara, Ayashi, Meiwazawa, Osakada, Zentsuka, Ichimatsuura, Fujishinan, Chata, Zushu, Numatsu, Joetsushi, Erimada, Yachinaka, Rumoto, Sukai, Shibai, Towara, Wara, Itsu



doc-файл
Публикация на сайте «XX2 Век»
Публикация в блоге автора


  • 1

Вот "и" после "т" встречается, а после "ы" - нет

Враги твои раболепствуют тебе, и ты попираешь выи их

Re: Вот "и" после "т" встречается, а после "ы" - нет

Родительный падеж. Хотя так может быть и со множественным числом в именительном. Однако не суть. Гипотетически мог бы быть такой топоним — «Вьюченные Выи». Но его нет.

ну опубликуйте статью на Хабре, посмотрим, что от нее останется )

либо цикл либо рекурсия, другого нет )

Собственно, тут много раз показано, что не только можно, а даже нужно, чтобы ни того, ни другого: только Map, GroupBy и т.д.

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

а от условий вообще не избавиться ))

От условий не надо избавляться. Надо избавляться от внутренних ветвлений. Особенно от многократно вложенных.

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

> Есть разные парадигмы программирования

Да. Например, есть годные, а есть херовые.


> давно уже от этого все, кто хотел, избавились даже в стандартном "императивном" программировании

Да. При помощи перехода на те языки, где есть ссылки на функции и замыкания.

да, грань между программистами и говнокодерами стирается постепенно
потому что последних - всё больше

Edited at 2018-07-20 02:55 (UTC)

> и всё дальше от минимализма и неинтуитивности Машины Тьюринга.

Правильно. Лямбда-исчисление гораздо интуитивнее ;-)

Да map, groupby (как и прочие элементы dataflow программирования) великая вещь.
Способная произвести революцию почти сравнимую с тем, что сделал в своё время php.

Немного не в тему

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

Но это, видимо, от незнания языка и культуры. Раз генерирующий алгоритм один и тот же, то, предположительно, "естественность" названий в среднем одинакова.

Наводит на известные мысли о том, что результат работы условного "бредогенератора" (например, выступление политика или какой-то псевдонаучный бред) - тем убедительнее, чем менее потребитель разбирается в теме.

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

>>в современном подходе к программированию всё уже не так, как раньше

Читаю ваши статьи про ФП, ув.Алексей и понимаю, что мы действительно живем в мире мультиправды.
Где в одной точке пространства фирменный компилятор с Си для микроконтроллеров PIC не позволяет объявлять переменные в произвольном месте внутри функции (а только в ее начале, ну как в Паскале). Где фирменный компилятор прошивки для ПЛИС с языка SystemVerilog и фирменный симулятор прошивки по-разному трактуют стандарт языка, так что один и тот же код вызовет синтаксическую ошибку или у симулятора или у компилятора. Где среды "из коробки" не обладают ни автоформатированием ни автодополнением кода. Где все библиотеки для микроконтроллеров (а какой прок с модных языковых конструкций, если нет концептуально соответствующих библиотек) написаны на чистом Си и никто их переписывать с учетом функциональщины не собирается и т.д.

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

Я ещё могу сказать, что есть целая куча так называемого "наследия", то бишь legacy, вроде управления энергосистемами или бухгалтерского учёта, родом ещё из восьмидесятых, в которых до сих пор есть фрагменты кода не то что на чистом Си, а скажем, на Фортране, в которых терминал наше всё (графический интерфейс есть, но выполнен на уровне Виндовс 95 и функции там далеко не все) и которые тупо боятся переписывать заново, а только накатывают понемногу новые фичи и графические плюшки. Куски кода на Фортране при этом остаются в неприкосновенности. Даже в относительно современных сферах вроде автомобильной навигации/мультимедиа - лезешь в исходный код фирменного устройства на БМВ каком-нибудь, а там банальный Си++ (который не сильно отличается от Си, т.е. объектов там с гулькин нос) пятнадцатилетней давности минимум. Мне это чем-то напоминает работу эволюции в природе.

  • 1