NIntegrate-почему в Mathematica 8 в этом случае он намного медленнее?

ruebenkoответ и комментарии от user1091201 и Леонид вместе объединяются, чтобы дать правильные ответы.

на изменить 1 ответ ruebenko правильный первый ответ для общие ситуации, подобные этой, то есть добавить опцию Method -> {"SymbolicPreprocessing", "OscillatorySelection" -> False}:

expr = (Pi*
      Cos[(Pi*(-2*x + y))/(1 + y)] + (1 + y)*(-Sin[(2*Pi*x)/(1 + y)] +
         Sin[(Pi*(-2*x + y))/(1 + y)]))/(E^x*(1 + y));

NIntegrate[expr, {x, 0, 100}, {y, 0, 100}, 
  Method -> {"SymbolicPreprocessing", 
    "OscillatorySelection" -> False}] // AbsoluteTiming

и user1091201 комментарий предлагая Method -> "GaussKronrodRule" близко к самому быстрому возможному ответьте за этот конкретный проблема.

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

Выбор Метода

в этом примере NIntegrate проверяет expr, приходит к выводу, что многомерное "LevinRule" является лучшим методом для этого интеграла, и применяет его. Однако, для этого конкретного например, " LevinRule "медленнее, чем" MultidimensionalRule "(хотя" LevinRule " получает более удовлетворительную оценку ошибки). "LevinRule" также медленнее, чем любое из нескольких одномерных правил типа Гаусса, повторяемых над двумя измерениями, таких как "GaussKronrodRule", который user1091201 нашли.

NIntegrate принимает свое решение после выполнения некоторого символического анализа интеграла. Существует несколько типов предварительной обработки символов; параметр Method -> {"SymbolicPreprocessing", "OscillatorySelection" -> False} отключает один тип предварительной обработки символов.

по существу, с включенным "OscillatorySelection", NIntegrate выбирает"LevinRule". При отключенном " OscillatorySelection "NIntegrate выбирает" MultidimensionalRule", который быстрее для этого интеграла, хотя мы можем не доверять результату, основанному на сообщении NIntegrate::slwcon, которое указывает на необычно медленную сходимость.

это часть, где Mathematica 8 отличается от Mathematica 7: Mathematica 8 добавляет "LevinRule "и связанные с ним эвристики выбора метода в"OscillatorySelection".

помимо того, что NIntegrate выбирает другой метод, отключение "OscillatorySelection" также экономит время, затрачиваемое на фактическую символьную обработку, которая может быть значительной в некоторых случаях.

задание Method -> "GaussKronrodRule" переопределяет и пропускает символьную обработку, связанную с выбором метода, и вместо этого использует 2-D декартовое правило продукта Method -> {"CartesianRule", Method -> {"GaussKronrodRule", "GaussKronrodRule"}}. Это случается очень быстрый метод для этого интеграла.

Другая Символьная Обработка

и ruebenko ' s Method -> {"SymbolicPreprocessing", "OscillatorySelection" -> False} и user1091201 ' s Method -> "GaussKronrodRule" не отключайте другие формы символьной обработки, и это, как правило, хорошо. См.эта часть расширенной документации NIntegrate для списка типов символьной предварительной обработки, которые могут быть применены. В частности, "SymbolicPiecewiseSubdivision" очень ценен для интегралы, которые не аналитичны в нескольких точках из-за наличия кусочно-функций.

отключить все символьная обработка и получить только методы по умолчанию с параметрами метода по умолчанию, используйте Method -> {Automatic, "SymbolicProcessing" -> 0}. Для одномерных интегралов это в настоящее время составляет Method -> {"GlobalAdaptive", Method -> "GaussKronrodRule"} с определенными настройками по умолчанию для всех параметров этих методов (количество точек интерполяции в правиле, тип обработки сингулярности для глобально-адаптивной стратегии и т. д.). Для многомерные интегралы, в настоящее время он составляет Method -> {"GlobalAdaptive", Method -> "MultidimensionalRule"}, опять же с определенными значениями параметров по умолчанию. Для многомерных интегралов будет использоваться метод Монте-Карло.

я не рекомендую переключаться прямо на Method -> {Automatic, "SymbolicProcessing" -> 0} в качестве первого шага оптимизации для NIntegrate, но в некоторых случаях это может быть полезно.

самый быстрый метод

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

тем не менее, вот самый быстрый метод, который я нашел для этого конкретного интеграла:

NIntegrate[(Pi*
      Cos[(Pi*(-2*x + y))/(1 + y)] + (1 + y)*(-Sin[(2*Pi*x)/(1 + y)] +
         Sin[(Pi*(-2*x + y))/(1 + y)]))/(E^x*(1 + y)), {x, 0, 
   100}, {y, 0, 100}, 
  Method -> {"GlobalAdaptive", Method -> "GaussKronrodRule", 
    "SingularityDepth" -> Infinity}] // AbsoluteTiming

(параметр "SingularityDepth" -> Infinity отключает обработку сингулярности преобразования.)

диапазон интеграции

кстати, ваш желаемый диапазон интеграции действительно {x, 0, 100}, {y, 0, 100} или {x, 0, Infinity}, {y, 0, Infinity} истинный пожеланный ряд интеграции для вашего применения?

Если вам действительно нужны {x, 0, Infinity}, {y, 0, Infinity}, я предлагаю использовать это вместо этого. Для бесконечной длины интеграции колеблется, NIntegrate compactifies подынтегральной функции в конечном диапазоне, эффективно образцов в геометрически размеченный путь. Это обычно гораздо эффективнее чем линейные (равномерно) разнесенные образцы, которые используются для конечных диапазонов интегрирования.