Сложность алгоритмов и промышленная разработка ПО.

Эффективность не при чём, нужно точное соответвие ТЗ. Остальное не канает.

>Эффективность не при чём, нужно точное соответвие ТЗ. Остальное не канает.

хм, а если в ТЗ указаны жесткие временные рамки работы программы? будут ли разрабатываься эффективные алгоритмы? кстати, может ли указываться в ТЗ ассимптотика?

Ну в ТЗ можно указывать вообще всё, что угодно, лишь бы с этим были согласны обе стороны.

>Ну в ТЗ можно указывать вообще всё, что угодно, лишь бы с этим были согласны обе стороны.

так вот это и интересует - берутся ли исполнители за разработку алгоритмов - или обычно напишем лишь бы работало правильно - а скорость - так задача такая? насколько часто приходится не только кодить, но и что то серьезно продумывать, исследовать?

Приходиться:) Приходится даже программу переписывать с нуля. Чаще всего именно из-за недоработок ТЗ. Страдает и заказчик, и исполнитель.

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

рассматривается ли это сразу? или только после реализации? и переписывают заново?

Если заказчик не говорит, то либо он будет вам моск натягивать и говорить "нормозиииит", либо ему на самом деле пох. Лучше подробнее узнайте у заказкчика, чтобы потом не было вопросов. А вы начинаете проектирование без подписанного ТЗ? Очень Вам не советую это делать... А ещё лучше возмите какую-нибудь литературу по проектированию ПО, там наверняка эти вопросы освещены.

Ясно. Спасибо.

То есть оптимизировать алгоритмы приходится.

И тогда еще один вопрос насколько важна фундаментальная подготовка в математике/теории алгоритмов при приеме на работу в серьезную контору именно в связи с необходимостью на практике разрабатывать новые эффективные алгоритмы?

Точнее сказать насколько это понадобиться при работе - умение разрабатывать алгоритмы? востребованиы ли такие практические знания? или это все таки разовые вещи?

ИМХО, это требуют очень редко, и только на должности software architect с опытом работы лет 5-10 и соответсвующим окладом. Естесственно, что такое быстрая сортировка, бинарный поиск, и другие элементарные вещи знать надо. Чаще требуют отличное знание технологии - будь то язык С, Java или что-то другое. Без этого на работу точно не возьмут, будь ты хоть гений математики.

> эффективностью алгоритмов дальше прочтения Кнута/Ахо/Кормена не занимаются?

"Эффективность алгоритма" - это сферический конь в вакууме :). Интересуют банальные конкретные вещи - затраты времени и памяти. Оцениваются подсчетами на салфетках^W^W^W аналитическими моделями :) Когда всё совсем серьезно, и нельзя постороить адекватную аналитическую модель, используются имитационные (теоретически - сам этого не встречал).

Ясно. Спасибо. Я конечно не гений математики, но зато со знанием языков у меня все в порядке. =)

>"Эффективность алгоритма" - это сферический конь в вакууме :). Интересуют банальные конкретные вещи - затраты времени и памяти.

ну вообще говоря, я этои имел в виду.

>Оцениваются подсчетами на салфетках^W^W^W аналитическими моделями :) Когда всё совсем серьезно, и нельзя постороить адекватную аналитическую модель, используются имитационные (теоретически - сам этого не встречал).

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

Ещё важно знать языки не только программирования:) Ещё хорошо иметь бумажки типа brainbench, либо серитфикаты от SUN и тд и тп.

Ещё, KISS, не забывай об этом:) Есть книга "Имитационной моделирование" не-помню-какого-автора.

> Ещё, KISS, не забывай об этом:)

На всякий случай: "Keep It Simple Stupid" (KISS:)

>дальше прочтения Кнута/Ахо/Кормена не занимаются

кто такие?

> не мог бы посоветовать какую-нибудь литературу кроме означенных классиков - желательно ближе к практике.

Для практики даже эти классики - оверкилл. Оценка (если она делается) делается так - берется "самый плохой" случай для алгоритма, и оценивается количество вычислений и объем памяти. Если в рамках здравого смысла - то начинается реализация :)

ясно. спасибо за информацию =)

но тогда возникает вопрос, неужели такая же ситуация и в таких местах как подразделения Oracle по разработке собственно БД? или это уже совсем другой невероятно крутой мир? а какже геймдев? неужели все стоит только на скорости процессоров, а в алгоритмах подвижек нет?

> но тогда возникает вопрос, неужели такая же ситуация и в таких местах как подразделения Oracle по разработке собственно БД? или это уже совсем другой невероятно крутой мир?

По-моему, ты смешиваешь собственно разработку алгоритмов (т.е. CS) и разработку программ (т.е. SE).

>По-моему, ты смешиваешь собственно разработку алгоритмов (т.е. CS) и разработку программ (т.е. SE).

