Где в жизни эти возникают парадоксы заключенного?

#парадокс

Да везде. Накидаю примеров.

Есть военный вариант парадокса – ловушка Фукидида или дилемма безопасности. Мы в нем прямо сейчас живем.

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

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

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

Поэтому Яндекс всегда идет в первую очередь в «красные океаны», рынок такси например. Потому что там всегда найдутся те, кто будет сотрудничать и Яндекс сможет подмять индустрию под себя.

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

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

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

Еще хочу добавить, что мир удивительно тесен временами. Я в 1999 году сделал игру мафия в интернете, как раз 25 лет назад на январских праздниках прогал.
Внутри получившейся тусовки были свадьбы и дети, и Ксения одна из таких. Так что я в некотором роде её крестный отец 😄. Её папа Евгений Кузнецов из СУНЦа, победитель олимпиад по информатике. И еще он написал лучший железный алгоритм для обработки jpeg, за который директор Интела ему жал руку и который до сих пор в интелловских процессорах и сидит, как я понимаю.

Ксения уже сама жжет, вместо того чтобы становиться чемпионкой по виндсерфингу пошла таки в ВУЗ, а там будучи студенткой уже несколько лет работает во ФРИИ, помогает продвигать на запад крутые проекты. Я для себя несколько лет назад пришел к выводу, что век программирования проходит и надо заниматься стартапами и бизнесом. И тут я вижу, что юное поколение знает все лучше нас. Причем если для меня понимание того, как устроен бизнес давалось кучей потраченных сил, времени и денег, и все равно это понимание на уровне иностранного языка. А для Ксении эти понятия просто родные. Короче я уверен, что дочка вполне может обогнать папу. Все для этого есть.

В общем подписывайтесь к ней на канал, и давайте вместе перевернем мир.

Почему часы тикают тик-так?
#физика #программирование #ооп #мысль

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

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

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

Завтра напишу, какой подход к архитектуре кода сложился у нас в команде.

Фиче-ориентированное программирование.
#программирование #архитектура

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

У нас есть своя специфика, так как мы в основном мы пишем модели для так называемого солвера целочисленного программирования.

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

Но некоторые фичи оказываются зависимы и приходится разбираться со всевозможными подслучаями, я это называю гиперкуб (10 разных флагов ~ 1024 комбинаций этих флагов). С гиперкубом мы боремся следующими способами. Там, где можно рефакторим фичи, чтобы из нескольких получилась одна. Если это невозможно, а получается куча нетривиальных случаев, то важные делаем, а на неважные пишем сообщение об ошибке Not implemented yet и останавливаем программу.

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

Бывает, нам надо решать похожие, но разные задачи. Например, планирование расписание работы конкретных людей на месяц, и одновременно стратегическое планирование на год вперед, где нет конкретных людей. Эти задачи как сиамские близнецы, с одной стороны существенно отличаются, с другой стороны куча общего.
1. Отдельно делать модели плохо - получается копипейст код, который потом провоцирует ошибки и который невозможно поддерживать.
2. Делать ООП модель с наследованием тоже совершенно неудобно, по причинам, описанным в предыдущем посте.
3. В результате ничего лучше, как сделать if-ы которые включают ту или иную голову мы не придумали. А с if-ами в целом все норм. Функция получается главная большая, но в целом читабельная, а сам код по общему числу строчек вполне компактный.

Могу еще добавить, что каждая фича имеет свой номер, делается в отдельной ветке гита с тем же номером, так что разработка становится достаточно удобной.
До нас я такой подход видел только в солвере SCIP.
Я не претендую на его универсальность, но для создания моделей и запуска их в солвере лучше мы ничего не нашли. Эта модель если что, у нас формировалась с 2009 года. ООП и функциональщину мы хорошо знаем. Я бы еще хотел поиграться с Julia и на макросах сделать DSL, но в целом это мелочи.

DeepMind AI решил 25 из 30 геометрических задач международных школьных олимпиад.
#новости #ии

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

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

https://www.nature.com/articles/s41586-023-06747-5#MOESM1

Продолжение про P=NP
#кейс #касдев #моделирование

На этой неделе поучаствовал вместе с заказчиком как эксперт в разговоре с уже их заказчиком. И продемонстрировал чудеса касдева и бизнес-аналитики. 😂

Задал напрямую вопрос:

“Господа. Вам на вход приходят прогнозные данные, которые явно ппп (пол/палец/потолок), особенно на год вперед. На кой ляд вам тогда абсолютная точность решения?”

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

Спрашиваю, а если решение не будет содержать такой кривизны, небольшой гэп не страшен?

Да говорят, вообще без проблем.

Занавес.

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

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

Напоминание.
Завтра в 12.00 в будет эфир с Ксенией, приходите!

Добавлю, что эфир будет на канале у Ксюши в 12.00

Вот запись эфира. Скоро также будет ссылка на видео.

Приоритеты задач.
#мысль #программирование #экономика

У вас есть 10 задач, которые надо сделать как определить приоритеты, что делать?
Очень просто, считаете приоритет по формуле <польза> / <потраченное время> и делаете первую задачу из списка.
Если польза не моментальная, а размазана во времени, то можно смотреть по ROI, то есть за какое время возвращаются инвестиции времени.
Мне в свое время взорвал мозг комикс xkcd, который я приложил. Оказывается, экономику можно применять не только к бизнесу, но и к программированию и даже к решению бытовых задач типа планирования дел и покупки бытовой техники.

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

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

#алгоритмы #бизнес #программирование #оптимизация

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

Варианты исправления:
1. Выбрать вместо одного бесплатного солвера другой бесплатный, но более качественный. Проверяется работоспособность солвера с различными тестами 2 дня. Вероятность улучшения 10%. В случае, если новый солвер потянет, переезд займет 1-2 недели.
2. Выбрать коммерческий солвер. Шансы, что он справится с задачей 20%. Проверка займет те же 2 дня. При выборе этого решения понадобится 1-2 недели на переезд плюс оплата коммерческого солвера, что сильно ухудшит себестоимость проекта (я не знаю цену, но пусть солвер стоит как полгода разработчика).
3. Написать эвристику. Есть перспективная идея, всем нравится. Шансы что заработает, оцениваются примерно в 50%. Можно за 1-2 проверить будет ли ускорение, а потом где-то за неделю сделать прототип эвристики и понять будет ли она работать или нет. При этом переход на эвристику усложнит код и замедлит последующую разработку на процентов на 20%.
4. Изменить модель так, чтобы она стала лучше работать. Есть идея которую проверять 3-5 дней и которая может решить проблему с вероятностью 5-10%.

Первичный приоритет простой. В первой задаче мы получаем 5% успеха в день.
Во второй без учета дедлайнов 20/120 = 0.16% успеха в условный рабочий день. Даже если потом проверка покажет что солвер все решает, 100%/120 = 0.83 < 5. То есть в любом случае выгодней сначала проверить бесплатный солвер.
В третьей задаче приоритет 50%/5 = 10 %/день. Самый высокий приоритет в ближайшей перспективе.
Четвертая задача – 10/5 = 2 %/день
На практике у нас есть жесткий дедлайн и проект близок к завершению.
Получается, что приоритеты задач: третья, первая, четвертая, вторая.

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

#мысль #бизнес #алгоритм #кейс

Хочу ко вчерашней теме про приоритеты еще добавить пару замечаний.

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

В этой системе приоритетов спрятана еще одна важная мысль.

Делай что любишь и люби что делаешь.

Надо понимать, чем именно ты занимаешься и работать исходя именно из этих приоритетов.
В этой формуле приоритетов зашито, что я выполняю заказ заказчика, то есть занимаюсь проектной деятельностью/бизнесом, и я уже не математик в полном смысле этого слова.
Я пробовал дать задачу по тестированию бесплатного солвера фрилансеру-математику, чтобы закрыть быстрее проект, но он отказался. Так как он математик и хочет решать именно математические задачи. Он бы согласился делать 4 задачу по изменению модели, а остальные ему неинтересны.

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

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

Результат стартапа думаю объяснять не надо.

Напишу про HADI цикл. Это очень важная штука при работе с рисками и исследованиями.

#мысль #rnd

HADI это акроним:
• Гипотеза (H) – какое-то наше представление, идея, которую мы хотим проверить.
• Действие (A) – Способ, которым мы будем проверять гипотезу, ну и реализация этого способа.
• Данные (D) – Любые показатели, на которые вы хотите повлиять.
• Инсайт (I) – не очень люблю это слово. Я бы назвал вывод.

Еще два важных момента, с которыми я как раз работал в прошлых постах.
• Вера (%) – вероятность успеха гипотезы на взгляд команды.
• Сложность – сложность выполнения задачи. Я меряю в днях или деньгах, можно просто в баллах от 1 до 5.

