Newbie can't handle the "true"th... explanation desired
Jon S.
I know this must seem dumb, but I'm trying to figure out the proper
way to set a scalar as a boolean "true" or "false".
Larry R. and others helped me before with a definition of a variable
using a condition that was either true or false, but now I've found a
spot where I just want to seed something a "true" value for later use.
I've resorted to using
$itstrue = 1;
(I also contemplated just giving it the string "true".)
But I keep wondering if there's a better way, more exact way. (Like,
is there some standard expression that comes up true which everyone
uses?)
Similarly, just what gets put into a variable when you set it as true
or false?
TIA,
Jon
Craig Berry
: I know this must seem dumb, but I'm trying to figure out the proper
: way to set a scalar as a boolean "true" or "false".
Not dumb at all, and you can choose a convention which works for you.
Personally, I prefer 1 and 0, since this mimics the behavior in C (a
language I've used much longer than Perl).
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Quidquid latine dictum sit, altum viditur."
|
Tim Conrow
> I know this must seem dumb, but I'm trying to figure out the proper
> way to set a scalar as a boolean "true" or "false".
>
> $itstrue = 1;
That's fine.
>
> (I also contemplated just giving it the string "true".)
That's fine too.
>
> But I keep wondering if there's a better way, more exact way. (Like,
> is there some standard expression that comes up true which everyone
> uses?)
'1' is robably the most common, but if you want to ensure maximum readability
and want to increase the cool factor of your program, you could do
use constant TRUE=>1;
>
> Similarly, just what gets put into a variable when you set it as true
> or false?
1 and undef.
perl -wle 'print 1==1'
1
--
-- Tim Conrow t...@ipac.caltech.edu |
Larry Rosler
20:43:20 GMT, Jon S. <jonce...@nospammiesno.earthlink.net> says...
> Hi,
Here in California, "Yo, dude!"
> I know this must seem dumb, but I'm trying to figure out the proper
> way to set a scalar as a boolean "true" or "false".
Any way that works is 'proper'.
> Larry R. and others helped me before with a definition of a variable
> using a condition that was either true or false, but now I've found a
> spot where I just want to seed something a "true" value for later use.
>
> I've resorted to using
> $itstrue = 1;
>
> (I also contemplated just giving it the string "true".)
More characters to type. You could even use 'false', to drive the
maintainers crazy.
> But I keep wondering if there's a better way, more exact way. (Like,
> is there some standard expression that comes up true which everyone
> uses?)
1 (though some people prefer 42)
Some people just autoincrement an unassigned value, which works but is
uninformative, IMO.
> Similarly, just what gets put into a variable when you set it as true
> or false?
The value of whatever you assign.
Though you didn't ask explicitly, the only 'false' values are:
an arithmetic expression that evaluates to 0
the string '0'
the undefined value (undef, or not assigning anything)
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
l...@hpl.hp.com
Larry Rosler
14:07:21 -0700, Tim Conrow <t...@ipac.caltech.edu> says...
> "Jon S." wrote:
...
> > Similarly, just what gets put into a variable when you set it as true
> > or false?
>
> 1 and undef.
No, it is 1 and the null string "", which is converted silently to 0 in
arithmetic context.
> perl -wle 'print 1==1'
> 1
perl -wle 'print 1==0'
perl -wle 'print 0 + (1==0)'
0
Mark-Jason Dominus
That's the right thing to do.
>(I also contemplated just giving it the string "true".)
Sometimes I use 'yes'. It depends on context.
>But I keep wondering if there's a better way, more exact way. (Like,
>is there some standard expression that comes up true which everyone
>uses?)
I have very rarely used
$flag = 'Cogito ergo sum';
which as everyone knows is self-evidently true in all possible
universes. This ensures maximum portability.
>Similarly, just what gets put into a variable when you set it as true
>or false?
Depends on how you set it. Boolean expressions such as ($a == $b)
return either 1 or ''.
Craig Berry
: Though you didn't ask explicitly, the only 'false' values are:
:
: an arithmetic expression that evaluates to 0
: the string '0'
: the undefined value (undef, or not assigning anything)
...and the empty string ''.
Various transformation rules allow this list to be shortened. For
example, undef interpreted as a string yields '', and as a number, 0.
Brad Baxter
> Hi,
>
> I know this must seem dumb, but I'm trying to figure out the proper
> way to set a scalar as a boolean "true" or "false".
>
> Larry R. and others helped me before with a definition of a variable
> using a condition that was either true or false, but now I've found a
> spot where I just want to seed something a "true" value for later use.
>
> I've resorted to using
> $itstrue = 1;
>
> (I also contemplated just giving it the string "true".)
>
> But I keep wondering if there's a better way, more exact way. (Like,
> is there some standard expression that comes up true which everyone
> uses?)
>
> Similarly, just what gets put into a variable when you set it as true
> or false?
In my own experience, using 1 for true and 0 for false are usually
adequate, and most people are used to it. If you have a good reason to use
"true" instead of '1', go right ahead. There is no "standard" value for true or
false in Perl, so the phrase, "when you set it as true or false", doesn't
really mean anything definite. The variable becomes whatever you actually
set it to.
my $true = 1;
my $false = 0;
my $a = $true; ### $a == 1
my $b = $false; ### $b == 0
my $c = 'hey'; ### but it's still true
As you surely know, perl considers $c true, even though it doesn't
equal "my" definition of $true.
I suggest not worrying about it very much. Use 1 and 0 when it's
convenient, but at the same time make sure you are intimately familiar
with Perl's idea of true/false.
Cheers,
Brad
Larry Rosler
23:05:29 -0000, Craig Berry <cbe...@cinenet.net> says...
> Larry Rosler (l...@hpl.hp.com) wrote:
> : Though you didn't ask explicitly, the only 'false' values are:
> :
> : an arithmetic expression that evaluates to 0
> : the string '0'
> : the undefined value (undef, or not assigning anything)
>
> ...and the empty string ''.
Oops, of course!
> Various transformation rules allow this list to be shortened. For
> example, undef interpreted as a string yields '', and as a number, 0.
But there may be warnings caused by conversions of undef. However, a
simple Boolean test of undef never produces a warning.
Larry Rosler
says...
...
> Interestingly, the set of false values is closed under such
> transformations; no conversion will automatically turn a false value into
> a true one. But the reverse is not true:
>
> my $x = 'a true value';
> print(($x ? 'true' : 'false'), " as a string\n");
> print((0+$x ? 'true' : 'false'), " as a number\n");
>
> $x is true as a string, but false if coerced into being a number. Of
> course, you'll get a warning about the value of $x being non-numeric if
> warnings are enabled.
To see the same phenomenon without warnings, set $x to the string '0E0'
or '00' or '0.' or '+0' or infinitely other such.
Craig Berry
: > Various transformation rules allow this list to be shortened. For
: > example, undef interpreted as a string yields '', and as a number, 0.
:
: But there may be warnings caused by conversions of undef. However, a
: simple Boolean test of undef never produces a warning.
Of course; I intended this for understanding purposes, rather than coding.
Knowing that undef is false, and that undef can become '' or 0 at need,
and that the latter stringifies to '0' at need, you can see how all the
false values are really special extensions of 'undef is false'.
Interestingly, the set of false values is closed under such
transformations; no conversion will automatically turn a false value into
a true one. But the reverse is not true:
my $x = 'a true value';
print(($x ? 'true' : 'false'), " as a string\n");
print((0+$x ? 'true' : 'false'), " as a number\n");
$x is true as a string, but false if coerced into being a number. Of
course, you'll get a warning about the value of $x being non-numeric if
warnings are enabled.
--
David Steuber
true is not false.
Another one:
true is not empty.
Anything whatsoever assigned to a scaler is true except "0", "", and
undef. At least, that is how I understand it. Actually, I think
undef makes the name go away.
use strict;
--
David Steuber | Perl apprentice, Apache/mod_perl user, and
NRA Member | general Internet web wannabe.
ICQ# 91465842 (Using Micq 0.4.6 under Linux)
It's time to be free: http://www.harrybrowne2000.org
Larry Rosler
steuber.com says...
...
> Anything whatsoever assigned to a scaler is true except "0", "", and
> undef. At least, that is how I understand it.
You forgot the number 0, however evaluated.
> Actually, I think
> undef makes the name go away.
$name = undef; # The value of $name is now undefined.
undef $name; # The variable $name no longer exists.
Ilya Zakharevich
<m...@plover.com>],
who wrote in article <39d51fba.6b5$2...@news.op.net>:
> Depends on how you set it. Boolean expressions such as ($a == $b)
> return either 1 or ''.
... or whatever the overloaded == operator returns...
Ilya
Ilya Zakharevich
<l...@hpl.hp.com>],
who wrote in article <MPG.143ea41f2...@nntp.hpl.hp.com>:
> Though you didn't ask explicitly, the only 'false' values are:
>
> an arithmetic expression that evaluates to 0
> the string '0'
> the undefined value (undef, or not assigning anything)
[ the string '' as noted in other followups...]
... and whatever with an overloaded 'bool'-accessor which returns
false (this is recursive!).
Ilya
Larry Rosler
the cited author.]
In article <8r8af2$lh2$1...@charm.magnus.acs.ohio-state.edu>,
il...@math.ohio-state.edu says...
Yeah, whatever. It's easy to forget that some people insist on twisting
Perl into C++.
Tim Conrow
>
> > > Similarly, just what gets put into a variable when you set it as true
> > > or false?
> >
>
> No, it is 1 and the null string "", which is converted silently to 0 in
> arithmetic context.
Oops. Thanks for the correction. I'd swear I've read false was undef somewhere;
maybe in another erroneous Usenet posting!
Jon S.
wrote:
>In article <39d4fc12...@news.earthlink.net> on Fri, 29 Sep 2000
>20:43:20 GMT, Jon S. <jonce...@nospammiesno.earthlink.net> says...
>> (I also contemplated just giving it the string "true".)
>
>More characters to type. You could even use 'false', to drive the
>maintainers crazy.
LOL
Well, since I'm the maintainer, I think I'll just use "1".
Thanks everyone for the help. It's appreciated.
Jon
Ren Maddox
> $name = undef; # The value of $name is now undefined.
>
> undef $name; # The variable $name no longer exists.
I'm trying to understand the semantics of this difference. At first,
I thought that perhaps defined would return a true value in the first
case, but that turned out to be false. Next, I thought perhaps a
reference to such a variable would somehow lose track of the variable,
but that didn't happen either.
From "perldoc -f undef":
undef EXPR
Undefines the *value* of EXPR, which must be an lvalue.
(emphasis added).
On all experiments I have tried, "undef $name" and "$name = undef"
appear to have the same effect. To wit:
#!/usr/local/bin/perl -w
use strict;
my $x = 5;
my $y = \$x; print "$y: $$y\n";
undef $x; print "$y: $$y\n";
$x = 4; print "$y: $$y\n";
$x = undef; print "$y: $$y\n";
$x = 3; print "$y: $$y\n";
$y = \$x; print "$y: $$y\n";
__END__
Note that some of these test are a bit paranoid. Naturally, the value
of $y never changes. Neither form of undef destroys $x, just its
value. Using package variables produces the same results.
What then, is the difference?
--
Ren Maddox
r...@tivoli.com
Brad Baxter
OTOH, you could do this and just not care what the value actually is,
my $true = 1==1;
my $false = 1==0;
Brad
Larry Rosler
15:24:39 -0500, Ren Maddox <ren.m...@tivoli.com> says...
> Larry Rosler <l...@hpl.hp.com> writes:
>
> > $name = undef; # The value of $name is now undefined.
> >
> > undef $name; # The variable $name no longer exists.
>
> I'm trying to understand the semantics of this difference. At first,
> I thought that perhaps defined would return a true value in the first
> case, but that turned out to be false. Next, I thought perhaps a
> reference to such a variable would somehow lose track of the variable,
> but that didn't happen either.
...
> What then, is the difference?
For other than a lexical variable, whether or not the name actually
exists in the symbol table. What the imnplications of this are (if any)
I don't know, because I have never had to muck around at that level of
coding.
Ilya Zakharevich
<ren.m...@tivoli.com>],
who wrote in article <m34s2vo...@dhcp11-177.support.tivoli.com>:
> > $name = undef; # The value of $name is now undefined.
> >
> > undef $name; # The variable $name no longer exists.
>
> I'm trying to understand the semantics of this difference.
undef WHATEVER
- clears the memory buffers associated for WHATEVER
$var = undef;
- marks the memory buffers as unapplicable;
So there is no difference from the Perl side. All the difference is
in performance. Using $var = undef keeps the buffers ready for the
next time something is going to be assigned to $var, so is a speed
optimization. Using undef $var free()es memory used by buffers, so it
is a space optimization.
Your choice - but only if the situation is so bad that you need
microoptimizations. Otherwise they are synonyms.
Ilya
Ren Maddox
> In article <m34s2vo...@dhcp11-177.support.tivoli.com> on 02 Oct 2000
> 15:24:39 -0500, Ren Maddox <ren.m...@tivoli.com> says...
> > Larry Rosler <l...@hpl.hp.com> writes:
> >
> > > $name = undef; # The value of $name is now undefined.
> > >
> > > undef $name; # The variable $name no longer exists.
>
> > What then, is the difference?
>
> For other than a lexical variable, whether or not the name actually
> exists in the symbol table. What the imnplications of this are (if any)
> I don't know, because I have never had to muck around at that level of
> coding.
Actually, it doesn't even seem to do that:
perl -e '$,=$\=$/;undef $x;print grep /^x$/, keys %::'
--
Ren Maddox
r...@tivoli.com
Ren Maddox
>
> undef WHATEVER
>
> - clears the memory buffers associated for WHATEVER
>
> $var = undef;
>
> - marks the memory buffers as unapplicable;
>
> So there is no difference from the Perl side. All the difference is
> in performance. Using $var = undef keeps the buffers ready for the
> next time something is going to be assigned to $var, so is a speed
> optimization. Using undef $var free()es memory used by buffers, so it
> is a space optimization.
>
> Your choice - but only if the situation is so bad that you need
> microoptimizations. Otherwise they are synonyms.
OK, in the same vein, how 'bout:
undef @array;
versus:
@array = ();
?
(and the same for hashes if it makes any difference....)
--
Ren Maddox
r...@tivoli.com
Craig Berry
: OTOH, you could do this and just not care what the value actually is,
:
: my $true = 1==1;
: my $false = 1==0;
Or even
my $false; # undef by default, a false value
my $true = ! $false;
This has a certain pleasing austerity to it.
Tina Mueller
|=head2 How can I free an array or hash so my program shrinks?
|
|You can't. On most operating systems, memory allocated to a program
|can never be returned to the system. That's why long-running programs
|sometimes re-exec themselves. Some operating systems (notably,
|FreeBSD and Linux) allegedly reclaim large chunks of memory that is no
|longer used, but it doesn't appear to happen with Perl (yet). The Mac
|appears to be the only platform that will reliably (albeit, slowly)
|return memory to the OS.
|
|We've had reports that on Linux (Redhat 5.1) on Intel, C<undef
|$scalar> will return memory to the system, while on Solaris 2.6 it
|won't. In general, try it yourself and see.
|
|However, judicious use of my() on your variables will help make sure
|that they go out of scope so that Perl can free up their storage for
|use in other parts of your program. A global variable, of course, never
|goes out of scope, so you can't get its space automatically reclaimed,
|although undef()ing and/or delete()ing it will achieve the same effect.
|In general, memory allocation and de-allocation isn't something you can
|or should be worrying about much in Perl, but even this capability
|(preallocation of data types) is in the works.
undef $x; is a little bit quicker as
$x = undef;
undef $x is the correct use.
what happens is maybe that with "$x = undef"
a new undef value on the fly is produced
which is assigned to $x. that's just useless.
however, it makes a difference with arrays:
@a = undef; will not result in an empty array
as one might assume.
tina
--
http://tinita.de \ enter__| |__the___ _ _ ___
tina's moviedatabase \ / _` / _ \/ _ \ '_(_-< of
search & add comments \ \__,_\___/\___/_| /__/ perception
please don't email unless offtopic or followup is set. thanx
Martien Verbruggen
Craig Berry <cbe...@cinenet.net> wrote:
> Brad Baxter (b...@ginger.libs.uga.edu) wrote:
> : OTOH, you could do this and just not care what the value actually is,
> :
> : my $true = 1==1;
> : my $false = 1==0;
>
> Or even
>
> my $false; # undef by default, a false value
> my $true = ! $false;
>
> This has a certain pleasing austerity to it.
I know the people discussing this already know this, but for the unweary
reader:
I generally have the same reservations about this as
#define TRUE 1
#define FALSE 0
for the C language. The objections are actually even stronger in Perl
than they are in C. In C false is 0, and true is anything else. In Perl,
there are many different values of false, and many different values of
true.
It invites the unweary programmer to do things like:
if (some_sub_call() == $true)
{
# do something
}
Of course, that sub may return all kinds of true values. If that true
value happens to be 2, or "hello", then your comparison suddenly stops
working.
In a language where booleans are not a separate type, and where the only
true and false values are booleans, this is all fine. However, in
languages where true is flexible, and especially if false is also
flexible, specific comparisons should be avoided. Just use
if (some_sub_call())
{
# do whatever you would do on true-ness
}
for the opposite, use one of
if (!some_sub_call()) {}
unless (some_sub_call()) {}
Using true and false as constants should only ever be done as
assignments, never for comparisons. Because it is too easy to forget
that, I generally use the rule that they should not be used at all.
Martien
--
Martien Verbruggen |
Interactive Media Division | Think of the average person. Half of
Commercial Dynamics Pty. Ltd. | the people out there are dumber.
NSW, Australia |
Ilya Zakharevich
> > undef WHATEVER
> > - clears the memory buffers associated for WHATEVER
> >
> > $var = undef;
> > - marks the memory buffers as unapplicable;
> >
> OK, in the same vein, how 'bout:
>
> undef @array;
>
> versus:
>
> @array = ();
>
> ?
>
> (and the same for hashes if it makes any difference....)
Same difference. ;-) This is why I wrote WHATEVER.
Ilya
aman...@my-deja.com
jonce...@nospammiesno.earthlink.net (Jon S.) wrote:
> Hi,
>
> I know this must seem dumb, but I'm trying to figure out the proper
> way to set a scalar as a boolean "true" or "false".
>
> Larry R. and others helped me before with a definition of a variable
> using a condition that was either true or false, but now I've found a
> spot where I just want to seed something a "true" value for later use.
>
> I've resorted to using
> $itstrue = 1;
>
>
> is there some standard expression that comes up true which everyone
> uses?)
>
> or false?
>
>
> Jon
>
>
How bout this
my $bool = 1
print "$test\n" if ($bool);
>> prints value of $test
$bool = 0;
print "$test\n" if ($bool);
>>print nothing
Sent via Deja.com http://www.deja.com/
Before you buy.