On Wed, Aug 20, 2014 at 4:47 PM, rjf <fate...@gmail.com> wrote: > > On Saturday, August 9, 2014 7:35:13 PM UTC-7, Erik Massop wrote: > >> In fact I don't >> expect addition, negation, multiplication, or subtraction to be exact >> either. Indeed, they are not exact: >> sage: a = 1e-58 >> sage: a >> 1.00000000000000e-58 >> sage: (1+a)-1 >> 0.000000000000000 > > > That's because it is not a field, and you know it. So why call it a field?
Because it is an approximation to a field, and that's just too much of a mouthful to say everywhere (though ComputableModelOfAPowerSeriesRingCheckDocumentationForDetailsAndOptions has a nice ring to it :-). As Erik said: > It seems quite common to me to (intentionally) confuse mathematical > objects with their imperfect realizations. The actual reason for RealField is probably because that's what Magma called it, and there wasn't a strong motivation to arbitrarily disagree with that. (Most other systems don't even have this as an object to call out or construct.) >> > When you enter the data into the computer you put the values for A and >> > b that are the closest numbers to what you believe. A major question >> > in computational linear algebra is how to measure the sensitivity of >> > the computed solution to slight changes in the initial data. The >> > numbers used in solving the system are exactly the represented >> > floating-point numbers. >> > >> > > They're representatives for the actual (either unknown or impossible >> > > to represent) elements of your data. And, yes, they're also exact >> > > rational numbers--once again they can be both--but the point is that >> > > the input and output floating point numbers are viewed as >> > > perturbations of the (actual) real field elements you care about. >> > >> > That does not give you or anyone else permission to say "oh, this >> > data might not be right so instead of solving the system as best as >> > I can, I will use some off-hand rule to clip bits off, since it's just >> > a perturbation of something". No, you compute the best you can >> > with the data you have. >> >> You cannot just assume either that the data is exact. > > If you think that there is a better assumption that gives you more > information than > computing the best you can, plus condition numbers, you are free to offer it > to the numerical linear algebra specialists who have been laboring under > this > model for, oh, 60 years. > >> >> >> Also it makes more sense to me not to do the best you can, but the best >> you can do efficiently. Trying to do the best you can is of no use if it >> means running out of memory or taking a year. If doing things >> efficiently involves some clipping, then that's okay with me, >> especially if the clipping is configurable. > > > Since the cost of a floating-point operation is generally constant > these days, you do not get higher efficiency by zeroing-out trailing bits. You're (intentionally?) missing the point. Given the linear system Ax = b, where A and b are given in terms of floating point numbers, one could (1) Return x' that is the closest (according to some chosen rounding scheme) to the x exact solution of Ax = b, treating the entries of A and b as exact rational numbers. (2) Solve for x approximately, in such a way that x is the exact solution to a perturbed problem, and one is able to bound the error wrt the exact solution in terms of condition numbers, etc. Approach (2) is saying, to quote you, "oh, this data might not be right so instead of solving the system as best as I can, I will use some off-hand rule to clip bits off" where the "clipping" here is not treating the unrepresented lower order bits as all 0. The input is not taken to be exact (meaning exactly representing the system you really want to solve). All (floating point) linear algebra software that I'm aware of take approach (2). - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
