[32374] in Perl-Users-Digest
Perl-Users Digest, Issue: 3641 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 15 16:09:24 2012
Date: Thu, 15 Mar 2012 13:09:07 -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 Thu, 15 Mar 2012 Volume: 11 Number: 3641
Today's topics:
Re: $var = do { ... }? (Tim McDaniel)
%hash + @keys -> @value_refs; existing associations onl <oneingray@gmail.com>
Re: %hash + @keys -> @value_refs; existing associations <m@rtij.nl.invlalid>
Re: %hash + @keys -> @value_refs; existing associations <rvtol+usenet@xs4all.nl>
Re: %hash + @keys -> @value_refs; existing associations <ben@morrow.me.uk>
Re: Find the oldest files without using ls -tr <janis_papanagnou@hotmail.com>
Re: Find the oldest files without using ls -tr <ben@morrow.me.uk>
Re: Find the oldest files without using ls -tr <janis_papanagnou@hotmail.com>
Re: Find the oldest files without using ls -tr <ben@morrow.me.uk>
Re: Find the oldest files without using ls -tr (Tim McDaniel)
Re: Find the oldest files without using ls -tr <ben@morrow.me.uk>
Re: Find the oldest files without using ls -tr <Casper.Dik@OrSPaMcle.COM>
Re: Find the oldest files without using ls -tr (Tim McDaniel)
Howto tinyperl - Newbie <yc282004@yahoo.com.sg>
reduce, anyone? <oneingray@gmail.com>
Re: reduce, anyone? <bugbear@trim_papermule.co.uk_trim>
Re: reduce, anyone? <ben@morrow.me.uk>
Re: reduce, anyone? (Seymour J.)
yet another question about numbers and strings (hymie!)
Re: yet another question about numbers and strings <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 15 Mar 2012 17:09:57 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: $var = do { ... }?
Message-Id: <jjt7p5$e3g$1@reader1.panix.com>
In article <jiqv7d$6k4$1@reader1.panix.com>,
Tim McDaniel <tmcd@panix.com> wrote:
>It occurred to me that I could code it as
>
> my $permanent_variable = do {
> my $this = ...;
> my $that = ... $this ...;
> yadda yadda;
> ... final computation ...;
> };
So I have to make sure the code evaluates the desired return value as
the last thing in the block, like
my $result = do {
if ($i % 2 == 0) { 'even' }
elsif ($i % 3 == 0) { 'divisible by 3' }
elsif ($i % 5 == 0) { 'divisible by 5' }
else { 'just wrong' }
};
Is there a clever way in Perl 5 to metaphorically return early with a
value?
"return", in Perl 5.8 and 5.14, returns from a sub, not a block.
"last" is documented in Perl 5.8.8 as
"last" cannot be used to exit a block which returns a value such
as "eval {}", "sub {}" or "do {}", and should not be used to exit
a grep() or map() operation.
Note that a block by itself is semantically identical to a loop
that executes once. Thus "last" can be used to effect an early
exit out of such a block.
So I can use "last" to end early, if I wrap it in an extra {...}.
But "last" doesn't return a value: if I just do "last", the do{...}
experimentally evaluates to undef.
So far as I can see, I can exit a do{...} early AND return a value
only by coding it myself using an extra {...}, like
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /usr/bin/perl
use strict;
use warnings;
for my $i (4, 9, 25, -1) {
my $result = do {
my $return;
{
if ($i % 2 == 0) { $return = 'even'; last };
if ($i % 3 == 0) { $return = 'divisible by 3' }
elsif ($i % 5 == 0) { $return = 'divisible by 5' }
else { $return = 'just wrong' }
}
$return;
};
print $i, (defined $result ? " defined $result" : ' undef '), "\n";
}
exit 0;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Of course that's contrived; the original if-elsif-else structure is
a much more concise way of expressing it.)
Is there a clever way in Perl 5 to metaphorically return early with a
value?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 15 Mar 2012 13:44:01 +0700
From: Ivan Shmakov <oneingray@gmail.com>
Subject: %hash + @keys -> @value_refs; existing associations only
Message-Id: <86mx7i749a.fsf@gray.siamics.net>
Given @keys and a %hash, a list of values could be produced
easily, like:
my @vals
= @hash{@keys};
Likewise, for the list of references:
my @refs
= \@hash{@keys};
I wonder, is it necessary to use map to get a list of references
/considering the existing associations only/?
my @refs
= map { exists ($hash{$_}) ? \$hash{$_} : undef; } (@keys);
I don't care about the missing keys, BTW. Thus, I can use
something like the following instead, but it's even more
verbose.
my @refs = ();
foreach my $k (@keys) {
push (@refs, \$hash{$k})
if (exists ($hash{$k}));
}
--
FSF associate member #7257
------------------------------
Date: Thu, 15 Mar 2012 09:37:39 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: %hash + @keys -> @value_refs; existing associations only
Message-Id: <jbm839-kto.ln1@news.rtij.nl>
On Thu, 15 Mar 2012 13:44:01 +0700, Ivan Shmakov wrote:
> I wonder, is it necessary to use map to get a list of references
> /considering the existing associations only/?
>
> my @refs
> = map { exists ($hash{$_}) ? \$hash{$_} : undef; } (@keys);
>
> I don't care about the missing keys, BTW. Thus, I can use
something
> like the following instead, but it's even more verbose.
>
> my @refs = ();
> foreach my $k (@keys) {
> push (@refs, \$hash{$k})
> if (exists ($hash{$k}));
> }
my @refs
= map { exists ($hash{$_}) ? \$hash{$_} : () } (@keys);
HTH,
M4
------------------------------
Date: Thu, 15 Mar 2012 10:00:19 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: %hash + @keys -> @value_refs; existing associations only
Message-Id: <4f61afa6$0$6989$e4fe514c@news2.news.xs4all.nl>
On 2012-03-15 07:44, Ivan Shmakov wrote:
> Given @keys and a %hash, a list of values could be produced
> easily, like:
>
> my @vals
> = @hash{@keys};
>
> Likewise, for the list of references:
>
> my @refs
> = \@hash{@keys};
>
> I wonder, is it necessary to use map to get a list of references
> /considering the existing associations only/?
>
> my @refs
> = map { exists ($hash{$_}) ? \$hash{$_} : undef; } (@keys);
>
> I don't care about the missing keys, BTW. Thus, I can use
> something like the following instead, but it's even more
> verbose.
>
> my @refs = ();
> foreach my $k (@keys) {
> push (@refs, \$hash{$k})
> if (exists ($hash{$k}));
> }
Can you sketch why you would need such a data set?
Would aliases also be OK?
--
Ruud
------------------------------
Date: Thu, 15 Mar 2012 11:09:25 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: %hash + @keys -> @value_refs; existing associations only
Message-Id: <58v839-1k22.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> Given @keys and a %hash, a list of values could be produced
> easily, like:
>
> my @vals
> = @hash{@keys};
>
> Likewise, for the list of references:
>
> my @refs
> = \@hash{@keys};
>
> I wonder, is it necessary to use map to get a list of references
> /considering the existing associations only/?
>
> my @refs
> = map { exists ($hash{$_}) ? \$hash{$_} : undef; } (@keys);
Do you care about exists vs defined? If not then you can use
my @refs = map \$_, grep defined, @hash{@keys};
If you do then I think the best you can do is
my @refs = map \$hash{$_}, grep exists $hash{$_}, @keys;
which isn't much better than you've got there.
Ben
------------------------------
Date: Thu, 15 Mar 2012 00:16:33 +0100
From: Janis Papanagnou <janis_papanagnou@hotmail.com>
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <jjr8sh$3vc$2@news.m-online.net>
On 14.03.2012 20:59, Ben Morrow wrote:
>
> Quoth Sven Mascheck <mascheck@email.invalid>:
>> In comp.unix.shell Ben Morrow <ben@morrow.me.uk> wrote:
>>> [f'up set to clpmisc]
>> [ignored, shell-only remark]
>>
>>> Better would probably be to use -print0 and perl -n0. -print0 isn't in
>>> POSIX, but it is in BSD find, which may be portable enough.
>>
>> or just "find ... -exec {} +" which is posix and obsoletes xargs
>
> The OP used that. It may obsolete xargs, but it is still subject to
> argv-length limitations. Something like
What sort of argv-limitation do you mean? The exec line length limitation
maybe? Anyway, the man page says
-exec command {} +
This variant of the -exec action runs the specified command on the
selected files, but the command line is built by appending each selected
file name at the end; the total number of invocations of the command will
be much less than the number of matched files. The command line is built
in much the same way that xargs builds its command lines. [...]
Janis
>
> find . -print0 | perl -n0 -le'...'
>
> will only invoke one instance of perl ever, and perl will run in
> parallel with find rather than having to wait until all its arguments
> have been collected up.
>
> Ben
>
------------------------------
Date: Thu, 15 Mar 2012 02:12:01 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <hov739-u091.ln1@anubis.morrow.me.uk>
Quoth Janis Papanagnou <janis_papanagnou@hotmail.com>:
> On 14.03.2012 20:59, Ben Morrow wrote:
> >
> > Quoth Sven Mascheck <mascheck@email.invalid>:
> >>
> >> or just "find ... -exec {} +" which is posix and obsoletes xargs
> >
> > The OP used that. It may obsolete xargs, but it is still subject to
> > argv-length limitations. Something like
>
> What sort of argv-limitation do you mean? The exec line length limitation
> maybe?
Yes.
> Anyway, the man page says
>
> -exec command {} +
>
> This variant of the -exec action runs the specified command on the
> selected files, but the command line is built by appending each selected
> file name at the end; the total number of invocations of the command will
> be much less than the number of matched files.
'Will be much less than'. Not 'will be exactly one regardless of'. Often
the difference is important, say when you're looking for a maximum.
Ben
------------------------------
Date: Thu, 15 Mar 2012 09:42:32 +0100
From: Janis Papanagnou <janis_papanagnou@hotmail.com>
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <jjsa1o$rhv$1@news.m-online.net>
On 15.03.2012 03:12, Ben Morrow wrote:
>
> Quoth Janis Papanagnou <janis_papanagnou@hotmail.com>:
>> On 14.03.2012 20:59, Ben Morrow wrote:
>>>
>>> Quoth Sven Mascheck <mascheck@email.invalid>:
>>>>
>>>> or just "find ... -exec {} +" which is posix and obsoletes xargs
>>>
>>> The OP used that. It may obsolete xargs, but it is still subject to
>>> argv-length limitations. Something like
>>
>> What sort of argv-limitation do you mean? The exec line length limitation
>> maybe?
>
> Yes.
>
>> Anyway, the man page says
>>
>> -exec command {} +
>>
>> This variant of the -exec action runs the specified command on the
>> selected files, but the command line is built by appending each selected
>> file name at the end; the total number of invocations of the command will
>> be much less than the number of matched files.
>
> 'Will be much less than'. Not 'will be exactly one regardless of'. Often
> the difference is important, say when you're looking for a maximum.
Yes, that are different semantics. But you had claimed that there's a
problem where there isn't one, compared with xargs.
The point in question of the original posting was cleared by the part
that you stripped:
"[...] The command line is built
in much the same way that xargs builds its command lines."
So I don't see where you are striving to with your argument. I think
your statement in your previous posting was just wrong.
Janis
>
> Ben
>
------------------------------
Date: Thu, 15 Mar 2012 10:56:00 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <0fu839-1k22.ln1@anubis.morrow.me.uk>
Quoth Janis Papanagnou <janis_papanagnou@hotmail.com>:
>
> The point in question of the original posting was cleared by the part
> that you stripped:
>
> "[...] The command line is built
> in much the same way that xargs builds its command lines."
*I* have never said anything about xargs. I always understood the find
invocation in the original post was equivalent to xargs.
> So I don't see where you are striving to with your argument. I think
> your statement in your previous posting was just wrong.
My point was that if you're going to feed perl from find it's better to
do so with find -print0 and perl -n0 than with either xargs or find
-exec {} +. Not only does it avoid any issues with argument length
limitations, it also runs perl in parallel with find rather than
waiting.
Ben
------------------------------
Date: Thu, 15 Mar 2012 15:46:12 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <jjt2s4$eru$1@reader1.panix.com>
In article <0fu839-1k22.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Janis Papanagnou <janis_papanagnou@hotmail.com>:
>> So I don't see where you are striving to with your argument. I think
>> your statement in your previous posting was just wrong.
>
>My point was that if you're going to feed perl from find it's better to
>do so with find -print0 and perl -n0 than with either xargs or find
>-exec {} +. Not only does it avoid any issues with argument length
>limitations,
The NetBSD version of "man find" may be more explicit than the man
page previously quoted (I can't check at the moment):
If terminated by a plus sign (``+''), the pathnames for which the
primary is evaluated are aggregated into sets, and utility will be
invoked once per set, similar to xargs(1). If any invocation
exits with non-zero exit status, then find will eventually do so
as well, but this does not cause find to exit early. The string
``{}'' must appear, and must appear last. Each set is limitted to
no more than 5,000 pathnames, and is also limitted such that the
invokation of utility does not exceed ARG_MAX.
So it appears to me that they've made an effort to make -exec work
like xargs in not blowing up on too-long command lines.
>it also runs perl in parallel with find rather than waiting.
I don't know of any reason why find couldn't run -exec in parallel,
but experimentally under NetBSD, it appears that it doesn't, so that
can be a valid objection. ("Can be" because, on a low-powered system,
you might not want them to run in parallel, but there's no way to
avoid that with "|xargs".)
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 15 Mar 2012 16:49:02 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <u4j939-2v62.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <0fu839-1k22.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
>
> >it also runs perl in parallel with find rather than waiting.
>
> I don't know of any reason why find couldn't run -exec in parallel,
Think about it. If you're running
find . -exec perl -e... {} +
then find has to collect up ARG_MAX-worth of filenames before it can
even try to invoke perl. With
find . -print0 | perl -n0 -e...
perl is invoked by the shell at the same time as find, and can (subject
to buffering) read filenames one at a time as they come in.
Ben
------------------------------
Date: 15 Mar 2012 17:13:27 GMT
From: Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM>
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <4f622337$0$6947$e4fe514c@news2.news.xs4all.nl>
tmcd@panix.com (Tim McDaniel) writes:
>The NetBSD version of "man find" may be more explicit than the man
>page previously quoted (I can't check at the moment):
> If terminated by a plus sign (``+''), the pathnames for which the
> primary is evaluated are aggregated into sets, and utility will be
> invoked once per set, similar to xargs(1). If any invocation
> exits with non-zero exit status, then find will eventually do so
> as well, but this does not cause find to exit early. The string
> ``{}'' must appear, and must appear last. Each set is limitted to
> no more than 5,000 pathnames, and is also limitted such that the
> invokation of utility does not exceed ARG_MAX.
This function has been part of Solaris find since 2.0, I believe; but it
was documented in a much later release.
Casper
------------------------------
Date: Thu, 15 Mar 2012 19:06:48 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Find the oldest files without using ls -tr
Message-Id: <jjtek8$slj$1@reader1.panix.com>
In article <u4j939-2v62.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <0fu839-1k22.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>>
>> >it also runs perl in parallel with find rather than waiting.
>>
>> I don't know of any reason why find couldn't run -exec in parallel,
>
>Think about it. If you're running
>
> find . -exec perl -e... {} +
>
>then find has to collect up ARG_MAX-worth of filenames before it can
>even try to invoke perl.
I was thinking of the parallelism of find starting, getting ARG_MAX
arguments, invoking perl for the first time, and then without waiting
for that first perl to finish, starts accumulating the arguments for
the second call of perl.
There's then the further design decision about parallelism: if find
gets the arguments for the second call of perl, should it wait for the
first perl to finish before running the second call of perl? I don't
know what xargs does in such a case. ... Experimentally, in NetBSD,
xargs waits for the first execution to finish before starting the
second. That's probably a wiser default, considering how one run
of whatever command you run might have a dependency with another run,
or that running several at once might hammer your machine.
With
>
> find . -print0 | perl -n0 -e...
>
>perl is invoked by the shell at the same time as find, and can (subject
>to buffering) read filenames one at a time as they come in.
The buffering is not negligable, I think, in small cases.
And that's a startup effect: in large cases, the parallelism of find
and perl (in the first sense I defined above) should dominate the
efficiency of this sort of parallelism. That is, if the perl process
takes longer to run than the find that gets its arguments, the total
time is (startup+time for all perls). Or, if find instead takes more
time, then it's (startup+time for all finds).
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 15 Mar 2012 08:14:01 -0700 (PDT)
From: dolphin <yc282004@yahoo.com.sg>
Subject: Howto tinyperl - Newbie
Message-Id: <7b09d61b-025a-43b2-acbb-4d0abc5c6a06@t8g2000pbe.googlegroups.com>
Hi,
I'm trying to learn how to use tinyperl as it does not require local
admin to install and very small but not successful. I tried to print
"Hello World", can anyone give a pointer?
Thanks in advance.
------------------------------
Date: Thu, 15 Mar 2012 14:11:46 +0700
From: Ivan Shmakov <oneingray@gmail.com>
Subject: reduce, anyone?
Message-Id: <86ehsu72z1.fsf@gray.siamics.net>
Since the days of APL, reduction (or folding) is one of the
basic operations on ordered collections (lists, arrays, etc.)
I see that Perl 6 has such an operator [1], but what about
Perl 5? A quick search on CPAN reveals [2] (though it seems to
implement APL's scan instead of reduce), but I still wonder if
there're any other possible choices? (It's not that hard to
implement such a function, BTW.)
TIA.
sub reduce {
my ($f, $a, @l) = @_;
foreach $v (@l) { $a = &$f ($a, $v); }
## .
$a;
}
sub add {
my ($a, $b) = @_;
## .
$a + $b;
}
sub access {
my ($h, $k) = @_;
## .
$h->{$k};
}
print (reduce (\&add, 0, 1, 2, 3), "\n");
## => 6
print (reduce (\&access, { "a" => { "b" => { "c" => "d" } } },
qw (a b c)), "\n");
## => d
[1] http://search.cpan.org/~lichtkind/Perl6-Doc-0.36/lib/Perl6/Doc/Overview/Reduce.pod
[2] http://search.cpan.org/~patch/Operator-Util-0.05/lib/Operator/Util.pm
--
FSF associate member #7257
------------------------------
Date: Thu, 15 Mar 2012 10:27:43 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: reduce, anyone?
Message-Id: <2Ludna5PUbm9WfzSnZ2dnUVZ8n2dnZ2d@brightview.co.uk>
Ivan Shmakov wrote:
> Since the days of APL, reduction (or folding) is one of the
> basic operations on ordered collections (lists, arrays, etc.)
I think Lisp predates APS, and map/reduce were implemented.
BugBear
------------------------------
Date: Thu, 15 Mar 2012 11:12:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: reduce, anyone?
Message-Id: <8dv839-1k22.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> Since the days of APL, reduction (or folding) is one of the
> basic operations on ordered collections (lists, arrays, etc.)
>
> I see that Perl 6 has such an operator [1], but what about
> Perl 5? A quick search on CPAN reveals [2] (though it seems to
> implement APL's scan instead of reduce), but I still wonder if
> there're any other possible choices? (It's not that hard to
> implement such a function, BTW.)
List::Util has the standard implementation.
Ben
------------------------------
Date: Thu, 15 Mar 2012 08:47:47 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: reduce, anyone?
Message-Id: <4f61e4f3$11$fuzhry+tra$mr2ice@news.patriot.net>
In <2Ludna5PUbm9WfzSnZ2dnUVZ8n2dnZ2d@brightview.co.uk>, on 03/15/2012
at 10:27 AM, bugbear <bugbear@trim_papermule.co.uk_trim> said:
>I think Lisp predates APS,
I don't know about APS, but LISP predates APL by half a decade.
<mandatory spilling error>
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: 15 Mar 2012 12:38:02 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: yet another question about numbers and strings
Message-Id: <4f61e2a9$0$28641$a8266bb1@newsreader.readnews.com>
Greetings.
I'm not entirely sure if I have a Perl problem, a MSSQL problem, or a
DBI problem. But it's a problem, and maybe somebody can help me
resolve it.
I have an MSSQL database. It includes a field for ID numbers
that are about 18 digits long.
I have a generic searching tool that I use on this database. It basically
does this:
use DBI;
my $dbh=DBI->connect("DBI:Sybase:$host",$user,$pass) or
die "Couldn't connect to MSSQL: $DBI::errstr\n";
$sth = $dbh->prepare("select * from $ARGV[0]");
$sth->execute;
while (my @row = $sth->fetchrow_array)
{
foreach my $i (0 .. $#row)
{
print "$headings[$i]\t$defs[$i]\n\t$row[$i]\n";
}
print "==========\n";
}
Sadly, I end up with a response that looks like this:
ID bigint 8 not null
9.21474030305498e+18
I'm not doing any mathematical operations on the number. I just need
to know what the actual number is.
Again, I have no idea if this means MSSQL is sending me data in exp format,
or if Perl is doing the changing for me.
But if anybody knows how to fix it, I'd be grateful.
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
-------------------------------------------------------------------------------
------------------------------
Date: Thu, 15 Mar 2012 17:02:14 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: yet another question about numbers and strings
Message-Id: <mtj939-2v62.ln1@anubis.morrow.me.uk>
Quoth hymie@lactose.homelinux.net (hymie!):
>
> I have an MSSQL database. It includes a field for ID numbers
> that are about 18 digits long.
<snip>
>
> Sadly, I end up with a response that looks like this:
> ID bigint 8 not null
> 9.21474030305498e+18
>
> I'm not doing any mathematical operations on the number. I just need
> to know what the actual number is.
At a guess: you are using a 32bit build of perl, and it isn't built with
-Duse64bitint? In that case the only way perl has to represent numbers
that big is with floats, and with numbers as big as 9e18 you are bound
to lose precision.
If you want to represent these numbers as Perl numbers, you will need to
rebuild perl to support 64-bit integers. However, if you just want to
print them you want to get the DBD to return them to you as strings,
instead.
At a further guess: you are using DBD::Sybase version 1.09 or older? The
current version has this comment in dbdimp.c:
* In DBD::Sybase 1.09 and before, certain large numeric types (money,
* bigint) were being kept in native format, and then returned to the
* caller as a perl NV data item. An NV is really a float, so there was
* loss of precision, especially for bigint data which is a 64bit int.
* In 1.10 these datatypes behave the same way as numeric/decimal -
* converted to a char string and returned that way to the caller, who
* can then use Math::BigInt, etc. If you want to revert to the previous
* behavior, you need to define SYB_NATIVE_NUM.
so if you'd be happy with string output then you just need to upgrade
DBD::Sybase.
Ben
------------------------------
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 3641
***************************************
