[31700] in Perl-Users-Digest
Perl-Users Digest, Issue: 2963 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue May 25 03:09:30 2010
Date: Tue, 25 May 2010 00:09:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 25 May 2010 Volume: 11 Number: 2963
Today's topics:
Another bug - on 64-bit-integer-and-floatingpoint machi <nospam-abuse@ilyaz.org>
Re: bit-twiddling on 32-bit machines <hjp-usenet2@hjp.at>
Re: bit-twiddling on 32-bit machines <nospam-abuse@ilyaz.org>
Re: bit-twiddling on 32-bit machines <hjp-usenet2@hjp.at>
Re: determining whether a server supports secure authen <merrilljensen@q.com>
Re: determining whether a server supports secure authen <nospam-abuse@ilyaz.org>
Re: Using rename script to change multiple files <m@rtij.nl.invlalid>
Re: Using rename script to change multiple files <hjp-usenet2@hjp.at>
Re: Using rename script to change multiple files <RedGrittyBrick@spamweary.invalid>
Re: Using rename script to change multiple files <nospam-abuse@ilyaz.org>
Re: What do N and R in $NR stand for? <uri@StemSystems.com>
Re: Where is the perl documentationn for '..' (command <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 25 May 2010 05:23:54 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Another bug - on 64-bit-integer-and-floatingpoint machines
Message-Id: <slrnhvmnna.2ks.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-24, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> my $x1 = 18014398509481728.000000; # exact FP value
> my $x2 = 18014398509481729; # exact 64 bit int value
> if ($x1 >= $x2) {
> print "surprise!\n";
> }
Thinking about it more, it is not a "surprise", but just a plain bug.
It is trivial to write down a macro ncmp_IV_NV(iv,nv) which would do
the "correct thing" in both cases (powerful- and braindamaged-NVs).
So the fact that Perl does not use such a construct is a bug.
Hope this helps,
Ilya
------------------------------
Date: Mon, 24 May 2010 11:44:27 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhvkijr.m3k.hjp-usenet2@hrunkner.hjp.at>
On 2010-05-23 23:08, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-05-22, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>> And: I do not have Perl with 64-bit IV AND 64-bit NV around, so all
>>> this is just a conjecture: I expect the the following things to break:
>>>
>>> rounding by int($n + 0.t);
>
>> what is $n here (conceptually)?
>
> A number.
Not specific enough.
>> An integer? Then it doesn't make sense to round it.
>
> Why? I can round 3 without any problem here...
Because it is already an integer. Rounding it is useless since it is
guarantueed to give you the same value (unless you want to round to the
nearest integer representable as an FP value, then the expression does
what you want).
>> A floating point value? Then adding 0.5 doesn't change the
>> type and whether IVs are 32 bit or 64 bit doesn't matter.
>
> perldoc perlnumber
Please be more specific.
>>> $x + 0.5 >= $x
>
>> Again, this is already "broken" (i.e., a false assumption) on large
>> numbers, making IVs 64 bit doesn't change that.
>
> ??? Are you sure you know what you are talking about?
Sorry, I misread the ">=" as ">".
But from what I see, ($x + 0.5 >= $x) actually seems to be true for all
numbers, because the comparison is done on the NVs.
That, however, does lead to a result which may surprise the unwary:
#!/usr/bin/perl
use warnings;
use strict;
no warnings 'portable';
use Devel::Peek;
my $x1 = 18014398509481728.000000; # exact FP value
my $x2 = 18014398509481729; # exact 64 bit int value
if ($x1 >= $x2) {
print "surprise!\n";
}
hp
------------------------------
Date: Mon, 24 May 2010 10:50:42 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhvkmg1.vqn.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-24, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>>> And: I do not have Perl with 64-bit IV AND 64-bit NV around, so all
>>>> this is just a conjecture: I expect the the following things to break:
>>>> rounding by int($n + 0.t);
>>> what is $n here (conceptually)?
>> A number.
> Not specific enough.
Specific enough for me. What part of
perldoc perlnumber
do you not agree with?
>>> An integer? Then it doesn't make sense to round it.
>> Why? I can round 3 without any problem here...
> Because it is already an integer. Rounding it is useless since it is
> guarantueed to give you the same value (unless you want to round to the
> nearest integer representable as an FP value, then the expression does
> what you want).
I do not see how a correct answer may be deemed "useless". Do you
want to allow sqrt(1) to be 75 since "it does not make sense to apply
sqrt() to 1"?
> But from what I see, ($x + 0.5 >= $x) actually seems to be true for all
> numbers, because the comparison is done on the NVs.
So one moved dust to be under a different carpet. This comparison
"looks" true, but only due to another problem...
> my $x1 = 18014398509481728.000000; # exact FP value
> my $x2 = 18014398509481729; # exact 64 bit int value
> if ($x1 >= $x2) {
> print "surprise!\n";
> }
Yes, this is what I meant by "looking true..."...
Yours,
Ilya
------------------------------
Date: Mon, 24 May 2010 17:23:21 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhvl6f9.l36.hjp-usenet2@hrunkner.hjp.at>
On 2010-05-24 10:50, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-05-24, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>>>> And: I do not have Perl with 64-bit IV AND 64-bit NV around, so all
>>>>> this is just a conjecture: I expect the the following things to break:
>
>>>>> rounding by int($n + 0.t);
>
>>>> what is $n here (conceptually)?
>
>>> A number.
>
>> Not specific enough.
>
> Specific enough for me.
Not for me. A number in a program isn't just a number. It represents
something. To determine which operations on that number make sense you
need to know what it represents, how accurate that represention is (and
needs to be), what properties it has. Then you can say whether a given
representation in a progrem (e.g. as a 64-bit FP number) is adequate and
whether computing int($n + 0.5) makes sense or not.
> What part of
>
> perldoc perlnumber
>
> do you not agree with?
Who says I don't agree with it? You were vaguely referring to it in
response to a very specific claim:
>>>> A floating point value? Then adding 0.5 doesn't change the
>>>> type and whether IVs are 32 bit or 64 bit doesn't matter.
I don't know why you referred to it, or which part of perldoc perlnumber
is supposed to proof that my claim is wrong, and I won't guess. Either
you refer to the specific part of perldoc perlnumber which is applicable
here or you let it rest.
>>>> An integer? Then it doesn't make sense to round it.
>
>>> Why? I can round 3 without any problem here...
>
>> Because it is already an integer. Rounding it is useless since it is
>> guarantueed to give you the same value (unless you want to round to the
>> nearest integer representable as an FP value, then the expression does
>> what you want).
>
> I do not see how a correct answer may be deemed "useless".
Not the answer is useless, but the operation. If I have a variable $x in
my program which at some point contains an integral value, why would I
write
$y = int($x + 0.5);
instead of simply
$y = $x;
at this point? I could just as well write
$y = $x * 1;
or
$y = $x + 0;
or
$y = $x + 1E300 - 1E300;
which are similarly useless (unless executed specifically for the
side-effects caused by the representation).
> Do you want to allow sqrt(1) to be 75 since "it does not make sense to
> apply sqrt() to 1"?
No, but I do want to allow sin(1E100) to return an (more or less) random
number between -1 and +1, because ε(1E100) ≫ 2π. The input to the
function is useless, so I must expect the output to be useless, too.
Similarly ($n + 0.5) is only useful if the result can actually be
represented in an FP number with adequate precision. Perl doesn't save
you from thinking about stuff like that. Actually, you have to think
more than in statically typed languages: A typeless language gives you
more freedom but demands more discipline.
hp
------------------------------
Date: Mon, 24 May 2010 20:32:16 -0700
From: Uno <merrilljensen@q.com>
Subject: Re: determining whether a server supports secure authentication
Message-Id: <860r5fFpniU1@mid.individual.net>
On 5/19/2010 12:36 PM, sln@netherlands.com wrote:
> On Wed, 19 May 2010 19:16:45 +0000 (UTC), Ilya Zakharevich<nospam-abuse@ilyaz.org> wrote:
>
>> On 2010-05-19, Uno<merrilljensen@q.com> wrote:
>>> I guess I don't know who an "attacker" is. I see movies where any
>>> computer capability can exist, like Seth Green controlling traffic in
>>> Los Angeles in "The Italian Job." I admire Seth's genius (Robot
>>> Chicken), but don't think the situation possible.
>>
>>> What would it take for another entity to suck up all my packets that I
>>> sent to q.com?
>>
>> Google for it; it must be discussed out to the death. (IIRC MIB do
>> not need to suck up anything; all they need is to reply EARLIER than
>> your intended target - which is not hard given that they are IN
>> BETWEEN.)
>>
>
> Such things are criminal, how are we to protect ourselves.
I like to bore them.
--
Uno
------------------------------
Date: Tue, 25 May 2010 06:07:08 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: determining whether a server supports secure authentication
Message-Id: <slrnhvmq8c.2ks.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-19, Uno <merrilljensen@q.com> wrote:
> I guess I don't know who an "attacker" is. I see movies where any
> computer capability can exist, like Seth Green controlling traffic in
> Los Angeles in "The Italian Job." I admire Seth's genius (Robot
> Chicken), but don't think the situation possible.
In my other reply to this message, I forgot about another example with
"real life Italian Job". According to comp.risks, there exists an
available-off-the-shelf router which does exactly what people fear all
the time, but think is technically impossible:
a) this router is advertised as having something like "smart firewall";
b1) to implement this "smartness", the install program for the
router inserts a fake certificate into the trust chain which
allows the router to impersonate any site;
b2) using this "breach of authentication trust", the router DOES
impersonate all the SSL targets, and decrypts all the
communications passing through it. Then the firewall acts
basing on the decrypted contents.
Hope this helps,
Ilya
------------------------------
Date: Mon, 24 May 2010 11:44:01 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Using rename script to change multiple files
Message-Id: <1cupc7-s3m.ln1@news.rtij.nl>
On Sun, 23 May 2010 18:39:12 -0700, Xho Jingleheimerschmidt wrote:
> Tad McClellan wrote:
>> James Egan <jegan473@comcast.net> wrote:
>>
>>> I'm trying to use the perl "rename" script to rename batches of files.
>>
>>
>> What is "the perl rename script"?
>>
>> I have never heard of it.
>
> I was quite surprised to find it on my Asus Linux machine, as I am used
> to 'rename' being a binary which does fixed string substitutions.
Clearly depends on your distro:
[martijn@cow ~]$ which rename
/usr/bin/rename
[martijn@cow ~]$ file $(which rename)
/usr/bin/rename: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18,
stripped
[martijn@cow ~]$
M4
------------------------------
Date: Mon, 24 May 2010 12:05:32 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Using rename script to change multiple files
Message-Id: <slrnhvkjrc.m3k.hjp-usenet2@hrunkner.hjp.at>
On 2010-05-24 02:49, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <sKqdnZZvCsoCDGTWnZ2dnUVZ8qmdnZ2d@bt.com>, on 05/23/2010
> at 09:35 PM, RedGrittyBrick <RedGrittyBrick@SpamWeary.invalid>
> said:
>
>>So far as I can see:
>
>>Part of "the perl distribution" - No.
>
> Yes.
>
>>The rename/prename script
>
> It's not a script. Look at perlfunc.
Yes, it is:
% file /usr/bin/rename
/usr/bin/rename: symbolic link to `/etc/alternatives/rename'
% file /etc/alternatives/rename
/etc/alternatives/rename: symbolic link to `/usr/bin/prename'
% file /usr/bin/prename
/usr/bin/prename: a /usr/bin/perl -w script text executable
So it is a script on Debian systems (as RedGrittyBrick wrote) and it is
part of the "perl" package:
% dpkg -S /usr/bin/prename
perl: /usr/bin/prename
Also as RedGrittyBrick wrote, it isn't part of the perl distribution,
but was added by Debian. I don't know why, but from the changelog I can
guess that perl 5.005 included rename as an example script, which was
included in the perl package, later replaced by an updated script, and
the updated is still provided by the perl package even though the
example script has been removed from the perl distribution.
hp
------------------------------
Date: Mon, 24 May 2010 12:31:52 +0100
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: Using rename script to change multiple files
Message-Id: <4bfa63ac$0$12171$fa0fcedb@news.zen.co.uk>
On 24/05/2010 00:04, Ilya Zakharevich wrote:
> On 2010-05-23, RedGrittyBrick<RedGrittyBrick@SpamWeary.invalid> wrote:
>>>> What is "the perl rename script"?
>
>>>> I have never heard of it.
>
>>> It's part of the perl distribution, and is actually a symlink to prename:
>
>> So far as I can see:
>>
>> Part of "the perl distribution" - No.
>>
>> Part of Debian's "perl" package - Yes.
>>
>> The rename/prename script is not listed at
>> http://perldoc.perl.org/index-utilities.html which is part of "the
>> official documentation from the Perl distribution(s)".
>
> Some people know how to look, some do not:
This is true, I'm always happy to learn.
>
> K:\get-perl\perl>ls perl5.005_03/eg
> ADB client findtar myrup rmfrom sysvipc van
> README down g nih scan travesty who
> cgi dus muck relink server unuc wrapsuid
> changes findcp muck.man rename shmkill uudecode
On my PC there's no rename script with Activestate perl v5.10.0, not in
the eg subdirectory nor anywhere else in the directory where perl is
installed.
I can't find it on my elderly Linux server either (find / -name rename).
It has perl 5.8.0 from a RedHat RPM package.
Maybe rename was removed from perl's examples sometime after perl 5.005?
>
> Hope this helps,
Not as much as I initially thought it would, but thanks.
--
RGB
------------------------------
Date: Tue, 25 May 2010 05:19:38 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Using rename script to change multiple files
Message-Id: <slrnhvmnfa.2ks.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-24, RedGrittyBrick <RedGrittyBrick@spamweary.invalid> wrote:
>> Some people know how to look, some do not:
>
> This is true, I'm always happy to learn.
Unfortunately, there is nothing specific to learn in this example.
Just the luck of "being at the precise spot at the precise time"
(like some kinds of photography! Well, in photography, some people
repeat such luck again and again...)
>> K:\get-perl\perl>ls perl5.005_03/eg
>> ADB client findtar myrup rmfrom sysvipc van
>> README down g nih scan travesty who
>> cgi dus muck relink server unuc wrapsuid
>> changes findcp muck.man rename shmkill uudecode
> Maybe rename was removed from perl's examples sometime after perl 5.005?
Definitely. This is the latest version on my disk which still has it.
Hope this helps,
Ilya
------------------------------
Date: Mon, 24 May 2010 03:17:36 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: What do N and R in $NR stand for?
Message-Id: <87fx1hdazz.fsf@quad.sysarch.com>
>>>>> "s" == sachin <reachsachin@gmail.com> writes:
s> On May 23, 1:36 am, Ben Morrow <b...@morrow.me.uk> wrote:
>> Quoth Peng Yu <pengyu...@gmail.com>:
>>
>> > I know $NR is the same as $INPUT_LINE_NUMBER. But I'm wondering what N
>> > and R in NR stand for.
>>
>> > I think R might stand for numbeR? Does N stand for iNput or liNe?
>>
>> I presume you are using the English module? I would recommend against
>> it. Quite apart from the minor performance penalty (which can be avoided
>> with newer versions of English) the puncuation names are much more
>> familiar to most Perl programmers.
>>
>> Ben
s> I believe if the record separator is '\n', and which is by default,
s> then NR would be same as number of lines. However, if we set the
s> record separator or delimiter as some other character, then value of
s> NR might be different.
s> Please correct me if I am wrong.
the name is Number of Records. a line is only a record if \n is the
value of $/. so $NR (or more commonly $.) is always correct from that
point of view. if you are reading lines, it is also the line number. so
your point is not really on target.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 24 May 2010 10:21:32 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Where is the perl documentationn for '..' (command line)
Message-Id: <87d3wlmikj.fsf@lifelogs.com>
On Sat, 22 May 2010 08:22:54 -0700 Jürgen Exner <jurgenex@hotmail.com> wrote:
JE> Peng Yu <pengyu.ut@gmail.com> wrote:
>> man perldata touchs '..' a little bit. But it seems that there should
>> a place that discuss '..' in details. Would you please let me know
>> where it is?
JE> It's an operator just like +, *, ==, gt, !, ... and can be found in
JE> perldoc perlop.
It would be nice if there was an operator perldoc switch analogous to -f
for functions.
Ted
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2963
***************************************
