On Fri, Jul 18, 2014 at 10:26 AM, Richard Fateman <fate...@gmail.com> wrote: > > > On Wednesday, July 16, 2014 8:35:49 PM UTC-7, James Crist wrote: >> >> On Friday, July 11, 2014 11:13:28 PM UTC-5, Richard Fateman wrote: >>> >>> The obvious brute force method would be to use software floats in which >>> case you could increase the precision and the range of the >>> numbers involved. I'm assuming the NaNs come from division by zero >>> where the denominator is not actually zero but computes to zero. >>> And the infs come from machine float overflows. >>> >> The NaNs come from division events where the denominator is actually zero, >> but after simplification isn't. For example: >> >> >>> expr = sin(a)/tan(a) >> >>> expr.subs(a, 0) >> nan >> # The deniminator of that was actually 0 (tan(0) = 0) >> >>> expr = expr.trigsimp() >> >>> expr >> cos(a) >> >>> expr.subs(a, 0) >> 1 >> >> In this case I don't think software floats would solve anything. > > > You don't need trig expressions to show that what you are doing cannot be > done with > substitution. Consider that (x^2)/x in the limit as x --> 0 is 0, but by > straight > evaluation is 0/0. You cannot expect subst to compute limits. Hacks > might > appeal to you like substituting "tiny" numbers, but that won't really > survive tough > tests. >> >> >>> >>> Incidentally, if you have 31,000,000 operations that result in a single >>> number, you can be fairly confident that the number is >>> not particularly accurate, and that rearranging the operations will get >>> you a different evaluation. Maybe extremely different. >>> >>> there are some forms that are susceptible to accurate evaluation, or >>> evaluation with known bounds. There is also >>> interval arithmetic, which should give you a bounding interval for a true >>> result. >>> >>> Possible winning forms would be polynomials, so-called Poisson series, >>> truncated Taylor series. >>> >> >> This is something that hadn't occured to me, or seemingly anyone in the >> `mechanics` team. I was under the impression that when evaluating >> numerically sympy used arbitrary precision floats to get accurate results. >> Is this not so? If not, what would be a good way around this, keeping in >> mind that the expressions in `mechanics` are often large, but fairly simple >> (i.e. contain mostly sums of terms containing variables, trigonometric >> functions, powers, and sqrt). > > > Evaluating expressions in a stable form CAN be done for some expressions so > that you get > (a) a value > (b) a bound on the error in the value. > > Not all expressions are easy to rearrange. But the sequence "compute in > single precision" > "compute in double precision" "compute in quad precision" ... does not > necessary solve > the problem because some expressions appear to converge, but to high enough > precision > are actually quite different. Nevertheless, not a bad heuristic. > > You can do an error analysis symbolically, at some cost. For each variable > x, y, z ... > replace x by x+epsilon_x, y by y+epsilon_y. For each operation add in > the > appropriate error. Then see what you get at the end ... > f(x,y,z) + errorf(x,x_epsilon,y,y_epsilon, ....)
If you're going to do things symbolically, you might as well just compute the symbolic limit (which SymPy is quite good at). The problem is that mechanics deals with *very* large expressions, for which doing any kind of nontrivial thing symbolically can be very expensive. Aaron Meurer > > A lot of algebra and maybe not so much insight. > > Interval arithmetic gives you confidence of bounds, but the bounds are > typically crude. > > >> >> >>> >>> RJF >>> >>>>> > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/016e6525-f78f-4799-96a8-68436ef96fcd%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LSnqe4Ng-9hHx_%3DJWNN2G0eMujicdrep6FLu8cEsed1g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
