Mathematica Student Edition
Mathematica Home Edition
Computable Document Format (CDF)
Aerospace Engineering & Defense
Biotechnology & Medicine
Finance, Statistics & Business Analysis
Financial Engineering & Mathematics
Financial Risk Management
Software Engineering & Content Delivery
Authoring & Publishing
Social & Behavioral Sciences
Design, Arts & Entertainment
Game Design, Special Effects & Generative Art
STEM Education Initiative
Community & Technical College Education
Primary & Secondary Education
Computable Document Format (CDF)
High-Performance & Parallel Computing (HPC)
See Also: Technology Guide
Other Ways to Buy
Volume & Site Licensing
Does My Site Have a License?
Wolfram User Portal
About Wolfram Research
Stephen Wolfram's Home Page
Wolfram Functions Site
More Info >>
Mark as an Answer
Possible integration problem with Mathematica
In performing an integral, I rearranged terms to make it easier to manipulate the integrand. When I did so, the results of the integral were different, though there should have been no order issues. When I copied and pasted the two versions of the integral to an Excel spread sheet to print and expand for comparison, one term did not display correctly, though it appeared OK in Mathematica. When I rewrote the term, the results were consistent with the reordered version. When I also replaced the offending term with a hand-calculated value, the resulting integral also matched the rewritten integrand results.
Here's the question: how can you ever know whether or not during a replication of an integrand that one is not replicating some internal error in how Mathematica interprets a particular instance of an alphanumeric? I have no idea how long this error has persisted in my analyses, since I have not mastered the technique of performing parametic analyses in batch mode, though it would make no difference since the error would replicate in all parametric variations.
Is this a known issue with Mathematica?
It is impossible to write error-free software. You should submit your problem to Wolfram's Technical Support group, so they can evaluate it and decide if it is something that needs fixing.
I was in the business, so I know that is true. That was not my question.
The question is, "In the presence of the possibility of such errors, what procedures would Mathematica recommend to catch the existence of such errors?"
My take is that no matter what mathematics we put into a model, we must re-do it in another order and see if the answer is the same.
On another note, what does it mean if a parametric model, in my case an NIntegrate function, throws off a complex value for certain parameters that, as they become larger, transitions to a purely real value?
Thanks for you answer.
I frequently run small test calculations in which I do the same problem symbolically and numerically and compare the results.
Another possibility for numerical calculations too large to do symbolically is to run the problem using different methods. I believe NIntegrate
has a number of methods. Also, it is not unusual for the numerical methods to return a result with a very small imaginary part, which I ignore
if I know the result has to be real rather than complex. Finally, sometimes Mathematica results contain a symbol which doesn't appear in OutputForm,
which may explain why you saw something different in Excel. I think that's probably a bug.
If two inputs give different results, it would be worth checking that they are equivalent.
FullSimplify[ (input1) - (input2) ]
Were the two outputs perhaps different in form, or in value, too?
Integrate sometimes generates special special functions for symbolic integrals.
Were the integrals definite or indefinite? If indefinite, could the difference be a constant?
It's always best to post your code if it's not too long. Then we can pound on it and give you brilliant suggestions ;-) .
By the way, why plot it in Excel? Mathematica is up to the task (ore so, in fact). And if there are issues with precision then Excel will fail without warning where as Mathematica will handle them gracefully and also you'd have control over the precision of the numerical computations in order to push them beyond simple machine precision if needed.
Not sure which comments I am replying to, but thanks for the suggestions. My use of Excel was simply to copy the code that was giving me problems into a separate applications. Sure enough, there was one term that I determined was the culprit. I was doing a parametric model and the results of the second parameter iteration looked out of scale, so I went back to the first iteration and simply copied and pasted the Mathematica code into Excel and the culpit showed up. I also played around with changing the order of integration with no changes.
The imaginary component of the solution is larger than the real part! Since the models are simply volumes and since the integrand does not have any poles, the size of the imaginary component surprised me.
I wanted to plot the integrand, but it is a six-variable function and I simply cannot figure out how to plot it to look for pathological conditions. As for plotting the solution set, I have yet to figure out how to perform a "batch" parametric variation within Mathematica and then collect and plot the results using Mathematica. At this point, I am doing it the hard way and plotting the results in Excel.
I am just getting into learning how to tell NIntegrate what method or strategy to use in performing the integration. The note that often comes up about a pole or oscillations does not seem to hold, though the way NIntegrate samples may be part of the problem.
The "bug" seems to be that the value 11.4 in Mathematica looks like ||.4 in Excel...pretty obvious. It only occurred in one of the instances of the value 11.4 that appeared in the integrand...the others were ok, so I am hard pressed to understand what the underlying bit structure is that was corrupted that turned 11.4 into ||.4.
That's all for now, but if and when I make any headway, I will report back.
Re Excel: Any port in a storm! But be sure that the port is open and ready for business....
Copying and pasting to and from Excel can be problematic. A very basic case in point: in Excel everything that **looks** like an integer is actually a floating point. Importing from Excel changes shows all aparent Excel "integers" as floats in Mathematica. Sometimes thins that look like numbers in Excel are actually strings, etc,... So often some post processing of an Import or copy is required.
And generally any "naieve" copy from Mathematica of expressions may well not past into another program as yuo might wish.
What you say may well be true, but since the Excel imports the Mathematica code as ascii, that is all I wanted and it served the purpose of identifying a code error. That same code when recopied from Excel into Mathematica gives the same results as before the export. The issue remains, where did that error come from originally? Since for me it appears to be a one-off issue, I can just be cautious about accepting anything at face value.
With regard to the imaginary component, it should come from some precision or accuracy limits, though setting the AccuracyGoal does not improve things. The NIntegrate process simply reduces the size of the imaginary component as I proceed with the parametric analysis until is quickly disappears. Unfortunately, it is large where I need it to be negligible. That is what I am working on now.