Если вы вычисляете оба квартиля, вы можете переместить «сортировку» за пределы функции, так что это нужно сделать только один раз. Это также означает, что вы не изменяете данные вызывающего абонента (сортируете!) И не делаете копию каждый раз, когда вызывается функция (сортировка).
Я знаю, преждевременная оптимизация и все такое. И немного неудобно говорить функции: «массив должен быть отсортирован перед вызовом этой функции». Поэтому разумно оставить все как есть.
Но сортировка уже отсортированных данных займет значительно больше времени, чем все остальные функции, вместе взятые (*). Он также имеет более высокую алгоритмическую сложность: в лучшем случае O (N), когда функция может быть O (1) для второго квартиля (хотя O (N log N) для первого, конечно, если данные еще не отсортированы) , Поэтому стоит избегать, если производительность может быть проблемой для этой функции.
Существуют несколько более быстрые способы поиска двух квартилей, чем полная сортировка (см. «Алгоритмы выбора»). Например, если вы знакомы с тем, как qsort использует опорные точки, обратите внимание, что если вам нужно знать 25-й и 75-й элементы из 100, и ваш опорный пункт на каком-то этапе заканчивается в позиции 80, то нет абсолютно никакого смысла возвращаться в блок выше оси. Вам действительно все равно, в каком порядке находятся эти элементы, просто они находятся в верхнем квартиле. Но это значительно увеличит сложность кода по сравнению с простым вызовом библиотеки для сортировки для вас. Если вам не нужно небольшое повышение производительности, я думаю, что вы хороши как есть.
(*) Если у ruby-массивов нет флага, чтобы помнить, что они уже отсортированы и с тех пор не были изменены. Я не знаю, делают ли они это, но если это так, то используйте сортировку! второй раз, конечно, бесплатно.