Re: Why Mathematica does not issue a warning when the calculations
- To: mathgroup at smc.vnet.net
- Subject: [mg117607] Re: Why Mathematica does not issue a warning when the calculations
- From: Richard Fateman <fateman at eecs.berkeley.edu>
- Date: Thu, 24 Mar 2011 06:29:39 -0500 (EST)
On 3/23/2011 1:22 PM, Daniel Lichtblau wrote: > Richard Fateman wrote: >> On 3/21/2011 4:13 AM, John Travolta Sardus wrote: >>> With Mathematica 8.0.1 >>> >>> N[FractionalPart[(6 + Sqrt[2])^20]] >>> >>> Result: >>> >>> -160. >>> >>> Is it a problem for all numerical software being able to recognize when >>> these calculations cannot be performed with the given machine accuracy? >> >> Yes, it is a problem. There is some support for this in other >> computational systems (e.g. "inexact" traps), and Mathematica has >> some tools involving increasing the precision of results, but basically >> recognizing that your answer is wrong is, in general, a problem. >> >>> Does this happen in this case only (where a wrong result is easily >>> recognized) or in other cases too? >> >> It happens in cases where you cannot see it directly, as well. > >> To some extent this is a problem with all arithmetic that is of finite >> precision, but it is especially a problem with Mathematica because of >> its unusual arithmetic. > > The example below, and the claim above, are completely tail backwards. Notice that all the previous posters failed to address the JTS's two questions, to wit 1. Is it a problem for all numerical software being able to recognize when these calculations cannot be performed with the given machine accuracy? and 2. Does this happen in this case only (where a wrong result is easily recognized) or in other cases too? I answered them both. I think I should get extra credit for this :) Your objection is that I point out what I think is a related problem, unique to Mathematica, and one that is relevant to the original poster's line of thought. It is natural to hope that Mathematica will do this FractionalPart correctly since Mathematica tends to make claims that it will increase the precision of calculations when necessary to get the right answer. Implicit in the previous respondents' answers is, "well, not this time". > > In slightly more detail, this is the customary gripe, from one poster, > about degradation of precision when using precision tracking. But that > degradation is made apparent by the low or zero precision of the result. It is apparent only if you happen to print the sequence of iterates. And the calculation was so trivial that you could instantly spot the iteration, and you were sufficiently attuned to the particular Mathematica version of arithmetic to understand what happened. One might reasonably assume that the iteration z=2*z-z starting from the initial value z=1.1....1 would converge at or very nearly at that initial value. Why reasonable? Just that standard error analysis and an understanding of the usual binary fixed-precision model for computer arithmetic strongly suggests this; also I know of no other computer programming language in which a loop like this converges to a number which is equal to zero for any initial point (at least a point which is specified with high precision. ) > > By way of contrast, programs that do no tracking give arbitrarily > terrible results, only with NO warning. Programs that are written in languages that do no automatic tracking can give arbitrarily terrible results. But if they are written carefully, they can give error bounds and warnings when appropriate. In fact carefully written scientific subroutine libraries are typically written in such languages, including C and Fortran. Yes, to be sure, you can write bad programs in any programming language, so the questions become one of which language is most helpful, has fewest surprises, is easiest to debug, produces results fastest, is most accurate, etc. > So they might well get wrong the example from the original post, even > when ostensibly working at high precision. > > >> Try this >> >> z = 1.11111111111111111111 >> While [(z = 2*z - z) != 0, Print[z]] >> >> This loop should never terminate, since 2*z-z is equal to z and is >> clearly very far away from zero, and setting z=2*z-z should not >> make it any closer to zero... Yet it terminates. So a test >> internal to a Mathematica program that involves arithmetic and >> comparison can produce odd results. >> >> This phenomenon is well-known to certain denizens of this newsgroup, >> who claim it is a feature.(!) You can judge for yourself. >> >> RJF > > Richard, > > The development of Mathematica, and usage of significance arithmetic, > is not going to change. That simply makes it more important that people who are new to using Mathematica, and/or who seem to be concerned about arithmetic precision, be aware of this issue. > The fact that you do not like it, or even necessarily know how to use > it to advantage, I am sure it can be used in a loop-free single-assignment computation to some advantage. That's why it works OK when you are doing something simple, like computing the product of three measurements, to approximate the volume of a room. You, I am sure, are able to overcome the occasional erroneous loss of precision by deliberately and repeatedly resetting the precision properly in a convergent iterative process. As am I. > will not alter that. My advice: get past it. Move onto something more > important. I assume that JTS thought his question was important :). I'm not sure this newsgroup is for actual important things... > Justifying this particular gripe as important is not the tack to take > (since you've gone that route before and made no impression). I assure you that demonstrations of this feature have made an impression on people. RJF