Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Mon, Oct 22, 2001 at 07:39:44PM +0100, Piers Cawley wrote:
>
>> Yeah, but it's correct. If you extract something and get garbage then
>> you're going to screw your average up. Admittedly, in 400,000 lines,
>> it's unlikely to shift the average by much, but it will shift it.
>
> No, I'm interpreting unknown values as zero. My average is correct.
> If you want to argue that I should be treating them as something
> else, that's your lookout, but I'm happy with that interpretation.
If you want to interpret unknown values as zero then you can make that
explicit. Which is a good thing, because it makes clarifies the intent
of your code.
> What REALLY worries me is that values that seem to be numbers, but are
> in fact garbage ARE going to screw my average up. I dare Perl6 to fix
> that for me.
It's not going to. Getting NaN as a result in this context should be a
*really* big clue that Perl's found some garbage that it didn't
understand. If you want to know where then CHECK YOUR VALUES.
>> Of course, this is assuming there's no difference between:
>>
>> $total += substr($_, 22, 2); # implicit numification
>>
>> $total += +substr($_, 22, 2); # explicit numification
>
> If we were to decompile the first example, it would not be the same
> as the second? Is there an implied operator here that I'm not seeing?
> How does it behave? According to Larry, unary + forces a numeric
> context, but you're saying that a numeric context can be distinguished
> from a unary +
>
> I'm confused.
No. I'm saying that this may be a possibility. But, frankly, it looks
like scary DWIMmery to me. I'd rather have it return NaN in both
contexts.
>> Which might be controllable via pragma.
>
> As long as the pragma leaves:
>
> perl -nle '$t+=$_;END{print $t}'
>
> alone, I'm OK. If blank lines will cause that to choke, I'm an
> unhappy camper.
>
>> if ($val ne 'NaN') { # Ugly, gets 'round the IEEE thing
>
> sub notnan ($number) {
> return $number >= -Inf;
> }
>
>> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
>> > continue to work.
>>
>> And it will, since it has nothing whatsoever to do with string
>> numification.
>>
>> %x{non_existent}++ # Doesn't do numification. Autovivifies an entry in
>> # %x, with value 'undef', which numfies to 0.
>
> Actually, numification of undef was the entry point to this thread,
> so my point remains. If notnan(undef), I'm happy, else I am become
> concerned....
Ah yes. That suggestion was so self evidently stupid it slipped my
mind. Though the stuff discussed above is definitely about
numification of strings.
--
Piers
