I've run into what seems like a bug in Mathematica 8. I can't find anything related to it online, but I admit I'm not exactly sure what to search for.
If I run this statement:
0.05 + .10 /. {0.15 -> "pass"}
1.04 + .10 /. {1.14 -> "pass"}
1.05 + .10 /. {1.15 -> "pass"}
1.15 /. {1.15 -> "pass"}
I get this output:
pass
pass
1.15
pass
Am I just overlooking something?
Edit: After reading the helpful discussion below, I changed my dispatch table to use a Which statement instead:
f[x_] := Which[x == 1.05, -1.709847, x == 1.10, -1.373823,
x == 1.15, -1.119214, x == 1.20, -0.9160143, x == 1.25, -0.7470223, x == 1.30, -0.6015966]
This seems to do the trick.
Welcome to the world of machine precision. If you examine 1.05 +.10 and 1.15 more closely, you'll see that they're not quite the same:
1.05 + .10 // FullForm
==> 1.1500000000000001`
1.15 // FullForm
==> 1.15`
In addition to incurring small errors when using MachinePrecision, the same floating-point calculation can produce slightly different results at different times of the day. This is not a bug, but rather a by-product of how modern hardware floating-point architectures work
This means you should not use operations like ReplaceAll that depend on knowing exact value of MachinePrecision numbers. Using == (and ===) might be OK because they ignore last 7 (respectively 1) binary digit of MachinePrecision numbers.
Using Mathematica arithmetic should give exact results regardless of time of day, you could use it for your example as follows (10 significant digits)
0.05`10 + .10`10 /. {0.15`10 -> "pass"}
1.04`10 + .10`10 /. {1.14`10 -> "pass"}
1.05`10 + .10`10 /. {1.15`10 -> "pass"}
1.15`10 /. {1.15`10 -> "pass"}
Update: What Every Computer Scientist Should Know About Floating-Point Arithmetic gives some more caveats about floating point arithmetic. For instance, page 80 gives examples of how different implementations of IEEE 754 give slightly different results, even despite being standard compliant
Your replacements only work on exact matches, whereas your While statement uses Equal. You can make the rule based approach work by using Equal as well.
0.05 + .10 /. {x_ /; x == 0.15 -> "pass"}
1.04 + .10 /. {x_ /; x == 1.14 -> "pass"}
1.05 + .10 /. {x_ /; x == 1.15 -> "pass"}
1.15 /. {x_ /; x == 1.15 -> "pass"}
Related
I am trying to calculate a definite integral. I write:
NIntegrate[expression, {x, 0, 1}, WorkingPrecision -> 100]
"expression" is described below. The WorkingPrecision was added in to help with another error.
I get an error:
"NIntegrate::ncvb: NIntegrate failed to converge to prescribed
accuracy after 9 recursive bisections in x near {x} = {<<156>>}.
NIntegrate obtained <<157>> and <<160>> for the integral and error
estimates. >>"
Why am I getting this error for near{x} = {<<156>>} when I am only looking at 0<x<1? And what do the double pointy brackets around the number mean?
The expression is really long, so I think it would be more meaningful to show how I generate it.This is a basic version (some of the exponents I need to be variables, but these are the lowest values, and I still get the error).
F[n_] := (1 - (1 - F[n-1])^2)^2;
F[0] = x;
Expr[n_]:= (1/(1-F[n]))Integrate[D[F[n],x]*x,{x,x,1}];
I get the error when I integrate Expr[3] or higher. Oddly, when I use regular Integrate and then //N at the end, I get a complex number for n=2.
The <<156>> does not mean that the integral is being evaluated at x=156. <<>> is called Skeleton and is used to indicate that a large output was suppressed. From the documentation:
Skeleton[n]
represents a sequence of n omitted elements in an expression printed with Short or Shallow. The standard print form for Skeleton is <<n>>.
Coming to your integral, here's the error that I get:
So you can see that this long number was suppressed in your case (depending on your preferences). The last >> is a link that takes you to the corresponding error message in the documentation.
If you try the advice in the document, which is to increase MaxRecursion, you'll eventually get a new error ::slwcon
So this now tells you that either your WorkingPrecision is too small or that you have a singularity (which is brought on by a small working precision). Increasing WorkingPrecision to 200 gives the following output:
You can look a little further into the nature of your expressions.
num = Numerator#Expr#3;
den = Denominator#Expr#3;
Plot[{num, den}, {x, 0, 1}, WorkingPrecision -> 100, PlotRange -> All]
So beyond 0.7ish, your expression has the potential for serious stability issues, resulting in singularities. It is the numerator rather than the denominator, that requires high precision to converge to the right value.
num /. x -> 0.99
num /. x -> 0.99`100
Out[1]= -0.015625
Out[2]= 1.2683685178049112809413795626911317545171610885215799438968\
06379991565*10^-14
den /. x -> 0.99
den /. x -> 0.99`100
Out[3]= 1.28786*10^-14
Out[4]= 1.279743968014714505561671861369465844697720803022743298030747945923286\
915425027352809730413954909*10^-14
You can see here the difference between the numerator and denominator when you don't have sufficient precision, causing a near singularity.
I came across some weird behaviour when using GroebnerBasis. In m1 below, I used a Greek letter as my variable and in m2, I used a Latin letter. Both of them have no rules associated with them. Why do I get vastly different answers depending on what variable I choose?
Image:
Copyable code:
Clear["Global`*"]
g = Module[{x},
x /. Solve[
z - x (1 - b -
b x ( (a (3 - 2 a (1 + x)))/(1 - 3 a x + 2 a^2 x^2))) == 0,
x]][[3]];
m1 = First#GroebnerBasis[\[Kappa] - g, z]
m2 = First#GroebnerBasis[k - g, z]
EDIT:
As pointed out by belisarius, my usage of GroebnerBasis is not entirely correct as it requires a polynomial input, whereas mine is not. This error, introduced by a copy-pasta, went unnoticed until now, as I was getting the answer that I expected when I followed through with the rest of my code using m1 from above. However, I'm not fully convinced that it is an unreasonable usage. Consider the example below:
x = (-b+Sqrt[b^2-4 a c])/2a;
p = First#GroebnerBasis[k - x,{a,b,c}]; (*get relation or cover for Riemann surface*)
q = First#GroebnerBasis[{D[p,k] == 0, p == 0},{a,b,c},k,
MonomialOrder -> EliminationOrder];
Solve[q==0, b] (*get condition on b for double root or branch point*)
{{b -> -2 Sqrt[a] Sqrt[c]}, {b -> 2 Sqrt[a] Sqrt[c]}}
which is correct. So my interpretation is that it is OK to use GroebnerBasis in such cases, but I'm not all too familiar with the deep theory behind it, so I could be completely wrong here.
P.S. I heard that if you mention GroebnerBasis three times in your post, Daniel Lichtblau will answer your question :)
The bug that was shown by these examples will be fixed in version 9. Offhand I do not know how to evade it in versions 8 and prior. If I recall correctly it was caused by an intermediate numeric overflow in some code that was checking whether a symbolic polynomial coefficient might be zero.
For some purposes it might be suitable to specify more variables and possibly a non-default term order. Also clearing denominators can be helpful at least in cases where that is a valid thing to do. That said, I do not know if these tactics would help in this example.
I'll look some more at this code but probably not in the near future.
Daniel Lichtblau
This may be related to the fact that Mathematica does not try all variable orders in functions like Simplify. Here is an example:
ClearAll[a, b, c]
expr = (c^4 b^2)/(c^4 b^2 + a^4 b^2 + c^2 a^2 (1 - 2 b^2));
Simplify[expr]
Simplify[expr /. {a -> b, b -> a}]
(b^2 c^4)/(a^4 b^2 + a^2 (1 - 2 b^2) c^2 + b^2 c^4)
(a^2 c^4)/(b^2 c^2 + a^2 (b^2 - c^2)^2)
Adam Strzebonski explained that:
...one can try FullSimplify with all
possible orderings of chosen
variables. Of course, this multiplies
the computation time by
Factorial[Length[variables]]...
Let's say I have a relation r^2 = x^2 + y^2. Now suppose after a calculation i get a complicated output of x and y, but which could in theory be simplified a lot by using the above relation. How do I tell Mathematica to do that?
I'm referring to situations where replacement rules x^2+y^2 -> r^2 and using Simplify/FullSimplify with Assumptions won't work, e.g. if the output is x/y + y/x = (x^2+y^2)/(xy) = r^2/(xy).
Simplification works really well with built in functions but not with user defined functions! So essentially I would like my functions to be treated like the built in functions!
I believe you are looking for TransformationFunctions.
f = # /. x^2 + y^2 -> r^2 &;
Simplify[x/y + y/x, TransformationFunctions -> {Automatic, f}]
(* Out= r^2/(x y) *)
In the example you give
(x/y + y/x // Together) /. {x^2 + y^2 -> r^2}
==> r^2/(x y)
works. But I've learned that in many occasions replacements like this don't work. A tip I once got was to replace this replacement with one which has a more simpler LHS like: x^2 -> r^2-y^2 (or even x->Sqrt[r^2-y^2] if you know that the values of x and y allow this).
Lets say, that problems are fairly simple - something, that pre-degree theoretical physics student would solve. And student does the hardest part of the task - functional reading: parsing linguistically free form text, to get input and output variables and input variable values.
For example: a problem about kinematic equations, where there are variables {a,d,t,va,vf} and few functions that describe, how thy are dependent of each-other. So using skills acquired in playing fitting blocks where thy fit, you play with the equations to get the output variable you where looking for.
In any case, there are exactly 2 possible outputs you might want and thy are (with working example):
1) Equation for that variable
Physics[have_, find_] := Solve[Flatten[{
d == vf * t - (a * t^2) /2, (* etc. *)
have }], find]
Physics[True, {d}]
{{d -> (1/2)*(2*t*vf - a*t^2)}}
2) Exact or general numerical value for that variable
Physics[have_, find_] := Solve[Flatten[{
d == vf * t - (a * t^2) /2, (* etc. *)
have }], find]
Physics[{t == 9.7, vf == -104.98, a == -9.8}, {d}]
{{d->-557.265}}
I am not sure, that I am approaching the problem correctly.
I think that I would probably prefer an approach like
In[1]:= Physics[find_, have_:{}] := Solve[
{d == vf*t - (a*t^2)/2 (* , etc *)} /. have, find]
In[2]:= Physics[d]
Out[2]= {{d -> 1/2 (-a t^2 + 2 t vf)}}
In[2]:= Physics[d, {t -> 9.7, vf -> -104.98, a -> -9.8}]
Out[2]= {{d -> -557.265}}
Where the have variables are given as a list of replacement rules.
As an aside, in these types of physics problems, a nice thing to do is define your physical constants like
N[g] = -9.8;
which produces a NValues for g. Then
N[tf] = 9.7;N[vf] = -104.98;
Physics[d, {t -> tf, vf -> vf, a -> g}]
%//N
produces
{{d->1/2 (-g tf^2+2 tf vf)}}
{{d->-557.265}}
Let me show some advanges of Simon's approach:
You are at least approaching this problem reasonably. I see a fine general purpose function and I see you're getting results, which is what matters primarily. There is no 'correct' solution, since there might be a large range of acceptable solutions. In some scenario's some solutions may be preferred over others, for instance because of performance, while that might be the other way around in other scenarios.
The only slight problem I have with your example is the dubious parametername 'have'.
Why do you think this would be a wrong approach?
I have a basic problem in Mathematica which has puzzled me for a while. I want to take the m'th derivative of x*Exp[t*x], then evaluate this at x=0. But the following does not work correct. Please share your thoughts.
D[x*Exp[t*x], {x, m}] /. x -> 0
Also what does the error mean
General::ivar: 0 is not a valid variable.
Edit: my previous example (D[Exp[t*x], {x, m}] /. x -> 0) was trivial. So I made it harder. :)
My question is: how to force it to do the derivative evaluation first, then do substitution.
As pointed out by others, (in general) Mathematica does not know how to take the derivative an arbitrary number of times, even if you specify that number is a positive integer.
This means that the D[expr,{x,m}] command remains unevaluated and then when you set x->0, it's now trying to take the derivative with respect to a constant, which yields the error message.
In general, what you want is the m'th derivative of the function evaluated at zero.
This can be written as
Derivative[m][Function[x,x Exp[t x]]][0]
or
Derivative[m][# Exp[t #]&][0]
You then get the table of coefficients
In[2]:= Table[%, {m, 1, 10}]
Out[2]= {1, 2 t, 3 t^2, 4 t^3, 5 t^4, 6 t^5, 7 t^6, 8 t^7, 9 t^8, 10 t^9}
But a little more thought shows that you really just want the m'th term in the series, so SeriesCoefficient does what you want:
In[3]:= SeriesCoefficient[x*Exp[t*x], {x, 0, m}]
Out[3]= Piecewise[{{t^(-1 + m)/(-1 + m)!, m >= 1}}, 0]
The final output is the general form of the m'th derivative. The PieceWise is not really necessary, since the expression actually holds for all non-negative integers.
Thanks to your update, it's clear what's happening here. Mathematica doesn't actually calculate the derivative; you then replace x with 0, and it ends up looking at this:
D[Exp[t*0],{0,m}]
which obviously is going to run into problems, since 0 isn't a variable.
I'll assume that you want the mth partial derivative of that function w.r.t. x. The t variable suggests that it might be a second independent variable.
It's easy enough to do without Mathematica: D[Exp[t*x], {x, m}] = t^m Exp[t*x]
And if you evaluate the limit as x approaches zero, you get t^m, since lim(Exp[t*x]) = 1. Right?
Update: Let's try it for x*exp(t*x)
the mth partial derivative w.r.t. x is easily had from Wolfram Alpha:
t^(m-1)*exp(t*x)(t*x + m)
So if x = 0 you get m*t^(m-1).
Q.E.D.
Let's see what is happening with a little more detail:
When you write:
D[Sin[x], {x, 1}]
you get an expression in with x in it
Cos[x]
That is because the x in the {x,1} part matches the x in the Sin[x] part, and so Mma understands that you want to make the derivative for that symbol.
But this x, does NOT act as a Block variable for that statement, isolating its meaning from any other x you have in your program, so it enables the chain rule. For example:
In[85]:= z=x^2;
D[Sin[z],{x,1}]
Out[86]= 2 x Cos[x^2]
See? That's perfect! But there is a price.
The price is that the symbols inside the derivative get evaluated as the derivative is taken, and that is spoiling your code.
Of course there are a lot of tricks to get around this. Some have already been mentioned. From my point of view, one clear way to undertand what is happening is:
f[x_] := x*Exp[t*x];
g[y_, m_] := D[f[x], {x, m}] /. x -> y;
{g[p, 2], g[0, 1]}
Out:
{2 E^(p t) t + E^(p t) p t^2, 1}
HTH!