Re: Why Mathematica does not issue a warning when the calculations
- To: mathgroup at smc.vnet.net
- Subject: [mg117632] Re: Why Mathematica does not issue a warning when the calculations
- From: Richard Fateman <fateman at eecs.berkeley.edu>
- Date: Tue, 29 Mar 2011 06:50:26 -0500 (EST)
On 3/25/2011 8:33 AM, Daniel Lichtblau wrote: ... snip > >> (RJF)We've discussed this before. If you have a true function f, that >> is a procedure whose results depend only on its argument(s), then when >> A is equal to B, f(A) should be >> equal to f(B). This is fundamental to programming and to mathematics, >> but is violated by Mathematica. > Probably by other mathematical programming languages as well. Especially in the operating world of finite precision arithmetic. It's something people often get used to (of necessity, if you work on this stuff). I disagree that this is a common problem, although it would probably not be allowed to discuss particular other mathematical programming languages in this forum. So far as I can tell, it has nothing to do with finite precision arithmetic unless you have some notion that "equality" means something like "close enough for government work". In Mathematica there are two kinds of equality: == and === . The latter means IDENTICAL. Consider a=SetPrecision[2,40] b=SetPrecision[2,50]. I could sympathize with a==b being true, but certainly not a===b, which says they are IDENTICAL, and in my book, f[a] must equal f[b] for all functions f. Yet let f=Precision, and you see we get different answers. 2.000000000000000001000 == 2 is False, but 2.00000000000000000100 == 2 is True. Such rules of the road lead to situations in which a==b but a-b is not zero, ... snip... >> This is not the understanding in Mathematica, where (for software >> bigfloats) >> 2.000000000000000000 is more like shorthand for >> "all numbers between >> 1.9999999999999999995 >> 2.0000000000000000005 >> " >> (DL may be willing and able to explain what Mathematica REALLY does) > Somethin along the lines you suggest. Your alternative approach is fine for handling of integers. It does not work so well for inputs such as 1.3 which do not translate exactly to finite binary representations. But Mathematica semantics would still be violated by upping precision, and that in no way contradicts the documentation remarks about ratcheting precision internally, as they refer to handling of exact input (N[2,10] et al are not exact, and they are what FractionalPart sees). The simplest way of having consistent mathematical semantics in a programming language is to have the programming language obey the rules of mathematical semantics. Each step away from this, as imposed by the reality of finiteness of computers etc, tends to add hazards. That's why floating-point arithmetic is cluttered with underflow/overflow/rounding etc, that does not occur with rational arithmetic. There has to be a tradeoff in utility vs deviation from mathematics for each such step. In my view Mathematica adds more steps and therefore more hazards. ... snip.. about Significance arithmetic. > I think there may be some since then. No matter. We find it works well for what we need. apparentlyy > Your view, roughly, is that we picked it up off the garbage heap of numerics literature. no, I speculate that Wolfram took the idea that is taught in Physics 101 lab about carrying significant figures when you are combining measurements, and thought that it would be a great idea to put this into a programming language. He might even have thought that he invented it. (That is, a programming language with significance arithmetic). I truly doubt that Wolfram studied any serious numerical analysis literature, and I would certainly not expect him to study its garbage heap :) > Perhaps so. In all the conferences I've attended, I've only once heard it disparaged (not derided, but disparaged) as a bad method. For disparagement, one need not look any further than the wikipedia article, at least last time I looked. > More below. Anyway, it may be helpful to bear in mind that (unlike these endless threads), this usage is not academic to us. We rely on it for those other things, like putting kids through school. Maybe the folks who shied away from it in the literature had similar considerations? That would make for a humerous rift between theory and practice... Tempting, but I will refrain. > >> I thought you were claiming that Mathematica had the >> lion's share of bigfloat usage. > No. Though I suspect it does, once you get past the 200 digit mark or so. Past the 200 (decimal) digit mark, I think most usage would be in trying to prove/disprove number-theory conjectures, though there are some poorly formulated geometry problems that might require this. Unless Mathematica gives really direct access to libraries, it would not be a good choice. But I think it (eventually) calls GMP and such. > This is to exclude the slightly high precision scientific computational apps, and those possibly ubiquitous cryptography apps, which will dominate any usage of Mathematica. (Caveat: with emergence of Wolfram|Alpha, this could change. Though I doubt W|A gets tremendous high precision usage at this time). > > >>> It is fairly obvious that nobody knows the extent to which bignum >>> arithmetic is used, either within or outside of Mathematica. My >>> claim is that those who use it in Mathematica seem to get along with >>> it. >> Except for the ones who post those annoying questions here:) > I'm not sure your plural is justified. Certainly the original post in this thread was about a limitation of machine arithmetic functionality. One that, I might add, is readily overcome with Mathematica's bignum arithmetic semantics. > OK, if we are going to talk about the original post, the answer looks absurd. To remind the patient readers, if there are any left.. N[FractionalPart[(6 + Sqrt[2])20]] Result: -160. (Though I get -64). Why does this appear absurd? For a starter, that expression is non-negative, so the fractional part of it would have to be non-negative. Next, the fractional part p would have to obey the relation 0<=p<1.0 So the answer -160 is crazy, and FractionalPart would seem to be nonsense. Actually, it is not total nonsense, just somewhat silly. It is apparently computed as FractionPart[x]= x- IntegerPart[x] where IntegerPart works pretty hard to work for arbitrary expressions, in this case resulting in (6 + Sqrt[2])^20 - 251942729309018542 , which is correct if inconvenient. now it appears that the next part of the computation N[%] is the guilty party, and that it might say "uhoh, there are too many digits there for me to do that calculation in hardware float without catastrophic loss of accuracy .." but instead of saying that, it just burps out an answer. Doing N[%,3] invokes the software floats and indeed uses enough precision to get 3 digits right IN THE ANSWER, which is nice. Clearly 3 digits internally is insufficient. It seems to me that a cure for all this is to allow IntegerPart and FractionPart to operate only on explicit rational and float expressions. Any float expression that has more digits to the left of the decimal (actually binary) point than precision, is equal to a particular integer, and has zero fractional part. Among other advantages: the result can be explained. ...snip... >> (RJF) My impression is that the actual primary use of Grobner basis >> computations is to >> write papers on Grobner basis computations, and the other "uses" are >> "in principle" "demonstrations". This may have changed with a more >> numerical >> approach, however. > Your impression is off insofar as industrial usage goes. For example, we use them in NSolve, exact equation solving, some polynomial algebra, and probably a few places I am forgetting. You are right. I should have expanded my statement to include .. "primary use of Grobner basis computations is to write papers AND PROGRAMS ...". Unfortunately, including GB in "NSolve" (etc.) does not, to me, really represent an application of GB. It represents a situation in which a well-intentioned programmer presents an opportunity for someone to use GB to solve a problem. With luck the program may be applied in simple circumstances that permit a simple solution. But a so-called application in "commutative algebra" does not represent an application. (Here, I am perhaps going out on a limb saying that I won't count "an application to pure mathematics" as a true application.) The rather extensive wikipedia article on the topic lists many many applications, most of which are of the type I do not count, or are of the form "in principle we could do this with GB, and so it is an application" though in fact no one could ever realistically use GB for it except on exceedingly toy-like instances. (Occasionally one can let a problem run for a very long time if you only have to solve it one time, as in some robotics problems.) I have only limited personal experience with trying to use GB, on 2 kinds of problems, oil reservoir simulation and the inverse problem of imaging via CAT scan or similar. A recent (2008) PhD thesis by M-LTorrente on Applications to the Oil Industry seems to show the situation has not changed. That is, casting a problem in terms of GB is unlikely to be a useful step in realistically solving that problem. This does not prevent the writing of a paper exploiting a vastly simplified formulation. While the numbers may change somewhat, consider that you could solve a problem characterized by 6 or 10 parameters and 3 variables using GB. Increasing the number of variables may increase the computation cost exponentially. In practice there will be 10,000 parameters and 200 variables. I am not, incidentally, saying there is an alternative symbolic method to replace GB that is much faster. Instead, I am suggesting that if you can reframe and simplify your question as a numerical procedure, you stand a much better chance of getting a result. As an analogy, one could ask for a factorization of a polynomial over an algebraic number field, but if all you need is an approximation of a root near a particular point, maybe that is what you should ask for. > Not an academic exercise, those applications. Also starting to make inroads in hybrid polynomial algebra computation e.g handling of low precision inputs. Not yet sure if that will fly, though. I remain skeptical. > >> Are you claiming that now people are buying Mathematica to run GB >> computations? >> And are you claiming furthermore this could only be done in >> significance >> arithmetic? > Neither. And most definitely not the first. Then I think we may agree on this. > I am claiming that this is extremely useful for the "bigger picture" technology it enables, a few parts of which I noted just above. Whether people buy Mathemntica for that stuff I would not know. Pretty sure it does not hurt though. > I do not fault Mathematica's Solve program for eventually trying GB; if people ask for all solutions to polynomial systems. I think a really good program would point out that what a user asks for may not be what he really wants, and enter into a dialog of some sort. ...snip.. > There are some issues with IEEE arithmetic, by the way. That too is a work in progress (I'm sure this is not news to Kahan). There are certainly issues, many of which were probably raised in the IEEE754 standards committee deliberations; also there is a more recent standards committee for (non-binary -- in particular decimal) arithmetic. Curiously some of the issues there include cases in which people would prefer results that are less accurate.. RJF