Nicholas Clark writes:
: On Fri, Nov 09, 2001 at 09:14:10AM -0800, Larry Wall wrote:
: NaN is merely the floating-point representation of undef when your
: variable is stored in a bare num. And if you declare a variable as
: int, there may well be no representation for undef at all!
Damian Conway [EMAIL PROTECTED] writes:
Of course, that's not to say that the particular Cundef that's returned on
failure-to-numerify mightn't have a property set that indicates the problem
was not-a-numeric in nature.
Having more than one 'undef' value sounds like a recipe for internals
David wrote:
Damian Conway wrote:
NaN is dead.
Except perhaps under a Cuse IEEE pragma of some kind, in which case it
would be a proper IEEE Norweigian Blue NaN.
which merely redifines the discussion to, how does the IEEENBNaN
behave under various
Aaron Sherman writes:
: On Thu, Oct 25, 2001 at 11:30:00AM +1000, Damian Conway wrote:
:
: Glenn wrote:
:
: Have I missed anything?
:
: Perhaps you've missed one thing.
:
: [snip]
:
: Perl 6 could provide a pragma to produce a warning on the first
:
On Thu, Oct 25, 2001 at 10:42:15AM -0700, Glenn Linderman wrote:
So then the lexically scoped operator:+ wouldn't be able to achieve
the goal of my suggested implicit numerification warning... the goal
being the ability to ensure that there are no implicit numerifications,
that all
Aaron Sherman wrote:
On Thu, Oct 25, 2001 at 10:42:15AM -0700, Glenn Linderman wrote:
So then the lexically scoped operator:+ wouldn't be able to achieve
the goal of my suggested implicit numerification warning... the goal
being the ability to ensure that there are no implicit
Damian Conway wrote:
Have I missed anything?
Perhaps you've missed one thing. It was kind of in a different branch of the
thread, about string numerification yielding NaN when given input that is bad
according to some definition of badness. It was clear from discussion that
various
Glenn wrote:
Have I missed anything?
Perhaps you've missed one thing.
[snip]
Perl 6 could provide a pragma to produce a warning on the first
run-time auto-numerification (compile time would be really hard to
do), together with a selection of different
Aaron Sherman wrote:
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
On Mon, 22 Oct 2001 12:18:16 -0400
Aaron Sherman [EMAIL PROTECTED] wrote:
$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].
An arbitrary and perhaps
Aaron Sherman wrote:
I see your point, but going from: you have to error-check to be
sure that the average you get is valid to you get NaN and like it
is a bit steep.
you get NaN and like it only happens when you put garbage in... and get garbage
out.
Yes, NaN is garbage. But when it
More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
continue to work.
What is void plus one?
Can't we utilize the lazy arrays stuff to make all this work.
Out of the box, all entries could default to NaN. But its easy
to write
@a ^= 0;
to change this default. I'm
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
Aaron Sherman wrote
On Mon, Oct 22, 2001 at 11:30:01AM -0700, David Whipp wrote:
More, someone has mentioned the %x{$_}++ feature, which
IMHO, MUST
continue to work.
What is void plus one?
Can't we utilize the lazy arrays stuff to make all this work.
Out of the box, all
Aaron Sherman wrote
Larry's hubris notwithstanding, I'd like to suggest that
more, in this
case means no, it prints nothing.
This *must* be true, as you don't want:
@a ^+ @b
to always return an infinite list. You want it to produce a list with
(as a3 suggested) length
On Wed, Oct 17, 2001 at 03:42:30PM -0500, David Nicol 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
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
17 matches
Mail list logo
