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!
More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST continue
to work.
NaN is a nice feature, but I don't think that it should be an EASY
to invoke it.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs 6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
"Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew." -Queen/_'39_
