[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removal from list



On Thu, Dec 21, 2000 at 05:12:00PM -0800, Erik Steffl wrote:
> brian moore wrote:
> > 
> > On Thu, Dec 21, 2000 at 03:08:15PM -0800, Erik Steffl wrote:
> > > brian moore wrote:
> > >
> > >   well, the confusing thing is that the address that I tried to
> > > unsubscribe by explicitly listing it in the subject (I have the same
> > > problem) is exactly the same as the one listed as similar. And since I
> > > explicitly asked for specific address to be unsubscribed I see no reason
> > > for SmartList to try to figure out what the address is from headers.
> > 
> > Sure there is.  For the simple reason that someone -changed- the defaults
> > so that your name would not match.
> 
>   I almost understand what you are saying (here and below) but I would
> think that it would be a fallback behaviour when EXACT match is not
> found. I guess that's why I am so puzzled because in my case the EXACTLY
> EXACT match is found.
> 
>   what defaults can change so that steffl@earthlink.com would not match
> steffl@earthlink.com?

You're thinking digital.  Don't.

The numeric value of matching is a number between -32767 and +32767 of
the 'closeness' of the match.  It is, effectively, a floating point number
between -1.0 and +1.0, non-inclusive  (ie, just the fractional part.)

Because of the nature of floating point on digital devices, you are
HIGHLY unlikely to get an -exact- match.

Here's a simple example for your calculator: what is sqrt(2) * sqrt(2)?
Is it 2?  Logically, yes, it is... but is that the answer your
calculator will give?  It's not what bc gives:
    [durin:~] 134 % echo 'sqrt(2) * sqrt(2)' | bc -l
    1.99999999999999999999

Better file a bug against bc since it's just as broken as you contend
SmartList is.

There is no configuration option to say "only do exact matches".  There
is only an option for how to round the numbers.  (ie, round 0.99995 to
1 or 'true', but 0.99994 would round to 0.0, or 'false').  That is the
value that was changed.  Effectively the list requires that 'sqrt(2) *
sqrt(2)' evaluate to 2... but in the real world, that won't happen.

>   smartlist as a program (or set of program) probably yes. smartlist as
> a mailing list system (or as particular installation of smartlist) does
> not.

No, the fault lies not in the software, but in the person who changed
it.  (cf Hamlet)

>   still, why is it that exact match does not take priority over all
> other approximate ones? I haven't thought much about mailservers but
> generaly the idea is to use deterministic algorithm first, if that fails
> try heuristics...

'apt-get source smartlist' and change the source yourself then.  When
properly set up (and not fucked with), it works great.  That someone
fucked with it and then it breaks doesn't mean the software itself is
broken.

Good luck getting anyone to use the 'improved' version, though, when the
standard version works fine until someone decides to 'fix' it.

>   or is it not exact match? why wouldn't steffl@earthlink.com (that I
> want to unsubscribe) be an exact match for steffl@earthlink.com (in the
> list of subscribers)?

Because 0.9999 isn't 1.0.... and 'sqrt(2) * sqrt(2)' isn't 2.0 on a
computer.

-- 
CueCat decoder .signature by Larry Wall:
#!/usr/bin/perl -n
printf "Serial: %s Type: %s Code: %s\n", map { tr/a-zA-Z0-9+-/ -_/; $_ = unpack
'u', chr(32 + length()*3/4) . $_; s/\0+$//; $_ ^= "C" x length; } /\.([^.]+)/g; 



Reply to: