Здравствуйте, Ikemefula, Вы писали:
I>Рекурсия проще в написании, ты про это забыл ?
То что проще в написании не может быть сложнее в отладке. Сложнее в отладке может быть то, что лаконичнее в написании. Простота и лаконичность это совершенно разные, а зачастую и прямо противоположные вещи.
Здравствуйте, -n1l-, Вы писали:
U>>В реальной работе условия задачи определяется Делом. N>А не тараканами ли заказчика?
Нет. У заказчика, кроме товарища Попила тараканов нет. Есть вполне конкретная задача, которую надо решить.
Здравствуйте, TK, Вы писали:
TK>Не расстраивайтесь, junior разработчики тоже бывают нужны
Прикольнее, когда в итоге на конторе одни такие юниор-сеньеры оказываются.
Здравствуйте, Ikemefula, Вы писали:
I>Понимание структур данных это в первую очередь умение их анализировать и, далее, умение модифицировать и строить новые.
Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает.
Здравствуйте, Ikemefula, Вы писали:
I>Скажи пожалуйста а кто определил специалиста по алгоритмам как зубрилу ? I>Я как раз и говорю, что зазубривать наизусть алгоритмы не нужно.
Как это не нужно зубрить? Ты сам писал:
На сортировке отлично проверяются алгоритмические скилы. Если ты гуглишь сортировки, то сильно вряд ли ты в курсе, что есть сортировки за линейное время или близкое к нему.
А еще у каждой сортировки целая куча разных особенностей, таких, как лучший и худший случаи.
И часто очень важно обосновать правильный выбор. Есть случаи, когда можно и нужно использовать быструю сортировку, а есть случаи, когда ни в коем случае этого нельзя делать.
Кроме того, если нужно будет модифицировать алгоритм, то гугл не скажет тебе, как изменяется вычислительная сложность.
Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
Так чем знание всех сортировок и их лучших/худших случаев поможет написать бинд топлива? Т.е. решить реально востребованную бизнесом алгоритмическую задачу?
Кстати, для общего развития в каких случаях ни в коем случае нельзя использовать быструю сортировку?
Здравствуйте, Undying, Вы писали:
U>Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает.
Я тебе больше скажу для задачи выше о топливе пофиг на эти структуры, достаточно и обычных массивов со структурами, главное придумать правильные фильтры и алгоритмы принятия решения.
Здравствуйте, Undying, Вы писали:
U>Так чем знание всех сортировок и их лучших/худших случаев поможет написать бинд топлива? Т.е. решить реально востребованную бизнесом алгоритмическую задачу?
Не знание всех, а умение строить и анализировать алгоритмы.
U>Кстати, для общего развития в каких случаях ни в коем случае нельзя использовать быструю сортировку?
У ней n*log(n) это среднее время работы, худший случай — n^2
Когда есть некоторые сведения о характере и количестве сортируемых данных, можно подобрать более подходящий алгоритм, часто даже O(n).
Здравствуйте, Undying, Вы писали:
I>>Понимание структур данных это в первую очередь умение их анализировать и, далее, умение модифицировать и строить новые.
U>Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает.
Правильно, а ты мне талдычишь про зубрение и гугление. Что бы правильно подобрать алгоритм надо уметь анализировать. Когда ты это умеешь, то найдешь нужный вариант даже если ты про него никогда не слышал.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ikemefula, Вы писали:
I>>Рекурсия проще в написании, ты про это забыл ?
U>То что проще в написании не может быть сложнее в отладке.
Может, запросто. Большинство рекурсивных алгоритмов на порядок сложнее обычной версии с циклами и приседаниями.
> Сложнее в отладке может быть то, что лаконичнее в написании.
Для отладки важна возможность поставить бряк, получить стек, лог и тд. В рекурсивной версии эти вещи часто приходится обеспечивать дополнительно.
Например в версии с циклами у тебя есть переменная цикла. А в рекурсивной версии она запросто может отсутствовать. Conditional break тебе больше не поможет.
>Простота и лаконичность это совершенно разные, а зачастую и прямо противоположные вещи.
Я честно говоря не знаю что ты подразумеваешь под этими терминами.
Здравствуйте, Vzhyk, Вы писали:
U>>>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей? V>Никак — оно вообще к этой задаче отношения не имеет. Здесь всего-лишь нужен ЦОС, немного ТВиМС и основ матана.
Эту математику еще нужно будет уложить в правильные структуры данных и тд, что бы не было мучительно больно. Здесь как раз теория алгоритмов и сгодится.
I>>А вот владение соответсвующей математикой это уже серьезная заявка. V>Не смеши а, никто вам такую задачу не даст ибо не решите, потому как кроме стандартных алгоритмов ничего не знаете и достаете всех этим. И да, в Минске есть нынче человек 20, кто эту задачу решит — образование нынче такое.
Не понял, ты не согласен с тем, что математика важна или просто хотел попонтоваться ?
Если первое, то пудозреваю, тебе надо поспать, если второе, то не боись, я в такие области лезу ровно настолько, насколько я знаю математику. Скажем в обработку звука я не лезу — нет у меня этой математики.
Здравствуйте, Vzhyk, Вы писали:
U>>>В реальной работе условия задачи определяется Делом. N>>А не тараканами ли заказчика? V>Нет. У заказчика, кроме товарища Попила тараканов нет. Есть вполне конкретная задача, которую надо решить.
Это у твоих заказчиков. А у других это может быть автоматизация бизнеса, выход на новый рынок и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Эту математику еще нужно будет уложить в правильные структуры данных и тд, что бы не было мучительно больно. Здесь как раз теория алгоритмов и сгодится.
Реально пофиг. Главное, чтобы то, что запрограммировал делало именно то что нужно. А вот какая там сортировка, вообще не интересно, главное, чтобы правильная была.
I> Скажем в обработку звука я не лезу — нет у меня этой математики.
А разница в обработке звука или других сигналов не велика, используется все тот же ЦОС, ТВиМС и чуть-чуть матана (большей частью, чтобы понимать первые два). Есть некоторые особенности, которые осознаются только с опытом в конкретной области.
Да, и кстати, еще совсем недавно все это делали на фортране и без всяких извращений. Кстати, до сих пор многие расчетные библиотеки так на фортране и остались.
Здравствуйте, Vzhyk, Вы писали:
U>>Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает. V>Я тебе больше скажу для задачи выше о топливе пофиг на эти структуры, достаточно и обычных массивов со структурами, главное придумать правильные фильтры и алгоритмы принятия решения.
Для этой может хватит и массивов, а вот обработка сигналов да в реалтайме очень часто требует работу с огромными массивами данных. Скажем, объемы данных могут быть больше чем любой непрерывный фрагмента адресного пространства. Как тут обойтись массивами — совершенно непонятно. Наверное у тебя массивы специальные, которые не требуют адресного пространства
Здравствуйте, Vzhyk, Вы писали:
I>> Скажем в обработку звука я не лезу — нет у меня этой математики. V>А разница в обработке звука или других сигналов не велика, используется все тот же ЦОС, ТВиМС и чуть-чуть матана (большей частью, чтобы понимать первые два). Есть некоторые особенности, которые осознаются только с опытом в конкретной области.
И в обработку сигналов я тоже не лезу по той же причине.
Вот скажи, приходит чел и говорит — я знаю матан, твимс и цос, и вдруг оказывается, что он умеет только обработку каких то сигналов, а со звуком у него проблемы. Что ты ему скажешь на собеседовании ?
V>Да, и кстати, еще совсем недавно все это делали на фортране и без всяких извращений. Кстати, до сих пор многие расчетные библиотеки так на фортране и остались.
Про офртран. Я как то сбоку следил, как развивалась софтина где ядро было на фортране. Количество фортранового кода по тем временам было около 15-20мб. Поверх ядра прикрутили НЕЧТО, эмулирующее гигантский массив, раз в десять больше чем адресное пространство, ибо программа на фортране ни с чем кроме обычных массивов работать не умела и ей нужны были конские массивы. И как то так вышло, что это НЕЧТО оказалось напичканым алгоритмами и структурами данных не хуже движка СУБД.
I>Для этой может хватит и массивов, а вот обработка сигналов да в реалтайме очень часто требует работу с огромными массивами данных. Скажем, объемы данных могут быть больше чем любой непрерывный фрагмента адресного пространства.
Не знаешь не пиши — это смешно. И да, у меня такие были и не раз и не влазили много куда, и что, сортировки и т.п. детские алгоритмы (переворот списка, обращения гномика, обход дерева, не помню уже все извращения, что на кывте приводились) к этому отношения не имеют. Модифицируешь алгоритм, чтобы он стал блочным и вперед к поиску "бутылочных горлышек", а они обычно или в скорости сетки (уменьшим обмен) или лишних расчетов (много чего можно закешировать, но иногда лучше пересчитать, чем кешировать — по разному бывает) или в том, что нужно использовать MKL, а не извращаться с велосипедами или просто нужно более мощное железо (ибо выше головы не прыгнешь).
I>Как тут обойтись массивами — совершенно непонятно. Наверное у тебя массивы специальные, которые не требуют адресного пространства
Порезать их на части и сделать блочный алгоритм. А вот тобой предлагаемые извраты с хитрыми контейнерами могут сильно усугубить ситуацию — баги искать задолбаешься, у уж про распараллеливание и не говорю.
Здравствуйте, Vzhyk, Вы писали:
I>>Для этой может хватит и массивов, а вот обработка сигналов да в реалтайме очень часто требует работу с огромными массивами данных. Скажем, объемы данных могут быть больше чем любой непрерывный фрагмента адресного пространства. V>Не знаешь не пиши — это смешно. И да, у меня такие были и не раз и не влазили много куда, и что, сортировки и т.п. детские алгоритмы (переворот списка, обращения гномика, обход дерева, не помню уже все извращения, что на кывте приводились) к этому отношения не имеют. Модифицируешь алгоритм, чтобы он стал блочным и вперед к поиску "бутылочных горлышек", а они обычно или в скорости сетки (уменьшим обмен) или лишних расчетов (много чего можно закешировать, но иногда лучше пересчитать, чем кешировать — по разному бывает) или в том, что нужно использовать MKL, а не извращаться с велосипедами или просто нужно более мощное железо (ибо выше головы не прыгнешь).
Кеширование да без структур данных — это новость !
I>>Как тут обойтись массивами — совершенно непонятно. Наверное у тебя массивы специальные, которые не требуют адресного пространства V>Порезать их на части и сделать блочный алгоритм. А вот тобой предлагаемые извраты с хитрыми контейнерами могут сильно усугубить ситуацию — баги искать задолбаешься, у уж про распараллеливание и не говорю.
А что хитрого может быть в кешировании которое ты сам же и упомянул ? Для распараллеливания, кстати, как раз и нужны всякие структуры данных.
Здравствуйте, Ikemefula, Вы писали:
I>Вот скажи, приходит чел и говорит — я знаю матан, твимс и цос, и вдруг оказывается, что он умеет только обработку каких то сигналов, а со звуком у него проблемы. Что ты ему скажешь на собеседовании ?
Скажу, что фигня, за пару месяцев войдешь в тему. Я кстати так и говорю, если хотят от меня не мою специализацию. У меня опыт с низкочастотными речевыми сигналами с их особенностями, а вот в сигналах того же кардиографа я лох и мне надо несколько месяцев будет читать статьи и литературу в той области (в т.ч. и медицинскую), чтобы начать что-то серьезное делать мочь. Да и желательно, чтобы был наставник. А если пропустить простейшие вещи с фильтрацией и уйти дальше, то там вообще сильно разные научные подходы используются и нескольких месяцев недостаточно. Но, о чем это я, нынче бери и кудай код отсюда и сюда, сортируй гномиков.
V>>Да, и кстати, еще совсем недавно все это делали на фортране и без всяких извращений. Кстати, до сих пор многие расчетные библиотеки так на фортране и остались.
I>Про офртран. Я как то сбоку следил, как развивалась софтина где ядро было на фортране. Количество фортранового кода по тем временам было около 15-20мб. Поверх ядра прикрутили НЕЧТО, эмулирующее гигантский массив, раз в десять больше чем адресное пространство, ибо программа на фортране ни с чем кроме обычных массивов работать не умела и ей нужны были конские массивы. И как то так вышло, что это НЕЧТО оказалось напичканым алгоритмами и структурами данных не хуже движка СУБД.
Для начала известные всем блас с лапаком. Но да, я понимаю, недостаток опыта и знаний виден и ничем я тебе не смогу помочь. Ну нет в РБ и РФ уже спроса на специалистов нужны только "индусы", а так года за 3 ты чему-нибудь научился.
Здравствуйте, Ikemefula, Вы писали:
I>Отдохни уже — мы давно выяснили что кроме твоей области всё остальное говно.
Не только всё, но и все.
А так да, тут я отдыхаю.
