ну, вообще говоря, учитывая условие n<nmax, то и программная реализация O(n) существует. Например, в книге Кормена она есть, причём крайне простая. Вопрос лишь в выделении соответствующего массива памяти
Хотя я, на данный момент, если нет каких-то прямо требований именно к матлабу, так как подавляющее большинство задач можно решить и без него, отдал бы предпочтение связке pythhon+SciPy+matplotlib. Понятно, что это не серебряная пуля, но часто этого более чем достаточно, а python все-таки поинтереснее и мощнее язык, чем матлабовские скрипты. Да и стоит это в… да ничего не стоит) Вот, в убунте уже предустановлено) Сиди и хреначь)
Ну, задачи на матлабе решаются разные, иногда очень нужно ООП, хотя бы взять банальный пример какого-нибудь игрового алгоритма или, как скажем один из моих преподавателей, писал на матлабе симуляцию прохождения флюида через пористую среду с визуализацией. Как только задача разрастается, а таких алгоритмов просто полно, сразу ООП способно дать ощутимую пользу.
Чтобы быть менее абстрактным, рассмотрим пример оптимизационной задачи с ограничениями в виде граничной задачи. Тут совершенно легко строится, возможно не самая лучшая, объектная модель, которая отделяет, скажем представление оптимизационной задачи от представления граничной задачи, плюс классы для того, чтобы доставать данные из базы, плюс класс, который управляет расчетами на разных машинах. Класс, отвечающий за визуализацию и т.д. Вопросов много. Повторюсь, что это не модель как я ее вижу, а пример просто.
Конечно, как уже писали, что не многие инженеры готовы писать код, но такие есть и по моему мнению таких не так уж и мало. А задачи встречаются очень сложные, которые, конечно, можно решить иначе, но ООП дает просто удобный инструмент для этого. Можно, конечно, рассмотреть функциональный подход, но такового, насколько я знаю в матлабе особенно и нет, а структурное программирование только все усложнит. Как-то так)
Спасибо, уже правда читал эту книгу на английском, но за перевод в любой ситуации спасибо!) Функциональные языки в массу!)
С оценкой книги согласен. И мне тоже кажется, что описывать в ней .NET и ООП излишне подробно было бы ошибкой.
Также, на мой взгляд, хорошо, что нет множества теоретических аспектов, потому что книга по сути введение, и излишняя строгость могла лишь помешать, опять же имхо!
Мэплу, если мне не изменяет память, можно указать метод решения, или матлабу, я сейчас не вспомню.
Насчет ошибки в рассуждениях — я не понимаю откуда взялась цифра в 1%, может это я просто не догоняю. Это к вопросу о моем заявлении о методе ветвей и границ, которое мы хотим проверить.
Но отбросим его, если меплу не получится указать точно метод решения. В любой ситуации, уверяю Вас, задача оптимизации с 65 булевыми переменными, линейным критерием и одним(!) ограничением решается очень быстро (положим, что я ошибся даже с ветвями и границами), а посему никакие эвристики не нужны просто.
Очень жаль, что Вам не смешно. А хотите эксперимент? Попросите какую-нибудь мат. пакет, типа матлаба, хуже мепла (он все же символьный, да и он пойдет) Решить Вашу задачу, без всяких эвристик — время решения Вас удивит. Вообще говоря, меня удивляет, что Вы так никогда не поступали, иначе очевидно не написали бы этой статьи.
Если хотите, дайте мне Ваши исходные данные, я сам напишу, у меня правда, кроме мэпла старенького нет ничего на данный момент, но и это сойдет))
А насчет эффективности в 1% — может я чего не знаю, а откуда эта цифра взялась?
Послушайте, Вам самому не смешно? Вы решаете элементарную задачу с детской размерностью и говорите, что нужна эвристика. Я писал прогу, которая решает задачу из нескольких десятков тысяч переменных, около тысячи из которых были целочисленными, и время расчета не превышало нескольких минут. А Вы тут травите.
Насчет всех узлов, я согласен, не заметил про один процент. Но во-первых, откуда этот процент? Почему процент? Во вторых, почему такая скорость расчета?
а я не люблю отвечать на бред, но не правы Вы. Метод ветвей и границ не предполагает расчет всех узлов вообще, иначе он не интереснее перебора. У Вас одни ветви, а границы где потеряли?)
Я не спорю, что используются, я не говорил про ущербность постановки, я имел ввиду, что если у нас такая «беда» в простейшем случае, то что же мы будем делать, когда введем доп. условия)
Что за детский сад? 2 млн лет на 65 булевых переменных в задаче оптимизации? Вы смеетесь?
Кроме того, у вас в разных «методах» просто разные критерии, и это Вы еще не учитываете вероятностные особенности инвестиций, их взаимосвязи и прочее.
Открою Вам страшную тайну, метод ветвей и границ решает Вашу задачу за секунды, если не за доли секунды, по крайней мере в той постановке, в которой вы написали. Вперед за учебник по оптимизации.
Я не говорил ничего о теореме Геделя. Я просто взял пример неполной системы аксиом. насчет Геделя — это Вы сами додумали.
Если рассматривать критерий истинности как частный случай, т.е. обговаривая все его условия истинности, то я, конечно, согласен. Думаю, что разошлись именно из-за общности Вашего первого высказывания.
Единственно, хочу немного сказать про эксперимент в физике. На мой взгляд, эксперимент не может считаться даже за ограниченный (частичный?) критерий истинности. Эксперимент может подтверждать теорию лишь на то время, пока она не опровергнута (сколь угодно долго), т.е. он говорит нам, что в рамках наших представлений эта теория позволяет нам с достаточной степенью точности оценить некоторый показатели(и), пока физический процесс протекает в данных условиях.
Мне кажется еще, что просто слово истина — довольно сильное, отсюда недопонимание.
Довольно глупое заявление, учитывая то, «критерия истины» не существует. Это написано в каждом учебнике физике во введении. Это как бы само собой разумеется для любого уважающего себя ученого. Можно на эту тему обратиться, кстати, к Хокингу.
Даже более того, в самой математике критерий истины — довольно интересный вопрос. На эту тему рассуждали такие ребята как Рассел, Гильберт и многие другие. Взять хотя бы простой вариант — неполная система аксиом. В этом случае вы можете получить утверждение, которое не сможете ни доказать, ни опровергнуть. Логически, я имею ввиду. Да и контр-пример возможен далеко не всегда.
Если же говорить о науке вообще, то система аксиоматизации физики была очень популярна в начале 20 века, но как-то до сих пор никто не сподобился. Поэтому, раз у нас нет точного набора предпосылок, мы пока не можем говорить даже о том, что наша система знаний является непротиворечивой (это может иметь воздействия на очень глубоком уровне, сохраняя непротиворечивость на внешнем, взять хотя бы геометрию Евклида, неопровергаемую в «бытовых» условиях).
В силу всего вышесказанного, критерий истины — это удел лишь философов как раз)
Недавно, ставя процесс разработки в компании всего четырех человек, столкнулись с подобной проблемой. А именно: один человек пишет, второй полночи рецензирует и правит, с утра второй выдает претензии первому, а тот кричит о том, что если у него такой плохой код, то почему он работает, и если его постоянно переделывают — то зачем он вообще работает?) И было много всего, что тут описано, причем проблема решилась, по крайней мере приостановилась, за счет как раз подхода XP — их посадили в пару.
Считаю, впрочем, что рецензирование важно для всех участников процесса, по крайней мере нам, как мне кажется, оно дало очень многое, хотя и не без описанных проблем. Но пользы точно больше)
Чтобы быть менее абстрактным, рассмотрим пример оптимизационной задачи с ограничениями в виде граничной задачи. Тут совершенно легко строится, возможно не самая лучшая, объектная модель, которая отделяет, скажем представление оптимизационной задачи от представления граничной задачи, плюс классы для того, чтобы доставать данные из базы, плюс класс, который управляет расчетами на разных машинах. Класс, отвечающий за визуализацию и т.д. Вопросов много. Повторюсь, что это не модель как я ее вижу, а пример просто.
Конечно, как уже писали, что не многие инженеры готовы писать код, но такие есть и по моему мнению таких не так уж и мало. А задачи встречаются очень сложные, которые, конечно, можно решить иначе, но ООП дает просто удобный инструмент для этого. Можно, конечно, рассмотреть функциональный подход, но такового, насколько я знаю в матлабе особенно и нет, а структурное программирование только все усложнит. Как-то так)
Думаю, что было бы круто добавить настроек и сделать это web-сервисом. Представляется, что нашлись бы сочувствующие.
С оценкой книги согласен. И мне тоже кажется, что описывать в ней .NET и ООП излишне подробно было бы ошибкой.
Также, на мой взгляд, хорошо, что нет множества теоретических аспектов, потому что книга по сути введение, и излишняя строгость могла лишь помешать, опять же имхо!
Удачи!
Насчет ошибки в рассуждениях — я не понимаю откуда взялась цифра в 1%, может это я просто не догоняю. Это к вопросу о моем заявлении о методе ветвей и границ, которое мы хотим проверить.
Но отбросим его, если меплу не получится указать точно метод решения. В любой ситуации, уверяю Вас, задача оптимизации с 65 булевыми переменными, линейным критерием и одним(!) ограничением решается очень быстро (положим, что я ошибся даже с ветвями и границами), а посему никакие эвристики не нужны просто.
Если хотите, дайте мне Ваши исходные данные, я сам напишу, у меня правда, кроме мэпла старенького нет ничего на данный момент, но и это сойдет))
А насчет эффективности в 1% — может я чего не знаю, а откуда эта цифра взялась?
Насчет всех узлов, я согласен, не заметил про один процент. Но во-первых, откуда этот процент? Почему процент? Во вторых, почему такая скорость расчета?
Кроме того, у вас в разных «методах» просто разные критерии, и это Вы еще не учитываете вероятностные особенности инвестиций, их взаимосвязи и прочее.
Открою Вам страшную тайну, метод ветвей и границ решает Вашу задачу за секунды, если не за доли секунды, по крайней мере в той постановке, в которой вы написали. Вперед за учебник по оптимизации.
Если рассматривать критерий истинности как частный случай, т.е. обговаривая все его условия истинности, то я, конечно, согласен. Думаю, что разошлись именно из-за общности Вашего первого высказывания.
Единственно, хочу немного сказать про эксперимент в физике. На мой взгляд, эксперимент не может считаться даже за ограниченный (частичный?) критерий истинности. Эксперимент может подтверждать теорию лишь на то время, пока она не опровергнута (сколь угодно долго), т.е. он говорит нам, что в рамках наших представлений эта теория позволяет нам с достаточной степенью точности оценить некоторый показатели(и), пока физический процесс протекает в данных условиях.
Мне кажется еще, что просто слово истина — довольно сильное, отсюда недопонимание.
Даже более того, в самой математике критерий истины — довольно интересный вопрос. На эту тему рассуждали такие ребята как Рассел, Гильберт и многие другие. Взять хотя бы простой вариант — неполная система аксиом. В этом случае вы можете получить утверждение, которое не сможете ни доказать, ни опровергнуть. Логически, я имею ввиду. Да и контр-пример возможен далеко не всегда.
Если же говорить о науке вообще, то система аксиоматизации физики была очень популярна в начале 20 века, но как-то до сих пор никто не сподобился. Поэтому, раз у нас нет точного набора предпосылок, мы пока не можем говорить даже о том, что наша система знаний является непротиворечивой (это может иметь воздействия на очень глубоком уровне, сохраняя непротиворечивость на внешнем, взять хотя бы геометрию Евклида, неопровергаемую в «бытовых» условиях).
В силу всего вышесказанного, критерий истины — это удел лишь философов как раз)
не понимаю!» — думала Алиса.
Например, такой:
Func<ulong, ulong> fib = null;
fib = (x) => x > 1? fib(x-1) + fib(x-2): x;
fib = fib.Memoize();
Что, на мой взгляд, гораздо симпатичнее) Производительность, конечно, надо сравнивать, но не 4 секунды на fib(40), это уж точно.
А за то, что автор, ударился в такие исследования, даже не упомянув такую возможность языка, как мемоизация, на мой взгляд — нереспект(
Считаю, впрочем, что рецензирование важно для всех участников процесса, по крайней мере нам, как мне кажется, оно дало очень многое, хотя и не без описанных проблем. Но пользы точно больше)