One needs to know something about the problem to know if such small amounts are significant. Like a small number in acceleration makes a big difference in calculating the path for a rocket to Mars or farther. But for something like oil reserves in the ground we are lucky if even the first significant digit is correct.
On Mon, May 27, 2013 at 9:47 AM, Roger Hui <[email protected]>wrote: > It's too late to worry about "destroy[ing] the evidence" when you have > things like 1=1+1e_15 or a non-zero result from 7-100*7%100. > > > Don't accountants have a similar long-standing issue with columns of > > (rounded) figures which should add to 1 but don't quite? > > Or in fancy annual reports where the arguments and the total are rounded > figures but the arguments have to add up to the total. One "solution" is > to use distributed rounding, e.g. Paul Berry's *Distributive Rounding in > Commercial Applications <http://dl.acm.org/citation.cfm?id=800114.803662> > *from > 1976. > > > On Mon, May 27, 2013 at 12:31 AM, Ian Clark <[email protected]> wrote: > > > Eugene's objection makes me stop and think. > > > > TABULA encounters this problem. See: > > > > > http://www.jsoftware.com/jwiki/TABULA/ChurchClock#Setting_a_temporary_hold_on_an_item > > > > Suppose I'm an engineer, not a mathematician, and I see: _8.731e_11 when > > I'm expecting 0. I feel something needs fixing up to show me 0. But what? > > > > 1. The quality of the algorithm? (Oh, yes...!) > > 2. The display of the number? > > 3. The underlying number? > > > > 3 is tempting and avoids overloading the display algorithm with hidden > > ad-hoc fixups that can come back and bite you. TABULA opts for 2, but > only > > via the decimal digits control. I think M$ Excel opts for 2 also. But > it's > > finicky in practice. > > > > I think Eugene is basically right: it's not good to destroy the evidence. > > But that doesn't solve the problem of a bozo display that makes your app > > look sloppy. Engineers have this term: "tolerance" (or fudge) but most > > accept it's an expediency, not an answer. > > > > Don't accountants have a similar long-standing issue with columns of > > (rounded) figures which should add to 1 but don't quite? > > > > > > On Mon, May 27, 2013 at 5:56 AM, Roger Hui <[email protected] > > >wrote: > > > > > clean=: (* |@*)&.+. > > > > > > Eugene McDonnell objected when we made *x to be 0 for x near 0, saying > > that > > > *x should be 0 only if x is 0. > > > > > > > > > On Sun, May 26, 2013 at 9:32 PM, km <[email protected]> wrote: > > > > > > > Let's say a real number "ought to be zero" if its absolute value is > <: > > > the > > > > comparison tolerance 2^_44 . Write a verb "clean" that replaces real > > > > numbers that ought to be zero with zero. How would you clean a > complex > > > > number? > > > > > > > > 1 o. 1r2p1 * i. 5 > > > > 0 1 1.22465e_16 _1 _2.44929e_16 > > > > clean 1 o. 1r2p1 * i. 5 > > > > 0 1 0 _1 0 > > > > > > > > ^ 0j1 * 1r2p1 * i. 5 > > > > 1 6.12323e_17j1 _1j1.22465e_16 _1.83697e_16j_1 1j_2.44929e_16 > > > > clean ^ 0j1 * 1r2p1 * i. 5 > > > > 1 0j1 _1 0j_1 1 > > > > > > > > --Kip Murray > > > > > > > > Sent from my iPad > > > > > > > > > ---------------------------------------------------------------------- > > > > For information about J forums see > http://www.jsoftware.com/forums.htm > > > > > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
