lookup wackiness

[Fairlight]

The honourable and venerable Nancy Palmquist spoke thus:
> Mark,
> 
> The edit on a key and the index data should match for sanity sake.
> 
> You will find that some edits change the nature of the data.  For example, and 
> uncast key field that contains 00000111 would be treated as a number, but a 
> value of 00000abc would cause it to be treated as a literal.

I'd be buying that explanation if both 00000111 and 00000001 had either
both failed or both succeeded.  But for one to work and the other not, when
they're both numeric with all digits present and accounted for?  Or a
full-on number like 77889908?  All 8-digits, all numeric.  I'd even buy it
if 77889908 worked but the others that were zero-padded failed, due to an
uncast variable stripping the leading zeroes (it doesn't, as it'll
faithfully print out the full text in an error message).

I'll grant that it should probably (especially given this quirky thing I
ran into) match for sanity's take.  But I still fail to see where
"77889908" ne "77889908" in -any- context, numeric, ASCII, hex, octal,
binary, Greek, Roman, Mandarin, or Cuneiform.  :)  Identical is identical.

There's a certain amount of dramatic irony that's not lost on me, when fP
claims that "sm" eq "smith".  :)  (Or is it "smith" eq "sm"?  I can never
remember which causes the false positive, longer or shorter first...)
We've (some of us) complained for years that matching is done too loosely,
and yet I fed it identical values and it refused to match them.  Yup,
dramatic irony there...

mark->
-- 
"I'm not subtle. I'm not pretty, and I'll piss off a lot of people along
the way. But I'll get the job done" --Captain Matthew Gideon, "Crusade"