Я всё-таки достиг результата, поэтому могу смело изменить название этой презентации с «Как я сбивал назойливый дрон соседского ребёнка» на «Как я сбил назойливый дрон соседского ребёнка».
Печаль. Всю статью ждал подробное описания того, как автор будет сбивать непосредственно дрон ребёнка.
И тут обнаруживается кое-что интересное. «Идентично» — то есть, тождественно, взаимозаменяемо при любых обстоятельствах. И даже при UB?
Неопределённое поведение — оно не определено. Значит и идентичность этого поведения какому-то другому поведению при нём тоже не определена.
Это как сравнивать два поля одного nullable типа (в БД для конкретики аналогии): если они определены, то их можно сравнить (проверить на равенство). Но если хотя бы одно из них null, то это значит, что мы вообще не можем их сравнивать, результат их сравнения тоже не определён. А само null — это не состояние данных, а неопределённость этого состояния. И думать о нём нужно именно на этом абстрактном уровне. Но программисту (говорю, основываясь на личных ощущениях) очень хочется воспринимать null как очередное состояние, потому что на уровне реализации это и есть состояние, а программист чаще мыслит реализацией.
Меня такой код восхищает, потому что он наверняка супер оптимален и с первого взгляда совершенно непонятно, как работает. От подобных алгоритмов я получаю особое удовольствие.
А я ровно наоборот. Не скажу, что в данном случае это плохо, всё-таки, как я понял, библиотечная реализация, которая, вообще говоря, критична к производительности. Но хотелось бы комментарий «как» и «почему так», хотя бы название алгоритма/приёма, если это какая-то классика. Вот опечатается коллега на один символ в реализации, а мне придёт бага — и как мне понять, есть ли здесь ошибка, где конкретно и как проявляется?
А что если функций не 4? Может, есть пятое слагаемое, навскидку, любовь созерцать воду. И через эту водосозерцательную функцию мы будем говорить о том, нравятся нам или не нравятся люди (которые на большую часть состоят из воды), какие занятия нам нравятся (близостью с водой либо похожестью на поведение воды) и т.д.?
Или что если ум и душа это одно и то же? Или что если никакой логики не существует в принципе? Что если есть люди, у которых нет каких-то из перечисленных четырёх функций? Что если у человека все четыре функции вторые или четвёртые? Что если «пробивной инструмент» человека в обычной жизни логика, а при опасности физика? Что если психотип приобретённый, а не врождённый? Что если он не постоянный, а меняется в течение жизни или даже по десять раз в течение дня? Что если не психотип определяет поведение человека, а сформировавшийся человек определяет свой психотип?
А ещё очень «здорово», что этой теорией можно объяснить что угодно. Есть, например, спортсмен. Он хорош, потому что его пробивной инструмент — физика. Ну или он хорош, потому что его тонкий инструмент — физика. Ну или физика его третья функция, поэтому он комплексует и вкачивает её на максимум. А есть человек, у которого со спортом плохо. Почему? Потому что его физика — первая функция, он плох в ней, но не осознаёт, поэтому ничего не делает для её улучшения. Или третья, поэтому он стесняется своего тела и не ходит в зал. Или четвёртая — и ему пофиг на спорт.
Проблема поставлена хорошо, да и решение предложено неплохое. Но ИМХО использование перечислений — шаг вперёд, а завязка их на булевы значения (и тем более каст к ним) — шаг назад. При определении перечислений нужно забыть, что переменные, из-за которых они возникают, были из множества {false, true}. Т.е. вместо
enum class WithValidation : bool { False, True };
enum class WithNewEngine : bool { False, True };
я бы написал как-то так:
enum class ValidationMode : bool { NoValidation, Validation };
enum class EngineVersion : bool { Old, New };
Тогда и мыслей о касте к булеву значению не возникает: мы будем проверять строгое соответствие переменной одному из её возможных значений.
Кстати, по опыту, часто функции (bool,…, bool) не обрабатывают весь спектр 2 в степени n индивидуально, она просто болеет «добавлением ещё флажка». Т.е., например, если у нас есть функция
То при первом аргументе false второй вообще не важен: какая разница, доступный контрол или нет, если мы его даже не будем отрисовывать по факту. Из-за этого напрашивается сделать что-то такое:
О том же подумал, когда статью читал. Всё надо либо проверять, либо заранее «договариваться» о том, чего быть «не должно», потому что это уже было обязательно проверено выше.
Но ведь одна из идей этой книги Нассима Талеба как раз в обратном: даже если теория правильно работает на предсказании в прошлом, то это не значит, что она будет работать в будущем.
Мне, навскидку, кажется, что для оценки и сравнения сложности лучше рассматривать количество рёбер взаимосвязи между модулями (и число самих модулей, но в меньшей степени), а не хроматическое число. При этом оценка
1. Будет работать для любого графа, а не только планарного.
2. Не будет ограничена (значением 4), как и сложность.
ИМХО советовать начинающему программировать читать Кнута — это всё равно, что советовать начинающему программировать на C++ читать Страуструпа. Книги-то обе отличные, вот только новичок с них как начнёт, так и закончит. Потому что, во-первых, нужен бекграунд, которого нет, во-вторых, понимание отсутствия этого бекграунда сразу начинает давить и демотивировать.
Аналогичная ситуация. Выдаёт город, первую букву улицы, номер квартиры и подъезд. Но количество звёздочек к скрытым символам, похоже, соответствует один к одному. Т.е. если подумать, то можно, например, легко определить улицу и сколько цифр в номере дома, что уже даёт некое сужение информации об адресе.
Мне, как клиенту, конечно, хотелось бы, чтобы не выводило вообще ничего.
Как я понял из статьи, речь идёт об одномерной интерполяции (т.к. рассматриваются только графики функций из R в R). В таком случае в самом начале задача интерполяции многочленом дана несколько небрежно. Необходимо рассматривать не произвольные точки на плоскости, а такие, что все абсциссы точек будут различными, если, конечно, мы не говорим о кратных узлах (но там совсем другая история).
ИМХО, чтобы убедить «крутого эксперта» работать в стартапе, нужно следующее:
1. Продемонстрировать хотя бы относительную надёжность.
Стартап в любой момент может сдуться. При этом сотрудник может быть кинут на зарплату за текущий месяц, а то и больше, если выплаты будут производиться несвоевременно. Даже если работник получит свой расчёт целиком при таком сокращении, то придётся искать новую работу и при этом жить на сбережения, что тоже приносит финансовые издержки.
2. Предлагать ЗП выше, чем если бы на ту же должность сотрудника искала стабильная компания.
Не только для того, чтобы окупить возможные расходы из первого пункта. Дело в том, что раз это стратап, то основную работу предстоит сделать. Скорее всего, коллег, которые подскажут, помогут и быстро введут в курс дела, минимум, и те постоянно заняты. Велика вероятность, что вкалывать придётся за двоих, осваивать всё быстро и без подсказок, постоянно решать самому сложные вопросы, причём каждое из решений будет аукаться в ближайшем будущем. Всё это должно отражаться на ЗП.
3. Продемонстрировать адекватность, профессионализм.
Т.к. типичные социальные схемы и стандарты ещё не отлажены, внутри стартапа возможны отношения спустя рукава. Например, вышел на работу, а у тебя клавиатура не работает у компа, а админ только один, и тот ушёл за пивом. И половина рабочего дня только уходит на то, чтобы найти админа, который выдаст новую клаву. Приходишь устраиваться, а кадровичка не знает, где трудовой распечатать и как правильно пишется название компании. И т.д.
Ну или он просто высказал своё субъективное мнение, которое подхватили, потому что он
Печаль. Всю статью ждал подробное описания того, как автор будет сбивать непосредственно дрон ребёнка.
Неопределённое поведение — оно не определено. Значит и идентичность этого поведения какому-то другому поведению при нём тоже не определена.
Это как сравнивать два поля одного nullable типа (в БД для конкретики аналогии): если они определены, то их можно сравнить (проверить на равенство). Но если хотя бы одно из них null, то это значит, что мы вообще не можем их сравнивать, результат их сравнения тоже не определён. А само null — это не состояние данных, а неопределённость этого состояния. И думать о нём нужно именно на этом абстрактном уровне. Но программисту (говорю, основываясь на личных ощущениях) очень хочется воспринимать null как очередное состояние, потому что на уровне реализации это и есть состояние, а программист чаще мыслит реализацией.
А я ровно наоборот. Не скажу, что в данном случае это плохо, всё-таки, как я понял, библиотечная реализация, которая, вообще говоря, критична к производительности. Но хотелось бы комментарий «как» и «почему так», хотя бы название алгоритма/приёма, если это какая-то классика. Вот опечатается коллега на один символ в реализации, а мне придёт бага — и как мне понять, есть ли здесь ошибка, где конкретно и как проявляется?
А что если функций не 4? Может, есть пятое слагаемое, навскидку, любовь созерцать воду. И через эту водосозерцательную функцию мы будем говорить о том, нравятся нам или не нравятся люди (которые на большую часть состоят из воды), какие занятия нам нравятся (близостью с водой либо похожестью на поведение воды) и т.д.?
Или что если ум и душа это одно и то же? Или что если никакой логики не существует в принципе? Что если есть люди, у которых нет каких-то из перечисленных четырёх функций? Что если у человека все четыре функции вторые или четвёртые? Что если «пробивной инструмент» человека в обычной жизни логика, а при опасности физика? Что если психотип приобретённый, а не врождённый? Что если он не постоянный, а меняется в течение жизни или даже по десять раз в течение дня? Что если не психотип определяет поведение человека, а сформировавшийся человек определяет свой психотип?
А ещё очень «здорово», что этой теорией можно объяснить что угодно. Есть, например, спортсмен. Он хорош, потому что его пробивной инструмент — физика. Ну или он хорош, потому что его тонкий инструмент — физика. Ну или физика его третья функция, поэтому он комплексует и вкачивает её на максимум. А есть человек, у которого со спортом плохо. Почему? Потому что его физика — первая функция, он плох в ней, но не осознаёт, поэтому ничего не делает для её улучшения. Или третья, поэтому он стесняется своего тела и не ходит в зал. Или четвёртая — и ему пофиг на спорт.
я бы написал как-то так:
Тогда и мыслей о касте к булеву значению не возникает: мы будем проверять строгое соответствие переменной одному из её возможных значений.
Кстати, по опыту, часто функции (bool,…, bool) не обрабатывают весь спектр 2 в степени n индивидуально, она просто болеет «добавлением ещё флажка». Т.е., например, если у нас есть функция
То при первом аргументе false второй вообще не важен: какая разница, доступный контрол или нет, если мы его даже не будем отрисовывать по факту. Из-за этого напрашивается сделать что-то такое:
Это почти ложь.
1. Будет работать для любого графа, а не только планарного.
2. Не будет ограничена (значением 4), как и сложность.
Мне, как клиенту, конечно, хотелось бы, чтобы не выводило вообще ничего.
1. Продемонстрировать хотя бы относительную надёжность.
Стартап в любой момент может сдуться. При этом сотрудник может быть кинут на зарплату за текущий месяц, а то и больше, если выплаты будут производиться несвоевременно. Даже если работник получит свой расчёт целиком при таком сокращении, то придётся искать новую работу и при этом жить на сбережения, что тоже приносит финансовые издержки.
2. Предлагать ЗП выше, чем если бы на ту же должность сотрудника искала стабильная компания.
Не только для того, чтобы окупить возможные расходы из первого пункта. Дело в том, что раз это стратап, то основную работу предстоит сделать. Скорее всего, коллег, которые подскажут, помогут и быстро введут в курс дела, минимум, и те постоянно заняты. Велика вероятность, что вкалывать придётся за двоих, осваивать всё быстро и без подсказок, постоянно решать самому сложные вопросы, причём каждое из решений будет аукаться в ближайшем будущем. Всё это должно отражаться на ЗП.
3. Продемонстрировать адекватность, профессионализм.
Т.к. типичные социальные схемы и стандарты ещё не отлажены, внутри стартапа возможны отношения спустя рукава. Например, вышел на работу, а у тебя клавиатура не работает у компа, а админ только один, и тот ушёл за пивом. И половина рабочего дня только уходит на то, чтобы найти админа, который выдаст новую клаву. Приходишь устраиваться, а кадровичка не знает, где трудовой распечатать и как правильно пишется название компании. И т.д.