Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Хорошо. Итак, на том, что инженеры должны ответить на вопрос, сколько это будет примерно стоить, мы согласны.
PD>>Тогда вопрос, к которому я и вел : каким образом инженеры будут оценивать эту стоимость ?
S>Традиционно — суммированием произведений количества на цену. В чём вопрос-то?

Как определить количество и цену ?


PD>>И зря ты не ответил на мой вопрос. Повторяю его, и надеюсь все же ответ получить
PD>>Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ?
S>Получит неприемлемые оценки для быстродействия и закроет проект

От кого ? От инженеров ?


PD>>Но только инженер сможет сказать, при каких условиях ее все же можно решать полным перебором, а при каких задача неразрешима при текущем уровне железа.
S>Опять смешение мух и котлет. Работа инженера — дать оценки стоимости, как асимптотические, так и в терминах конкретного времени.

А, все же инженер должен дать оценки ?

S>А "можно или нельзя" — это вопрос бизнеса. NP-полнота — это ж не бабайка, которой детишек пугают. Это совершенно конкретная вещь, когда в асимптотике времени исполнения есть экспонента.

Это все слова, а реально это может означать, что проект вообще не осуществим. Сказать об этом может только инженер.

S>Ну, да, можно иногда ограничиться низкими степенями и всё ещё уложиться в нормативы — например, если мы возьмёмся факторизовывать маленькие числа, то несмотря на NP-полноту получим приемлемое время работы.
S>Но приемлемость определяется не инженерами, а обратно бизнесом. Хороший инженер, конечно же, помогает бизнесу с этим определением. Потому что бизнес не всегда имеет экспертизу в UX, а инженеру, если он берётся рассуждать о требованиях, такая экспертиза крайне полезна.

Значит, инженер, хоть и как-то туманно, но все же помогает ?

S>Вот, кстати, даже в формулировке задачи прозвучало "Приближенные решения не годятся, допустим". Откуда взялось это требование? Его что, инженер придумал?

Да. С приближенными решениями не получить нужный результат.

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

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

S>А для задачи коммивояжёра приближённое решение устроит примерно любой бизнес. То есть — приемлемость приближений зависит не от инженерных свойств (потому что математически все NP-полные задачи сводимы друг к другу), а от потребностей бизнеса. Почему эта простая мысль вызывает такие трудности в освоении?

Бизнес уже знает про задачу коммивояжера ? И может определить без инженеров, что она тут возникает ?

PD>>Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.
S>Я вроде бы русским языком пишу. Вот цитата:
S>

S>Если ни один из вариантов по Z0, Z1, T0, и Y не укладывается в неравенство — значит, проект не имеет экономического смысла, и мы его закрываем.

S>Какой из пунктов непонятен? Вы же пишете ровно то же самое, только другими словами. "Денег у заказчика не хватит" — ну вот это и означает, что предел стоимости проекта определяет не инженер, а заказчик.
S>Откуда инженер знает, хватит или нет у заказчика денег?

А он и не должен знать. Его дело — оценить задачу и затраты. А потом выяснится, устраивает ли это заказчика. По деньгам, срокам разработки и окупаемости.

PD>>Цитирую
>>>Но пока пишем в блокнотик просто Y.
PD>>Y — прямо зависит от Z, только с учетом времени на окупаемость, так как X — текущие расходы, это константа, уже данная.
S>Y зависит от Z косвенно. Потому что можно за очень большой Z сделать систему со вполне себе стрёмным Y — в том числе, и выше, чем X.
S>А иногда с невеликим Z можно получить систему с хорошим Y.
S>Бывает, что уменьшение Y на считанные проценты требует кратного роста Z.
S>Но чаще всего у нас получается ряд вариантов с примерно одинаковым Z, которые дают существенно разные Y (что опровергает гипотезу о существовании зависимости Y от Z), и парочка экстремальных вариантов — "для бедных", с низким Z и высоким Y, и "наилучший" — с приемлемым Z и хорошим Y.

PD>>Да не в принциапх бизнес-планирования дело. Бизнес может, конечно, на основе этих принципов определить желаемую цену проекта. А вот насколько это реальная цена с точки зрения разработчиков ?
S>Ну так это пусть разработчики скажут. Ещё раз поясню простую вещь, которая от вашего понимания почему-то ускользает: бизнес выставляет требования. Например — уложиться в стоимость Z.

Мне кажется, что мы говорим о разных вещах. Ты — о том, как бизнес выставляет требования. Это понятно, что он их должен выставлять из бизнес-соображений, но не будучи компетентен в технической реализации, он может что угодно выставить. И только специалисты-инженеры могут определить, насколько такие требования реальны. И сказать — нет, за время T мы не сделаем, сделаем только за 2T. И железа нужно не на N USD, а на 10N. И обрабатывать K элементов в минуту мы вообще не сможем, техника не позволяет, а только K/2. И т.д.

С этим согласен ? Да или нет ?

S>Всё верно. А может — не устроит. Инженерам об этом узнать неоткуда. Именно бизнес определяет, устроит или не устроит.

Разумеется, только бизнес определяет, устроит или нет его. Деньги-то его. А инженеры определяют эти данные для бизнеса.