ermouth: (ang)

Благодаря https://nplus1.ru/news/2015/05/25/nash мне попался на глаза оригинал доказательства существования точки равновесия в играх с ненулевой суммой.

Оно выглядит так (клик – PDF с работой):

Снимок экрана 2015-05-27 в 23.00.46

Соотнесение некоторых терминов типа “product space” с, например, теорией множеств можно посмотреть в моём старом посте про HoTT, там табличка есть. Это, возможно, несколько облегчит понимание.

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

Теорему Какутани о неподвижной точке можно посмотреть в Вики, она достаточно понятна. Упрощённый механистический смысл этой теоремы – если какая-то сущность выпукла, у неё есть точка равновесия, лежащий внутри этой сущности.

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

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

Это можно объяснить даже школьникам. Очень красивое и простое доказательство, жаль, что я никогда не доходил до него раньше.

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

RIP, Джон Нэш.

J operator

May. 21st, 2015 11:51 pm
ermouth: (Default)

J – это от JUMP, “безусловный переход”, GOTO. Совершенно нехарактерная для современных высокоуровневых языков конструкция, а для функциональных – и вовсе практически табуированная.

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

Про J operator у Лэндина есть оригинальная работа 1965 года, клик по картинке – академический PDF.

Снимок экрана 2015-05-21 в 22.56.00

Абстракция эта – довольно любопытный зверёк. Это конструкт, который превращает блок кода по метке в лямбду сохраняя её собственный scope в месте объявления, плюс перекрывая этот scope локальным к месту вызова. После этого лямбда исполняется, но вместо return-а она делает jump обратно (или куда-то ещё).

И получается, что блок кода по метке как бы исполняется по месту вызова.

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

Любопытно, что приблизительно таких свойств конструкт я выдумывал, когда делал CoverCouch. Та-же песня – совмещение scope’ов, но не в общем, а в конкретном случае (что гораздо проще), исполнение и возврат результата по месту вызова мутированием аккумулятора в scope вызова.

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

1965 год. Не перестаю удивляться.

ermouth: (Default)

Отличный материал про промисы, от самого активного контрибутора PouchDB.

http://pouchdb.com/2015/05/18/we-have-a-problem-with-promises.html

Там хороший разбор, особенно для тех, кто до сих пор по-старинке коллбэками пишет. Куча примеров, ошибки разобраны – в том числе достаточно частые:

Снимок экрана 2015-05-19 в 19.09.24

Вообще, систематическое применение промисов порождает вот такой, например, код:

Снимок экрана 2015-05-18 в 19.08.45

Снимок экрана 2015-05-18 в 19.09.49

Это реальный код из cloudwall.me, слева – старт приложения, справа – старт системы. По читаемости с коллбэками не идёт ни в какое сравнение, конечно. Нельзя сказать то же о скорости и прожорливости, но всё не так плохо.

http://spion.github.io/posts/why-i-am-switching-to-promises.html

Так что да, главная проблема с промисами – что их готовить не умеют. С функционалом всё более-менее устаканилось.

ermouth: (ang)

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

Снимок-экрана-2015-04-20-в-0.12

Уважаемые френды кто про схемку спрашивал, так понятнее?

ermouth: (Default)

Новое модное веяние, во многом – просто красивое название для концепции distributed render, которая у меня оформилась в середине 2012. Дополнительно к distributed render это ещё и быстрая синхронизация локальных данных клиента и сервера, максимальная согласованность того, что в UI и того, что в главной БД.

Ну и главная фишка – более-менее единый код для клиента и для сервера.

Я с этими штуками за 3 последних года вдоволь наэкспериментировался вдоль и поперёк – просто не называл это isomorphic javascript. В этой связи у меня оформилось несколько стойких соображений.

Изоморфность, когерентность и диффы

Изоморфные веб-приложения – это, конечно, такая серебряная пуля. В идеале – отображение удалённой БД на UI, работающее в обе стороны в реальном времени.

Самая главная беда у нас по пути – канал связи. Мы заранее не знаем какой он у нас будет – и это главное соображение, почему серебряной пули не случится. Когда приложение исполняется локально, скорость отображения изменений UI на подлежащий документ известна и она очень высока.

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

Простой пример. У нас есть чатик, который дописывает узлы в какой-то док по мере появления реплик. Пусть он их передаёт diff-ами, например.

Мы начинаем передавать в чатик 10 картинок по 10 мегабайт каждая. Добавляем их в UI – и хотим написать реплику со ссылкой на одну из картинок.

Если мы требуем ссылочной когерентности – реплика не сможет быть отправлена в БД до того, как туда попадут картинки. Это, конечно, так себе чатик будет.

