tobber

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

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

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

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

 

 

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

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

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

 

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

Конечно же остались )
Неплохо знаю ruby, в т.ч. и без рельс, спрашивайте

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

Для достижения максимальной скорости в данном типе алгоритмов вариант вообще только один - кодогенерация.
Итак, смотрим на метод "оптимальнее некуда", через генерацию вложенного for-loop - http://ideone.com/MmoUd
Действительно быстро и все такое... Но стоп 0.42 это примерно 30% от 1.25, которые были в "тупельном".
Т.е. ценой втрое более массивного кода, который еще и немного сложнее для понимания из-за кодогенерации, мы получили трехкратный прирост в скорости.

Мне сложно сказать стоит ли оно того.

Поэтому я еще раз повторюсь - если производительность не совсем уж критична, то вариант с .product лучше, т.к. он проще ( и немного быстрее, да ).
Если требуется максимальная скорость - то делаем генератор кода, который разворачивает рекурсивный алгоритм во вложенную итерацию.
В любом случае вариант с рекурсией на голом Python - лишний. На небольших объемах данных ( до 10^6 строк в итоговой таблице ) он проигрывает в скорости даже у .product().

итого вместо 10-ти кратного ускорения от использования туплов в теории, в реальности имеем 40...400% проседание производительности

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

Да, enumerate не шустр, скорее наоборот. Да, itertools.product тоже тормозит. Деструктуризация туплов в enumerate - не самая летающая операция.
Однако же, мое "тупельное" решение работает немного быстрее вашего и потребляет меньше памяти. ( я про последний вариант http://ideone.com/WmSk1 )

Более того - вы сильно переоцениваете общий вес "туплов" в программе.
Например - http://ideone.com/od632 - здесь, в table_manual_counter, я заменил enumerate на ручной счетчик, получив всего ~10% скорости, избавившись от "дорогого" enumerate и сопутствующей декомпозиции туплов.
На мой взгляд оно того просто не стоит.