[32020] in Perl-Users-Digest
Perl-Users Digest, Issue: 3284 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Feb 12 16:09:43 2011
Date: Sat, 12 Feb 2011 13:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 12 Feb 2011 Volume: 11 Number: 3284
Today's topics:
Re: Hashes are good, but not good enough. <nospam.gravitalsun@hotmail.com.nospam>
Re: Hashes are good, but not good enough. <hjp-usenet2@hjp.at>
Re: Hashes are good, but not good enough. <willem@turtle.stack.nl>
Re: Hashes are good, but not good enough. <jurgenex@hotmail.com>
Re: Hashes are good, but not good enough. <jurgenex@hotmail.com>
Re: Hashes are good, but not good enough. <jurgenex@hotmail.com>
Re: Hashes are good, but not good enough. <jurgenex@hotmail.com>
Re: Hashes are good, but not good enough. <willem@turtle.stack.nl>
Re: Hashes are good, but not good enough. <hjp-usenet2@hjp.at>
Re: Hashes are good, but not good enough. <jurgenex@hotmail.com>
Re: Hashes are good, but not good enough. <hjp-usenet2@hjp.at>
Re: Hashes are good, but not good enough. <hjp-usenet2@hjp.at>
Re: perl sorting <kkeller-usenet@wombat.san-francisco.ca.us>
Re: perl sorting <jimsgibson@gmail.com>
Re: perl sorting <nospam.gravitalsun@hotmail.com.nospam>
Re: perl sorting <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 12 Feb 2011 01:33:53 +0200
From: George Mpouras <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <ij4h13$i7h$1@ulysses.noc.ntua.gr>
>
> either way, the OP can't code it nor can he compare the growth of either
> algorithm.
>
DAWG and compressed DAWG unfortunately are not possible to implemented
with pure perl, but A C++ module is possible.
I believe CDAWG functionality, will give Perl a huge advantage over
other languages. CDAWGs can give instant ansewers over bilion of
recoreds. They are even faster than Perfect hashes (no collision hashes)
------------------------------
Date: Sat, 12 Feb 2011 07:46:56 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnilcb71.grs.hjp-usenet2@hrunkner.hjp.at>
On 2011-02-11 14:34, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Fri, 11 Feb 2011 11:13:07 +0200 "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam> wrote:
>
> GM> We all find hashes pretty convenient, and helpful to make things fast; but
> GM> the problem with hashes is that they consume too much memory on big trees,
> GM> and they are too slow for hundred millions of keys.
>
> This is true and any experienced programmer will tell you not to put
> hundreds of millions of keys in a hash in any language.
Actually, only part of this is true. Hashes do consume a lot of memory,
but they are not slow for a large number of keys. As Willem correctly
pointed out, they are O(n) on the length of the key but O(1) on the
number of keys. As long as your hash fits into RAM, lookups and
insertions are the same speed whether your hash contains 100 keys or
100,000,000.
hp
------------------------------
Date: Sat, 12 Feb 2011 09:12:07 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnilcjn7.112j.willem@turtle.stack.nl>
George Mpouras wrote:
)>
)> either way, the OP can't code it nor can he compare the growth of either
)> algorithm.
)>
)
) DAWG and compressed DAWG unfortunately are not possible to implemented
) with pure perl, but A C++ module is possible.
Where did you get that strange idea ?
Of course they are possible to be implemented with pure perl.
) I believe CDAWG functionality, will give Perl a huge advantage over
) other languages. CDAWGs can give instant ansewers over bilion of
) recoreds. They are even faster than Perfect hashes (no collision hashes)
This DAWG data-structure only has very few, limited use cases.
It is definitely not a replacement for perl hashes.
If you want to use it, fine, but just write it as a perl module,
perhaps with a C library for speed. You can even tie it to a hash.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sat, 12 Feb 2011 03:50:28 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <lbscl6tnjq1k950k1o2vv3qf3vdadfgt59@4ax.com>
"George Mpouras" <nospam.gravitalsun@hotmail.com.nospam> wrote:
>We all find hashes pretty convenient, and helpful to make things fast; but
>the problem with hashes is that they consume too much memory on big trees,
>and they are too slow for hundred millions of keys. Try it yourself.
>
>What we need in these situations is something different called DAWG.
>
>Please have a look at this article to understand what I mean.
>
>http://en.wikipedia.org/wiki/DAWG
>
>I tried to implement this DAWG data structure with Perl but I found it VERY
>difficult.
>
>What are your thoughts about the necessity of this new data structure.
Apples and oranges.
A hash is a mapping from string to scalar, a DAWG is a special
implementation of a string set, which trades space for algorithmic
complexity (ever tried deleting a word from a DAWG?).
The one has nothing to do with the other. Of course you can use hashes
to implement a DAWG, but that's a different story.
jue
------------------------------
Date: Sat, 12 Feb 2011 04:01:44 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <83tcl6d11p97lur2sqjbbasmgbk4ru3o0h@4ax.com>
Willem <willem@turtle.stack.nl> wrote:
>Uri Guttman wrote:
>)>>>>> "W" == Willem <willem@turtle.stack.nl> writes:
>) W> You should read up on big-oh notation. You certainly cannot sweep an O(N)
>) W> operation under the carpet and claim that something is O(1), because the
>) W> O(N) bit is blazingly fast. The whole basis of big-oh is that O(f(x)) is
>) W> *always* based on the largest *growing* factor of f(x), and that any
>) W> constant factors are irrelevant to the big-oh.
>)
>) you can do that if the work per unit is less than the tree scanning
>) operation. it is done all the time. you need to look at the largest work
>) unit and compare them. a disk sort will use ram sorts but the ram sort
>) work is irrelevent as the disk sort will dominate the run time. the
>) dominant part of a hash is just a hash generation which is much faster
>) in a scan than going down a tree. a hash and tree may both be O(N) but
>) they have different dominant parts. hashing is considered close to O(1)
>) because it doesn't make a difference in how many elements you have, it
>) is close to a constant time per lookup. any tree is dependent on the
>) size of the tree itself. that means it is O(log N) at best and O(N) at
>) worst. the scale factor is the number of elements in the structure, not
>) the length of the keys. this is how you do proper algorithm analysis -
>) you need to find the growth curve and that is dependent on the count of
>) elements, not their string length.
>
>You're talking about trees. A trie is different, in that each node is
>a small part of a key, not a whole key. A lookup in a trie takes N
>operations, where N is the key length. In a hash a lookup also takes
>at least N operations, the only difference being that the operations
>themselves are faster by a constant factor.
>
>) W> To restate: hashes and tries have the same big-oh time complexity
>) W> for key lookups, but the constant factor probably differs by a few
>) W> orders of magnitude.
>)
>) and as i showed you, you are wrong. in growth terms hashes are close to
>) O(1) and any tree is no better than O(log N).
>
>You did not show me any such thing, all I saw was some handwaving about
>how an O(N) operation is dominated by a O(1) operation, which is hogwash
>in complexity theory. O(N) *always* dominates O(1). No exceptions.
Would you agree if instead of "dominate" Uri would have used "most
expensive"? I guess that would have made it clearer.
For the kind of operation we are looking at here the most expensive
operation is RAM access. And the number of times the algorithm reads
from RAM for a hash is typically 1 or a small number if the bucket has
more than one element while for a DAWG or tree it will be one RAM access
for each character in the word, i.e. total of O(n).
jue
------------------------------
Date: Sat, 12 Feb 2011 04:14:25 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <mmtcl6h8p7s2c2a3kg3vun4t9jf72jvfjf@4ax.com>
George Mpouras <nospam.gravitalsun@hotmail.com.nospam> wrote:
>>
>> either way, the OP can't code it nor can he compare the growth of either
>> algorithm.
>>
>
>DAWG and compressed DAWG unfortunately are not possible to implemented
>with pure perl,
Perl is (except for space constraints) turing-capable, therefore of
course you can implement DAWGs in Perl.
And I think it's not even that hard using cascading HoH's. Of course
designing the algorithms to add and in particular to delete elements is
a totally different story.
>I believe CDAWG functionality, will give Perl a huge advantage over
>other languages. CDAWGs can give instant ansewers over bilion of
>recoreds. They are even faster than Perfect hashes (no collision hashes)
Yeah, but where do you need such features? I am sure there are areas,
maybe genetics or astronomie or particle physics or fluid dynamics.
But Perl is a general purpose language and the needs of people working
in those exotic fields of science are so, well, exotic, that they need
to do their own specialized coding anyway.
DAWGs are nothing but a very special implementation of string sets. If
at all you should be asking for adding string sets as a basic data
structure to Perl. And then as a second step you can discuss the actual
implementation of string sets and DAWGs may be one option among many.
jue
------------------------------
Date: Sat, 12 Feb 2011 04:18:14 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <7eucl65sp0o75nnffmkik4mj68gn61s6sc@4ax.com>
Willem <willem@turtle.stack.nl> wrote:
>This DAWG data-structure only has very few, limited use cases.
>It is definitely not a replacement for perl hashes.
Quite right. A DAWGs is merely a set of strings while a hash is a
mapping (from strings to scalar). And thus can also be used to simulate
a string set.
>If you want to use it, fine, but just write it as a perl module,
>perhaps with a C library for speed.
Exactly
jue
------------------------------
Date: Sat, 12 Feb 2011 12:48:34 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnild0d2.13t8.willem@turtle.stack.nl>
J?rgen Exner wrote:
) Would you agree if instead of "dominate" Uri would have used "most
) expensive"? I guess that would have made it clearer.
)
) For the kind of operation we are looking at here the most expensive
) operation is RAM access. And the number of times the algorithm reads
) from RAM for a hash is typically 1 or a small number if the bucket has
) more than one element while for a DAWG or tree it will be one RAM access
) for each character in the word, i.e. total of O(n).
You can't just claim that one RAM access of unlimited size can be counted
as one operation. How long that access takes is still linearly dependent
on the size of the key.
I'm not saying that hashes are not orders of magnitude faster than tries.
What I'm saying is that you can't use complexity theory as a proof of this.
For example, you could (roughly) say the following:
(The numbers are just examples, to make the point)
The time to check if a key of length N is in a hash is 1000 + N.
The time to check if a key of length N is in a trie is 1000 * N.
Now, looking at that, it's obvious that a hash is a lot faster.
But from the viewpoint of complexity theory, 1000 + N = O(N),
and 1000 * N = O(N), so they're both O(N). They have the same
time complexity.
If two algorithms have the same time complexity, you have
to look at other things to determine which will be faster.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sat, 12 Feb 2011 16:15:40 +0100
From: Peter J. Holzer <hjp-usenet2@hjp.at>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <844537681319214326.522087hjp-usenet2-hjp.at@zeno.hjp.at>
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2011-02-11, George Mpouras <nospam.gravitalsun@hotmail.com.nospam> wrote:
>> What we need in these situations is something different called DAWG.
>>
>> Please have a look at this article to understand what I mean.
>>
>> http://en.wikipedia.org/wiki/DAWG
>
> I find this claim
>
> a DAWG is very similar to a trie, but it is much more space efficient
>
> very suspicious. If you want DAWG to be dynamic, then extra "parent"
> pointers you need to keep would, in most situations, far outweight the
> space savings. If DAWG is not intended to change, you do not need
> parent pointers,
I don't think a DAWG is intended to change. Inserts and deletions look
expensive to me. You probably build it once from a collection of words
and then do only lookups.
> but still, I can't imagine many situations in which
> the tail-folding would save much.
The data structure seems to be designed to represent a dictionary of
(English) words. Many words share a common suffix, so would expect
significant space savings compared to a trie. If you use it to store
data without common suffixes it will degenerate into a trie, so it should
never be worse than a trie, IMHO.
hp
------------------------------
Date: Sat, 12 Feb 2011 07:58:05 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <2qadl69ndjca8kign2jkgg1ds2e4n49ucr@4ax.com>
Willem <willem@turtle.stack.nl> wrote:
>J?rgen Exner wrote:
>) Would you agree if instead of "dominate" Uri would have used "most
>) expensive"? I guess that would have made it clearer.
>)
>) For the kind of operation we are looking at here the most expensive
>) operation is RAM access. And the number of times the algorithm reads
>) from RAM for a hash is typically 1 or a small number if the bucket has
>) more than one element while for a DAWG or tree it will be one RAM access
>) for each character in the word, i.e. total of O(n).
>
>You can't just claim that one RAM access of unlimited size can be counted
>as one operation. How long that access takes is still linearly dependent
>on the size of the key.
???
You lost me, with both sentences. Probably I simply don't understand
what you are meaning. But from my understanding
- there is no "unlimited size". In a hash without collisions there is
exactly one retrieval operation which grabs exactly the one single
element that is wanted.
- the time it takes to retrieve this one element is a constant because
it is retrieved by direct access instead of going through a chain of
"check for next letter; retrieve pointer to the rest of the word"
>I'm not saying that hashes are not orders of magnitude faster than tries.
>
>What I'm saying is that you can't use complexity theory as a proof of this.
>
>For example, you could (roughly) say the following:
>(The numbers are just examples, to make the point)
>
>The time to check if a key of length N is in a hash is 1000 + N.
But it isn't. The hash function returns the direct location of where to
find the desired value, therefore the cost is 1000+1.
jue
------------------------------
Date: Sat, 12 Feb 2011 21:03:06 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnildprr.iqc.hjp-usenet2@hrunkner.hjp.at>
On 2011-02-12 15:58, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Willem <willem@turtle.stack.nl> wrote:
>>J?rgen Exner wrote:
>>) Would you agree if instead of "dominate" Uri would have used "most
>>) expensive"? I guess that would have made it clearer.
>>)
>>) For the kind of operation we are looking at here the most expensive
>>) operation is RAM access. And the number of times the algorithm reads
>>) from RAM for a hash is typically 1 or a small number if the bucket has
>>) more than one element while for a DAWG or tree it will be one RAM access
>>) for each character in the word, i.e. total of O(n).
>>
>>You can't just claim that one RAM access of unlimited size can be counted
>>as one operation. How long that access takes is still linearly dependent
>>on the size of the key.
>
> ???
> You lost me, with both sentences. Probably I simply don't understand
> what you are meaning. But from my understanding
> - there is no "unlimited size". In a hash without collisions there is
> exactly one retrieval operation which grabs exactly the one single
> element that is wanted.
A hash in Perl is a mapping from string to scalar. A lookup in a hash
consists of:
1) Compute the hash value of the key.
2) Locate the bucket for the hash value.
3) For each key/value pair in the bucket, perform a string comparison
until the matching key is found.
ad 1) To compute the hash value of a string, you have to retrieve each
byte of the string. So for a key of n bytes length, this step consists
of n memory accesses plus n computation steps, so this step is
O(key_length). (you may be able to optimize this to n/4 or n/8 memory
accesses, but that's a constant factor so it doesn't change Big O).
ad 2) Locating the bucket is typically a single memory access. This
memory access is typically much more expensive than each of the byte
accesses in step 1 (which had a good chance of hitting L1 cache). But
it's a single operation with an upper bound in time, so it's O(1).
ad 3) Each string comparison is O(key_length) for a hit and at most
O(key_length) for a miss (for a good hash function I would expect a
difference in the first few bytes, though). So this is something between
O(key_length) + O(bucket_size) and O(key_length) * O(bucket_size).
In total we now have a complexity between
O(key_length) + O(1) + O(key_length) + O(bucket_size)
= O(key_length) + O(bucket_size)
and
O(key_length) + O(1) + O(key_length) * O(bucket_size)
= O(key_length) * O(bucket_size)
Since the bucket size should be roughly constant, this reduces to
O(key_length).
IMO this is almost completely irrelevant, though. Big O notation is only
useful to determine the behaviour for large values, while hash keys are
typically short.
>>The time to check if a key of length N is in a hash is 1000 + N.
>
> But it isn't. The hash function returns the direct location of where to
> find the desired value, therefore the cost is 1000+1.
The hash function itself is O(key_length).
hp
------------------------------
Date: Sat, 12 Feb 2011 21:23:06 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnildr1a.plv.hjp-usenet2@hrunkner.hjp.at>
On 2011-02-12 20:03, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2011-02-12 15:58, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> Willem <willem@turtle.stack.nl> wrote:
>>>J?rgen Exner wrote:
>>>) Would you agree if instead of "dominate" Uri would have used "most
>>>) expensive"? I guess that would have made it clearer.
>>>)
>>>) For the kind of operation we are looking at here the most expensive
>>>) operation is RAM access. And the number of times the algorithm reads
>>>) from RAM for a hash is typically 1 or a small number if the bucket has
>>>) more than one element while for a DAWG or tree it will be one RAM access
>>>) for each character in the word, i.e. total of O(n).
>>>
>>>You can't just claim that one RAM access of unlimited size can be counted
>>>as one operation. How long that access takes is still linearly dependent
>>>on the size of the key.
>>
>> ???
>> You lost me, with both sentences. Probably I simply don't understand
>> what you are meaning. But from my understanding
>> - there is no "unlimited size". In a hash without collisions there is
>> exactly one retrieval operation which grabs exactly the one single
>> element that is wanted.
>
> A hash in Perl is a mapping from string to scalar. A lookup in a hash
> consists of:
>
> 1) Compute the hash value of the key.
>
> 2) Locate the bucket for the hash value.
>
> 3) For each key/value pair in the bucket, perform a string comparison
> until the matching key is found.
[...]
> this reduces to
>
> O(key_length).
>
>
> IMO this is almost completely irrelevant, though. Big O notation is only
> useful to determine the behaviour for large values, while hash keys are
> typically short.
Maybe not quite so irrelevant. I expected the linear behaviour to show
itself only for keys of at least a few thousand bytes, but I was wrong.
At least on my system, some dependence on key length is noticeable even
for very short key lengths and from about 200 bytes on the run-time is
almost completely linear (i.e. a lookup of a 400 bytes key takes about
twice as long as a lookup of a 200 bytes key).
Here is a short benchmark program:
#!/usr/bin/perl
use warnings;
use strict;
use Time::HiRes qw(time);
my $n1 = 1000;
my $n2 = 1000;
$| = 1;
for (my $len = 10; $len < 1_000_000; $len *= 2) {
print "$len preparing ...";
my @keys = ();
for (1 .. $n1) {
my $k = "";
for (1 .. $len) {
$k .= chr(int(rand(64)) + 32);
}
push @keys, $k;
}
print "\n";
my $t0 = time;
my %hash;
for (1 .. $n2) {
for (@keys) {
$hash{$_}++;
}
}
my $t1 = time;
printf "%d %g\n", $len, ($t1 - $t0);
}
hp
------------------------------
Date: Fri, 11 Feb 2011 15:41:39 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: perl sorting
Message-Id: <k2ug28xk5f.ln2@goaway.wombat.san-francisco.ca.us>
On 2011-02-11, Deepu <pradeep.bg@gmail.com> wrote:
>
> I need some help in sorting a file numerically based on the numbers in
> a specified column.
>
> File contents:
>
> [1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
> [893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
> [893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
>
> I need to get an output in ascending order of the numbers in column2.
>
> Output:
>
> [893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
> [1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
> [893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
You should post a short but complete snippet of your Perl code that is
giving you difficulties.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Fri, 11 Feb 2011 15:44:17 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: perl sorting
Message-Id: <110220111544178899%jimsgibson@gmail.com>
In article
<3297d706-97b5-4d84-97a3-de172dc67189@y36g2000pra.googlegroups.com>,
Deepu <pradeep.bg@gmail.com> wrote:
> Hi All,
>
> I need some help in sorting a file numerically based on the numbers in
> a specified column.
>
> File contents:
>
> [1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
> [893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
> [893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
>
> I need to get an output in ascending order of the numbers in column2.
>
> Output:
>
> [893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
> [1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
> [893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
Have you read the following?:
perldoc -f sort
perldoc -q sort
This is one sort function that should work:
@sorted =sort { (split(/ /,$a))[1] <=> (split(/ /,$b))[1] } @unsorted;
Making that more efficient is left as an exercise (the above performs
the split function more times than is necessary). See the perldoc
references for how.
--
Jim Gibson
------------------------------
Date: Sat, 12 Feb 2011 01:52:47 +0200
From: George Mpouras <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: perl sorting
Message-Id: <ij4i4h$kpj$1@ulysses.noc.ntua.gr>
Στις 12/2/2011 12:15 πμ, ο/η Deepu ÎγÏαψε:
> [1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
> [893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
> [893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
my @i;
while(<DATA>) {/:- (\S+) --/ && push @i, [$1,$_]}
foreach (sort{$a->[0] <=> $b->[0]} @i) { print $_->[1] }
__DATA__
[1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
[893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
[893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
------------------------------
Date: Sat, 12 Feb 2011 15:08:15 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: perl sorting
Message-Id: <slrnildtbs.9g7.tadmc@tadbox.sbcglobal.net>
Deepu <pradeep.bg@gmail.com> wrote:
> I need some help
OK, but you didn't tell us what part you need help with.
> in sorting a file numerically based on the numbers in
> a specified column.
>
> File contents:
>
> [1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
> [893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
> [893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
>
> I need to get an output in ascending order of the numbers in column2.
>
> Output:
>
> [893.234]:- 8.89 -- tempe.tempw -> tempe.tempd
> [1000.123]:- 10.234 -- tempa.tempc -> tempd.tempe
> [893.234]:- 15.75 -- tempc.tempg -> tempt.tempr
Show us the code you have so far, and we will help you fix it.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
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 3284
***************************************
