[31819] in Perl-Users-Digest
Perl-Users Digest, Issue: 3082 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 17 14:14:21 2010
Date: Tue, 17 Aug 2010 11:14: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, 17 Aug 2010 Volume: 11 Number: 3082
Today's topics:
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <tzz@lifelogs.com>
Re: combining hashes (Randal L. Schwartz)
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <tadmc@seesig.invalid>
Re: combining hashes <jurgenex@hotmail.com>
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <jurgenex@hotmail.com>
Re: combining hashes <tadmc@seesig.invalid>
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <tadmc@seesig.invalid>
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <hjp-usenet2@hjp.at>
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <ben@morrow.me.uk>
Re: combining hashes <kst-u@mib.org>
Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest <tzz@lifelogs.com>
Warning message: Can't spawn ... No error <dilbert1999@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 17 Aug 2010 06:37:31 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <09f1e120-ecc8-412f-a960-eb25d03c0edf@l6g2000yqb.googlegroups.com>
On Aug 16, 6:31=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> you have a strange definition of order. what you say is an association
> (hashes used to be called associative arrays), not an ordering. ordering
> ALWAYS implies sequence. hashes have no inherent sequence. you can't
> have order and also string access at one time without a complex
> structure (btree, etc.). strings can't directly index into an array
> without converting them to an integer and that is what a hash does
> internally. arrays are ALWAYS ordered regardless of how you look at the
> data. this is a clear cut definition of hashes and arrays. you keep
> looking at the data but the access method or slots are what is important
> here. the data is just baggage added to the slot. it could be anything
> and nothing but the order/non-order remains the same.
We have more than one view of data, in this discussion we have at
least the programmer's view and the end user's view.
I agree fully with Tad that, in the programmer's view, arrays are
'ordered' and hashes are 'unordered'. My comment was wrong, and I
stand corrected. I don't make any excuse or want to be argumentative
about this, but I do want to at least explain the other view.
I have a job, which I go to every work day and at which I labor all
day. My job mostly requires reporting of data, and to be useful, the
data must be in some order. Many time, this ordering is multi-leveled.
For example, an accountant might want to see a listing ordered by past
dues, balance size, zip code, frequency of purchases, or any number of
other things, and might want to see a listing sorted first by zip
code, secondly by aging, third by balance size, and finally by the
customer's last, first, and middle names.
I use hashes almost exclusively, because I can stuff a hash element
with many types of data, e.g., name, balance, date of last payment,
address, and so on. Then, it's no trick to order the data however I
want, by the particular hash element or combination thereof.
I very rarely use arrays, and then only when the order is entirely
irrelevant. Most of the time, I use an array ref as a hash element
where I just need some kind of list that won't be further sorted or
filtered. For example, if I were to list items in a purchase order for
a customer account, I might list the items in am array as the ORDER of
the items doesn't matter, like this:
push @{$customers{$customer{$order}{items}}}, $item;
To be real clear, specific, and unambiguous, when I'm working on a
report and the items need to be ordered in some kind of way, I think
'hash.' When the order of the items doesn't matter and all I need is
some kind of list, I think 'array.'
Yeah, I was wrong when I said that hashes were an ordered data
structure and that arrays were an unordered data structure, and I
acknowledge the error. But I was speaking as an end user, not as a
programmer, so my error (hopefully) can be seen as what it really is
-- speaking as a user rather than as a programmer.
> not my point. you really have backwards understanding of the word order.
I see why you say this, and I won't quibble.
> and doing listifying of hashes for assignment is much faster than any
> looped version. but with a looped version you can do finer grained
> control over which hash's values will be used in merged.
In my example of an account list, it's difficult for me to see how you
could get the same result with an array as you could with a hash. You
can go directly to a hash element with $customers{'CUST-1234'}
{'ORD-5678'}{'items'}, but you would have to iterate through an array
to find the element.
CC.
------------------------------
Date: Tue, 17 Aug 2010 08:59:52 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: combining hashes
Message-Id: <87r5hxuyp3.fsf@lifelogs.com>
On Mon, 16 Aug 2010 15:53:59 -0400 monkeys paw <monkey@joemoney.net> wrote:
mp> I have two hashrefs, i want to combine them into one hash.
mp> I think there is an easier way than what i am doing (shown below):
mp> $fc = {'a' => 'hash'};
mp> $ref = {'another' => 'hash'};
mp> for (keys %{$fc}) {
mp> $args{$_} = $fc->{$_};
mp> }
mp> for (keys %{$ref}) {
mp> $args{$_} = $ref->{$_};
mp> }
use Hash::Merge qw( merge );
my %c = %{ merge( \%fc, \%ref ) };
You can specify the behavior for conflicting keys in GREAT detail. It's
a wonderful module.
Ted
------------------------------
Date: Tue, 17 Aug 2010 06:54:19 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: combining hashes
Message-Id: <86k4npfipg.fsf@red.stonehenge.com>
>>>>> "ccc31807" == ccc31807 <cartercc@gmail.com> writes:
ccc31807> Yeah, I was wrong when I said that hashes were an ordered data
ccc31807> structure and that arrays were an unordered data structure, and I
ccc31807> acknowledge the error. But I was speaking as an end user, not as a
ccc31807> programmer, so my error (hopefully) can be seen as what it really is
ccc31807> -- speaking as a user rather than as a programmer.
This isn't even right speaking as "a user" though. Unless you make up
completely unusual meanings for "ordered". Which at that point, you
have no intention of communication, since you're not interested in
recreating for me the state of the universe that you live in. End of
game.
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Tue, 17 Aug 2010 16:28:28 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6l74e.aiv.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-17 03:03, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Keith Thompson <kst-u@mib.org>:
>> ccc31807 <cartercc@gmail.com> writes:
>> [...]
>> > Let me recast my statement: the keys of a hash are ordered in the
>> > sense that the value of the key correlates to the content of the hash,
>> > while the indices of an array are ordered but the values contained in
>> > the array are not necessarily ordered, although they certain can be.
>>
>> I decided to look up the technical meaning of "ordered". foldoc.org
>> seems like a likely place to find a good definition. Here's what I
>> found:
>>
>> <http://foldoc.org/ordering>
>> An "ordering" is defined as a "relation".
>
> That definition is woefully incomplete. For a relation to be
> meaningfully called an order, it must be
>
> - from a set A to itself
> - transitive (that is, x * y and y * z => x * z forall x,y,z in A)
- antisymmetric: x * y and y * x => x = y
- reflective: x * x for all x
- total (for total orders only): x * y or y * x for all x, y
> (I'm fairly sure I was taught that a relation was always on AxA, but
> mathematics being what it is different people use different
> definitions.)
That's a pretty restrictive definition. It fits the "relational
operators" ==, <, >, etc. but normally a relation is defined more
generally:
Suppose you have a number of sets S_1 ... S_n.
Then a relation R on S_1 x ... x S_n is a set of ordered tupels
(e_1, ..., e_n) where e_1 ∈ S_1, ... e_n ∈ S_n.
All the sets can be different and there is no limit on the number of
sets.
This kind of relation is what the "relational" in "relational databases"
is about. Each relation is a set of tupels, or, in other words, a table
(relational databases only handle finite sets). And since the "ordering"
in a database has already been mentioned, I'd like to point out that the
tupels in a relation have no natural order, and if you use SQL you need
to explicitely specify "order by" if you want a specific order.
>> > And yes, I know that the order of the items in an array do not change
>> > because they are tied to the numerical order of the index, while the
>> > output order of a hash is nondeterministic.
>>
>> And the "output order" of a hash is not necessarily related to any
>> ordering property of the hash itself; it could even be literally
>> random.
>
> As Xho pointed out, it is at worst deterministic: if you don't modify
> the hash, the order will not change between successive calls to keys,
> values or each.
Yep. For every hash there is an order of the keys. However, "the hash"
is extremely ephemeral here. If you create a second hash with the same
contents, the order may be different. If you add an element and delete
it again, the order may be different ... So there is no general order
on the set of hash keys.
hp
------------------------------
Date: Tue, 17 Aug 2010 09:45:57 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: combining hashes
Message-Id: <slrni6l7tu.opj.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> You
> can go directly to a hash element with $customers{'CUST-1234'}
> {'ORD-5678'}{'items'}, but you would have to iterate through an array
> to find the element.
... unless you had some sort of function that would calculate
what array index the data is located at.
http://en.wikipedia.org/wiki/Hash_function
Hash data structures are often implemented on top of an array,
with a "hash function" that calculates the needed index.
http://en.wikipedia.org/wiki/Hash_table
In short, you have developed the rationale for implementing
a hash data structure!
Here is a hash implemented in Perl with a horrid hash function and
no handling of collisions. As long as no two keys start with the
same character, it works as a hash is expected to work though.
-----------------------------
#!/usr/bin/perl
use warnings;
use strict;
store('adam', '12');
store('benny', 'hill');
store('charlies', 'angels');
print "the value associated with benny is: ", fetch('benny'), "\n";
print "the value associated with charlies is: ", fetch('charlies'), "\n";
print "the value associated with adam is: ", fetch('adam'), "\n";
{
my @hash;
sub store {
my($key, $value) = @_;
$hash[ord substr($key, 0, 1)] = $value;
}
sub fetch {
my($key) = @_;
return $hash[ord substr($key, 0, 1)];
}
}
-----------------------------
--
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: Tue, 17 Aug 2010 07:48:28 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: combining hashes
Message-Id: <dh7l66pvtnt4rsinns6o2ro12f699j1f1a@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
[...]
>To be real clear, specific, and unambiguous, when I'm working on a
>report and the items need to be ordered in some kind of way, I think
>'hash.' When the order of the items doesn't matter and all I need is
>some kind of list, I think 'array.'
This paragraph and the rest of what you wrote makes perfect sense if you
swap 'array' and 'hash'.
>In my example of an account list, it's difficult for me to see how you
>could get the same result with an array as you could with a hash. You
>can go directly to a hash element with $customers{'CUST-1234'}
>{'ORD-5678'}{'items'}, but you would have to iterate through an array
>to find the element.
A: The fact that you can access your desired hash element directly has
ABSOLUTELY NOTHING to do with ordering. It is due to the fact that a
hash is a (partial) mapping from string to scalar while an array is
restricted to mapping only integers to scalars.
B: There are many smarter ways to find an item in an array than
iteration, beginning with simple bisection (if the elements are
ordered!!!) up to implementing your own hash index function.
jue
------------------------------
Date: Tue, 17 Aug 2010 07:49:14 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <9e324787-ac07-4098-ad80-e66ca28cbb53@y11g2000yqm.googlegroups.com>
On Aug 17, 9:54=A0am, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> ccc31807> Yeah, I was wrong when I said that hashes were an ordered data
> ccc31807> structure and that arrays were an unordered data structure, and=
I
> ccc31807> acknowledge the error. But I was speaking as an end user, not a=
s a
> ccc31807> programmer, so my error (hopefully) can be seen as what it real=
ly is
> ccc31807> -- speaking as a user rather than as a programmer.
>
> This isn't even right speaking as "a user" though. =A0Unless you make up
> completely unusual meanings for "ordered". =A0Which at that point, you
> have no intention of communication, since you're not interested in
> recreating for me the state of the universe that you live in. End of
> game.
So what do you do when your customer specifies a report 'in order' by
last, first, middle name, or by GPA and major, or inversely by last
payment date and account balance? Tell him that he doesn't know know
what 'order' means and that if he can't communicate properly he can't
get his report?
Emerson is quoted as saying that a foolish consistency is the
hobgoblin of small minds. Judging by what some have posted here, I'm
beginning to question mind size.
I took the hit for speaking in error. I've also tried to be as clear
as I could about the purpose of using specific data structures. In the
universe where I live, I have to translate user specifications into
program code. Sometimes I get confused. Sometimes my users get
confused. Confusion isn't the end of the game, but actually the
beginning of the game.
CC.
------------------------------
Date: Tue, 17 Aug 2010 16:51:24 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6l8ff.aiv.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-17 13:37, ccc31807 <cartercc@gmail.com> wrote:
> On Aug 16, 6:31 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>> you have a strange definition of order. what you say is an association
>> (hashes used to be called associative arrays), not an ordering. ordering
>> ALWAYS implies sequence. hashes have no inherent sequence. you can't
>> have order and also string access at one time without a complex
>> structure (btree, etc.). strings can't directly index into an array
>> without converting them to an integer and that is what a hash does
>> internally. arrays are ALWAYS ordered regardless of how you look at the
>> data. this is a clear cut definition of hashes and arrays. you keep
>> looking at the data but the access method or slots are what is important
>> here. the data is just baggage added to the slot. it could be anything
>> and nothing but the order/non-order remains the same.
>
> We have more than one view of data, in this discussion we have at
> least the programmer's view and the end user's view.
End users know nothing about hashes and arrays. I don't see where end
users come into this.
> I use hashes almost exclusively, because I can stuff a hash element
> with many types of data, e.g., name, balance, date of last payment,
> address, and so on.
You not only seem to use the word "order" in a strange way, but also the
word "stuff". As far as I can see, I can stuff exactly the same type of
data into a hash element as into an array element: Any kind of scalar.
I can *access* them differently: With a string in one case, with a
non-negative integer in the other.
> Then, it's no trick to order the data however I
> want, by the particular hash element or combination thereof.
But you have to *explicitly* order/sort the output. The hash itself has
no (useful) order.
> To be real clear, specific, and unambiguous, when I'm working on a
> report and the items need to be ordered in some kind of way, I think
> 'hash.' When the order of the items doesn't matter and all I need is
> some kind of list, I think 'array.'
You shouldn't do this. Think "how do I need to access the elements?". If
you need to access them either in sequence (in *order*!) or by a numeric
key, think array. If you need to access them by a string key, think
hash.
hp
------------------------------
Date: Tue, 17 Aug 2010 08:00:07 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: combining hashes
Message-Id: <0n8l6690hscsaukqcg8e64of1m6ctan093@4ax.com>
ccc31807 <cartercc@gmail.com> wrote:
>In my example of an account list, it's difficult for me to see how you
>could get the same result with an array as you could with a hash. You
>can go directly to a hash element with $customers{'CUST-1234'}
>{'ORD-5678'}{'items'}, but you would have to iterate through an array
>to find the element.
If items are ordered, then by definition of ordered there is always
(except for the first and last item) a predecessor and a successor of
this element.
Please tell us, how do you access the successor of
$customers{'CUST-1234'}{'ORD-5678'}{'items'},
I can tell you how to do that for arrays: you just add 1 to the index,
e.g.
$foo[4][321][987+1]
Now it's your turn to demonstrate how to get the successor of a given
hash element.
jue
------------------------------
Date: Tue, 17 Aug 2010 10:05:53 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: combining hashes
Message-Id: <slrni6l939.otv.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> On Aug 17, 9:54Â am, mer...@stonehenge.com (Randal L. Schwartz) wrote:
>> ccc31807> Yeah, I was wrong when I said that hashes were an ordered data
>> ccc31807> structure and that arrays were an unordered data structure, and I
>> ccc31807> acknowledge the error. But I was speaking as an end user, not as a
>> ccc31807> programmer, so my error (hopefully) can be seen as what it really is
>> ccc31807> -- speaking as a user rather than as a programmer.
>>
>> This isn't even right speaking as "a user" though. Â Unless you make up
>> completely unusual meanings for "ordered". Â Which at that point, you
>> have no intention of communication, since you're not interested in
>> recreating for me the state of the universe that you live in. End of
>> game.
>
> So what do you do when your customer specifies a report 'in order' by
> last, first, middle name, or by GPA and major, or inversely by last
> payment date and account balance?
Imposing a particular ordering is known as "sorting".
So, you sort your data into the order specified by your customer.
--
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: Tue, 17 Aug 2010 08:40:00 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <f4fe6d7a-300f-4b71-8004-77eb54f3d7bc@l14g2000yql.googlegroups.com>
On Aug 17, 11:05=A0am, Tad McClellan <ta...@seesig.invalid> wrote:
> Imposing a particular ordering is known as "sorting".
> So, you sort your data into the order specified by your customer.
This is absolutely, one hundred percent correct.
However, my users still specify their reports in some order. To do
this, I use sort().
However, I still ordinarily think 'hash' when the instruction is 'in
order' and think 'array' when it doesn't matter and all I need is
something to hold a list.
Thanks, CC.
------------------------------
Date: Tue, 17 Aug 2010 11:25:34 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: combining hashes
Message-Id: <slrni6ldom.p5a.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
>
> However, I still ordinarily think 'hash' when the instruction is 'in
> order' and think 'array' when it doesn't matter and all I need is
> something to hold a list.
However, you still have an inversion in your thinking!
--
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: Tue, 17 Aug 2010 12:59:13 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87wrrpw4ym.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Aug 17, 11:05 am, Tad McClellan <ta...@seesig.invalid> wrote:
>> Imposing a particular ordering is known as "sorting".
>> So, you sort your data into the order specified by your customer.
c> This is absolutely, one hundred percent correct.
c> However, my users still specify their reports in some order. To do
c> this, I use sort().
c> However, I still ordinarily think 'hash' when the instruction is 'in
c> order' and think 'array' when it doesn't matter and all I need is
c> something to hold a list.
you can sort arrays and sort arrays of hashes. you can't sort a
hash. you can output fields of a hash in a particular order but that is
not ordering as the elements are all different (hash keys are
unique). printing last, first, address, city, zip is NOT ordering, just
printing fields as requested. it is formatting output. ordering is when
you have lots of similar entries and you sort them or loop over them for
a reason (queues, fifos, etc.). you keep thinking order when you really
think access. it isn't the same. just because most of your data is
effectively lists of hashes (records in your world), doesn't make your
view correct. the word order is for arrays, not hashes. or ordering a
list of hashes by sorting them. you can only order an array or list.
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: Tue, 17 Aug 2010 19:09:12 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: combining hashes
Message-Id: <slrni6lghq.c0b.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-17 14:49, ccc31807 <cartercc@gmail.com> wrote:
> On Aug 17, 9:54 am, mer...@stonehenge.com (Randal L. Schwartz) wrote:
>> ccc31807> Yeah, I was wrong when I said that hashes were an ordered data
>> ccc31807> structure and that arrays were an unordered data structure, and I
>> ccc31807> acknowledge the error. But I was speaking as an end user, not as a
>> ccc31807> programmer, so my error (hopefully) can be seen as what it really is
>> ccc31807> -- speaking as a user rather than as a programmer.
>>
>> This isn't even right speaking as "a user" though. Unless you make up
>> completely unusual meanings for "ordered". Which at that point, you
>> have no intention of communication, since you're not interested in
>> recreating for me the state of the universe that you live in. End of
>> game.
>
> So what do you do when your customer specifies a report 'in order' by
> last, first, middle name, or by GPA and major, or inversely by last
> payment date and account balance? Tell him that he doesn't know know
> what 'order' means and that if he can't communicate properly he can't
> get his report?
Your users appear to know exactly what "order" means. All the examples
you've mentioned are orders.
hp
------------------------------
Date: Tue, 17 Aug 2010 10:17:01 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <ca7689cf-fa89-400d-9d40-468b26681be8@v8g2000yqe.googlegroups.com>
On Aug 17, 10:51=A0am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> End users know nothing about hashes and arrays. I don't see where end
> users come into this.
End users know how they want their data. If it weren't for the end
users, I wouldn't have a job, and (probably) neither would you. The
reason we do what we do is for end users.
> You not only seem to use the word "order" in a strange way, but also the
> word "stuff". As far as I can see, I can stuff exactly the same type of
> data into a hash element as into an array element: Any kind of scalar.
> I can *access* them differently: With a string in one case, with a
> non-negative integer in the other.
Yes, you can stuff whatever you want into an array element. To me,
this is the first or second most useful feature of Perl, the fact that
it's easy to build and use data structures suited to the shape of your
data.
As for using 'order' in a strange way, what about this (albeit in
another language):
select first, middle, last, address, city, state, zip, balance
from customer order by zip;
Database tables aren't intrinsically ordered, but the use of the word
'order' has a specific meaning in SQL that creates a particular order
for the results.
> But you have to *explicitly* order/sort the output. The hash itself has
> no (useful) order.
Looking back on what I originally wrote, this is what I said -- you
can't use a common key to combine the values in two different hashes
unless you 'order' the key in the second hash by the key in the first
hash. The little code snippet I posted shows this explicitly.
> > To be real clear, specific, and unambiguous, when I'm working on a
> > report and the items need to be ordered in some kind of way, I think
> > 'hash.' When the order of the items doesn't matter and all I need is
> > some kind of list, I think 'array.'
>
> You shouldn't do this. Think "how do I need to access the elements?". If
> you need to access them either in sequence (in *order*!) or by a numeric
> key, think array. If you need to access them by a string key, think
> hash.
The sequence of an array isn't usually the way you want the items,
excepting inherently numeric items like DOW or MOY. In a hash, you
sort like this a lot:
$hash{$a}{last} cmp $hash{$b}{last} ||
$hash{$a}{first} cmp $hash{$b}{first} ||
$hash{$a}{middle} cmp $hash{$b}{middle} ||
$hash{$a}{suffix} cmp $hash{$b}{suffix}
You can tell me that a list of names by last, first, middle, and
suffix isn't an ordered list, but I don't have to believe you. The
underlying DATA may be unordered as the natively in a hash, but the
INFORMATION is certainly ordered, and there's a big difference between
DATA and INFORMATION.
CC.
------------------------------
Date: Tue, 17 Aug 2010 18:24:07 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: combining hashes
Message-Id: <n6tqj7-heu2.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2010-08-17 03:03, Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > Quoth Keith Thompson <kst-u@mib.org>:
> >> ccc31807 <cartercc@gmail.com> writes:
> >> [...]
> >> > Let me recast my statement: the keys of a hash are ordered in the
> >> > sense that the value of the key correlates to the content of the hash,
> >> > while the indices of an array are ordered but the values contained in
> >> > the array are not necessarily ordered, although they certain can be.
> >>
> >> I decided to look up the technical meaning of "ordered". foldoc.org
> >> seems like a likely place to find a good definition. Here's what I
> >> found:
> >>
> >> <http://foldoc.org/ordering>
> >> An "ordering" is defined as a "relation".
> >
> > That definition is woefully incomplete. For a relation to be
> > meaningfully called an order, it must be
> >
> > - from a set A to itself
> > - transitive (that is, x * y and y * z => x * z forall x,y,z in A)
> - antisymmetric: x * y and y * x => x = y
Yes.
> - reflective: x * x for all x
Or anti-reflexive. < is a strict total order on the integers, and it
certainly isn't reflexive.
> - total (for total orders only): x * y or y * x for all x, y
'A total order must be total'. Well, duh :).
> > (I'm fairly sure I was taught that a relation was always on AxA, but
> > mathematics being what it is different people use different
> > definitions.)
>
> That's a pretty restrictive definition. It fits the "relational
> operators" ==, <, >, etc. but normally a relation is defined more
> generally:
Well, this was undergraduate mathematics, so that's likely.
> Suppose you have a number of sets S_1 ... S_n.
> Then a relation R on S_1 x ... x S_n is a set of ordered tupels
> (e_1, ..., e_n) where e_1 ∈ S_1, ... e_n ∈ S_n.
>
> All the sets can be different and there is no limit on the number of
> sets.
>
> This kind of relation is what the "relational" in "relational databases"
> is about. Each relation is a set of tupels, or, in other words, a table
> (relational databases only handle finite sets). And since the "ordering"
> in a database has already been mentioned, I'd like to point out that the
> tupels in a relation have no natural order, and if you use SQL you need
> to explicitely specify "order by" if you want a specific order.
Yes, of course. I knew that really :).
> >> > And yes, I know that the order of the items in an array do not change
> >> > because they are tied to the numerical order of the index, while the
> >> > output order of a hash is nondeterministic.
> >>
> >> And the "output order" of a hash is not necessarily related to any
> >> ordering property of the hash itself; it could even be literally
> >> random.
> >
> > As Xho pointed out, it is at worst deterministic: if you don't modify
> > the hash, the order will not change between successive calls to keys,
> > values or each.
>
> Yep. For every hash there is an order of the keys. However, "the hash"
> is extremely ephemeral here. If you create a second hash with the same
> contents, the order may be different. If you add an element and delete
> it again, the order may be different ... So there is no general order
> on the set of hash keys.
I think that if you insert the same keys in the same order and you don't
hit the anti-DoS randomisation logic you will get the same key order at
the end... but 'order of insertion' is not a property preserved by a
(normal Perl) hash, so that's somewhat cheating.
Ben
------------------------------
Date: Tue, 17 Aug 2010 10:50:10 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: combining hashes
Message-Id: <lnsk2druwd.fsf@nuthaus.mib.org>
"Uri Guttman" <uri@StemSystems.com> writes:
>>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
>
> KT> "Uri Guttman" <uri@StemSystems.com> writes:
> >>>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
> >>
> KT> "Uri Guttman" <uri@StemSystems.com> writes:
> >>
> >> please don't tell me how to do searching in c. i was doing that in PL/I
> >> before your parents were born! :) i was comparing how close to the metal
> >> c's arrays are vs all string lookups.
>
> KT> Then don't tell me that "to get access to an element keyed by
> KT> a string your first pass was a sequential scan and looking at
> KT> each key". It's not necessarily true. (Oh, and PL/I didn't exist
> KT> before *I* was born, much less my parents.)
>
> first pass means first attempt by early coders. sequential scan is a
> simple algorithm which anyone can implements. and for short lists,
> likely a speedy one too. and were you born before 1967 or so? :)
Ok, I didn't understand what you meant by "first pass"; I assumed you
were referring to the first pass of an algorithm. All is clear now.
PL/I came out in 1964; it and I are both still alive.
[...]
> KT> You make a valid point, but your apparent claim that C only
> KT> supports linear searches obscures it. C supports a wide variety
> KT> of data structures (though often less directly than Perl does),
> KT> not just arrays.
>
> no, i never implied that. i said c lets you get to the metal with arrays
> and all other index/search method require lots more cpu. that is all i
> was saying. i was trying to ccc explain the reasons hashes exist as you
> can't do fast key searches without that algorithm.
Agreed, mostly. There are certainly other algorithms that let you
do reasonably fast key searches; binary trees can be quite fast if
the data structure isn't too big and is reasonably well balanced.
And of course any such algorithm can be implemented in C (with
some effort).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Tue, 17 Aug 2010 09:08:20 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: FAQ 5.23 AND: Perl the latest vs Perl the gratest
Message-Id: <87mxsluyaz.fsf@lifelogs.com>
On Fri, 13 Aug 2010 21:11:33 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
IZ> When I write reusable code, I'm interested in balancing "the lowest common
IZ> denominator" vs "annoyance factor with coding to rare flavors of Perl".
IZ> I'd be more interested in consulting FAQ (and other docs) when I
IZ> operate in the second ("reusable") mode. So I'm much more interested
IZ> in FAQ focusing on the "current pool" of deployed Perl than it
IZ> focussing on the latest version.
You want the FAQ to be a textbook/cookbook; I want it to reflect what's
current. Your viewpoint is valid and well-addressed by about 50 books
in the marketplace. I don't see why the FAQ should be another. There
just aren't that many places to find out "what's the best way to do X
with the latest Perl."
Ted
------------------------------
Date: Tue, 17 Aug 2010 10:39:18 -0700 (PDT)
From: Dilbert <dilbert1999@gmail.com>
Subject: Warning message: Can't spawn ... No error
Message-Id: <24030906-c03d-438c-89d4-5b36d3e3cd6c@l6g2000yqb.googlegroups.com>
I have the following perl program to test return codes (I am running
Strawberry Perl 5.12 under Windows Vista 64 bits):
===============
use 5.012;
use warnings;
say 'Start';
system qq{perl -e"exit -1"};
say 'Stop';
===============
Here is the output:
===============
Start
Can't spawn "perl -e"exit -1"": No error at C:\test.pl line 5.
Stop
===============
The program as such runs ok, but the problem is the warning message
>>Can't spawn "perl -e"exit -1"": No error<< which I don't understand
at all. I want to have warnings on in general, but this particular
warning is not desired. Why should there be a warning at all if the
return code is negative ? -- If I run the same program with "...exit
1;..." then everything is ok, i.e. no warning is emitted.
In the real world scenario, I have an *.exe file that occasionally
emits negative return codes, in which case a >>Can't spawn...No
error<< warning message is emitted. I can't change the behaviour of
the *.exe file. How can I get rid of this particular warning message ?
-- I could say no warnings in the lexical scope of the system command,
but I find this message is completely useless.
I wonder what my fellow perl programmers think about this warning
message.
------------------------------
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 3082
***************************************