То-есть требование ссылочной когерентности отвалилось на простейшем юз-кейсе. Ну или нам надо сделать такую БД в которой два произвольных апдейта всегда коммутируют – что-то не видать таких, ога.

Итого: изоморфность – наверное, когерентность – видимо нет.

Декомпозиция задачи

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

Мы, в идеале, хотим иметь такую среду исполнения, приложения которой:

  1. можно использовать на клиенте как UI для модификации подлежащего документа,
  2. можно использовать на сервере как валидатор,
  3. можно использовать на сервере как параметризуемый шаблон, генерящий HTML,
  4. не должны заботиться, где вообще находится документ и его реплики.

Ну и мы подразумеваем, что у нас приложение – это одинаковая сущность и для клиента, и для сервера.

Условие №1, клиентский UI – чисто здравый смысл. Приложения – они для людей.

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

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

С точки зрения математики каждый валидный документ приложения образует неподвижную точку для функции, которая “вычисляет” приложение над документом.

С точки зрения пользователя это эквивалент операций Открыть >> Сохранить, после которого документ не должен измениться, и по пути не должно возникнуть никаких ошибок. Вот только всё это надо иметь возможность делать без UI.

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

Условие №3. Приложение как параметризуемый шаблон. Это считается главной серебряной пулей, чуть не самой желанной фичей. Дескать чтобы вот передать на сервер URL – а он тебе HTML-снапшот приложения в нужном состоянии.

Или не передавать – а попросить с сервера данные и отрендерить приложение на клиенте, но чтобы то же самое получилось.

Это серебряной пулей считается напрасно, хотя усилия по реализации предприняты в целом колоссальные. Это примерно так же переоценено, как responsive layouts. Да, иногда нужно, и даже удобно – но если всё так делать, то это очень ограничивает.

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

То-есть не надо смешивать две задачи:

  1. Максимально эффективно скормить гуглу вашу базы.
  2. Иметь на сервере функцию, которая может вам прислать HTML-снапшот вашего приложения в любом его состоянии.

Первая задача стОит, чтобы её решать, вторая – ну её нафиг.

Условие №4. Среда исполнения должна сама выбирать стратегию распространения изменений по уровням кэша (локальная БД >> удалённая БД или несколько удалённых БД, пиринговая доставка другим юзерам, дайджесты на емэйлы и тп).

Ну или как минимум давать максимально удобно конфигурировать параметры стратегии.

Для приложения все эти детали должны быть скрыты, у него одна операция – сэйв, и один ивент – внешний апдейт документа.

Я такую конструкцию в части API к БД смог довольно быстро собрать – но в целом оно довольно неудобно. С одной напрягает бардак с promise. С другой – с памятью.

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

Серверные API, напротив, просто обязаны давать возможность обрабатывать данные экономно с точки зрения монопольного занятия CPU и памяти надолго.

Это, вообще говоря, требования противоречивые (ситуация кста касается и пункта №2 про валидатор).

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

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

Итого

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

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

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

Вообще, думаю, тут не обойдётся без появления нового языка (или следующей итерации JS) – и он будет ближе к Erlang по компоновке кода и соглашениям, чем к JS.

MEAN

Dec. 8th, 2013 09:48 pm
ermouth: (ang)

MEAN – это Mongo DB + express.js + angular.js + node.js. Это такой новый LAMP – и он сыграет такую же роль в развитии небольших интерактивных многопользовательских проектов и особенно сервисов, как в своё время “сыграл” LAMP при взрывном росте количества небольших сайтов.

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

Как это было в LAMP

Хороший пример LAMP – Битрикс, который умеет всё, но ничего не умеет хорошо и быстро. Когда Битрикс был маленький, он был быстрый (хотя и дырявый). А потом стала ограничивать платформа – потому что иногда нужна быстрая key-value БД, а у тебя под рукой только MySQL. Потому что для организации расширяемой бизнес-логики по-хорошему язык должен поддерживать функции как объекты первого класса – а php это заумел только с 5.3 (медленно и через жопу). Потому что апач – это приемлемо для “классического” около-REST веб-сервера, но совсем плохо для организации IM-обмена. Ну итд.

Ровно то же самое будет происходить с MEAN. Покомпонентно в нём два слабых звена – Angular и Mongo. Разбираю.

Mongo DB

