On Wed, 25.03.2009 00:14:12 , Alexey Pechnikov wrote: > Hello! > > On Tuesday 24 March 2009 22:29:36 Тихон Тарнавский wrote: > > Вы сказали что-то вроде "транспонирование матрицы -- это ерунда, это и > > си с sql-ем сделать не сложнее". Я привёл другой пример. В файле 92 > > строки. Из них минимум треть добавена исключительно в целях, нужных > > для статьи; в частности, для рассмотрения некоторых искуственно > > введённых сюда приёмов и для удобства построчного комментирования. > > Плюс многочисленные проверки, которые на функциональном языке тоже > > выглядели бы лаконичнее. Итого строк 50 максимум. Добавим реализацию > > матаппарата в том объёме, который нужен для этой функции -- пусть ещё > > 50 строк (с большим запасом). Для императивного языка даю фору -- > > порядок. В тысячу строк уложитесь? Уверен, что нет. Если два порядка > > форы дам -- тогда можно. Намного меньше вряд ли. > > Согласен, что для символьных преобразований императивный подход использовать > противопоказано. Что касается функционального... пожалуй, в основном нужно > динамическое выполнение кода, а map и apply просто удобные обертки для > итератора и стэка. Но в случае > apply #'map 'list matrix > явно лучше обойтись без map и apply, если они в данном случае требуют > каких-то > "хаков" с комментированием (#) и апострофами (это что, игра на ошибке > реализации какого-то диалекта лиспа?!). > > Пусть матрица содержит скалярное или векторное поле. Диффузионные уравнения и > т.п. оперируют с элементом и его "соседями" (простое численное > дифференцирование требует использования как минимум 1 соседней точки, > симметричное - двух соседних), то есть обработка императивная по сути. > > Если в матрице находится нечто символьное, то возникнет задача индексации и > различных выборок и оптимальнее будет использование SQL. Понятно, что в > функциональном языке различные итерации и фильтры реализовать легко, но > индексация и групповые функции (что-то вроде select sum(value) from test > where > value>1) станут проблемой. Я не видел функциональных реализаций b-tree и r- > tree индексов и мне кажется проще их реализовать на императивных языках > (интересно, существуют ли для них высокопроизводительные и устойчивые к сбоям > реализации на функциональных языках). Прошу прощения, но мне теперь уже с каждым письмом, чувствую, будет стоить таких усилий вернуть дискуссиию к её теме от околичных рассуждений, что я бросаю это неблагодарное занятие.
-- С уважением, Тихон Тарнавский. http://linuxforum.ru http://posix.ru -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
