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! Similarly,
> it may be impossible to
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! Simila
Piers Cawley writes:
: Damian Conway <[EMAIL PROTECTED]> writes:
: > Of course, that's not to say that the particular C 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 sound
Damian Conway <[EMAIL PROTECTED]> writes:
> Of course, that's not to say that the particular C 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
mad
David wrote:
> Damian Conway wrote:
> > NaN is dead.
>
> > Except perhaps under a C 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 cir
hi all. What a nice thread you all had a couple weeks ago under
a subject line I wrote.
Damian Conway wrote:
> NaN is dead.
> Except perhaps under a C pragma of some kind, in which case it
> would be a proper IEEE Norweigian Blue NaN.
which merely redifines the discussion to, how does th
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 num
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 numeri
Larry Wall wrote:
> 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 coul
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 o
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
>> run-time auto-numerificat
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 diff
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 contr
On Tue, Oct 23, 2001 at 08:08:27AM +1000, Damian Conway wrote:
>
>> > To check for numericity of input, you'll write:
>> >
>> > $number = +<$fh>
>> > until defined $number;
>> >
>> > If you ignore the definedness, the C will just promote to zero
>
Aaron Sherman wrote:
> Someone's missing something, and I sure hope it's not me. Let me write
> a code sample here:
>
> sub incrind (@ary, $ind) {
> @ary[$ind]++
> }
>
> Are you suggesting that by adding in "@ary ^= 0", like so:
>
> sub incrind (@ary, $ind) {
>
> > To check for numericity of input, you'll write:
> >
> > $number = +<$fh>
> > until defined $number;
> >
> > If you ignore the definedness, the C will just promote to zero
> > in numeric contexts.
>
> I'm confused. By the time $number see
On Tue, Oct 23, 2001 at 07:30:00AM +1000, Damian Conway wrote:
> To check for numericity of input, you'll write:
>
> $number = +<$fh>
> until defined $number;
>
> If you ignore the definedness, the C will just promote to zero
> in numeric contexts.
I'm confused. By the
[Oops, I fired off too-early a draft. Here's the full thing...]
Okay, in the (probably forlorn) hope of finally Beating This Subject To Death,
let me offer a (possible) new position on NaN.
NaN is dead. It's not pinin'! It's passed on! This value is no more! It
has ceased to be! It's expired a
Okay, in the (probably forlorn) hope of beating this subject to death,
let me offer a possible (post-A3/E3) position on NaN.
NaN is dead.
Except perhaps under a C pragma of some kind, in which case it
would be a proper IEEE NaN.
C with numerify to zero (it always has; and we always intended
th
On Mon, Oct 22, 2001 at 04:21:32PM -0400, Aaron Sherman wrote:
> On Mon, Oct 22, 2001 at 08:25:21PM +0100, Piers Cawley wrote:
>
> > > 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
On Mon, Oct 22, 2001 at 01:36:02PM -0700, David Whipp wrote:
> OK, now we've got this resolved, I'd like to return the focus
> back to the original point.
>
> @x ^= 0;
> @x[5]++;
>
> does not have problems with NaNs; and does not generate a warning
> with -w.
Someone's missing some
> > 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
On Mon, Oct 22, 2001 at 12:23:34PM -0700, David Whipp wrote:
> Aaron Sherman wrote
> >
> > my @a;
> > @a ^= 0;
> > print @a
> >
> > Are you saying that this should print an infinite number of zeros?
> >
>
> Quoting Larry on this subject (apocalypse 3, bottom of page 3): "I
> can th
On Mon, Oct 22, 2001 at 08:25:21PM +0100, Piers Cawley wrote:
> > 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 shoul
Aaron Sherman <[EMAIL PROTECTED]> writes:
> 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 t
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 mu
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.
> >
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 entries could defau
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 u
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 reali
> > 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.
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
On Mon, Oct 22, 2001 at 05:43:58PM +0100, Sam Vilain wrote:
> > More, someone has mentioned the %x{$_}++ feature, which IMHO, MUST
> > continue to work.
>
> What is void plus one?
According to every Perl book I've ever read, 1. I've yet to run into someone
who finds that a difficult concept when
On Mon, Oct 22, 2001 at 09:39:50AM -0700, Glenn Linderman wrote:
>
> Indeed, you might consider "ignoring garbage" as producing a "meaningful
> result", and in the application you envision, that could be extremely useful.
>
> However, in other applications, the fact that there was garbage on the
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> 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 a
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
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,00
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 i
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 g
At 03:42 PM 10/17/2001 -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.
Yup, and it generically bre
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.
>
>
41 matches
Mail list logo
