Здравствуйте, Gaperton, Вы писали:
G>Не думал, что у вас создание такого класса представляет такую сложность
. А у нас — вот так:
G>G>fib = 1 : 1 : [ a+b | (a,b) <- zip fib (tail fib) ]
G>
G>Напиши такое на шарпе, можешь даже воспользоваться yield. Посмотрим, позволяет-ли он определать рекурсивные типы данных. Да, кстати, насчет "не думал" — это я слукавил. Я весьма хорошо представляю себе, как это будет выглядеть (правда, без yield)
Для меня этот пример не более чем набор "палочек". Опиши что хочешь получить словами.
Что же касается рекурсивных типов данных, то ты опсываешь функцию, а не данные. Данные могут ссылаться на себя, но не могут быть сами пос себе рекурсивными. Чудес не бывает.
G>Ответ неправильный.
Ты сам себе ответы придумываешь и за одно подтасовываешь их так чтобы под рассужения подходили.
G> Иногда необходимо кэшировать предыдущие.
Кто-то запрещает?
G> Этот пример вычисляет фибонначи эффективно — сложность O(N),
Да плевать всем на фиборачи. В мирной жизни такая лабуда не встречается. Если ФЯ для математиков, то дальше разговаривать нечего. У них и у всех остальных задачи кардинально разные.
G> как раз благодаря кэшированию серии элементов (которое происходит абсолютно прозрачно). Синклеру приводил пример, когда кэшировать надо вообще все: http://www.rsdn.ru/Forum/Message.aspx?mid=790607&only=1Автор: Gaperton
Дата: 02.09.04
.
Блин. Если надо, то значит надо. Или в ФЯ все святым духом делается?
Ты утверждаешь, что на ФЯ нельзя создать линивых вычислений. Вот тебе пример примитивного варианта:
class A
{
int _value = 0;
public void Next() { ++_value; }
public int Current() { return _value; }
}
...
A a = new A();
for (;;a.Next())
{
... a.Current() ...
}
Что это по твоему не линивые вычисления? Нужно обязательно создать список из всех допустимых значений?
Ну, раз линивые, то закроем этот спор. Признай что сморозил глупость.
G>Возможно. На самом деле "ленивые потоки" — наименее опасный вид ленивых вычислений. Это вполне можно включить в императивный язык, как синтаксический сахар и приятную мульку. Но и только.
А только и нужно. Все остальное для теоритиков.
G>Потому как насчет устранения необходимости кэширования — это еще бабка надвое сказала.
Да пускай она все что хочешь говрир. Ты за ней не повторяй.
G>
К барьеру. Напиши код на С#, который имеет такую же характеристику, как приведенный код для фибонначи. А мы посмотрим, где проще ошибиться. Обрати внимание, что если я напишу
G>G>process1( fib ) + process2( fib ) + process3( fib )
G>
G>то числа фибонначи все равно вычисляются один раз, а не три.
Может уже прямо сразу написать тебе сферического коня в вакууме?

Меня твои абстракции уже малость достали. Ты бы написал что-нибудь мнее абстрактное и сравнил бы. А то постоянно цитаты из учебников ничего с жизнью общего не имеющие и те все как один демонстрируют прблемы ФЯ. Взялся быструю сортировку показать, и сразу проблемы. По месту массив отсотрировать не удается. Взять элемент из середины списка таоже. В итоге кода больше, а эффективность меньше. В общем, сплошная антиреклама.
Проблема ФЯ в том, что для жизни на них очень тяжело задачу найти. Библиотеки все черт знает для чего предназначены. Сравнить с тем же фрймворком ну, никак не получается. Давно вот говорю перепишите тесты из шустриков. Хоть что-то можно будет сопоставить. К примеру, вот крайне выгодный для ФЯ тест рассчета ПИ:
public static string pi(int digits)
{
if (digits > 54900)
throw new System.Exception("n must be <= 54900");
StringBuilder pi = new RStringBuilder(digits);
string[] zero = { "0", "00", "000" };
int d = 0, e, b, g, r;
int c = (digits / 4 + 1) * 14;
int[] a = new int[c];
int f = 10000;
for(int i = 0; i < a.Length; i++)
a[i] = 20000000;
while((b = c -= 14) > 0)
{
d = e = d % f;
while(--b > 0)
{
d = d * b + a[b];
g = (b << 1) - 1;
a[b] = (d % g) * f;
d /= g;
}
r = e + d / f;
if (r < 1000)
pi.Append(zero[r > 99 ? 0 : r > 9 ? 1 : 2]);
pi.Append(r.ToString());
}
return pi.ToString();
}
... << RSDN@Home 1.1.4 beta 2 >>