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

S>PerfectFourNeighborAverage() или аналогичное решение, которое не использует linq от слова вообще.
Это — худший возможный вариант. Его дорого как писать, так и исполнять.лохо оптимизируемым.
S>Любые достаточно сложные алгоритмы плохочитаемые и это нормально. Использовать linq, чтобы легче понять алгоритм или не использовать, чтобы он был оптимальным?
В первую очередь алгоритм должен быть понятным. Потому что понятный алгоритм можно сделать корректным. Нас принципиально не интересуют алгоритмы, которые быстро выдают неверный результат.
S>>Очень вряд ли PerfectFourNeighborAverage() станет нормальным решением для семитерабайтного массива, даже если использовать внутри какой-нибудь кеш.
S>Вы имели в виду размер базы данных или именно "массив"?
Я имел в виду "массив данных".
S>Возможно вы меня не поняли, я предлагал использовать другой тип данных + ваш метод с использованием indexer (indexer != array). А если речь именно о размере, то неважно какой алгоритм, все равно придется все данные обработать, все 7 терабайт.
Ну, тут как раз важно, какой алгоритм. Например, можно ли обрабатывать данные в несколько потоков. Или, лучше, на нескольких машинах.
Можно ли векторизовать алгоритм.
Алгоритм с явным выписыванием for for крайне трудно поддаётся каким-либо трансформациям — нам нужен очень умный компилятор, чтобы восстановить замысел программиста, и реализовать его по-новому; не так, как написано.

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

S>PerfectFourNeighborAverage() или аналогичное решение, которое не использует linq от слова вообще.
Это — худший возможный вариант. Его дорого как писать, так и исполнять.

S>Любые достаточно сложные алгоритмы плохочитаемые и это нормально. Использовать linq, чтобы легче понять алгоритм или не использовать, чтобы он был оптимальным?
В первую очередь алгоритм должен быть понятным. Потому что понятный алгоритм можно сделать корректным. Нас принципиально не интересуют алгоритмы, которые быстро выдают неверный результат.
S>>Очень вряд ли PerfectFourNeighborAverage() станет нормальным решением для семитерабайтного массива, даже если использовать внутри какой-нибудь кеш.
S>Вы имели в виду размер базы данных или именно "массив"?
Я имел в виду "массив данных".
S>Возможно вы меня не поняли, я предлагал использовать другой тип данных + ваш метод с использованием indexer (indexer != array). А если речь именно о размере, то неважно какой алгоритм, все равно придется все данные обработать, все 7 терабайт.
Ну, тут как раз важно, какой алгоритм. Например, можно ли обрабатывать данные в несколько потоков. Или, лучше, на нескольких машинах.
Можно ли векторизовать алгоритм.
Алгоритм с явным выписыванием for for крайне трудно поддаётся каким-либо трансформациям — нам нужен очень умный компилятор, чтобы восстановить замысел программиста, и реализовать его по-новому, а не так, как написано.