Asp Forum - hash.keys and hash.values

Mage

8/13/2006 10:22:00 PM

Hello,

I know the order of the keys of a hash is arbitary. However, has the
hash.keys and hash.values same order? Will they be consistent with each
other?

I found nothing in the manual about this. The @Agile Web Developing"
book uses the form below:

Users.update(params[:user].keys,params[:user].values)

So, I think, the order of the keys and values should be same. If it is
then it should be documented, too.

If I missed something, excuse me.

Mage

14 Answers

Hal E. Fulton

8/13/2006 10:31:00 PM

Mage wrote:
> Hello,
>
> I know the order of the keys of a hash is arbitary. However, has the
> hash.keys and hash.values same order? Will they be consistent with each
> other?
>
> I found nothing in the manual about this. The @Agile Web Developing"
> book uses the form below:
>
> Users.update(params[:user].keys,params[:user].values)
>
> So, I think, the order of the keys and values should be same. If it is
> then it should be documented, too.
>
> If I missed something, excuse me.

They'll certainly be the same order. It would be crazy otherwise.

This perhaps should be mentioned somewhere, but maybe people
take it for granted.

Hal

Chad Perrin

8/13/2006 11:13:00 PM

On Mon, Aug 14, 2006 at 07:31:05AM +0900, Hal Fulton wrote:
>
> They'll certainly be the same order. It would be crazy otherwise.

Not necessarily. It could be that, when calling on them separately,
they are accessed in a different order -- and only when using one to
reference the other do their associations come to light. It's
conceivable where there might come a time when someone decides, for
implementation reasons, that this might be a better way to handle it.
It's still less surprising for them to be accessed in the same order,
though, so it's nice that it's implemented this way in absence of a
compelling reason to do otherwise.

>
> This perhaps should be mentioned somewhere, but maybe people
> take it for granted.

I suspect people don't even get as far as taking it for granted, since
they probably tend to access one from the other in almost all cases.

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid

Austin Ziegler

8/14/2006 2:18:00 AM

On 8/13/06, Chad Perrin <perrin@apotheon.com> wrote:
> On Mon, Aug 14, 2006 at 07:31:05AM +0900, Hal Fulton wrote:
> > They'll certainly be the same order. It would be crazy otherwise.
> Not necessarily. It could be that, when calling on them separately,
> they are accessed in a different order -- and only when using one to
> reference the other do their associations come to light. It's
> conceivable where there might come a time when someone decides, for
> implementation reasons, that this might be a better way to handle it.
> It's still less surprising for them to be accessed in the same order,
> though, so it's nice that it's implemented this way in absence of a
> compelling reason to do otherwise.

They would be the same order so long as no changes have been made to
the internal hash table. ;) So, "yes unless you modify the hash or
you're in threaded code which might modify the hash."

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Erik Veenstra

8/14/2006 8:57:00 AM

If you really want to be sure that they're in the same order:

keys, values = hsh.to_a.transpose

gegroet,
Erik V. - http://www.erikve...

Mage

8/14/2006 3:02:00 PM

Erik Veenstra wrote:
> If you really want to be sure that they're in the same order:
>
> keys, values = hsh.to_a.transpose
>
>
Thank you, I like to be 100% sure, so it's comfortable.

Mage

Mage

8/14/2006 3:07:00 PM

Chad Perrin wrote:
>
> I suspect people don't even get as far as taking it for granted, since
> they probably tend to access one from the other in almost all cases.
>
On the second week of my Ruby "experience" I found myself writing a
method (for a very basic db layer) where hash.keys and hash.values could
come in play.
So I think it's a natural need. After a short Google session I found
others dealing with this, most of them assumed that they have same order.

Based on the answers of this thread I believe they are, however until it
becomes documented I will use hash.to_a.transpose in production environment.

Mage

Robert Klemme

8/14/2006 3:26:00 PM

On 14.08.2006 17:06, Mage wrote:
> Chad Perrin wrote:
>>
>> I suspect people don't even get as far as taking it for granted, since
>> they probably tend to access one from the other in almost all cases.
>>
> On the second week of my Ruby "experience" I found myself writing a
> method (for a very basic db layer) where hash.keys and hash.values could
> come in play.
> So I think it's a natural need. After a short Google session I found
> others dealing with this, most of them assumed that they have same order.
>
> Based on the answers of this thread I believe they are, however until it
> becomes documented I will use hash.to_a.transpose in production
> environment.

Here's another solution - maybe it's even more efficient as it doesn't
need the transposing:

>> hash={1=>2,3=>4}
=> {1=>2, 3=>4}
>> keys,vals = hash.inject([[],[]]) {|(ks,vs),(k,v)| [ks << k, vs << v]}
=> [[1, 3], [2, 4]]
>> keys
=> [1, 3]
>> vals
=> [2, 4]

.... of course using #inject. :-)

Kind regards

robert

Mage

8/14/2006 4:01:00 PM

Robert Klemme wrote:
>
> >> hash={1=>2,3=>4}
> => {1=>2, 3=>4}
> >> keys,vals = hash.inject([[],[]]) {|(ks,vs),(k,v)| [ks << k, vs << v]}
> => [[1, 3], [2, 4]]
> >> keys
> => [1, 3]
> >> vals
> => [2, 4]
Thank you, maybe I will benchmark this at home against the transpose
solution.

Mage

Erik Veenstra

8/14/2006 5:14:00 PM

> Here's another solution - maybe it's even more efficient as
> it doesn't need the transposing:

Well, a quick benchmark... No, it isn't more efficient. Neither
time-wise, nor memory-wise.

gegroet,
Erik V. - http://www.erikve...

----------------------------------------------------------------

$ cat test.rb
require "ev/ruby"

GC.disable

hash = {}

1000.times do |n|
hash[n] = n*n
end

case ARGV.shift
when "transpose"
bm do
1000.times do
keys, values = hash.to_a.transpose
end
end
when "inject"
bm do
1000.times do
keys, values = hash.inject([[],[]]){|(ks,vs),(k,v)| [ks <<
k, vs << v]}
end
end
else
raise "uh?"
end

puts meminfo

$ ruby test.rb transpose
VmSize: 58284 kB
CPU ELAPSED COUNT CPU/COUNT LABEL
1.020000 1.153397 1 1.020000 "test.rb:13"

$ ruby test.rb inject
VmSize: 146676 kB
CPU ELAPSED COUNT CPU/COUNT LABEL
2.700000 2.826171 1 2.700000 "test.rb:19"

----------------------------------------------------------------

Chad Perrin

8/14/2006 6:01:00 PM

On Tue, Aug 15, 2006 at 12:06:51AM +0900, Mage wrote:
> Chad Perrin wrote:
> >
> >I suspect people don't even get as far as taking it for granted, since
> >they probably tend to access one from the other in almost all cases.
> >
> On the second week of my Ruby "experience" I found myself writing a
> method (for a very basic db layer) where hash.keys and hash.values could
> come in play.
> So I think it's a natural need. After a short Google session I found
> others dealing with this, most of them assumed that they have same order.

I stand corrected.

>
> Based on the answers of this thread I believe they are, however until it
> becomes documented I will use hash.to_a.transpose in production environment.

That's probably an excellent policy.

--
CCD CopyWrite Chad Perrin [ http://ccd.ap... ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky

comp.lang.ruby

hash.keys and hash.values

Mage

Hal E. Fulton

Chad Perrin

Austin Ziegler

Erik Veenstra

Mage

Mage

Robert Klemme

Mage

Erik Veenstra

Chad Perrin

x Login to ForumsZone