я понимаю ход мысли, но делать так нельзя, иначе мы получим производную задачу. Полученное решение производной задачи нельзя будет перевести обратно в предметную область исходной задачи. swap (обмен) предметов противоречит механизму перемещения указанному в задаче, а он — челночный. И это важный аспект предметной области для которой мы ищем решение, и пренебрегать этим нельзя.
Но я не люблю словесных баталий, давайте лучше разберем эту производную задачу «на бумаге», чтобы было на что ссылаться. Обозначим козу 1, капусту 2, а волка 4. Не допустимой будет любая нечетная комбинация.
Изначально, по условию задачи, все находятся на одном берегу. Комбинация 7. Нечетная. Это недопустимое состояние. Давайте, ради продолжения мысленного эксперимента, выведем систему из недопустимого состояния, перенеся козу на другую сторону, как Вы предлагали в исходном комментарии.
Челнок находится на другом берегу. Там где коза. Возвращаем челнок к волку с капустой. Кого бы мы не переправили на другой берег (к козе) мы получим не допустимое состояние.
Эта производная задача не решается.
Продолжим мысленный эксперимент, пусть у нас будет портал, в который можно войти либо с одной стороны либо с другой. Перенеся один предмет через портал нельзя перенести следующий предмет в том же направлении, не перенеся какой-то предмет обратно. Т.е нельзя сделать два перемещения в одну сторону это бы противоречило условию задачи. (Мужик может и не нужен, но челнок никуда не деть, это важный аспект механики предметной области) Коза перебралась через портал.Теперь чтобы открыть портал со стороны волка с капустой снова, нужно перенести козу обратно. Эта производная задача не решается, потому, что пренебрегает устройством пропускного механизма. Он челночный.
от «мужика» избавиться не получается, это было бы недопустимым упрощением. Без него мы не сможем скомбинировать волка козу и капусту. Все таки мы перемещаем предметы из одной точки в другую и у нас есть паромщик. Если мы пренебрежём паромщиком, то у нас получится совсем другая задача. Важно при моделировании, не увлекаться и не уничтожить детали изначальной задачи, которая имеет вполне прикладной контекст. (Как в анекдоте про физика, инженера и математика на пожаре — «решение существует») При решении мы упрощаем до допустимой абстракции, а потом переводим решение, которое мы вывели для общего случая, обратно в предметную область.
Можно ведь вообще сказать «поменям берега местами» — задача решена. Нет так делать нельзя.
Очень верное замечание. В задаче имеется неявное правило. Именно поэтому я думаю, в программировании всегда нужен будет человек, чтобы из задачи сформулированной на человеческом языке, выделять правила явные, и неявные. Это как раз то, что мы понимаем под словом «думать» и чему, как мне кажется, машина в сегодняшнем ее виде, никогда не сможет «научиться».
2 на обратном пути между перевозкой волка и капусты, коза переезжает с того берега на этот.
По условиям оригинальной задачи, перемещение возможно только с участием крестьянина. А так получается у нас какая-то квантовая физика уже, коза как бы еще там но уже не там. В классической машине Тъюринга нет неопределенности. Или мы в одном состоянии или в другом. Нет никакого промежуточного состояния. Как и нет процесса. Т.е. процесс конечно можно смоделировать в пригодном для машины Тьюринга виде, но это будет тоже состояние. Машина Тьюринга не имеет памяти, т.е если остановить ее в какой-то момент, а потом запустить снова, она просто продолжит выполнять свой алгоритм с того места на котором остановилась. (Чего не делают, кстати сказать современные персональные компьютеры)
В результате мы имеем на выходе полную симметрию начальному условию:
… Осталось забрать козу.
Да, в задаче есть симметрия. Это видно из расположения допустимых состояний на ленте, они симметичны относительно середины. Если развернуть ленту в машине Тьюринга, но не изменять программу, то когда коза на одном берегу, а все остальные на другом, машина дойдет до решения за два перехода: крестьянин поедет за козой и перевезет ее на берег, где волк, в гордом одиночестве, пасет капусту.
Люди не хотят принимать то, что они не не могут охватить умом, им легче использовать то что они хорошо понимают. (Есть даже какое-то когнитивное искажение с этим связанное). Это все равно что команду которая всю жизнь работала с subversion пытаться перевести на git. Они не поверят в то, что это удобно потому что это не понятно.
Все-таки когортный анализ заставляет людей делать интеллектуальный кульбит. Далеко не способны делать умственные кульбиты. И уж тем более не на собрании, когда все скорее думают от том, когда же он закончится. Я даже в спокойной домашней обстановке перечитывал пассажи статьи по нескольку раз, поскольку не знаком с темой. И только после этого, и то приблизительно, понял о чем речь. К сожалению исходня таблица представленна не полностью, а последняя таблица недостаточно хорошо обьяснена, чтобы можно было проследить путь трансформации данных. А если заставить людей на собрании понимать такое — это будет полный провал. Тут нужно проводить дидактическую редукцию до уровня «У Саши было две конфеты..»
(сразу извиняюсь за оффтоп, но мысль приходится выкладывать полностью.)
Это к сожалению проблема практически всей айтишной литературы. Особенно касающейся архитектуры. Провести дидактическую редукцию сложной концепции дело непростое, и людям просто лень. А может они и не умеют этого делать.
Я очень критически отношусь к такой «лени» — «не можешь привести пример, значит это пустая болтовня». «Пример получится слишком большим?» — ничего мы подождем.
Как я отличаю хорошую литературу от плохой? В хорошей не пишут «мы вернемся к этому чуть позже» — ведь обычно не возвращаются. В хорошей дают развернутые примеры, и не противоречат установленным догмам, типа не стоит называть тест XTest, но для примера, чтобы развить мысль, называют свой пример ХТest. Это никак не оправдано, даже если это запись разговора по памяти, то всегда есть такой этап как редактирование. И в нужном месте нужно изменить достоверность диалога в угоду дидактической удобоваримости.
Вот у нас на работе недавно встала тема, давайте обмениваться опытом между отделами. Но я также недавно понял, что передать опыт на словах невозможно, его можно только получить. Иначе это не опыт а знание. Знание есть в книгах, все знания мира, но люди все равно озадачены проблемами ответы на которые есть в книгах. Значит людям нужно не знание, а решение их проблемы. Получается надо обмениваться не опытом, а проблемами. И наверное пытаться вместе их решить.
Вот возьму я тест, и захочу переписать его на контрвариантный лад. С чего начинать? В голове на «чистом листе» все очень стройно, но большинство людей имеют уже «запоротый проект» который надо чинить и переделывать. Вот у нас недавно делали ремонт в магазине техники, не закрывая магазин ни на день — вот этому хочется научиться. Как перестраивать приложение не останавливая его разработку.
С другой стороны опытные разработчики знают как это можно сделать но работы для этого нужно очень много. Т.е такая перестройка просто нерентабельна. Чтобы перестроить магазин фирма ведь заказала дополнительный труд. Они не смогли бы сделать этого только силами своих сотрудников в рабочее время. Вот перед какой проблемой все в основном и стоят. Но если мне попадется проект с чистого листа, я обязательно попробую.
Спасибо Вам за подробный анализ. Думаю это хорошее дополнение к статье.
Я не являюсь свитерато-бородатым програмистом в третьем колене, а просто интересуюсь базовыми принципами информатики, так, больше для общего развития. Поэтому для меня наглядность важнее формальной точности. И Википедия в этом плане к сожалению часто тоже не достаточно популярно излагает. С минимальной дидактической редукцией, так сказать.
А сам принцип единственного предназначения (мне такое название больше нравится) довольно интуитивен для понимания: если выключатель в корридоре включает свет и в корридоре и в зале, нам это покажется, как минимум, странным. А создатель такого решения просто подумал, мол почему бы и нет, ведь он, когда приходит домой, сразу идет в зал к телевизору. Звучит вроде обоснованно, но на практике выглядит дико. А в зале есть выключатель который выключает свет в корридоре. (реальный случай из жизни, между прочим)
Или более распространенный случай, но в обратную сторону, у нас два выключателя в корридоре, и оба включают и выключают свет. Тут можно сказать, что нарушается принцип неповторения (DRY), но это так же и случай нарушения единственного предназначения. На один функционал (свет в корридоре) должна быть одна _и только одна_ управляющая компонента (выключатель).
Другой пример — бюрократия, каждое ведомство занимается только своим делом и ничем другим, и передает дело при необходимости другому ведомству. И не может быть двух ведомств имеющих одно и то же предназначение.
Я надеялся в статье на такое вот наглядное описание, для чайников, без избыточного формализма.
Я не граммар-наци, и не люблю споры на этот счет. Запятые расставляю на слух. А иногда не ставлю совсем. Но раз Вы подняли эту тему, то я поинтересовался. И убедился, что они однородные.
характеризуют предмет с разных сторон, но в данном контексте объединяются каким-то общим признаком; Лунный, ясный вечер – «лунный, а потому и ясный»; тяжёлые, мрачные времена – «тяжёлые, а потому и мрачные».
Другой пример: «Умный, красивый, в меру упитанный мужчина в полном расцвете сил».
Тут нельзя не поставить запятую.
И даже без этого, между ними можно написать «а также». Если мы пропускаем часть предложения, то запятая оправдана. Хотя, вобщем, мне все равно. Просто указанный мной в комментарии кусок предложения ввел меня в ступор на полминуты. Вот и решил обратить на это внимание.
Логика программирования заключается в том, чтобы разбить большую задачу на маленькие подзадачи и последовательно реализовать их, а потом связать воедино.
согласен на 100%. Этот подход стоит использовать и в управлении проектом (макро). Видел сам, как опытные программисты впадают в уныние, когда перед ними стоит плохо описанная, большая задача. Если ее не разбить на мелкие, легко выполнимые задачи, то можно засесть в таком «болоте» надолго. И тут нельзя не отметить (из чистого прагматизма), что agile, как методика, делает именно это.
Hyperevolution А про SkinCoin можете сказать пару слов, для сравнения? Вроде слово «коин» в названии подразумевает наличие блокчейна, и соответственно децентарлизованного подхода, но это как говорится «не точно». А чем оно является на самом деле не очень ясно.
Я должен внести поправку, я имел ввиду Outlook 2013. Про 2016 ничего сказать не могу.
Но проблема того, что программа никак не помогает пользователю, а вместо этого заставляет с собой разбираться, остается. Я в 2017 году не могу элементарно дать тег элементу почтового ящика. Только разноцветные метки.
Я для того чтобы искать в прикрепленных документах должен в поисковое поле писать префикс «attachment:»? Вы серьезно? В то время как Mac OS с незапамятных времен просто индексирует все. Я знаю, что тут минусуют за выражение недовольства и критику, мол, «не осилил». Да, не осилил. Не пользователь должен разбираться с программой, а программа с пользователем. Гугл, например вобрал все самое лучшее в свой почтовый клиент. Значит это возможно. Там все как-то само собой интуитивно. А те кто минусуют критику, так в своем теплом болоте всю жизнь и будут жить, и никогда ничего не изменят к лучшему.
Минусуем, не стесняемся ;)
Про аккредитацию отдельная история. К нам приезжают «серьёзные» люди из университета, дают тесты и проверяют документы. Документы заранее все приведены в порядок, а ответы на тесты мы получили за час до приезда этих самых «серьёзных» людей.
У меня тоже порой сводит скулы от некоторых формулировок.
кто-нибудь может находил ресурс где англицизмы переведены на русский язык? Не обьяснены, а именно представлены их русские аналоги.
мне на работе приходится работать с Outlook 2016 и это грустно. Мне не ясно, как им можно эффективно пользоваться. Некоторые диалоги еще из девяностых годов неизменялись, модальные окна. Какой-то мрак. Искать нормально невозможно, опции где и какие не понятно. Чтобы пользоваться Outlook мне приходится шариться в поисковике. Так вот, у меня есть опасения что весь этот вселенский бред так и оставят в приложении, а добавят поддержку каких нибудь mojis в емейлах, и прочей лабуды. Презентационный слой расширять проще, чем делать рефакторинг пользовательского интерфейса.
Я всегда, не глядя на метку, определяю что это перевод:
Черт возьми, я люблю стикеры. Это просто маленькие кусочки клейкой бумаги, но я клянусь, они обладают магической силой! Возьмите любой старый документ, прикрепите к нему любой глупый стикер и БАМ! Этот документ теперь источает веселье.
наверное инфантилизм в стилистике текста выдает зарубежные популярные источники.
Можно избавится от этого, но тогда это уже будет художественный перевод. Хотя для некоторых видов текста это наверное не критично. Тут сам оригинал не тянет на технический текст.
Но я не люблю словесных баталий, давайте лучше разберем эту производную задачу «на бумаге», чтобы было на что ссылаться. Обозначим козу 1, капусту 2, а волка 4. Не допустимой будет любая нечетная комбинация.
Изначально, по условию задачи, все находятся на одном берегу. Комбинация 7. Нечетная. Это недопустимое состояние. Давайте, ради продолжения мысленного эксперимента, выведем систему из недопустимого состояния, перенеся козу на другую сторону, как Вы предлагали в исходном комментарии.
Челнок находится на другом берегу. Там где коза. Возвращаем челнок к волку с капустой. Кого бы мы не переправили на другой берег (к козе) мы получим не допустимое состояние.
Эта производная задача не решается.
Продолжим мысленный эксперимент, пусть у нас будет портал, в который можно войти либо с одной стороны либо с другой. Перенеся один предмет через портал нельзя перенести следующий предмет в том же направлении, не перенеся какой-то предмет обратно. Т.е нельзя сделать два перемещения в одну сторону это бы противоречило условию задачи. (Мужик может и не нужен, но челнок никуда не деть, это важный аспект механики предметной области) Коза перебралась через портал.Теперь чтобы открыть портал со стороны волка с капустой снова, нужно перенести козу обратно. Эта производная задача не решается, потому, что пренебрегает устройством пропускного механизма. Он челночный.
Можно ведь вообще сказать «поменям берега местами» — задача решена. Нет так делать нельзя.
Да, в задаче есть симметрия. Это видно из расположения допустимых состояний на ленте, они симметичны относительно середины. Если развернуть ленту в машине Тьюринга, но не изменять программу, то когда коза на одном берегу, а все остальные на другом, машина дойдет до решения за два перехода: крестьянин поедет за козой и перевезет ее на берег, где волк, в гордом одиночестве, пасет капусту.
Как область применения статистических методов — совершенно бестолково.
— да? а у меня 50% пальцев не с той стороны.
«точность воспроизведения» — ведь понятно что давать такому критерию обьективную оценку практически бесполезно.
Все-таки когортный анализ заставляет людей делать интеллектуальный кульбит. Далеко не способны делать умственные кульбиты. И уж тем более не на собрании, когда все скорее думают от том, когда же он закончится. Я даже в спокойной домашней обстановке перечитывал пассажи статьи по нескольку раз, поскольку не знаком с темой. И только после этого, и то приблизительно, понял о чем речь. К сожалению исходня таблица представленна не полностью, а последняя таблица недостаточно хорошо обьяснена, чтобы можно было проследить путь трансформации данных. А если заставить людей на собрании понимать такое — это будет полный провал. Тут нужно проводить дидактическую редукцию до уровня «У Саши было две конфеты..»
Это к сожалению проблема практически всей айтишной литературы. Особенно касающейся архитектуры. Провести дидактическую редукцию сложной концепции дело непростое, и людям просто лень. А может они и не умеют этого делать.
Я очень критически отношусь к такой «лени» — «не можешь привести пример, значит это пустая болтовня». «Пример получится слишком большим?» — ничего мы подождем.
Как я отличаю хорошую литературу от плохой? В хорошей не пишут «мы вернемся к этому чуть позже» — ведь обычно не возвращаются. В хорошей дают развернутые примеры, и не противоречат установленным догмам, типа не стоит называть тест XTest, но для примера, чтобы развить мысль, называют свой пример ХТest. Это никак не оправдано, даже если это запись разговора по памяти, то всегда есть такой этап как редактирование. И в нужном месте нужно изменить достоверность диалога в угоду дидактической удобоваримости.
Вот у нас на работе недавно встала тема, давайте обмениваться опытом между отделами. Но я также недавно понял, что передать опыт на словах невозможно, его можно только получить. Иначе это не опыт а знание. Знание есть в книгах, все знания мира, но люди все равно озадачены проблемами ответы на которые есть в книгах. Значит людям нужно не знание, а решение их проблемы. Получается надо обмениваться не опытом, а проблемами. И наверное пытаться вместе их решить.
Вот возьму я тест, и захочу переписать его на контрвариантный лад. С чего начинать? В голове на «чистом листе» все очень стройно, но большинство людей имеют уже «запоротый проект» который надо чинить и переделывать. Вот у нас недавно делали ремонт в магазине техники, не закрывая магазин ни на день — вот этому хочется научиться. Как перестраивать приложение не останавливая его разработку.
С другой стороны опытные разработчики знают как это можно сделать но работы для этого нужно очень много. Т.е такая перестройка просто нерентабельна. Чтобы перестроить магазин фирма ведь заказала дополнительный труд. Они не смогли бы сделать этого только силами своих сотрудников в рабочее время. Вот перед какой проблемой все в основном и стоят. Но если мне попадется проект с чистого листа, я обязательно попробую.
Я не являюсь свитерато-бородатым програмистом в третьем колене, а просто интересуюсь базовыми принципами информатики, так, больше для общего развития. Поэтому для меня наглядность важнее формальной точности. И Википедия в этом плане к сожалению часто тоже не достаточно популярно излагает. С минимальной дидактической редукцией, так сказать.
А сам принцип единственного предназначения (мне такое название больше нравится) довольно интуитивен для понимания: если выключатель в корридоре включает свет и в корридоре и в зале, нам это покажется, как минимум, странным. А создатель такого решения просто подумал, мол почему бы и нет, ведь он, когда приходит домой, сразу идет в зал к телевизору. Звучит вроде обоснованно, но на практике выглядит дико. А в зале есть выключатель который выключает свет в корридоре. (реальный случай из жизни, между прочим)
Или более распространенный случай, но в обратную сторону, у нас два выключателя в корридоре, и оба включают и выключают свет. Тут можно сказать, что нарушается принцип неповторения (DRY), но это так же и случай нарушения единственного предназначения. На один функционал (свет в корридоре) должна быть одна _и только одна_ управляющая компонента (выключатель).
Другой пример — бюрократия, каждое ведомство занимается только своим делом и ничем другим, и передает дело при необходимости другому ведомству. И не может быть двух ведомств имеющих одно и то же предназначение.
Я надеялся в статье на такое вот наглядное описание, для чайников, без избыточного формализма.
Другой пример: «Умный, красивый, в меру упитанный мужчина в полном расцвете сил».
Тут нельзя не поставить запятую.
И даже без этого, между ними можно написать «а также». Если мы пропускаем часть предложения, то запятая оправдана. Хотя, вобщем, мне все равно. Просто указанный мной в комментарии кусок предложения ввел меня в ступор на полминуты. Вот и решил обратить на это внимание.
Но проблема того, что программа никак не помогает пользователю, а вместо этого заставляет с собой разбираться, остается. Я в 2017 году не могу элементарно дать тег элементу почтового ящика. Только разноцветные метки.
Я для того чтобы искать в прикрепленных документах должен в поисковое поле писать префикс «attachment:»? Вы серьезно? В то время как Mac OS с незапамятных времен просто индексирует все. Я знаю, что тут минусуют за выражение недовольства и критику, мол, «не осилил». Да, не осилил. Не пользователь должен разбираться с программой, а программа с пользователем. Гугл, например вобрал все самое лучшее в свой почтовый клиент. Значит это возможно. Там все как-то само собой интуитивно. А те кто минусуют критику, так в своем теплом болоте всю жизнь и будут жить, и никогда ничего не изменят к лучшему.
Минусуем, не стесняемся ;)
кто-нибудь может находил ресурс где англицизмы переведены на русский язык? Не обьяснены, а именно представлены их русские аналоги.
наверное инфантилизм в стилистике текста выдает зарубежные популярные источники.
Можно избавится от этого, но тогда это уже будет художественный перевод. Хотя для некоторых видов текста это наверное не критично. Тут сам оригинал не тянет на технический текст.