Нет, ты не совсем понял - меня и интересует именно востребованность специалистов в CS в компьютерных фирмах, а также вообще ведутся ли разработки в области CS в корпорациях или все на откуп академикам?

а также как поступают Software Engineers в случае если не существует известного им эффективного алгоритма решениязадачи. точнее - как поступаю ХОРОШИЕ инженеры, на которых следует равнятся и на которых есть спрос на рынке =)

Я уверен на 99%, что Oracle заказывает сложные части ПО в универах. Либо имеют собственный R&D центр на базе какого-то универа. В гейм-деве как правило, есть несколько движков(от дум3, или UT), и на из базе делают игры.

> как поступают Software Engineers в случае если не существует известного им эффективного алгоритма решениязадачи. точнее - как поступаю ХОРОШИЕ инженеры, на которых следует равнятся

Не уверен, что я подхожу на "ХОРОШЕГО инженера", но - мы спрашиваем у постановщиков задачи (алгоритмистов). Либо, если сам себе постановщик и нужны нетривиальные алгоритмы - смотрю в CS-литературу.

>(алгоритмистов).

вот - вот про них я и спрашивал в том числе. они этим занимаются или тоже из литературы по CS?

Jedem das Seine

ну что каждому его это понятно.

просто интересно - разрабатываются ли в конторах нетривиальные алгоритмы или нет.

Да они вообще к программированию отношения не имеют. Они - специалисты в предметной области. Как они оценивают - ХЗ. Но после них сложность их алгоритмов оцениваем мы и практика :)

>Да они вообще к программированию отношения не имеют. Они - специалисты в предметной области. Как они оценивают - ХЗ. Но после них сложность их алгоритмов оцениваем мы и практика :)

ну да, значит все как и моей конторе. хм, а какую карьеру можно сделать прикладному математику кроме SE? какие есть еще варианты?

> они этим занимаются или тоже из литературы по CS?

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

А и чуть было не забыл Мнооого простых карандашей, бумаги формата A4 и кофе/сигарет ;)

и большая мусорная корзина:)

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

ты сегодня особенно жизнерадостен.

Мне кажется разработка эффективных алгоритмов сильно востребована в специализированном софте. Например системы визуализации 3D графики. Там действительно неправильный алгоритм может утормозить систему напрочь.

а так большинство ведь коммерческого софта это клиент серверные приложения, поэтому 90% эффективности зависит от SQL запросов :-)

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

Это вы про себя?:) Вообще за несоответствие ТЗ можно попасть хорошо.

за несоответствие ИЗ штрафуют рублем, а то и долларом.

да наверное так + всякие серьезные академические научные проекты.

>меня и интересует именно востребованность специалистов в CS в компьютерных фирмах

У тебя мало шансов. Специалистов по CS можно найти в любом компьютерном клу^W подвале.

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

> и большая мусорная корзина:)

Не у нас уборщица программируемая, уходя на столе оставляется листок с надписью "мусор". Утром приходишь - чистота...

> В лучшем случае, а если это для управления станком, и из-за бага поранился или погиб человек? Тогда и сесть можно по статье.

Были случаи, или теоретизируешь?

>У тебя мало шансов. Специалистов по CS можно найти в любом компьютерном клу^W подвале.

да? и где же такой подвал? я хочу туда. а то в лучшем случае быдлокодера\ы попадаются.

> где же такой подвал?

шо, у вас в подвалах в контру не играют? :D

да на любом хуторе, даже на мухосранских выселках и то есть.. правда у этих спецов есть особенность - они обычно в кланы объединяются :)

А вы где-нибудь видели, чтобы в ТЗ было указано, что конечный продукт должен эффективно работать и не содержать галимых багоф? ._.

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

> должен эффективно работать и не содержать галимых багоф?

ГЫ а ведь и точно... Интересно что-бы сказал фрейд про подсознательную тягу к изнасилованию..

Это уж 100%. Жуть как сильно любят ИТ-шные конторы change request-ы, манна небесная. Насчет алгоритмов в общем случае что-то уровня Introduction to Algorithms (ISBN 0-262-03293-7) за глаза хватает.

>рассматривается ли это сразу? или только после реализации? и переписывают заново?

в R&D сразу оговаривается, и перед писанием конечного ТЗ проводятся исследования на эту тему - по сути исследования заключаются в том что люди пишут по размному то или иное имплементируя, сравнивают и приходят к выводу тому или иному, ну это еще и от задачи сильно зависит и от условий.

без R&D там получается что то вроде - "надо заоптимизировать!", потом "медленно, но надо еще!", потом "повысим требования к железу или другим кускам ПО"

>В лучшем случае, а если это для управления станком, и из-за бага поранился или погиб человек? Тогда и сесть можно по статье.

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