Это прекрасная NoSQL БД, когда у проекта нет дизайна. Не от русского слова “дизайн”, а от английского “design”. Ну то-есть нужна какая-то БД. Когда заранее неизвестно, что точно от БД требуется, но хорошо бы, чтобы БД умела всё, мало ли что понадобится. MongoDB (как и MySQL) такая и есть.


  1. Key-value – умеет, но небыстро, до Redis или Couchbase как до звёзд.

  2. Map-reduce – умеет, но очень медленно, до CouchDB как до звёзд.

  3. Репликация – умеет, но криво и ненадёжно, с Couchbase не сравнить даже.

  4. Индексы – умеет, но медленнее SQL.

  5. Geospatial index как бы есть, но нечеловеческий.

  6. Fault-tolerance вроде ничего, но для решения, которое настолько плохо масштабируется – до Riak как до звёзд.

  7. Write lock настолько страшен, что блокирует целую таблицу даже для чтения – то-есть как MyISAM в MySQL, но без вкусности в виде полнотекстового поиска в качестве компенсации )). Для асинхронного javascript-мира блокировка кста вообще абсолютное зло.

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

Angular

Всё, что нужно знать про Angular – это то, что если вы писали на php например
<div>Width = <?php echo (width/2.54); ?>см</div>, с помощью Angular вы будете писать
<div>Width = { {someObj.width/2.54;}}см</div>.

Оно имеет все те же родовые травмы, что и php – фрагментарность, недекларативность и “размазанность” кода, который затруднительно разделять на независимые компоненты.

Зато оно позволяет очень быстро делать простые какие-то проекты с несложным интерактивом.

UPD. После написания поста в ЖЖ вскрылась уязвимость. Код Angular выше исполнялся и заменялся на null, пришлось вставить пробел между { и {. Таким образом мы имеем явную проблему с Angular – типа XSS. Пусть оно называется XSAS – cross site angular scripting. Чёто не особо улыбается проверять юзеринпуты на то, могут ли они быть Angular-кодом.

Итого

В любом случае MEAN – это отличная альтернатива LAMP. Уже вовсю появляются хостинги под него (Nodejitsu, Heroku), codebase под js растёт бешенными темпами, оно всё модульное и легко настраивается.

Но это неуниверсальное решение для небольших проектов.

ermouth: (ang)

Вообще, удивляет диспропорция наград и общественного признания между Тимом Бернерсом-Ли и Брендоном Айком.

В появлении того интернета, что мы видим сейчас, роль Айка ничуть не меньше – он придумал javascript. И именно javascript превратил интернет в медиа и дал возможность соцсетям стать столь популярными – потому что сделал статичные страницы интерактивными приложениями.

Теперь связка js+браузер+WebGL становится платформой для игр. РПГ причём, реального времени – потому что стало хватать производительности. Пока это всё продукты кросс-компиляции с C++ в js – потому что бОльшая часть игр написана на C++ – но это не навсегда.

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

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

Догоняющей на этом рынке будет, как обычно, Microsoft – IE не поддерживает WebGL, равно как и движок js в IE оч медленный.

ermouth: (Default)

Такая сложно формализуемая штука, особенно для айтишников. Лорд Кельвин говорил – “что нельзя измерить, то нельзя улучшить”. Не уверен, что каждый инженер эту фразу знает, но подспудно верит в неё, кмк, едва ли не каждый.

Вера эта ложная, и чем дальше в XXI век, тем всё сильней это проявляется. И дело тут вот в чём.

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

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

Read more... )
ermouth: (Default)

Больше для себя, зафиксировать, предыстория здесь и здесь.

Прочитал первые четыре главы http://hottheory.files.wordpress.com/2013/03/hott-a4.pdf.  Первые две главы прочитал уже на два раза. Страниц там 475, а не 600.

Дальше много про математику, довольно нудно. В конце вывод о классах программ, для которых можно строго доказать вычислимость.

Read more... )

HoTT

Jul. 2nd, 2013 06:21 am
ermouth: (Default)

morfizm меня навёл на потрясающую совершенно базовую математическую теорию – HoTT. Собсно, у него-то шла речь о том, что несколько математиков разработали теорию и написали по ней научный 600-страничный труд используя… github. Морфизм это скорее как забавный курьёз привёл – а я пришёл в полный, неописуемый восторг.

В восторг от теории.

Я тут недавно писал про неподвижную точку, валидацию, вычислимость, то-сё… Так вот, цитатка одна:

Secondly, every type-forming rule conforms to a well-understood pattern: there is a part for formation (making a new type), a part for introduction (how to construct elements of that type), a part for elimination (how to extract information from an arbitrary element of that type), and a part for computation (how introduction and elimination interact). This uniformity makes the meta-theoretic analysis of type theory particularly simple, allowing proofs of “consistency by evaluation”.

Болд – от меня. Это вот отсюда, длинный довольно пост, который умеренно подготовленному читателю объясняет, чем же этот HoTT отличается от теории множеств.