Этот фреймворк нужен, чтобы не было каши в голове, а процесс работы с гипотезами и рисками был отсмартован (то есть был по методике SMART). А это нужно просто чтобы не делать лишнюю работу, которой на самом деле может быть очень много, 50-80 и больше процентов.

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

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

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

Кстати, вопрос про SMART имеет смысл писать или это все знают?

#текучка #трекинг
Встречался недавно с одним заказчиком.
Чтобы договориться нормально об условиях success fee протрекал его по сути. 
Спрашиваю сегодня как дела, а он мне отвечает вот так:

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

Задачу кстати обсуждаем классическую, задача 2d раскроя материала. Жуткая классика, в СССР все книжки по оптимизации с этого начинались. Тем не менее готового свободного алгоритма со всеми необходимыми нюансами нет, и есть что прогать.
В принципе это наверно со всеми задачами так.

#математика #геометрия #задача_раскроя
Рассказывал заказчику по поводу 2д раскроя, что даже сложные примеры часто очень хорошо упаковываются. И если у нас одна деталь, для которой нало вырезать много копий. То надо обязательно делать алгоритм периодической упаковки.

Универсальный алгоритм написания алгоритмов.
#программирование #алгоритм #икр

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

1. Ставим правильно задачу. Выявляем все требования. Формируем цель задачи, то есть идеальный конечный результат по ТРИЗ.
2. Смотрим базовое решение, то есть то которое имеется на данный момент. Уточняем цель задачи с учетом этого.
3. Решение — это набор микрорешений, то есть выбранных величин булевых переменных. Например работает ли конкретный человек в конкретный час в конкретном месте конкретную работу – да/нет.
4. Рассматриваем зависимости микрорешений между собой.
5. Если есть независимые компоненты (горох) – отлично.
6. Если в компоненте есть зависимость (уровни) в одну сторону – отлично.
7. Выявляем в конце концов ядро задачи, которое уже нельзя упростить, потому что все микрорешения зависят друг от друга.
8. Смотрим на особенности входных данных. Возможно там есть некоторая закономерность, которая может все упростить.
9. Смотрим на требования по скорости, цене продвижения, объему используемых ресурсов.
10. Если задача слишком сложная, огрубляем и упрощаем её. Главное сделать лучше базового решения. После упрощения повторяем весь проход.

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

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

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

Важное свойство хорошего алгоритма.
#задача #алгоритмы #бутылочное_горлышко

Давно задачек не давал. Вот еще одна уже классическая, её когда-то давали на собеседовании в Microsoft.
Имеется 100-этажный дом и две одинаковые лампочки. Надо узнать с какого этажа сброшенная лампочка разобьется. За какое минимальное число попыток это точно можно узнать и какой алгоритм действий? Если бы лампочка была одна, то пришлось бы потратить последовательно 100 попыток, бросая последовательно с 1 по 100 этаж. А так как у нас две лампочки, то мы можем разбив одну продолжить эксперименты.

Порешайте пожалуйста сами, кто решил сам поставьте палец вверх, а кто нет – вниз.

Правильный ответ: 14 попыток.
Схема следующая.
Бросаем последовательно первую лампочку на следующих номерах: 14, 27, 39, 50, 60, 69, 77, 84, 90,95,99 ( это первые суммы ряда 14+13+12+…)
После того как первая лампочка разобьется (например, на 39 этаже), мы начинаем прибавлять по 1 этажу к последней успешной попытке (то есть 28, 29, ... , 38), и когда вторая лампочка разобьется, мы узнаем правильный ответ.

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

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

Объединение вместо выбора.
#алгоритмы #мысль

Еще одна идея о том, как написать хороший алгоритм.

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

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

Я же люблю третий вариант – я думаю, как обобщить алгоритм так, чтобы оба старых алгоритма были просто его частными случаями. Чтобы был параметр, который выставлен в 0 – работает, по сути, первый алгоритм, а в 1 – второй. При этом параметр был естественный, а не просто <если>. То есть код должен быть один, а параметр мог меняться непрерывно.
Если думать в этом направлении, то часто получается склеить алгоритм. Плюс тут не только в том, что удалось избежать выбора и потери времени работы алгоритма или ресурсов. А в том, что мы получили качественно новый алгоритм, на который можно снова смотреть и улучшать.
Проблема выбора из двух алгоритмов, это не проблема, а способ получить инсайт.