So the difference is in the intent. A pragmatical aspect of as the linguistical paradigm of J continuing the analogy of Parts of Speech, Idioms, etc.
1 = 2. Looks like their difference of 1 is huge and they do not seem to be identifiable. Now let's shift them together away from zero a little, 1 =&(+&(2^43)) 2 0 1 =&(+&(2^44)) 2 NB. Oops, two points with 1 NB. the same difference became one 1 -&(+&(2^43)) 2 NB. difference is still the same = 1 _1 The above is an example of unintended identifivation. Near zero we have the opposite situation, no matter how close we move to zero or how stringent we make the tolerance, we fail to identify anything close with zero itself. 0 = 2^_44 0 0 = 2^_84 0 0 =!.(2^_300) 2^_84 0 This can be called unintended misidentification. Any such examples can result in rounding errors in calculations and not necessarily based on some unusual application requirements. There are alternative implementations of relative tolerance. For example in "Safe Comparisons" section of http://www.lahey.com/float.htm it also can be: x=y if (|x-y)<:(t*|x+y) Though it does not resolve the problem with zero. 0=y if (|0-y)<:(t*|0+y) NB. x=0 0=y if y<:(t*y) NB. assume y>0 We get the same problem. P.S. I stated or implied that either J worked incorrectly or that any changes needed. The problem is that this topic has been shrouded by a cloud of mystery and not described with enough detail in the documentaion. For example, how to deal with the artifacts of relative tolerance; other aspects of tolerance -- so called absolute, which deseves a better name, maybe uniform tolerance. --- Henry Rich <[EMAIL PROTECTED]> wrote: > What I am trying to say is, tolerant comparison is just > a way to see if two numbers are probably actually the same > number, but represented slightly differently because of > rounding error. > > A comparison that would say, for example, that 1 = 2, > is so far removed from a comparison intended to mask > the effects of rounding that, even though the mathematical > description might be similar, the implementation is > different. > > Such a wide 'tolerance', which I called interval comparison, > is an application-specific requirement that is not, and > should not be, part of the general-purpose language. > > Henry Rich > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko > > Sent: Monday, May 29, 2006 11:27 PM > > To: Programming forum > > Subject: RE: [Jprogramming] Equal tolerance fit conjunction -- again > > > > You are talking about tolerance and comparison > > on intervals as if they were two diffent things. > > What is your definition of comparison on intervals? > > > > > > --- Henry Rich <[EMAIL PROTECTED]> wrote: > > > > > > However, for some mystical reasons J implementation > > > > does not allow the tolerance (factor of the radius) > > > > to grow above 2^_34, thus, as pointed out by Roger Hui > > > > http://www.jsoftware.com/jwiki/Essays/Tolerant_Comparison > > > > ... This is also why it's hard to grasp > > > > this limitation concept. > > > > > > It is my understanding that tolerant comparison is intended > > > not to solve any application problem, but just to hide the > > > numerical inaccuracies that result from floating-point > > > arithmetic. For such a use, relative tolerance is > > > the right approach, and 2^_34 is plenty big. > > > > > > If your application needs comparison on intervals, you > > > are expected to code it yourself. Tolerance larger than > > > 2^_34 hurts integer code & so is not available as a way > > > to handle interval comparisons. > > > > > > Henry Rich __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
