class inheritance

[JLundell]

On Mar 16, 8:06 am, Robert Kern <robert.k... at gmail.com> wrote:
> On 2010-03-16 07:35 AM, Dave Angel wrote:
>
>
>
>
>
>
>
> > Carl Banks wrote:
> >> On Mar 15, 4:34 pm, JLundell <jlund... at 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.