Здравствуйте, thesz, Вы писали:
T>Его отсутствие тем более. Про старые вещи мы знаем больше.
Он не является в общем случае ни достоинством, ни недостатком, поэтому о нём тут вообще не стоит говорить.
А кроме него ты других достоинств Z notation ты не привел.
Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот.
Здравствуйте, Кодёнок, Вы писали:
Кё>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот.
По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр.
Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>>>Что такое ООП? Определи его без языка. IT>>>Думаю, что твои попытки сделать из дискуссии банальный терминологический трёп, в лучшем случае для тебя будут проигнорированы. T>>Я думал помочь Владу в переводе дискуссии в указанное им (и тобой) русло. IT>Не видно, чтобы ты действительно реально этого хотел. По крайней мере, судя по форме твоих сообщений. А от формы напрямую зависит желание людей с тобой общаться.
Со стороны виднее.
Возьмем в качестве наблюдателя тебя.
Ты, например, увидел попытки сделать из дискуссии банальный терминологический трёп.
Я же честно пытался вести дискуссию в русле, заданном Владом. Он придирается ("вместо ФП подсовывают ФЯ"), почему нельзя мне?
Поэтому, я реально этого хотел. Того, что ты увидел.
Боюсь, правда, что я запутал тебя еще сильнее.
T>>А вообще интересно получается: ФП без языка должно быть, ООП без языка — нет. IT>Ты же ведь сам так не думаешь, правда?
Не думаю.
ФП — это язык программирования, если кто не знал. Лямбда-исчисление называется. ФЯ ограничивают порядок упрощения и навешивают синтаксический сахар, оставаясь все тем же ЛИ (читай — ФП) внутри.
ОО — метод классификации.
T>>Double standards. Tell me about it. IT>Just take it easy.
Why should I?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Кё>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр.
Рекомендую попробовать.
Разреженность уменьшается при произведении, например. Произведения специальных случаев (ленточных, например) отличаются по алгоритмам от произведений более общих.
Как сделаешь одинаковый для всех интерфейс, так мало и не покажется. Но уже в районе runtime.
E>Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций.
T>>Его отсутствие тем более. Про старые вещи мы знаем больше. Кё>Он не является в общем случае ни достоинством, ни недостатком, поэтому о нём тут вообще не стоит говорить. Кё>А кроме него ты других достоинств Z notation ты не привел.
Я пост про формальные методы вообще написал.
Там в обозрении их применения есть про плюсы и минусы на примерах многих компаний.
Небольшое чтение про Z notation выявляет, что она основана на Zermelo-Frenkel set theory, одной из наиболее полных и непротиворечивых теорий множеств.
Соответственно, с ее помощью можно отклассифицировать практически все, что встречается в жизни, не получив противоречия. И не получив затруднений наподобие "что от чего должно наследоваться — Квадрат от Прямоугольника или наоборот?"
Кё>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот.
Это ты привык все делать как можно абстрактней.
Достаточно не зацикливаться на "сокрытии реализации," как оно пойдет со страшной силой. Да еще и компилятором поддержано.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
Кё>>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр.
T>Рекомендую попробовать.
. Вполне нормально получилось.
T>Разреженность уменьшается при произведении, например. Произведения специальных случаев (ленточных, например) отличаются по алгоритмам от произведений более общих.
T>Как сделаешь одинаковый для всех интерфейс, так мало и не покажется. Но уже в районе runtime.
Извините, юмора не понял.
Я сам делал обращения к полуленточной матрице в виде обычной записи a[i][j] -- в точности как к обычной. Что дало существенное упрощение реализации пусть и учебной, но все-таки задачи. Не показалось ни много, ни мало.
E>>Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций.
T>Indexless algebra?
Кё>>>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>>>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр. T>>Рекомендую попробовать. E>Пробовал, 13 лет назад
(про невозможность применить метод Гаусса понравилось даже мне, не полностью прочитавшему Вычислительную Линейную Алгебру уже забыл, какого автора)
T>>Разреженность уменьшается при произведении, например. Произведения специальных случаев (ленточных, например) отличаются по алгоритмам от произведений более общих. T>>Как сделаешь одинаковый для всех интерфейс, так мало и не покажется. Но уже в районе runtime. E>Извините, юмора не понял. E>Я сам делал обращения к полуленточной матрице в виде обычной записи a[i][j] -- в точности как к обычной. Что дало существенное упрощение реализации пусть и учебной, но все-таки задачи. Не показалось ни много, ни мало.
Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась?
Не из-за этого ли все тормозило?
E>>>Так же нужно упомянуть, что ООП и ФП (которое без мутабельных данных) накладывают разные органичения на вычисления. Скажем на операцию обращения матрицы большой размерности. Или, например, на решение СЛАУ большой размерности методом итераций. T>>Indexless algebra? E>И что я должен был увидеть в куче устаревших ссылок типа: http://www.numeric-quest.com/haskell/Orthogonals.html E>
В тех же самых cache oblivious вариантах перемножения матриц применяется, практически, indexless представление. Там такой рекурсивный алгоритм блочного перемножения.
Смотри, сколько я умных слов знаю! Это из-за использования ФЯ, вот так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
Кё>>>>>Я например, на практике знаю что для интерфейсов объектная декомпозиция подходит как винт к гайке, а функциональная — плохо подходит, а вот для вычислений и обработки данных всё наоборот. E>>>>По поводу вычислений -- это еще вопрос. ООП может вводить абстракцию matrix и скрывать за ней различные виды матриц -- обычные, треугольные, разряженные, летночные, полуленточные, полуленточные-треугольные и пр. T>>>Рекомендую попробовать. E>>Пробовал, 13 лет назад
. Вполне нормально получилось.
T>Это же явно не сегодняшний день.
ФП -- это вообще даже не вчерашний день. Появилось лет 40-50 назад и так и осталось уделом "избранных". Зачем тогда о нем вообще говорить?
T>(про невозможность применить метод Гаусса понравилось даже мне, не полностью прочитавшему Вычислительную Линейную Алгебру уже забыл, какого автора)
Да, мне нравиться веселить людей. Особенно хорошо это получается с теми, кто уверен в своей интеллектуальной непогрешимости и черезвычайно широкой эрудиции.
T>Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась?
Поскольку вы не внимательно читали, то повторю еще раз -- в моем случае спецпредставление использовалось ради экономии памяти. Поскольку при тривиальном подходе СЛАУ для нескольких сотен конечных элементов просто не помещалась в имевшиеся под MS-DOS-ом 540-600 Kb.
T>Не из-за этого ли все тормозило?
У кого тормозило?
T>>>Indexless algebra? E>>И что я должен был увидеть в куче устаревших ссылок типа: http://www.numeric-quest.com/haskell/Orthogonals.html E>>
T>Wayback Machine to the rescue!
T>Да и просто в качестве идеи.
T>В тех же самых cache oblivious вариантах перемножения матриц применяется, практически, indexless представление. Там такой рекурсивный алгоритм блочного перемножения.
T>Смотри, сколько я умных слов знаю! Это из-за использования ФЯ, вот так.
Наверное, освоившие ФЯ люди по фразе google:indexless+algebra способны найти все, что им нужно.
Завидую вам, но с гораздо большим уважением отношусь к тем, которые ради экономии времени собеседника дают точные URL. К счастью, они встречаются даже среди приверженцев ФП.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодёнок, Вы писали:
IT>>Что именно тебе не понятно в этом выражении: максимальный или эффект?
Кё>Какая ловкая демагогия Что именно тебе не понятно в выражении «треугольный звук» — «треугольный» или «звук»?
Ну, а если закочить упражнения, то ты можешь объяснить, что непонятного в словах ИТ?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Вполне нормально получилось. T>>Это же явно не сегодняшний день. E>ФП -- это вообще даже не вчерашний день. Появилось лет 40-50 назад и так и осталось уделом "избранных". Зачем тогда о нем вообще говорить?
Я про другое.
С тех пор ландшафт языков изменился.
Например, ФЯ перестали быть уделом избранных.
T>>Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась? E>Поскольку вы не внимательно читали, то повторю еще раз -- в моем случае спецпредставление использовалось ради экономии памяти. Поскольку при тривиальном подходе СЛАУ для нескольких сотен конечных элементов просто не помещалась в имевшиеся под MS-DOS-ом 540-600 Kb.
djgpp? watcom?
Или какая-то религия не позволяла?
T>>Не из-за этого ли все тормозило? E>У кого тормозило?
Да у вас же и тормозило. Цитата: "метод итераций сходился очень долго (из-за большого объема матрицы)." В итерационном методе (Gauss-Seidel, I presume) используется умножение на матрицу.
Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты).
. Вполне нормально получилось. T>>>Это же явно не сегодняшний день. E>>ФП -- это вообще даже не вчерашний день. Появилось лет 40-50 назад и так и осталось уделом "избранных". Зачем тогда о нем вообще говорить?
T>Я про другое.
T>С тех пор ландшафт языков изменился.
T>Например, ФЯ перестали быть уделом избранных.
Сильно сомневаюсь. Может быть количественно приверженцев ФЯ и стало больше, но в процентном соотношении ко всем остальным программистам ситуация могла и не измениться.
T>>>Сложность перемножения матриц (ради которой и пользуются спецпрсдетавлениями, а не ради экономии памяти) не поменялась? E>>Поскольку вы не внимательно читали, то повторю еще раз -- в моем случае спецпредставление использовалось ради экономии памяти. Поскольку при тривиальном подходе СЛАУ для нескольких сотен конечных элементов просто не помещалась в имевшиеся под MS-DOS-ом 540-600 Kb.
T>djgpp? watcom?
T>Или какая-то религия не позволяла?
Железо. На наших 86-х было всего 640Kb памяти. На 286-х 1Mb, но с использованием himem.sys под DOS-овские программы удавалось выкраивать что-то около 600-610Kb.
В распоряжении был только Borland C++ 2.0.
Да и в любом случае удалось бы втиснуть в 1Mb СЛАУ для 300КУ, обломились бы на 350.
T>>>Не из-за этого ли все тормозило? E>>У кого тормозило?
T>Да у вас же и тормозило. Цитата: "метод итераций сходился очень долго (из-за большого объема матрицы)." В итерационном методе (Gauss-Seidel, I presume) используется умножение на матрицу.
Насколько я понимаю, я использовал метод простой итерации (вроде бы он называется методом Якоби), где на каждом шаге вычислялось очередное приближение вектора неизвестных. При увеличении точности количество итераций значительно возрастало. Это же итерации, а не точный метод (вроде метода квадратных корней, Гаусса или Халецкого).
T>Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты).
T>http://www.ddj.com/cpp/184403264
T>Беда с этими универсальными интерфейсами.
Да, здесь идет плата скоростью исполнения за скорость разработки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Значит, умножение на ленточную матрицу имело сложность O(N^2) вместо O(N*ширина_ленты). T>>http://www.ddj.com/cpp/184403264 T>>Беда с этими универсальными интерфейсами. E>Да, здесь идет плата скоростью исполнения за скорость разработки.
Ну, я о чем и говорю. Точнее, о чем и говорили в самом начале.
ФЯ с их алгебраическими типами и сравнением с образцом позволяют вынести наружу знания о реализации и проконтролировать правильность их применения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
[]
T>ФЯ с их алгебраическими типами и сравнением с образцом позволяют вынести наружу знания о реализации и проконтролировать правильность их применения.
T>>ФЯ с их алгебраическими типами и сравнением с образцом позволяют вынести наружу знания о реализации и проконтролировать правильность их применения. С>а это всегда хорошо?
Зависит от проблемы.
Можно балансировать.
Главное, у нас есть выбор — скрывать или открывать, сколько открывать...
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Определение отсортированного массива можно дать по разному. Попробуйте дать определение сортировки вставкой и сортироваки слиянием. Во вторых, делает ваш код примерно то же, но выглядит существенно угребищнее Хаскельного варианта. Третье — в вашем случае компилятор не имеет возможностей провернуть ряд ацких оптимизаций, что в состоянии сделать компилятор Хаскеля — у него будет больше информации.
VD>Давай, чтобы не быть голословными, сравним производительность сортировки классического QuickSort написанного на Яве/дотнете в тупом императивном стиле и Хаскелевскую "красоту"? А в качестве входных данных пустим еще отсортированные по убыванию и по возрастанию списки... чтобы выбор точки разделения из начала списка привел бы к квадратичному падению скорости сортировки...
Давай ты не будешь разводить флейм, а почитаешь пост, на который я отвечаю, и в котором автор выписал чисто функциональную реализацию Хаскелевского варианта квиксорта на С#. И если тебе очень хочется — сравним производительность Хаскелевского кода и С# для сортировки, записанной в таком стиле — т.е. одного и того же алгоритма. Специально для тебя цитирую этот дотнетовский квиксорт, о котором идет речь — ты ведь не читаешь ветку нифига.
public static int[] sort(int[] a) {
if (a.length <= 1) {
return a;
}
int x = a[0];
return ArrayUtils.concat(sort(ArrayUtils.less(a, x)),
ArrayUtils.equal(a, x),
sort(ArrayUtils.greater(a, x)));
}
VD>Что не хочшь?
Разумеется, зачем мне в беспредметных спорах участвовать.
VD>Так что не надо этих инсунуаций. Тебе правлиьно показали, что тут приемущество не в некой крутости ФЯ, а в наличии готовых высокуровневых фуцний или конструкций языка и в том, что сортировка получается несолько другим алгоритмом.
Ты сейчас с воображаемым каким-то собеседником споришь. Не буду мешать.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, lomeo, Вы писали:
L>>Ну, я к тому, что ничего тот флейм не показал, а если кто выводы и делал — то больше для себя
VD>Он ничего не показал только упертым фанатикам. Ежу понятно, что в ФП просто нет средст декомпозиции сравнимых по мощьности с классами. То что один из языков расширен хитрой концепцией предоставляющей подобный механизм ни как не меняет дела с самим ФП.
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, VladD2, Вы писали:
VD>>Не. Он просто примерно 3-1000 раз (в зависимости от ситуации) бстре Хаскеля компилятор которого что-то там может в этом плане.
NGG>Серьёзно? Не подскажешь сслыки, где можно почитать про такое сравнение?
Здравствуйте, thesz, Вы писали:
T>Вопрос: сколько операций мне придется сделать, чтобы получить первый элемент массива?
T>В случае Хаскеля O(n). У тебя?
И эти люди тут рассуждают о высших материях...
Это с каких пор у нас алгоритм быстрой сортировки Хора давал результаот O(n)?
И какие к черту первые элементы при сортировке? Пока все не отсортируешь, ни одного элемента не получишь.
Если QuickSort будет написан по человечески в стиле С, то ты в лучшем случае получишь логарифмическую зависимость, а написав его таким вот образом ты получишь полную задницу. Именно по этому в реальной жизни в ФЯ для сортировки списков используют алгоритм сливания.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
