Related
My question is regarding integration. I have a complex function that needs to be integrated and its a definite integral. The thing is when I use Wolfram Alpha to integrate this function it gives me nothing i.e its unable to compute it. However if I remove the boundaries of integration i.e I make my integral an indefinite integral, Wolfram Alpha is able to compute. Now my question is
Can I take the result I obtained for the indefinite integral and just evaluate for the boundary limits to evaluate my definite integral ?
If my analysis is correct, then why wouldn't Wolfram alpha give the result anyways?
using Wolfram Alpha, if I try
integrate(exp(-v)/(1+sv^-1))
then I get the following result
-e^(-v)-e^s s Ei(-s-v)
While if I try
integrate(exp(-v)/(1+sv^-1),{v,1,+infinity})
I get nothing!
since you tagged this Mathematica:
by specifying an appropriate assumption on s we get the expected result:
Integrate[Exp[-v]/(1 + s/v) , {v, 1, Infinity}, Assumptions -> {s > -1}]
--> 1/E + E^s s ExpIntegralEi[-1 - s]
I don't know if alpha has some similar syntax to add assumptions..
additionally if we try a finite integral:
Integrate[Exp[-v]/(1 + s/v) , {v, 1, 2} ]
mathematica returns a conditional expression that tells us the result is valid for s>-1 or s<-2. For some reason it doesn't give such result for the infinite case however.
Yes, you can take the result obtained for the indefinite integral and use to calculate the definite integral. When I try to run your request at Wolfram Alpha, here's what I get:
As you can see in the highlighted portion at the bottom left of the above picture, Wolfram Alpha didn't complete your request because it exceeded the standard computation time. This is because they need to offer some extra features for Wolfram Alpha Pro users to pay for the service. One of this features is extended computation time.
Wolfram Alpha is a business, and this is one of the ways it makes money. See for yourself, it'll offer you the pro service if you click the "Try again with additional computational time" on the bottom right.
If you just break down the definite integration between first the indefinite integral (which it can handle) and then calculate the boundary values and take the difference, it seems to work fine:
This is mathematically correct because that is how definite integrals are calculated.
However your input has an sv in the dividend. Wolfram Alpha is taking it to mean s*v, which might not be what you meant—if sv is a variable on it's own, I suggest you rename it to s or something else. The point is that if s is indeed a variable, if you take a look at the plot in the answer, there seems to be a ridge due to the -∞ term, so for some values of s that ridge might be within your integration curve, and then the integral can't be calculated, as Bill pointed out in his comment to your question.
I have a simple question, for the specific project I am working on I would like mathematica to not evaluate extremely small decimals (of the order of ~10^-90) to zero. I would like a scientific notation return. When I evaluate similar expressions into WolframAlpha I receive a non-zero result.
For an example of a specific evaluation which returns non-zero in wolfram, and zero in mathematica:
Mathematica:
In[219]:= Integrate[dNitrogen, {v, 11000, Infinity}]
Out[219]= 0.
Compared to WolframAlpha:
I've tried searching around myself but oddly enough have only found solutions to the opposite of my problem -Those wanting when mathematica evaluates the small number to print as zero, this seems to involve some use of the Chop function.
Thanks for help/suggestions.
You should use NIntegrate instead of Integrate. By default it will give you the precision you're wanting, and it's also configurable through the PrecisionGoal parameter (and other parameters, see the NIntegrate docs for details).
It is helpful to use physical constants included in mathematica. Unfortunately they all include units. This provides errors when trying to integrate numerically. Is there a way just to get the value of a variable without any dimensions?
Thank you!
Martin
If e.g. c is the speed of light:
c = UnitConvert[Quantity["SpeedOfLight"]]
Then the obvious way would be to write:
c/Quantity["Meters"/"Seconds"]
Because that way, you're certain the unitless quantity you work with actually means something in m/s, not e.g. ft/hour. In other words: If you wrote c/Quantity["Feet"/"Hours"], the result would be the speed of light, in ft/hour, without a unit attached.
Alternatively, you could always write:
QuantityMagnitude[c]
Which just returns the magnitude, without the unit
Perhaps this will help
In[1]:= sol = UnitConvert[Quantity["SpeedOfLight"]]
Out[1]= 299792458 m/s
In[2]:= FullForm[sol]
Out[2]//FullForm= Quantity[299792458,Times[Meters,Power[Seconds,-1]]]
In[3]:= mysol = First[sol]
Out[3]= 299792458
In[4]:= FullForm[mysol]
Out[4]//FullForm= 299792458
In Mathematica as in other systems of computer math the numbers are internally stored in binary form. However when exporting them with such functions as Put and PutAppend they are converted into approximate decimals. When you import them back with such functions as Get they are restored from this approximate decimal representation to binary form.
The question is whether the recovered number is always identical to the original binary number and, if not always, in which cases it is not and how large can be the difference? I am particularly interested in the Put - Get cycle (on the same computer system).
The following two simple experiments show that probably the Put - Get cycle in Mathematica always restores original numbers exactly even for arbitrary precision numbers:
In[1]:= list=RandomReal[{-10^6,10^6},10000];
Put[list,"test.txt"];
list2=Get["test.txt"];
Order[list,list2]===0
Order[Total#Abs[list-list2],0.]===0
Out[4]= True
Out[5]= True
In[6]:= list=SetPrecision[RandomReal[{-10^6,10^6},10000],50];
Put[list,"test.txt"];
list2=Get["test.txt"];
Order[list,list2]===0
Total#Abs[list-list2]//InputForm
Out[9]= True
Out[10]//InputForm=
0``39.999515496936205
But maybe I am missing something?
UPDATE
With more correct test code I have found that in reality these tests show only that restored numbers have identical binary RealDigits but their Precisions may differ even in Equal sense. Here are more correct tests:
test := (Put[list, "test.txt"];
list2 = Get["test.txt"];
{Order[list, list2] === 0,
Order[Total#Abs[list - list2], 0.] === 0,
Total[Order ### RealDigits[Transpose[{list, list2}], 2]],
Total[Order ### Map[Precision, Transpose[{list, list2}], {-1}]],
Total[1 - Boole[Equal ### Map[Precision, Transpose[{list, list2}], {-1}]]]})
In[8]:= list=RandomReal[NormalDistribution[],10000]^1001;
test
Out[9]= {False,True,0,1,3}
In[6]:= list=RandomReal[NormalDistribution[],10000,WorkingPrecision->50]^1001;
test
Out[7]= {False,False,0,-2174,1}
I'm afraid I can't give a definitive answer. If you look into the text file you see it's stored as something like the InputForm of the values, including the precision indication for non-machine precision numbers.
Assuming that Get uses the same conversion routines as ImportString and ExportString your test can be sped up a tiny bit.
Monitor[
Do[
i = RandomReal[{$MinMachineNumber, 10 $MinMachineNumber}, 100000];
If[i =!=
ToExpression[ImportString[ExportString[i, "Text"], "List"]],
Print[i]], {n, 100}
],
n]
I have tested this for several hundreds of millions of numbers in various ranges between $MinMachineNumber and $MaxMachineNumber and I always get back the original numbers. It's no proof, of course, but it seems unlikely that you're going to see numbers for which this is not true if there are any (and in that case the difference would be so tiny as to be negligible).
One important thing to know is that Put[] / Get[] doesn't keep packed arrays packed. You should check out DumpSave[]. It's much faster as it's a binary format and keeps arrays packed.
Examples:
In
CT = Table[Prepend[10^4*x[range2] /.
NDSolve[{...series of equations here...}, {t, range1, range2},
MaxSteps -> 10000,
PrecisionGoal -> 11], delay],
{delay, delaymin, delaymax, 0.1}]; // Timing
what does it mean this // Timing after the semicolon?
In
Dρ = -I*((H0 + V).ρ - ρ.(H0 + V)) - Γ*ρ // Simplify;
And this // Simplify here?
I can't find this explanation anywhere!
Thanks in advance,
Thiago
This is Mathematica's postfix notation.
Basically x//f is the same as f[x]
Yes, argument // function is postfix function application.
Useful about it is that it has a different, lower binding power relative to prefix application (f # x).
In fact it is lower than most other things (exceptions include CompoundExpression ; and Set =), and therefore it can often be considered as "apply to everything before this."
You say: "I can't find this explanation anywhere!". I assume this means you are not aware of the documentation center that's right under your fingertips whenever you're using Mathematica.
All you have to do is to place your cursor on the // and press F1 and you'll get some sort of explanation, or a list with relevant (hopefully) matches. In this case the PostFix page, which is not extremely helpful. However, it has some links at the bottom (assuming you have versions 6, 7 or 8) that provide more insight, among which a link to the syntax overview page (click the Mathematica syntax link, or enter "guide/Syntax" in the search box).
expr // f is essentially equivalent to f[expr]. Sometimes, it's called postfix notation. I read expr // f as "pass the expression expr to the function f".
a // f
is, I believe, the same thing as
f[a]
(which incidentally, any sane mathematician I know would write as
f(a)
just as it is done in most computer languages.)
As others have mentioned, // is the postfix notation and expr//f means f[expr] in mathematica and f(expr) in math.
Although there might be more subtleties involved, my usage of // has often been in cases where I've started writing out an expression and then realized I wanted to operate a function on it. So instead of moving the cursor all the way back to type f#expr or f[expr], I can simply finish typing what I had in mind, and use expr//f.
Example:
Plot[Sin[x],{x,0,Pi}]
%//Export["test.pdf",#]&
The graphics is passed to the export function and is saved as test.pdf.
As your question has already got very good answers, I want to add just a clarification on usage.
The three expressions
Sin[x]
Sin#x
x // Sin
Are equivalent.
Although, to my knowledge, the last two can't be used with functions with more than one argument. So
Plot[Sin[x], {x, 0, Pi}]
Can't be invoked in prefix or postfix notation without tricks like
Sin[x] // Plot[#, {x, 0, Pi}] &
or
Plot[#, {x, 0, Pi}] &#Sin[x]
The prefix notation is usually seen when using simple functions like Sin#x or Sort#list, while most uses of the postfix involve a reasoning like "and now do whatever with this thing I got", for example
(Sin#x+ ...) // Timing
where you decided what to calculate, and then you also want it timed.
One more note:
Really there is much more under the scenes, as the priority of each of these functional constructs is different, but I think that is a much deeper subject and you have to experiment a little before going for subtleties.