tobber

Дело в том, что вывод этого PHP скрипта в браузере обрабатывается и показывается по правилам HTML-разметки.

Переносы строк при этом игнорируются или переводятся в пробелы, а множественные пробелы сокращаются до одного.

Если вы запустите этот скрипт в консоли - то получите именно то, что ожидали - http://ideone.com/VFToed

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

 

 

Но ведь это и есть правильный, насколько это возможно, вариант решения данной задачи.

Такое обычно дают студентам или на курсах. Eval'ить тут - все равно что шпаргалку использовать на экзамене - теряется смысл обучения.

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

 

Если это не студенческая задача - то есть куча решений под .NET, в гугле находятся на раз. Хотя бы http://stackoverflow...culator/2859130

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

In [11]: def void(): pass
In [12]: %timeit void()
10000000 loops, best of 3: 121 ns per loop
In [13]: %timeit (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
10000000 loops, best of 3: 27.6 ns per loop

^ создание тупла из 10-ти элементов и его удаление намного быстрее простого вызова функции.

Проблема в том, что Itertools.product создает по полноценному ряду для всех комбинаций, хотя нам надо всего лишь небольшую часть, т.к. первые элементы выводятся только каждые N раз.
Рекурсивный итератор как у вас эту проблему решает, а мне приходится дополнительно проверять надо ли на этой строке выводить этот столбец.

Впрочем сейчас, на свежую голову, я понял что допустил в самом коде грубую ошибку - использовал %d вместо %s в сборке строки, а это дорогая операция.
Если банально заменить %d -> %s в строке, где собирается <td>, то получается совсем другой результат - http://ideone.com/WmSk1

Хотя product все равно лажает, особенно с ростом входных данных, но это практически не имеет значения в данном случае. Время, которое тратится в .product() - ничтожно, как и время на рекурсию и итерацию.

In [5]: %timeit for i in itertools.product(range(10), range(10), range(10)): pass
10000 loops, best of 3: 59.3 us per loop



In [6]: def product(head, *tail):
   ...:     for item in head:
   ...:         yield item
   ...:     if tail:
   ...:         for item in product(*tail):
   ...:             yield item
   ...:        

In [7]: %timeit for i in product(range(10), range(10), range(10)): pass
100000 loops, best of 3: 6.51 us per loop

Даже сотня-другая us накладных расходов - это абсолютно не важно в общем ходе выполнения данного алгоритма.
Так что выигрыш пусть и в 10 раз по скорости обхода у рекурсивного варианта - не имеет значения.

Мое основное замечание - что если нет разницы, то лучше использовать itertools, т.к. это дает более "чистый" и простой код, без рекурсий и монад.

Мне кажется, что данная задача хоть и образовательная, не является в то же время слишком академической ( как числодробилки на codeforces к примеру ), поэтому я и утверждал что "Подобную задачу гораздо лучше ( на питоне если ) решить так".
Признаю, может это было немного резко.

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