По мере общения с сообществом инфостарта у меня начало закрадываться подозрение, о довольно фрагментарном и слабом гуманитарном образовании IT-шников. Не хочу никого обидеть и тем более вносить сюда элементы какого-либо хвастовства, но очень уж не терпится проверить свою гипотезу или догадку.
Большинство из рассматриваемых на форуме проблем имеют либо слишком узкую специальную либо, наоборот, слишком отдаленную от программирования постановку. Поэтому засунуть прикладную задачу по программированию в более широкий гуманитарный контекст пришло мне в голову при помощи специального кейса. Сначала хотел вынести этот кейс на форум с голосовалкой по вариантам ответов, но когда взялся за описание задачи понял, что такой объем для форума великоват.
Собственно у данного кейса есть 3 основные цели:
- Моя чисто эгоистичная – оценить уровень способности программистов применять гуманитарные знания самого широкого спектра при разработке подходов к решению прикладных задач. Это просто любопытно.
- Моя еще более эгоистическая – оценить собственные способности через качество решения по данному кейсу.
- Общечеловеческая – потренировать программистов и проектировщиков информационных систем, обменяться опытом, знаниями и соображениями по методологии проектирования информационных решений.
Ну а теперь сам кейс и пришедшие мне в голову варианты решений:
Итак, Ваша компания намерена принять участие в тендере на разработку ПО для фирмы Х.
Фирма X занимается тем, что отлавливает каких либо животных (кроликов, удавов или, допустим, лошадей) по всему миру при помощи автоматических ловительных терминалов. Терминал уже разработан и имеет устройство в виде ворот и загона. В ворота могут входить самые различные животные, а вот дверь загона для нужного вида животных (остановимся таки на лошадях) должен открывать Ваш софт. В терминале есть 4 контроллера определяющие для вошедшего в ворота животного:
- Рост
- Длину
- Вес
- Цвет
Сигналы от контроллеров поступают в вашу систему обработки и она должна либо открыть дверь загона, определив, что в проходе именно лошадь, либо не открывать и тогда животное пройдет через ворота дальше по своим делам.
Для КП на тендер нужно выставить цену проекта, срок и подход к решению. Почему так важен подход? Потому что на конкурсе кроме финансистов от заказчика будут присутствовать в качестве независимых экспертов 2-3 очень известных специалиста в области разработки алгоритмов и оценок эффективности систем и они-то и дадут заключение об эффективности Вашего подхода.
Специфика области применения Вашего будущего софта в том, что для эффективности очень важна вероятность правильного определения лошади. Если Ваш софт будет пропускать мало лошадей – клиенту это не будет выгодно, если Ваш софт будет пропускать много лишних животных, то возрастают расходы по «сортировке» полученного улова, а в случае если, допустим вместо лошади система запустит в загон льва, то клиент просто потеряет всю наловленную партию. В конце концов при низкой вероятности определения лошадей программой для клиента может оказаться выгоднее вообще посадить дежурить инвалидов в три смены перед монитором и дать им кнопку открытия вольера. А это означает, что потребность в софте отпадет совсем.
Ваша задача по кейсу определить именно ту часть предложения в которой будет описан подход к построению информационной компоненты терминала. То есть какова будет структура и состав базы данных и основной принцип обработки с ее помощью сигналов от контроллера, так чтобы система была по возможности проще (дешевле и быстрее реализуемой) и достаточно точной для определения вероятности. Насколько точна будет Ваша система оценят эксперты на тендере (Вы не знаете заранее кто это будет, поэтому возможности подкупить их нет). Итак Ваша цель – победа в тендере, но очевидно, что претендовать на первенство сразу во всех номинациях требований к решению у Вас тоже не получится. Давайте опишу основные возможные решения и вы поймете почему:
- Сверхпросто. Информационная база – максимальные и минимальные значения по всем контролируемым параметрам и набор возможных цветов для лошадей. Алгоритм – сравнение фактических показаний контроллеров с допустимыми на больше меньше и на ИЛИ равно для цвета. Если животное вписывается в параметры и подходит по цвету – оно запускается. Решение очень простое — дешевое, быстрореализуемое, но, очевидно далеко не точное по вероятности определения.
- Просто. Аналогично сверхпростому, но животное отсекается между минимумами и максимумами по какому-либо критерию в стиле Парето. То есть берется промежуток 20-25% между минимальными и максимальными значениями в центре (которые как известно должны включить примерно 80% существующих в природе лошадей) и берутся только те животные, которые пролезут в данные «ворота», теперь уже меньшего чем у сверхпростого варианта размера.
- С анализом функции вероятности. Похоже на простой вариант, но вместо критерия Парето используется специальные критерии рассчитанные на основании нормального закона распределения. В информационную базу в этом случае добавляется: среднее по всем количественным показателям и среднеквадратичные отклонения. Усложняется соответственно расчетный алгоритм, так как теперь на основании показаний контроллеров рассчитывается и оценивается вероятность того, что это лошадь. Потом, возможно, вероятности перемножаются (или берется средняя) и сравниваются с неким пороговым уровнем. Этот вариант еще точнее, но дольше и дороже так как необходимо написать больше и более сложного кода, а также требует проведения полноценного статистического исследования популяции лошадей.
- Моделью статистической взаимосвязи. В данном случае база данных сокращается до одной формулы, в которую нужно подставить рост, длину, вес и цвет (кодированный числом) и которая выдаст вероятность того, что это лошадь. Метод точнее, но опять же снова возможно дольше и возможно дороже, так как помимо исследования популяции необходимо выделить и проанализировать статистические взаимосвязи, протестировать несколько возможных функций вероятности и даже, возможно, потерпеть здесь неудачу, так как устойчивой и пригодной зависимости найдено не будет. Скорее всего эту работу (по разработке статистических методов) нужно будет поручать субподрядчику, так как она требует сильной математической специализации. В общем скорее всего будет очень точно, но не исключен и провал.
- Распознающей моделью. В данном методе выбирается одна, допустим, нейросетевая модель распознавания (или несколько способов распознавания) в нескольких вариантах, собирается статистический массив данных о лошадях, обучаются и тестируются возможные сети. Затем в терминале моделируется обученная модель распознавания с лучшими из возможных характеристиками. По сложности программирования сложнее варианта D, по точности, наверное, немного выше. И сроки… Сроки здесь тоже жмут.
Этот список вариантов решения, не конечен, и даже у меня их возникло намного больше, однако, как мне кажется это довольно полный спектр возможных предложений.
Вам, собственно, никто не мешает предложить в комментариях свой или объяснить почему Вы выбрали тот или иной из существующих вариантов.
Напомню до начала обсуждения, что это кейс. То есть единственного правильного ответа у задачи нет и подходить таким образом к решению не нужно. Нам нужно по возможности найти лучший ответ. Надеюсь, что получитсяJ
Как раз таки пример того, что программисту не нужны гуманитарные науки. Ну не будет же программист ловить лошадей и мерить их а потом на основе этих данных строить функции. При наличии функции вероятность(а,б,в) предпочтительнее пользоваться ей — остальные способы это попытки аппроксимировать эту функцию с потерей точности.
(1) Alien_job, ОК. Вариант 3 как я понял?
С Alien_job я полностью согласен. Программист не должен предлагать метод получения параметров по которому он будет составлять алгоритм определения лошадь это или нет. Это должен делать другой человек с другими знаниями.
А так все методы имеют право на существование.
Мой способ: создать работа (например пчела или овод) который будет летать и определять по днк, какое это животное. И если это лошадь, то помечать животное (это либо чипировать либо маркер оставлять). По это признаку и пропускать.
🙂
А при чем тут гуманитарные знания?
(3) cmd_vasec, ну тут опять же нужна база с ограничениями. Ведь у каждой лошади свой ДНК и может случится так что нам попадется лошадь-мутант-каннибал и съест всех других лошадей. Так что нужны ограничения по допустимым мутациям. Придется взять ДНК сферического коня в вакууме и вывести границы на изменения по каждому гену на 10-20% чтобы в допустимый интервал попало 90% лошадей и исключить генные линии, которые приводят к каннибализму среди лошадей. =)
(2) 4 вариант.
(4) DoctorRoza, При том, наверное, что точная наука — это реализация решения, а вот выбор варианта для реализации чаще всего происходит с известной долей неопределенности, которую количественно не измерить. И как выбирать? Интуитивно или все таки обосновывая выбор не количественными критериями?
Чтобы сделать задачу гуманитарной, предлагаю решение:
1. Обучить всех лошадей говорить какой-либо пароль (кодовое слово), соответственно на разных языках, в зависимости от места обитания лошади.
2. На воротах «ловушки» установить микрофон и динамик.
3. При подходе какого-либо животного у него (животного) будет спрашиваться пароль.
4. Программное обеспечение распознаёт этот пароль.
5. Если пароль верный — то это лошадь, и ворота открываются, если пароль не верный, тогда животное может идти дальше по своим делам (например учить нужный пароль).
В итоге мы получаем 100% результат, по отбору грамотных лошадей.
Также есть дополнительная аналитическая информация — место обитания в зависимости от языка на котором говорится пароль.
🙂
Плюс за то, что имеет место быть попытка расширить подходы к проблеме )))
(3) cmd_vasec,
В том-то все и дело:) Здесь нужно, действительно мыслить не как программист, но ведь плох тот программист, который не мечтает ставить задачи другим программистам:) Можно сказать, что кейс на выявление карьерного потенциала, на способность не просто реализовывать решения, но и выбирать лучший из возможных вариантов еще до начала реализации.
(8) Dmitri_1C, Распознавание речи это тоже задача на распознавание, только не лошади а речи. Надежнее и быстрее все-таки вместо обучения закреплять на лошади датчик, а в воротах считыватель — эти вещи уже разработаны, а вот учебники по лошадиным языкам предстоит еще писать:)
Тогда наверное не «гуманитарные» науки, а «естественные» науки?
Не вижу связи между «лошадками» и программистами.
(11)
Так вот и задача для гуманитариев — учебник по лошадиным языкам.
🙂
хах, что-то подобное приходилось внедрять — только не лошади, а люди — в фитнесс центре =), для оптимизации пути/подходов и загруженности каждого тренажера, сделали банально — сперва эл.карта, потом браслет с ID.
Но конкретно для этой задачи — не думаю что трудности возникнут с написанием кода именно для 1С, скорее всего трудности будут с оборудованием (датчики и т.п.) и дальнейшей идентификацией.
P.S. а вот для первобытных людей было бы еще проще: 1) сделать ворота/клетку, чтобы большие животные не смогли зайти, 2) сделать барьер — чтобы мелкие/низкорослые лошади не смогли зайти, 3) в качестве приманки использовать что больше всего любят лошади определенной масти, 4) при подходе к кормушке и/или в процессе еды срабатывает механизм по закрытию ловушки, 5) Profit =) Одноразовые конечно, но зато 0 вложений…
(12) TODD22, Естественные — изучают природу (физика, химия, биология…), общественные — общество (история, экономика, социология и т.д.), точные — изучают абстракции и модели (математика, кибернетика и т.д.). Под гуманитарными я имел в виду не точные. То есть естественные и общественные, именно как противопоставление мира абстракций в котором профессионально тонут программисты миру реальных вещей и явлений.
(5) Alien_job, тогда это не лошадь.
(10) dusha0020
полностью согласен.
(11)
А если лошадь глухонемая или с дефектами речи, тогда что?
(15) Гуманита́рные нау́ки (от humanus — человеческий, homo — человек) — дисциплины, изучающие человека в сфере его духовной, умственной, нравственной, культурной и общественной деятельности.
Думаю проще сразу остановиться на варианте с инвалидами.
Что-то у этой задачи слишком много неизвестных. Если лошадей попадётся слишком мало то бизнес заказчика становится не рентабельным. Сколько минимум лошадей надо поймать? Количество лошадей в округе не от нас зависит. Кто будет отвечать за то что их в принципе может быть недостаточно? Далее в зависимости от количества лошадей в округе допустимый процент брака будет меняться. Его программист должен замерить?
Ну и вообще… Я конечно знаю что у меня телефон лицо как-то распознаёт, но писать подобный алгоритм Я не возьмусь. Так же и с алгоритмом распознавания лошади по 4 параметрам. Цвет зебры какой код будет иметь, кстати?
Эта задача не для программиста. Программист обрабатывает только те данные которые может получить не вставая с места. А тут надо идти и популяцию лошадей мерить. Хотя если поговорить с животноводами то возможно нужные параметры уже есть. Но это не задача программиста.
(14) succub1_5, Чувствуется опыт:) Чудесный пример про первобытных людей. Действительно нужны ли датчики, софт и высшая математика чтобы поймать лошадь? Может проблема намного проще? Она решаема даже очень примитивными средствами и стоит ли как в (8) или (3) все усложнять? Или все-таки нужно пользоваться возможностями науки и техники пусть и с далеко непонятным результатом?:)
(19) TODD22, Ну уж простите неточность формулировки. Хотя в данной задаче из естественных наук физиология лошадей может быть притянута и то весьма сомнительно, а общественные — они же и есть гуманитарные.
(20) Pavean,
Напомнило старую шутку:
Спрашиваешь у человека: «Сколько нужно программистов, чтобы вкрутить лампочку?» В ответ слышишь массу вариантов с объяснениями почему, но всегда отвечаешь «Неправильно.» Когда человек сдается гордо заявляешь: «Да нисколько! Ноль! Это аппаратная проблема — программисты этим не вообще занимаются!»
А вариант с инвалидами действительно кажется лучшим, вот только кейс так построен, что при этом варианте Вы дадите бесплатный совет заказчику, а не заработаете денег:)
(18) cmd_vasec,
Если лошадь глухонемая или с дефектами речи, тогда нужно обучать языку жестов, жаль пальцев нет.
Тогда еще решение пусть лошадь в танце сообщает, что она лошадь — по сигналу (звуковой или световой), если сплясала, то проходи, не сплясала — ковыля дальше.
🙂
(22)
Естествозна́ние — совокупность знаний о природных объектах, явлениях и процессах.
Вы в предмете разберитесь. А то в элементарных терминах путаетесь. А уже кейсы загадываете….
пара вариантов:
1) Посадить 3 инвалида, которые будут в течении месяца вручную пропускать зверей и помечать лошадей отдельно, вносить по ним данные в таблицу. В итоге у нас будет статистика, анализируя которую, можно пропускать лошадей используя пункты 1 или 2. При этом в течении последующего месяца инвалиды становятся тестерами и проверяют правильно ли сработала автоматика и вносят коррективы в статистику.
2) Нанять группу цыган, которые будут ловить/воровать лошадей и приводить их в загон.
Так как известна особенность лошадей «ржать».
Давайте будем рассказывать животным анекдоты, заржала — лошадь, не заржала — глухонемая лошадь.
🙂
(26) slazzy, Понимаете в чем проблема (здесь, конечно, мое имхо) если Вы выйдете на тендер с 2-3 предложениями то скорее всего тендер Вы проиграете, потому что заказчик не отдаст заказ в компанию которая не знает как сделать лучше и предлагает выбрать заказчику. Заказчик этого не знает сам и хочет чтобы Вы его убедили что знаете. Это, кстати, и есть психологическая часть кейса:)
(27) Dmitri_1C,
Еще варианты:
1. Лошадь без чувства юмора.
2. Лошадь не в настроении (любимый вчера бросил)
3. Анекдот попался не смешной или с огромной «бородой»
4. Схватила пучок травы потолще и рот временно занят.
(23) Зато Я не ввяжусь в проект рентабельность которого трудно прощитываема.
(28) ещё вариант написать заказчику проработанную с точки зрения психологии лабуду чтобы ему понравилось а реально выполнять заказ с помощью цыган-инвалидов.
Или четно сказать что без цыган в вопросе лошадей никак, но на тендер идти именно в качестве табора цыган а не программистов.
Хорошо. Проблему обшутили, однако, давайте попытаюсь дать правильный ответ. Именно в категориях не точных наук:
Первое что нам нужно — это осознать задачу. А задача не в том чтобы выиграть тендер, а дать предложение имеющее наибольшую вероятность заработать на заказе (НЕ ВЫИГРАТЬ, а именно ЗАРАБОТАТЬ).
Второе что нам нужно — это убедить наше руководство принять и просчитать предложение именно для нашего варианта. Причем руководство также должно понимать, что предложение Ваше лучшее, но не 100%-е, а значит согласиться с ним и не ругаться в случае неудачи.
То есть видим двойственную цель: попытаться выиграть тендер и при этом не быть козлом отпущения в случае неудачи.
Теперь наша аргументация для собственного руководства:
Мы расположили варианты решения от самого простого и неточного к самому сложному и точному, но как правило в жизни самое простое и самое сложное решение оказываются неприменимы. Из оставшихся по тому же принципу Парето большинство наших конкурентов будут реализовывать именно центральный 3-й вариант, а значит если мы просчитаем его то конкуренция на тендере сведется по сути к цене, что все равно не даст нам нормально заработать. Значит остаются варианты 2 и 4. Из них я бы предложил остановиться на 2-м так как предлагать сразу оба нельзя, чтобы клиент не заподозрил нас в том, что мы не можем найти лучшего. Второй хорош еще и тем, что он проще и его будет легче донести до заказчика чем более сложные варианты (если уж возникнет спор не только о цене, но и о методах). Мы убедили начальство и смотрим, что может произойти на тендере:
В этом случае если пройдет какой-то из вариантов серии 3 то почти наверняка цена будет сбита множеством предложений, а значит — не велика потеря. Если победит почти без конкуренции вариант 4, то можем сказать — пусть теперь помучаются с реализацией, а мы за это время найдем 2-3 заказа попроще и заработаем больше, а если вариант 2 (как у нас), но наших конкурентов, то обвинить можно спокойно во всем финансистов, не сумевших дать конкурентоспособную цену — Вы здесь совершенно не причем, все что от Вас зависело Вы сделали идеально и попали в самый правильный вариант.
Вот примерно таких ответов и рассуждений я ждал.
И совершенно никакого программирования:)
Зачем я это прочитал?
(32) Идальго, А я два дня читал, понял, что я не гуманитарий и с лошадьми у меня ступор.
Хотя родилась идея:
Зазывать самцов на соблазнительную самку, а самок на крутого самца. Зов природы и все такое.
Можно ещё найти место их водопоя и там выкопать яму на подобии той в которую Кинг-Конга поймали.
Натренировать собаку на запах лошадей, посадить около ворот,- пускай сама открывает ворота кнопкой. (выработать условный рефлекс). Плюсы: 1) Платить денег вообще не надо; 2) Корм обойдется дешевле чем самая низкая зарплата инвалида; 3) Вероятность попадания лошадей очень высокая; 4) Вероятность попадания льва,- крайне низкая (Взрослая собака не очень ладит с взрослыми кошками).
В условиях российской тендерной экономики ни гуманитарные, ни программистские рассуждения не имеют никакого смысла 😉
(36) AlX0id,
🙂
Мы же моделируем реальность! Может быть, конечно, слишком смело:)
(35) ZERO_, Собака, кстати, хороший вариант. Но вот по корму не вполне согласен. Корм-то дешев, но вот кормить собак, тренировать собак, возможно лечить и т.д. придется людям. А это значит все равно нужно платить зарплату.
(23) …..при этом сэкономим время чтобы заработать денег на другом проекте. чем не вариант?
(31) резюмируем: для решения вашей задачи вы предложили воспользоваться принципом Парето. Использование этого принципа привело к тому, что для тендера следует опять же предложить использовать принцип Парето. И при чём тут гуманитарные знания?
Интересные вы гуманитарии… выбор решения основывается на ничем не подкрепленных предположениях:
1. что конкуренты нагенерируют столько же вариантов
2. расположат их в таком же порядке
3. начнут рассуждать примерно так же (это просто, это сложно, возьмем посередине), и только автор опередил их на один шаг и выбрал вариант легче среднего
Причем п.3 очень напоминает старый анекдот про наркомана
В этой задачи учли мнение владельца предприятия, который эту задачу поставил?
Общаюсь с разными заказчиками.
Представления правильного конечного решения очень разные.
Я так понимаю, лучший вариант, это когда заказчик удовлетворен результатом.
И тут сложно угадать, кто выиграет в тендере.
(39) ander_, Вариант. Неявно он присутствует всегда при принятии любого решения, но на предварительной стадии: то есть сначала мы принимаем решение что-то делать или не делать ничего. В данном случае решение «делать» по условию уже принято.
(41) ander_, Вот это уже действительно сущностная дискуссия, спасибо. Я не идеализирую свою точку зрения и она, безусловно, не идеальна… Но нам как раз и предстоит принять решение в условиях неопределенности. Здесь явно не хватает обоснованных количественных суждений формализуемых той же теорией игр, и речь идет как раз не об измеряемых и подтвержденных знаниях, а на наиболее рациональных предположениях.
И моя цель в данном случае была именно посмотреть как себя чувствуют программисты в условиях качественной (а не количественной) неопределенности.
Пока, могу констатировать, что не очень хорошо. Отказ от реализации самый популярный ответ. Мотивации отказа в основном сводятся к двум моментам — невозможность определения количественного критерия эффективности или самого проекта (рентабельность), или эффективности решения (вероятности определения).
А вот почему у программистов такая проблема я все еще не понял. Варианта вижу 2:
1. Психологический «дискомфорт» от количественной неопределенности.
2. Недостаток все-таки как и предполагалось знаний и опыта для построения стратегий принятия решений в таких условиях.
(40) vlad.frost, Может быть при том, что Парето не был математиком, а его закон — это не математическая конструкция, а эмпирическое правило?
А то, что при длительном использовании «ловушки», лошади как вид по весу, размеру, цвету начнут меняться учли? Т.е. те, что будут попадать в «параметры» будут ловиться и не давать потомство, а те, что не попадают — больше распространяться в диких условиях;-)
(46) venger, Как было сказано ранее — это уже не лошади. =)
(45) в педивикии ,что «основная сфера использования закона — экономика, менеджмент, хотя он также эффективен и в политологии». Так что пусть менеджеры этот принцип применяют, а не программисты.
А лучше посадить человека. Они будут лучше определять кто перед ним.
(48) vlad.frost, Созвучно уже приведенному анекдоту про программистов и лампочки. На самом деле меня беспокоит именно то, что программисты мыслят только как программисты. То есть для принятия решения программисту нужны измеренные величины. Но ведь выбирая девушке букет программист не вычисляет вероятность получить этим букетом по морде. Или вычисляет?
(50) разница в мыслях программиста и гуманитария в том, что программисту надо думать «Как это реализовать», а гуманитарию или управленцу не надо об это заботится. Для гуманитария решение задачи про лошадей выглядит так:
1) Построили загон
2) Зашла лошадь
3) Определии лошадь это или нет
4) Отпустили или поймали.
Какие то там тонкости по строительству, оборудованию. алгоритмам гуманитариев не волнует. Не им же код писать, или столбы ставить для загона.
А вот тем, кто непосредственно реализует, вот он уже думает КАК сделает, и что сделает, что бы добиться конечного результата.
Касательно букета, программист не задумывается как был сделан этот букет. В отличие от гуманитария цветочника) Который выбрал плёнку, цветы, скомпоновал их по длине, увяданию, перевязал лентой с хитрым узлом. В общем подумал как программист и реализовал букет.
По этому гуманитарий ты или программист, это состояние человека по отношению к решению конкретной задачи.
ИМХО.
(51) KiLLius, Очень интересная мысль… Но в данном контексте получается что когда, допустим, программисту нужен букет он ведет себя как гуманитарий, то есть доверяется исполнителю (цветочнику) не продумывая реализацию и выбор. В (42) была такая же мысль. То есть мы можем выбирать совершенно произвольную реализацию решения, так как мы: а) профессионалы в отличие от заказчика, б) все равно не можем заранее угадать какое решение заказчика в конце концов устроит (и устроит ли вообще какое-нибудь).
Получается выбор методом игральной кости или рулетки…
Или осознанно мы будем стремиться к тому решению которое нам будет легче всего реализовать так как все варианты для клиента равновероятно хороши/плохи.
В этом есть логика и рацио:)
(49) ololoanonim, человеческий фактор) самый хреновый фактор. От машины можно ожидать отклонения или сбоя. А человек заболеет, напьется, ослепнет, получит амнезию, уйдет в декрет, перепутает с зеброй или коровой. Хотя в рабочем адекватном состоянии он подходит лучше.
По поводу задачи надо делать исследование по параметрам: платежеспособности клиента, окружающей фауны(средний процент отличия по доступным параметрам от необходимого нам животного), разброс доступных параметров искомого животного, режим работы оборудования(24/7,12/5,?), погрешности оборудования(дневное,ночное время) ну и ожидаемые сроки.
Только после этого можно делать какие то предположения относительно логики решения задачи.
(52) ну как правило, правд много. И клиенту выбрать лучшую/наименее худшую правду помогает(при гуманитарном подходе), когда нет цифр и аргументированных доводов, только интуиция управленца, талант, внутренний голос, называйте как хотите.
В примере с букетом, нет некрасивых букетов, есть те которые нам не понравились. А почему? Ответ каждый даст себе лично. И будет по своему прав.
(51) KiLLius, Странное сравнение, про букет. Допустим я не знаю как прога работает, исходники могут быть вообще закрыты, но есть api и я умею его дергать в своей программе. я гуманитарий?
(55) vslimv, относительно своей программы конечно же нет, если ты сам подцепляешь API, разрабатываешь прогу и тд. А если ты как Обезьянка нажимаешь кнопки, потому что так надо работать с программой, то конечно же ты гуманитарий.
А касательно API ты являешься гуманитарием. Ты не участвовал в её разработке. Ты пользуешься готовым рашением. Там код может матом написан справа налево, для тебя главное что бы он работал и не важно как.
(51)(52), коллеги, думаю, здесь спор не про физиков против лириков, а об уровне погружения конкретного исполнителя в детализацию задачи, и о возможности этого исполнителя иногда выглядывать на соседние уровни абстракции, и прикидывать, как его реализация на них повлияет. Будь то программист, оперирующий интерфейсами, или управленец, принимающий решения в условиях неопределённости. Вот это умение видеть как твои действия повлияют на общий результат, оно видится полезным, и надо бы его всячески развивать. Программисту, например, получить знания о менеджменте, а менеджеру — о программировании.
(57) vlad.frost, Действительно, может быть в такой формулировке проблема становится более общей. Можем ли мы видеть весь проект в целом, или не смотрим дальше результата выполнения кода («не видим лес за деревьями»)?
Вообще сладкий сон большинства программистов — качественное ТЗ, это когда кто-то увидел весь проект целиком, разделил его на подсистемы и дал тебе качественную постановку твоей задачи. В этом случае нет спора физиков и лириков, а есть профессиональная и направленная работа по достижению общей цели — лирики играют поют и танцуют, физики изготавливают и настраивают инструменты.
Но качественное ТЗ, это то чего все хотят, но никто не видел:) И умение встраиваться в проект с нечеткими постановками задач, и более того самому разрабатывать проекты и ТЗ это я думаю вещь полезная и необходимая для работы и особенно для карьеры…
Во-первых, этих четырех параметров не достаточно для однозначной идентификации лошади. Я бы их использовала для первичного грубого отбора особей от других животных. Цвет можно исключить: животных красного цвета не бывает в природе. Можно использовать фотографию животного в профиль. И ее уже распознавать обученной нейронной сетью. Мне кажется, такая система будет работать с наименьшей погрешностью.
Я бы занялась такой задачкой! 😉
(59) inlimbo, Именно об этом я говорил параметров не достаточно. А по поводу фотографий это точно. Пару фото в профиль и ищем совпадение ключевых слов. Дядя Гугл нам поможет)
(59) inlimbo, (60) vslimv, Знаете, ребята, есть такой принцип бритвы Оккама. Вы пытаетесь плодить сущности без необходимости. Распознавание лошади по фото — та еще задача. Вы не забывайте, что все виденные Вами фото сделаны людьми и Вы видите лишь те на которых лошадь удачно получилась. Лошадь может опускать/поднимать голову в момент съемки, ступать на какую либо ногу, а другую соответственно поднимать, размахивать гривой и хвостом, отгоняя гнус и т.д. Не задумывались о том, что автоматические фото будут весьма сильно отличаться от образцов? А если мы наберем очень много образцов для обучения нейронной сети (да и любого другого распознающего механизма) будет ли при этом надежной такая сеть?
Задачу нужно начинать с оценки надежности определения лошади в уже существующем терминале, а потом (если приемлемой надежности добиться не удастся) плодить сущности, но лишь после того как будут исчерпаны все подходы к идентификации в рамках существующих (извините за тафтологию) сущностей.
Гуглим кластерный анализ и не заморачиваемся гуманитарными отвлечениями ))
(62) MaxDavid, А почему кластерный анализ не является по Вашему одним из типов распознающей модели? Различия по форме есть, а по сути это обучение на множестве.
Ну вопрос о габаритах лошадей это все-таки не из гуманитарной области.
Для построения лошадеразделочной машины технари-пищевики скорее всего перемерили бы одно-два стада, вывели коэффициенты подобия для лошадей (длина ног/рост, ширина крупа/рост и т.д.) а затем бы занялись настройкой ножей на этих коэффициентах от одного-двух параметров, которые проще измерить. Например лошадь может проходить мимо датчика, который фиксирует ее рост в неразделанном состоянии. Или готовая к разделке протискиваться между слегка подпружиненными рычагами, что позволяет считать ее максимальную ширину.
ЗЫ.: В практических целях проще всего вместо чудо-датчиков установить камеру, а управление дверью доверить профессионалу-ЧОПовцу или блондинке-секретарше.
(63)
В том-то и дело )) Кластерный анализ — способ алгоритмизации поставленной задачи, исключающий необходимость изучения гуманитарных знаний. Грубо говоря, приходит 1Сник на место, выслушивает ТЗ и говорит: «Это задача кластерного анализа, я вам дам работающий алгоритм, а коэффициенты будете задавать сами в зависимости от текущих надобностей.» Все довольны, 1Сник уходит с баблом ))
(65) Infector,
Неужели нельзя найти более интересных задач для блондинки-секретарши?:)
Датчик движения фиксирует приближение объекта. При сработке датчика движения фотографируется объект. Фото объекта отправляется на распознавание специально нанятым на upwork индусам. Индус в вероятностью 99.99 распознает лошадь. Правда может перепутать лошадь с пони 🙂