Эффективный алгоритм декартовых произведений

вы не можете реально изменить производительность вложенного цикла без некоторых дополнительных знаний, но это было бы специфично для использования. Если у вас есть n элементов is и m элементов js, это всегда будет O (n*m).

вы можете изменить посмотреть этого:

var qry = from i in is
          from j in js
          select /*something involving i/j */;

это все еще O (n*m), но имеет номинальный дополнительно накладные расходы LINQ (вы не заметите его в обычном использовании, хотя).

что ты делать в код случае? Могут быть фокусы...

одно наверняка избегать-это все, что заставляет перекрестное соединение буферизировать -foreach подход прекрасен и не буферизует-но если вы добавляете каждый элемент в List<>, тогда остерегайтесь последствий памяти. Дитто OrderBy etc (если использовано неуместно).

Я не могу предложить ничего лучше, чем O (n^2), потому что это размер выходного, и алгоритм, следовательно, не может быть быстрее.

что я могу предложить, это использовать другой подход к тому, нужно ли вам вычислять продукт. Например, вам может даже не понадобиться набор продуктов P если только вы собираетесь запросить, принадлежат ли ему определенные элементы. Вам нужна только информация о наборах, из которых он состоит.

действительно (псевдокод)

bool IsInSet(pair (x,y), CartesianProductSet P)
{
   return IsInHash(x,P.set[1]) && IsInHash(y,P.set[2])
}

где декартово произведение рассчитывается следующим образом:

// Cartesian product of A and B is
P.set[1]=A; P.set[2]=B;

если вы реализуете наборы как хэши, то поиск в декартовом произведении m наборы-это просто поиск в m хэши вы получаете бесплатно. Построение декартова произведения и IsInSet поиск каждого взять O(m), где m - это количество множеств, которые вы умножаете, и это намного меньше, чем n--размер каждого набора.

дополнительная информация была добавлена к вопросу.

дубликатов можно избежать, если вы записываете те, которые вы уже вычисляли, чтобы избежать их дублирования снова-предполагается, что стоимость такой бухгалтерии - хеш - карты или простого списка-меньше, чем стоимость вычисления дубликата.

среда выполнения C# действительно очень быстрая, но для экстремального тяжелого подъема вы можете захотеть перейти в собственный код.

вы также можете заметить существенная параллельность этой проблемы. Если вычисление продукта не влияет на вычисление любого другого продукта, вы можете прямо использовать несколько процессорных ядер для выполнения работы параллельно. Посмотреть ThreadPool.QueueUserWorkItem.

Если локальность кэша (или локальная память, необходимая для поддержания j) является проблемой, вы можете сделать свой алгоритм более удобным для кэша, разделив входные массивы рекурсивно. Что-то вроде:

cartprod(is,istart,ilen, js,jstart,jlen) {
  if(ilen <= IMIN && jlen <= JMIN) { // base case
    for(int i in is) {
      for(int j in js) {
        // pair i and j
      }
    }
    return;
  }
  if(ilen > IMIN && jlen > JMIN) { // divide in 4
    ilen2= ilen>>1;
    jlen2= jlen>>1;
    cartprod(is,istart,ilen2,            js,jstart,jlen2);
    cartprod(is,istart+ilen2,ilen-ilen2, js,jstart,jlen2);
    cartprod(is,istart+ilen2,ilen-ilen2, js,jstart+jlen2,jlen-jlen2);
    cartprod(is,istart,ilen2,            js,jstart+jlen2,jlen-jlen2);
    return;
  }
  // handle other cases...
}

обратите внимание, что этот шаблон доступа автоматически использует все уровни автоматического кэша; этот вид техники называется кэш-не обращая внимания алгоритм проектирования.

Я не знаю, как писать Java-подобные-итераторы на C#, но, возможно, вы знаете и можете передать мое решение здесь в C# самостоятельно.

Это может быть интересно, если ваши комбинации слишком велики, чтобы держать их полностью в памяти.

однако, если вы фильтруете по атрибуту над коллекцией, вы должны фильтровать перед построением комбинации. Пример:

Если у вас есть числа от 1 до 1000 и случайные слова и объединить их, а затем отфильтруйте те комбинации, где число делится на 20, а слово начинается с "d", вы можете иметь 1000*(26*x)=26000*X комбинаций для поиска.

или вы сначала фильтруете числа, что дает вам 50 чисел и (если равномерно распределены) 1 символ, которые в конце концов составляют только 50*x элементов.