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

T>>В случае Хаскеля O(n). У тебя?

VD>Это с каких пор у нас алгоритм быстрой сортировки Хора давал результаот O(n)?

VD>И какие к черту первые элементы при сортировке? Пока все не отсортируешь, ни одного элемента не получишь.

кстати, на дняз было сообщение о библиотеке lazy quick check. если я правильно понял, она быстро проверяет все возможные варианты списка/дерева/.. вплоть до определённого размера именно за счёт ленивости — если результат вычислений не зависит от некоторых значений (они остаются невычисленными), то какой смысл генерировать раличные их варианты?


Announcing Lazy SmallCheck 0.1, a library for exhaustive,
demand-driven testing of Haskell programs.

Lazy SmallCheck is based on the idea that if a property holds for a
partially-defined input then it must also hold for all fully-defined
instantiations of that input. Compared to `eager' input generation
in SmallCheck, Lazy SmallCheck may require significantly fewer
test-cases to verify a property for all inputs up to a given depth.

There is a webpage for Lazy SmallCheck:

http://www-users.cs.york.ac.uk/~mfn/lazysmallcheck/

There you'll find a more detailed description, a worked example, a
comparison with SmallCheck on a number of benchmarks, and link to
download the library.

The library was developed together with Fredrik Lindblad during his
recent visits to York.

Suggestions, experiences and bug reports are welcome!

T> В случае Хаскеля O(n). У тебя?

Вапще-то в этом случае (даже в случае Хаскелла) лучше всё-таки воспользоваться стандартными функциям min/max. Даже если сортировка нестандартных объектов специализированной функцией сорт, всё равно min/max лучше... :о))

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

BZ>кстати, на дняз было сообщение о библиотеке lazy quick check. если я правильно понял, она быстро проверяет все возможные варианты списка/дерева/.. вплоть до определённого размера именно за счёт ленивости — если результат вычислений не зависит от некоторых значений (они остаются невычисленными), то какой смысл генерировать раличные их варианты?

Я не понял, причем тут какието "lazy quick check" и банальная быстрая сортировка?

Орлы вы уже так перефанатели, что ради прославления бох вест чего начинаете оспаривать законы логики и физики.

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

VD>Я не понял, причем тут какието "lazy quick check" и банальная быстрая сортировка?

не кипятись, Влад, я не тебе писал, хотя и отвечал на твоё письмо

thesz,

T>>>Не из-за этого ли все тормозило?
E>>У кого тормозило?

T>Да у вас же и тормозило. Цитата: "метод итераций сходился очень долго (из-за большого объема матрицы)." В итерационном методе (Gauss-Seidel, I presume) используется умножение на матрицу.

T>Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты).

T>http://www.ddj.com/cpp/184403264

T>Беда с этими универсальными интерфейсами.

Прошу прощения за некромантию, но мне непонятно что же всё-таки не так с классом bandStorage? В чём проявляется беда? Вроде класс как класс...

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

NGG>Причин две:
NGG>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
NGG>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.

NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?

Я лично использую ocaml для некоторой разновидности задачи символьных вычислений и переписывания термов. Проект не коммерческий, а, скажем, научно-эксперементальный. Проверяю свои теоретизирования для научной работы. Лучше ocaml-а для этой задачи пока не нашел. Он, имхо, наиболее оптимально сочетает высокоуровневые возможности ФП, что очень удобно для быстрого прототипирования, когда надо срочно поверить новую идейку, и производительность, что также очень важно, ибо размерности задачи иногда огромные и решения приходится ждать по нескольку часов. Моя практика показывает что ocaml (ну и наверное в меньшей степени scala) хорошо подходят для задач обработки всевозможных рекурсивных структур данных. Типичное приложение — разработка трансляторов. Ковыряй в эту сторону. Насчет lisp-а ничего путного сказать не могу.

T>>Беда с этими универсальными интерфейсами.
LCR>Прошу прощения за некромантию, но мне непонятно что же всё-таки не так с классом bandStorage? В чём проявляется беда? Вроде класс как класс...

http://thesz.livejournal.com/807522.html

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

T>>>Беда с этими универсальными интерфейсами.
LCR>>Прошу прощения за некромантию, но мне непонятно что же всё-таки не так с классом bandStorage? В чём проявляется беда? Вроде класс как класс...

T>http://thesz.livejournal.com/807522.html

Неточность:

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

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

То, что в методе итераций я не додумался использовать только L элементов, входящих в полуленту -- да, есть такой грех. Начало четвертого курса, как-никак, да и не ВМиК МГУ К тому же в любом случае метод итераций дает приближенное значение, а методы Гауса и Халецкого -- точные за один проход.

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

E>То, что в методе итераций я не додумался использовать только L элементов, входящих в полуленту -- да, есть такой грех. Начало четвертого курса, как-никак, да и не ВМиК МГУ К тому же в любом случае метод итераций дает приближенное значение, а методы Гауса и Халецкого -- точные за один проход.

Да и еще одна штука. Насколько я помню, при N=100 ширина полуленты была где-то 10-15.

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


NGG>Бывает приятно посидеть вечерком на работе, поделать простенькие программки, почитать баталии ООП vs ФЯ. Достаточно продолжительное время пробовал использовать фвп в коде на c#, но, как бы это сказать, запал стал проподать.

Там это как-то коряво сделано. Типы писать задалбывает, нормального type inference нет и не будет. Я пробовал написать библиотеку, аналогичную parsec, но на C#... С тех пор в функциональном стиле на C# писать зарёкся.

NGG>Причин две:
NGG>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.

У меня другие, значит, насущные задачи. Мои задача на Java решаются долго, криво, и муторно. А на Лиспе или Хаскелле — в десяток строк и без использования мозгов вообще.

NGG>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.

Они дают более адекватный набор примитивов для формулировки решения задачи. Соотвественно, думать надо гораздо меньше.

NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?

Ну, например, любая задача, которая требует реализации маленького проблемно-ориентированного языка.