[32019] in Perl-Users-Digest
Perl-Users Digest, Issue: 3283 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 11 18:09:26 2011
Date: Fri, 11 Feb 2011 15: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 Fri, 11 Feb 2011 Volume: 11 Number: 3283
Today's topics:
data transformation, Perl and MicroSoft <cartercc@gmail.com>
Re: Hashes are good, but not good enough. <willem@turtle.stack.nl>
Re: Hashes are good, but not good enough. <willem@turtle.stack.nl>
Re: Hashes are good, but not good enough. <tzz@lifelogs.com>
Re: Hashes are good, but not good enough. <uri@StemSystems.com>
Re: Hashes are good, but not good enough. <willem@turtle.stack.nl>
Re: Hashes are good, but not good enough. <uri@StemSystems.com>
Re: Hashes are good, but not good enough. <willem@turtle.stack.nl>
Re: Hashes are good, but not good enough. <nospam-abuse@ilyaz.org>
Re: Hashes are good, but not good enough. <nospam-abuse@ilyaz.org>
Re: ParseExcel $font->{Color} Question? <zihav@yahoo.com>
Re: ParseExcel $font->{Color} Question? <jimsgibson@gmail.com>
perl sorting <pradeep.bg@gmail.com>
Re: table --> pre? (hymie!)
Re: table --> pre? <hhr-m@web.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 11 Feb 2011 09:33:31 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: data transformation, Perl and MicroSoft
Message-Id: <ed6e13ea-ce50-4c17-ba5d-d863e4476cdd@o39g2000prb.googlegroups.com>
My apology to those of you who think this post is OT.
Here is an extended quotation from a Microsoft white paper on data
transformation services, or Integration Services in MS SQL 2008. This
really hit me hard -- I'm a database guy who uses Perl extensively to
do my job. SQL Server is a commercial product, which MS sells to
generate revenue. Ordinarily, people buy stuff that they perceive has
value over and above the purchase price. Microsoft obviously wants to
persuade people that SIS adds value, and they may be right, I'm not
going to prejudge SIS, particularly since I don't know anything about
it. I'm wondering how others may respond, hence this post. I will
follow up this post with my response. (I don't want to do it now lest
I poison the well.)
In case you are wondering, this post is directly related to certain
events that have transpired in my workplace in the past couple of
days. I'll leave it to you to guess what those events are.
Here is the article, and yes, I know it violates the terms of use,
according to which you need written permission from Microsoft
Corporation to even discover that the document exists, much less to
read it!
<quote>
Challenges of Data Integration
At one level, the problem of data integration in our real-world
scenario is extraordinarily simple. Get data from multiple sources,
cleanse and transform the data, and load the data into appropriate
data stores for analysis and reporting. Unfortunately, in a typical
data warehouse or business intelligence project, enterprises spend 60=96
80% of the available resources in the data integration stage. Why is
it so difficult?
Technology Challenges
Technology challenges start with source systems. We are moving from
collecting data on transactions (where customers commit to getting,
buying, or otherwise acquiring something) to collecting data on pre-
transactions (where mechanisms such as Web clicks or RFID tags track
customer intentions). Data is now not only acquired via traditional
sources and formats, such as databases and text files, but is
increasingly available in a variety of different formats (ranging from
proprietary files to Microsoft Office documents to XML-based files)
and from Internet-based sources such as Web services and RSS (Really
Simple Syndication) streams.
The most pertinent challenges are:
=95 Multiple sources with different formats.
=95 Structured, semi-structured, and unstructured data.
=95 Data feeds from source systems arriving at different times.
=95 Huge data volumes.
In an ideal world, even if you somehow manage to get all the data we
need in one place, new challenges start to surface, including:
=95 Data quality.
=95 Making sense of different data formats.
=95 Transforming the data into a format that is meaningful to business
analysts.
Suppose that you can magically get all of the data that you need and
that you can cleanse, transform, and map the data into a useful
format. There is still another shift away from traditional data
movement and integration. That is the shift from fixed long batch-
oriented processes to fluid and shorter on-demand processes. Most
organizations perform batch-oriented processes during =93downtimes=94 when
users do not place heavy demands on the system. This is usually at
night during a predefined batch window of 6-8 hours, when no one is
supposed to be in the office. With the increasing globalization of
businesses of every size and type, this is no longer true. There is
very little (if any) downtime and someone is always in the office
somewhere in the world.
As a result you have:
=95 Increasing pressure to load the data as quickly as possible.
=95 The need to load multiple destinations at the same time.
=95 Diverse destinations.
Not only do you need to achieve all of these results, but also you
need to achieve them as fast as possible. In extreme cases, such as
online businesses, you must integrate data on a continuous basis.
There are no real batch windows and latencies cannot exceed minutes.
In many of these scenarios, the decision-making process is automated
with continuously running software.
Scalability and performance become more and more important as you face
business needs that cannot tolerate any downtime.
Without the right technology, systems require staging at almost every
step of the warehousing and integration process. As different
(especially nonstandard) data sources need to be included in the
Extract, Transform, and Load (ETL) process and as more complex
operations (such as data and text mining) need to be performed on the
data, the need to stage the data increases. As illustrated in Figure
1, with increased staging the time taken to =93close the loop,=94 (i.e.,
to analyze, and take action on new data) increases as well. These
traditional ELT architectures (as opposed to value-added ETL processes
that occur prior to loading) impose severe restrictions on the ability
of systems to respond to emerging business needs.
Finally, the question of how data integration ties into the overall
integration architecture of the organization is becoming more
important when you need both the real-time transactional technology of
application integration and the batch-oriented high-volume world of
data integration technology to solve the business problems of the
enterprise.
</quote>
------------------------------
Date: Fri, 11 Feb 2011 11:09:53 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnila681.faa.willem@turtle.stack.nl>
Uri Guttman wrote:
)>>>>> "GM" == George Mpouras <nospam.gravitalsun@hotmail.com.nospam> writes:
) GM> What we need in these situations is something different called DAWG.
) GM> Please have a look at this article to understand what I mean.
) GM> http://en.wikipedia.org/wiki/DAWG
)
) from that article:
)
) for a query operation that tests whether a given string belongs
) to the set in time proportional to its length
)
)
) do you understand O() theory? hashes are close to O(1) while DAWG is
) effectively O(N). not even close.
No, hash lookups on strings are O(N), where N is the length of the string.
This DAWG structure is the same as a trie in complexity. Also O(N).
The only difference is a constant factor, which is quite in favour of
hashes, because calculating a hash is such a simple operation, and can be
unrolled. (Also, in Perl, it's internal, which is a big speed win.)
The problem with DAWG over a trie is that building it is effectively akin
to data compression, especially when it grows large and you have multiple
choices how to proceed.
It's perfect for static dictionaries where you build it once, and then use
it for millions of lookups. Dynamic structures seem nigh impossible.
I think the best way to build this data structure would be to first build a
simple trie, and then run a sort of compressor on it that combines the
redundant suffixen.
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: Fri, 11 Feb 2011 11:14:58 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnila6hi.faa.willem@turtle.stack.nl>
Uri Guttman wrote:
) hashes don't change their speed based on key length.
Excuse me ?
You have to traverse the whole length of the key to calculate the hash.
And after that, to check that you've got the right entry, you have to
compare the search key to the hash key. Again O(N) in key length.
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: Fri, 11 Feb 2011 08:34:55 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <8739nu8ws0.fsf@lifelogs.com>
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. Can you give a
specific case where this is needed?
GM> What we need in these situations is something different called DAWG.
I think that's very debatable. At the very least you should understand
the data and the functional requirements when you deal with non-trivial
data management on a medium-to-large scale. This is what good database
designers will help you accomplish. Here's a sample of the questions I
would ask:
- is access batched, random, or mixed?
- is the data clustered in any way? Can it be partitioned?
- are updates random, append, or both?
- what are the performance requirements for each of the above?
- what's the budget?
- how stable does the environment need to be, e.g. 99.999% uptime
- what's the security model?
- have we done this before? Has this been done before?
etc etc. A different data structure will not help you with most of
these questions. Also, remember that VENDORS AND PROGRAMMERS LIE. They
lie about cost, stability, performance, and support. So suspect anyone
that tells you managing this much data is easy with ANY product,
including Perl.
Ted
------------------------------
Date: Fri, 11 Feb 2011 09:57:20 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <877hd68vqn.fsf@quad.sysarch.com>
>>>>> "W" == Willem <willem@turtle.stack.nl> writes:
W> Uri Guttman wrote:
W> )>>>>> "GM" == George Mpouras <nospam.gravitalsun@hotmail.com.nospam> writes:
W> ) GM> What we need in these situations is something different called DAWG.
W> ) GM> Please have a look at this article to understand what I mean.
W> ) GM> http://en.wikipedia.org/wiki/DAWG
W> )
W> ) from that article:
W> )
W> ) for a query operation that tests whether a given string belongs
W> ) to the set in time proportional to its length
W> )
W> )
W> ) do you understand O() theory? hashes are close to O(1) while DAWG is
W> ) effectively O(N). not even close.
W> No, hash lookups on strings are O(N), where N is the length of the string.
W> This DAWG structure is the same as a trie in complexity. Also O(N).
i would disagree. the hash computation is O(N) on the length of the
string and then you still need a string compare to check that the bucket
hit is correct. but that is a linear scan of a string. the tree designs
have to go node to node for the length of the string. it is a higher
order amount of work which is O(N). so on average a hash lookup will be
close to O(1) with minor differences based on string length. a tree
lookup will be O(N) on string length in all cases. you need to compare
the largest operation to each other, not the string length.
W> The only difference is a constant factor, which is quite in favour of
W> hashes, because calculating a hash is such a simple operation, and can be
W> unrolled. (Also, in Perl, it's internal, which is a big speed win.)
that isn't just a constant factor. the O(N) parts are doing different
amounts of work.
W> The problem with DAWG over a trie is that building it is effectively akin
W> to data compression, especially when it grows large and you have multiple
W> choices how to proceed.
that is another higher level of work that adds more to the tree than
hashing. note that even in hashing you occaisionally need to rebuild the
hash when it gets too filled. that is still accounted for in the close
to O(1) growth (it is a large part of why it isn't exactly O(1).
W> It's perfect for static dictionaries where you build it once, and then use
W> it for millions of lookups. Dynamic structures seem nigh impossible.
W> I think the best way to build this data structure would be to first build a
W> simple trie, and then run a sort of compressor on it that combines the
W> redundant suffixen.
either way, the OP can't code it nor can he compare the growth of either
algorithm.
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: Fri, 11 Feb 2011 15:20:50 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnilakui.j6h.willem@turtle.stack.nl>
Uri Guttman wrote:
)>>>>> "W" == Willem <willem@turtle.stack.nl> writes:
) W> No, hash lookups on strings are O(N), where N is the length of the string.
) W> This DAWG structure is the same as a trie in complexity. Also O(N).
)
) i would disagree. the hash computation is O(N) on the length of the
) string and then you still need a string compare to check that the bucket
) hit is correct. but that is a linear scan of a string. the tree designs
) have to go node to node for the length of the string. it is a higher
) order amount of work which is O(N). so on average a hash lookup will be
) close to O(1) with minor differences based on string length. a tree
) lookup will be O(N) on string length in all cases. you need to compare
) the largest operation to each other, not the string length.
You should read up on big-oh notation. You certainly cannot sweep an O(N)
operation under the carpet and claim that something is O(1), because the
O(N) bit is blazingly fast. The whole basis of big-oh is that O(f(x)) is
*always* based on the largest *growing* factor of f(x), and that any
constant factors are irrelevant to the big-oh.
To restate: hashes and tries have the same big-oh time complexity for key
lookups, but the constant factor probably differs by a few orders of magnitude.
) W> The only difference is a constant factor, which is quite in favour of
) W> hashes, because calculating a hash is such a simple operation, and can be
) W> unrolled. (Also, in Perl, it's internal, which is a big speed win.)
)
) that isn't just a constant factor. the O(N) parts are doing different
) amounts of work.
I don't follow. The amount of work done for a single character, when
comparing the string to the key in a hash, is constant. The amount of
work done for a single character, when following nodes in a tree, is
also constant. Since they are both constant, the difference is a constant
factor.
) W> The problem with DAWG over a trie is that building it is effectively akin
) W> to data compression, especially when it grows large and you have multiple
) W> choices how to proceed.
)
) that is another higher level of work that adds more to the tree than
) hashing. note that even in hashing you occaisionally need to rebuild the
) hash when it gets too filled. that is still accounted for in the close
) to O(1) growth (it is a large part of why it isn't exactly O(1).
This part of my reply had nothing to do with the time complexity.
The DAWG structure is effectively ROM. You build it once, at quite
a high cost, and then you get very fast lookups with relatively small
space usage.
) W> It's perfect for static dictionaries where you build it once, and then use
) W> it for millions of lookups. Dynamic structures seem nigh impossible.
)
) W> I think the best way to build this data structure would be to first build a
) W> simple trie, and then run a sort of compressor on it that combines the
) W> redundant suffixen.
)
) either way, the OP can't code it nor can he compare the growth of either
) algorithm.
I think what the OP especially missed is the time complexity of inserting
keys, as opposed to a trie. As a side note, it is also impossible to
store data along with the keys, because the uniqueness of the end nodes
is lost.
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: Fri, 11 Feb 2011 12:14:32 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <87ipwq7atj.fsf@quad.sysarch.com>
>>>>> "W" == Willem <willem@turtle.stack.nl> writes:
W> Uri Guttman wrote:
W> )>>>>> "W" == Willem <willem@turtle.stack.nl> writes:
W> ) W> No, hash lookups on strings are O(N), where N is the length of the string.
W> ) W> This DAWG structure is the same as a trie in complexity. Also O(N).
W> )
W> ) i would disagree. the hash computation is O(N) on the length of the
W> ) string and then you still need a string compare to check that the bucket
W> ) hit is correct. but that is a linear scan of a string. the tree designs
W> ) have to go node to node for the length of the string. it is a higher
W> ) order amount of work which is O(N). so on average a hash lookup will be
W> ) close to O(1) with minor differences based on string length. a tree
W> ) lookup will be O(N) on string length in all cases. you need to compare
W> ) the largest operation to each other, not the string length.
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.
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).
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: Fri, 11 Feb 2011 18:14:12 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnilav3k.lmi.willem@turtle.stack.nl>
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.
Also, a trie is very different from a tree in this respect. log N
doesn't even enter into the picture.
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: Fri, 11 Feb 2011 22:20:35 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnilbdhj.tob.nospam-abuse@powdermilk.math.berkeley.edu>
On 2011-02-11, Ted Zlatanov <tzz@lifelogs.com> 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.
???!!! How comes? If what I need is a hash-like semantic, and I need
"hundreds of millions of keys", why would not I use hash? I never
programmed in this "any language", so you can reduce your arguments to
Perl. Again, to be specific, assume that this particular process has
ulimit of 100GB heap, and other processes do not use much memory, so
there won't be any swapping...
Ilya
PS [I skip the rest, which is very on-point...]
------------------------------
Date: Fri, 11 Feb 2011 22:29:09 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Hashes are good, but not good enough.
Message-Id: <slrnilbe1l.tob.nospam-abuse@powdermilk.math.berkeley.edu>
On 2011-02-11, 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 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, but still, I can't imagine many situations in which
the tail-folding would save much.
Are you sure that your set of keys is so special?
Ilya
------------------------------
Date: Fri, 11 Feb 2011 04:44:33 -0800 (PST)
From: Tom <zihav@yahoo.com>
Subject: Re: ParseExcel $font->{Color} Question?
Message-Id: <82f548fb-a2a0-4bde-8525-7a27d829e167@glegroupsg2000goo.googlegroups.com>
Hi,
Thanks! That was it, I can now get the color and I'm using:
$RGB = $parser->ColorIdxToRGB($format->{Font}{Color});
to convert that to the hex color number, I then found this page
which maps hex numbers to the name of the color:
http://www.yellowpipe.com/yis/tools/hex-to-rgb/color-converter.php
I'm going to see if there is a CPAN module for that as well. Thanks
for all the help!
Tom
------------------------------
Date: Fri, 11 Feb 2011 10:15:20 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: ParseExcel $font->{Color} Question?
Message-Id: <110220111015208701%jimsgibson@gmail.com>
In article
<82f548fb-a2a0-4bde-8525-7a27d829e167@glegroupsg2000goo.googlegroups.com>
, Tom <zihav@yahoo.com> wrote:
> Thanks! That was it, I can now get the color and I'm using:
>
> $RGB = $parser->ColorIdxToRGB($format->{Font}{Color});
>
> to convert that to the hex color number, I then found this page
> which maps hex numbers to the name of the color:
>
> http://www.yellowpipe.com/yis/tools/hex-to-rgb/color-converter.php
>
> I'm going to see if there is a CPAN module for that as well.
A little googling reveals the Graphics::ColorNames module and its
offspring:
<http://search.cpan.org/dist/Graphics-ColorNames/>
--
Jim Gibson
------------------------------
Date: Fri, 11 Feb 2011 14:15:01 -0800 (PST)
From: Deepu <pradeep.bg@gmail.com>
Subject: perl sorting
Message-Id: <3297d706-97b5-4d84-97a3-de172dc67189@y36g2000pra.googlegroups.com>
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
Thanks..
------------------------------
Date: 11 Feb 2011 14:36:47 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: Re: table --> pre?
Message-Id: <4d55497f$0$13638$882e7ee2@usenet-news.net>
In our last episode, the evil Dr. Lacto had captured our hero,
Mart van de Wege <mvdwege@mail.com>, who said:
>hymie@lactose.homelinux.net (hymie!) writes:
>
>> Greetings.
>>
>> Can somebody recommend to me a perl script or a perl module that
>> takes an HTML-formatted <table> and produces a space-formatted
>> output that would be suitable for use within a <pre> tag?
>>
>I use Text::FormatTable to create those kind of text-only formatted
>tables.
Thanks for the tip. It would be nice if this could manage colspans,
but I think this is the way I'm going to end up going.
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
------------------------------
Date: Fri, 11 Feb 2011 17:06:00 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: Re: table --> pre?
Message-Id: <Pine.LNX.4.64.1102111704090.4589@lxhri01.ws.lrz.de>
On Fri, 11 Feb 2011, hymie! wrote:
> Thanks for the tip. It would be nice if this could manage colspans,
> but I think this is the way I'm going to end up going.
Of the ready-for-use tools (not exactly what you were asking), w3m seems
the one that does the job best to convert text/html to text/plain.
--
Helmut Richter
------------------------------
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 3283
***************************************
