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

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

_>И для таких целей в нормальных языках имеется перегрузка операторов. Которая позволяет именно что читабельным образом задавать математику любого уровня сложности. Например если говорить про этот алгоритм, то на каком-нибудь numpy (конечно же скомпилированном с mkl) это и запишется проще и работать будет скорее всего быстрее. )))
Очень может быть. С нетерпением ждём примера С4 с nearest neighbour на языке с перегрузкой операторов.

_>Да, а по поводу выбора между производительностью и инвариантами — это у тебя будет в любом языке. Т.е. или ты доверяешь входным данным (позволяешь делать двоичный поиск по произвольным массивам, факт сортировки которых гарантируется "административно") или же не доверяешь (постоянно пересортировываешь их на всякий случай). Третьего варианта нет.
Конечно же есть. Третий вариант — отслеживать отсортированность данных при помощи системы типов. То есть sort(array) возвращает sortedArray; insert(array) возвращает просто array.
Можно даже степень неупорядоченности отслеживать, для выбора оптимального алгоритма сортировки
binarySearch требует sortedArray.
А в мире linq, реализация where поверх sortedArray пользуется двоичным поиском, а поверх просто array — линейным.

_>Эмм, какой ещё linq2d или i4o, если мы говорили про двоичный поиск? )))
Двоичный поиск — это малоинтересный частный случай. Общий подход — такой, как я сказал. Вас интересовал поиск в коллекции? Вот вам i4o. Он заточен не на массивы целых, а на коллекции "тяжёлых" объектов. Поэтому вместо сортировки он строит индекс. Тем не менее, это прекрасно иллюстрирует концепцию linq — декларация запроса и его выполнение разделены.

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

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

_>И для таких целей в нормальных языках имеется перегрузка операторов. Которая позволяет именно что читабельным образом задавать математику любого уровня сложности. Например если говорить про этот алгоритм, то на каком-нибудь numpy (конечно же скомпилированном с mkl) это и запишется проще и работать будет скорее всего быстрее. )))
Очень может быть. С нетерпением ждём примера С4 с nearest neighbour на языке с перегрузкой операторов.

_>Да, а по поводу выбора между производительностью и инвариантами — это у тебя будет в любом языке. Т.е. или ты доверяешь входным данным (позволяешь делать двоичный поиск по произвольным массивам, факт сортировки которых гарантируется "административно") или же не доверяешь (постоянно пересортировываешь их на всякий случай). Третьего варианта нет.
Конечно же есть. Третий вариант — отслеживать отсортированность данных при помощи системы типов. То есть sort(array) возвращает sortedArray; insert(sortedArray) возвращает просто array.
Можно даже степень неупорядоченности отслеживать, для выбора оптимального алгоритма сортировки
binarySearch требует sortedArray.
А в мире linq, реализация where поверх sortedArray пользуется двоичным поиском, а поверх просто array — линейным.

_>Эмм, какой ещё linq2d или i4o, если мы говорили про двоичный поиск? )))
Двоичный поиск — это малоинтересный частный случай. Общий подход — такой, как я сказал. Вас интересовал поиск в коллекции? Вот вам i4o. Он заточен не на массивы целых, а на коллекции "тяжёлых" объектов. Поэтому вместо сортировки он строит индекс. Тем не менее, это прекрасно иллюстрирует концепцию linq — декларация запроса и его выполнение разделены.