Эта цитата соотносится с задачей из поста про неподвижную точку, да и вообще с конструкцией и идеологией jQuery.my так, как будто я про эту теорию знал, когда $.my придумывал. Я был просто потрясён.

Type-forming rule из цитаты – это манифест формы (или рекурсивно её фрагмента), прямо до мелких соответствий. То, что в цитате про inroduction, elimination и computation – это просто таки с точностью до замены терминов вот это http://jquerymy.com/tutorial/what-is-bind/. Все три этих действия у меня просто совмещены в одну функцию для краткости записи. Она просто в обе стороны работает, и для introduction, и для elimination, и для computation посредине.

Та же логика, один-в-один. Даже то, что эта форма может служить дочерним типом для другой формы прямо соотносится с системой построения типов в HoTT.

Элемент определённого типа в моём случае – это группа отображений множества состояний html-формы на множество состояний подлежащего js-объекта. Предполагается, что есть отображения в обе стороны всегда. Такая структура называется в теоркате группоид – и как раз на основе таких структур и выстроена HoTT-теория.

Которая ни много ни мало претендует практически на роль теории множеств в современной математике. И которая… это оттуда же, следующее предложение:

It makes type theory into essentially a programming language, at the same time as a foundational system, allowing the easy verification and construction of proofs by computers.

Так вот, есть уже такой language. В крошечном масштабике и под определённый круг задач, но есть. Жду, когда же наступит этот proof by computers – это ровно та задача, что я озвучивал в посте про неподвижную точку.

Напишу письмо чувакам, как осилю 600 страниц с гитхаба. Это очень интересно.

И неожиданно. Кстати, уважаемому morfizm: в группоиде, который в этой теории базовая конструкция, каждый морфизм – изоморфизм )

Что бы это ни значило.

ermouth: (Default)

Я недавно писал, что за день потерял $3000+ (в самом деле получилось чуть меньше). Это часть суммы контрактов на размещение рекламы в нашем новом проекте, которые были расторгнуты из-за неготовности к тому моменту (деньги не пришли, макет не подписан и т.п.)

Это решение было хоть и неприятным, но посчитанным. morfizm меня попросил писать про всякие мои дела – вот я сейчас и расскажу, как это посчитать, используя сеть Байеса.

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

И посмотреть на общую картину.

Рисковые факторы, по которым у меня была приемлемого качества статистика, получились такие:

Read more... )
ermouth: (Default)

Чёрный
Красный
Фиолетовый
Жёлтый
Голубой
Зелёный
Коричневый
Синий
Розовый
Оранжевый

Превед, ога )

ermouth: (Default)

Сегодня я впервые поинтересовался:

  • что значит точно слово “прокрастинация”
  • что такое китч
  • и что же делает JOIN в SQL.

Знал про всё, но не полностью. Удовлетворён, да.

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

И да, another failed romance.

ermouth: (Default)

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

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

Я полагаю, что к появлению предпринимателя определённого масштаба приводит довольно большой, но всё же ограниченный набор причин. Сложно предположить слёту, что это за причины, каково их взаимовлияние и какие у них “веса” в общем результате. Тем не менее, я верю в причинность в физическом смысле – и уверен, что набор факторов можно определить.

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

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

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

То-есть, это как-бы проверка алгеброй божьего промысла.

Идея, в общем, не нова – и её легко довести до абсурда (у Азимова есть рассказик “Профессия”, тамошняя система раздачи профессий – наверняка байесова сеть). Тем не менее, мне было б чрезвычайно любопытно посмотреть, что же приводит к появлению бизнесов нацмасштаба.

Вообще, кто-нибудь слышал про применение сетей Байеса в оценке перспектив в образовании? А?

ermouth: (Default)
Фотон

Рассказывают, что процесс исследования всего сущего на предмет наличия фотона учёный сопровождал комментариями: «та ктее жее он?!», «таа кутаа жее он патевался?!» и «пыл жее тут с утраа, я федь точнаа помню!». «Фот он!!» — радостно закричал учёный муж, обнаружив новую элементарную частицу. 

Больше про то, что такое фотон, читайте здесь.
ermouth: (Default)
Пучеглазка

Очень сильно красивый рекламный проспект о деятельности компании 8-) .

Взято отсюда.
ermouth: (Default)
Маркетолог

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

Встречаются исключения.
ermouth: (Default)

Мафия

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

С этого поста начинаю тэг def с лучшими определениями.

Profile

ermouth: (Default)
ermouth

September 2017

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 24th, 2017 04:53 am
Powered by Dreamwidth Studios