Tom 7: Weird Chess Algorithms and Crap Art

Интересные эксперименты с шахматными алгоритмами — от полностью случайных до настоящих сильных играющих программ.

Автор (Tom 7, http://tom7.org) меня впечатлил, поэтому я пошел к нему на страничку и там нашел еще одну чудесную вещь, никак не связанную с шахматами или алгоритмами:

Crap art, тут что-то вроде манифеста: http://crapart.spacebar.org/

И как пример, album-a-day: идея в том, чтобы за день записывать музыкальный альбом, с нуля, не используя никаких предыдущих наработок. Мне показалось это очень интересной техникой. Моя проблема в том, что я по году хожу с какой-то музыкальной идеей в голове, и так и не могу из нее сделать даже один трек. А тут вообще экстремальная противоположность — за день сделать даже не трек, а целый альбом! 

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

UPD: под «количество бьет качество» я имею в виду метод, не конечный результат. Например, если поставить себе цель создать хорошую уличную/ фотографию, есть два противоположных подхода: (1) щелкать целый день все подряд или (2) поставить себе задачу снять — буквально —  только один кадр в день, но хороший; смотреть, ходить, планировать, постараться поймать то самое уникальное мгновение и нажать на спуск. Вопрос, какой метод даст лучшую фотографию с большей вероятностью? мое мнение на этот счет менялось, но сейчас я считаю что подход (1) лучше, как метод.

Windows 10, software development

Вопрос к программистам.
Впервые за много лет я купил Windows-лаптоп (чтобы пользоваться одной программы, которая есть только под Windows) и пытаюсь разобраться как им правильно пользоваться.
Последние лет 15 все связанное с разработкой делал только на Linux или Mac OS X.
Вопрос - можно ли под Windows организовать удобную среду для разработки, или лучше сделать компьютер dual-boot и поставить Linux?
Главные языки/библиотеки, которые интересуют:
- С++ (желательно C++14)
- Python + tensorflow
- R
- J
Дополнительные, nice to have, но некритично:
- Haskell
- Clojure
- Racket
- Elixir / Erlang.
Спасибо!

О категориях

В рассказе-эссе «Аналитический язык Джона Уилкинса» Хорхе Луис Борхес описывает «некую китайскую энциклопедию» под названием «Небесный эмпориум благодетельных знаний» (исп. «Emporio celestial de conocimientos benévolos»), в которой содержится классификация животных, согласно которой животные делятся на 14 категорий:
( Collapse )

Задачка которую я не решил

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

Задача такая:

Дается произвольный ненаправленный граф, и два человека играют на нем в следующую игру:
Первый игрок выбирает узел графа по своему усмотрению, У1.
Второй выбирает один из смежных с У1 узлов, У2.
Затем первый продолжает, выбирая смежный с У2 узел У3. И так далее. Каждый узел может быть выбран только один раз. Тот, кто не может сделать очередного хода, проигрывает.

Вопрос: Каким образом мы можем определить по графу, кто выигрывает при оптимальной игре - первый или второй?

Рояль

Созрел к покупке рояля среднего размера. Акустического, не цифрового.

Четкого бюджета нет. Есть надежда встретить инструмент, от которого не смогу отказаться. Ну, жду любовь с первого взгляда. Езжу по магазинам и объявлениям уже второй месяц, и пока явной любви не случилось, хотя симпатии были.
( Collapse )

Amidakuji

Наконец-то узнал, как называется этот метод: Amidakuji. См. тут: http://www.datagenetics.com/blog/may42014/index.html
Я о нем узнал когда-то давным давно из одной из книг Гарднера (но не помню, из какой). И с тех пор регулярно применяю этот метод для принятия решений, типа выбрать одну из N возможностей. По сравенению с кубиками или другим генератором случайных чисел у этого метода есть преимущество (по крайней мере, на мой взгляд). Когда я рисую "случайный" паттерн, теоретически, подсознательно я могу просчитать каждую траекторию, так что возможно что и выбор определяется подсознательно, и это то что мне и нужно.

P.S. Только заметил, что метод amidakuji похож на Гарднеровский, но более ограниченный - у них соединяются перемычками только соседние вертикальные линии, в то время как в Гарднеровском методе можно было соединять произвольные линии. Поэтому там было нужно гораздо меньше "уровней" чтобы достичь достаточной "случайности".

О сжатии случайных данных. Не гербалайф!

Вдогонку моей прошлой задаче - ее "случайный" вариант, в котором об оптимальности можно говорить строго.
У нас есть словарь из N строк, каждая строка - длиной M байт. Все символы - случайны, с равномерным распределением от 0 до 255.
Нужен алгоритм который позволит сжать-расжать словарь. Порядок строк в востановленном словаре неважен (т.е. главное, чтобы в декомпрессированном словаре было N строк, и между элементами исходного и декомпрессированного словаря можно было установить взаимно-ознозначное соответствие).
Требуется
1) определить теоретический предел компресии для произвольных N и M
2) спроектировать практический алгоритм, который даст наилуший ожидаемый коэффициент компрессии для заданных N и M
Задача (1) - несложная, а вот (2) - мне кажется более интересной.

Задачка про алгоритм компрессии

Есть текстовый файл длиной, скажем, 100 тысяч строк. Каждая строка - примерно 10-20 байт. Порядок строк - неважен. То есть, другими словами, есть просто неупорядоченный набор строк. Как его лучше всего сжать (пооптимальнее)?

Звучит как что-то что должно быть давно решено, но сходу не вспомню чтобы я это где-то видел. Наиболее естественным кажется представить набор как trie и его закодировать. Но не уверен, что это будет оптимально. В голове есть еще несколько идей, надо обдумать. В качестве теста, наверное, можно взять /usr/share/dict/words.