On Mar 16, 8:06 am, Robert Kern <robert.k...@gmail.com> wrote: > On 2010-03-16 07:35 AM, Dave Angel wrote: > > > > > > > > > Carl Banks wrote: > >> On Mar 15, 4:34 pm, JLundell <jlund...@pobox.com> wrote: > >>> It's also unfortunate that Python doesn't have an approximately-equal > >>> operator; it'd come in handy for floating-point applications while > >>> preserving hash. If only there were a ~=r ≈ operator I could > >>> overload. And ~ is unary, so no joy. > > >> One problem with it is that there's no way to make it universal; > >> different appiplications have different ideas of close. Conceivably > >> it could be usefully defined for a user type though.. > > >> Bacause of this problem almost no languages have an almost equal > >> operator. I'm curious what languages do, of if there are any with a > >> trinary operator that also takes a threshold. > > >> Carl Banks > > > If I recall correctly, APL has a *fuzz* value, which is used in all(?) > > comparisons. But I do not recall anything about how it was defined. I do > > recall that you could change the threshold, and suspect it was relative > > to the operands. For symmetry, it would probably have to be relative to > > the average of the two values, or some such. > > The problem is that frequently there is no system-wide fuzz value which is > appropriate for all comparisons in a given program. You need to choose the > right > value for each comparison. Consequently, you might as well use a function > instead of an operator and a global variable. > > -- > Robert Kern >
APL scaled their fuzz to the larger of the values being compared. In my case, my domain permits me to use a constant fuzz; all my units are the same (votes, as it happens). I've seen abs(a/b-1) used instead of abs(a-b); obviously you'd need to treat comparison with zero specially. But yeah, it's really a domain-specific problem. -- http://mail.python.org/mailman/listinfo/python-list
