Re: Why Mathematica does not issue a warning when the calculations
- To: mathgroup at smc.vnet.net
- Subject: [mg117611] Re: Why Mathematica does not issue a warning when the calculations
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Thu, 24 Mar 2011 06:30:27 -0500 (EST)
Richard Fateman wrote: > 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 :) In regard to the second question, your example was not on target insofar as it involved a very different phenomenon. One would have to interpret the question quite broadly, roughly as "Are there any conceivable issues in Mathematica numerics?" Since the post specified "when these calculations cannot be performed with the given machine accuracy" I think such a broad interpretation is a stretch. Your answer to the first question was good to a point, but strayed from reality with "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 reason this is wide of the mark is that, in point of fact, Mathematica's "unusual arithmetic" is exactly what makes this sort of computation usually work. What you imply is the reverse of the actual situation. (And then you wonder why I keep saying you shouldn't write about such things.) > 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. No, then yes, then probably no but maybe the poster will overrule me on that. > 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". Mathematica documentation is fairly clear about distinctions between machine vs. (Mathematica's implementation of) software arithmetic. The claims to which you refer are made for the latter and not the former. While I've not looked too hard of late, I think this is made reasonably clear in the Documentation Center. >> 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. ) Not that many languages support high precision arithmetic. Amongst the ones that do, Mathematica seems to be holding its own in terms of use. >> 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. And even Mathematica. But that's not the point. Many computations cannot be done with good error control, or a priori estimates of needed initial precision. In such cases significance arithmetic can be quite helpful (the cases wehere no careful writing can be done). And if it's not needed, chances are the code will not be using it to begin with, since Mathematica works quite well with native machine double arithmetic. I will add that if you can estimate needed initial precision before the fact, there is a good chance that your computation will work with significance (as well as fixed prec) arithmetic. You will lose precision, which is unfortunate but not usually tragic. And as you remark below, one can adjust the arithmetic to avoid that. > 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. Actually that's a dubious statement. It applies to some iterative processes done in bignum arithmetic. I'm sure there are some new users who will do such things. But I'd guess not so many. What many new users might try would be computations such as the one that began this thread (note: I do not recall offhand if that poster is new to Mathematica). In such cases it is useful to make the distinction between precision tracking and fixed precision. As it happens, though, that example is a success story for the former. >> 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. It works quite well in some (not all) more complex settings. But the biggest importance is that it gives one a fighting chance to discern that a computation is producing garbage. I find I've come to value that more with the passage of time. > 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... His question was important. A large part of your response, a diverting of readers to your long-time iteration example, is what I rather clearly referred to. I've come to be impatient with such responses exactly because I do think this forum should cover useful things (and usually it does). Me, I'd like to see it not go the route of that once vibrant dead zone I mentioned in some private email. >> 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 Not very many. One such person carries considerable weight in his field (which is very much the appropriate term, as it happensy). But his field is something quite removed from computer arithmetic. Daniel Lichtblau Wolfram Research