Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Mon, Oct 22, 2001 at 04:27:24PM +0100, Sam Vilain wrote:
>> On Fri, 19 Oct 2001 09:27:50 -0400
>> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>>
>> > > I am implementing a textbook algo in Perl (the textbook has
>> > > it written in C++) and have realized that if undef was to
>> > > numericize to NaN instead of 0, there are a lot of uninitialization
>> > > errors that would get caught.
>> > > use strict vars;
>> > > does not recognize use of new array indices as unitialized variables.
>> > Yes, but do you really want to break:
>> > $z[0] = 50;
>> > $z[2] = 20;
>> > @x = @y[@z];
>>
>> In your code, should @x contain (@y[50,0,20]) or (@y[50,20]) or
>> (@y[50,undef,20]) ?
>
> @y[50,undef,20], which in Perl5 is @y[50,0,20].
>
> I have a great many fears around NaN. I think I should only be able to
> get a NaN by:
>
> Directly invoking it (e.g. $x = NaN)
> Performing a mathematical operation whose result would
> otherwise be an exception (e.g. $x = 1/0)
>
> If there are other means, I'm not thinking of them right now.
> Perl's conversion of undefined values and strings to 0 is VERY
> USEFUL. I'd really like to avoid breaking it. Yes //, makes it
> easier to get over the undef thing, but only a little.
>
> Let's take this code as an example:
>
> while(<>) {
> $count++;
> $total += substr($_,22,2);
> }
> printf "Average: %.2f\n", $total/$count;
>
> Right now, if my expected numeric column has garbage in it on the
> 400,000th line, I treat it as zero and go on, getting a meaningful
> result. If that garbage translates to NaN, then I'm going to get
> "Average: NaN" as my result? That's just freaky!
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.
Of course, this is assuming there's no difference between:
$total += substr($_, 22, 2); # implicit numification
$total += +substr($_, 22, 2); # explicit numification
Which might be controllable via pragma.
However, it seems to me that having both explicit and implicit
numification of garbage go to NaN is a *good* thing because it will
force you to think about what you're doing with code like this. Maybe
you want garbage to increment the count and numify as zero, so you'd
do:
while (<>) {
my $val = +substr($_, 22, 2);
$count++;
if ($val ne 'NaN') { # Ugly, gets 'round the IEEE thing
$total += $val;
}
}
Or, if you just want to skip that line:
while (<>) {
my $val = +substr($_, 22, 2);
next if $val eq 'NaN';
$count++;
$total += $val;
}
> 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.
%x{string} = 'string';
%x{string}++
%x{string} == 'strinh';
> NaN is a nice feature, but I don't think that it should be an EASY
> to invoke it.
Disagree.
