I've been wondering what the real usefulness of an ordered hash is.
Lately I've found that when I initially think of an ordered hash I
really want one of the following constructs
(1) An array of pairs
(2) A hash with multiple keys for a value.
For (2) I have implemented the second as method of hash like this:
Hash.multiple_keys([1,'str',some_object]=>'a string',[valu]=>another_object)
#=>{1=>'a string','str'=>'a
string',valu=>another_object,some_object=>'a string'}
What I really want to know is, is there some usefulness to ordered
pairs I am missing?
Daniel Brumbaugh Keeney
···
On Nov 12, 2007 7:56 AM, James Edward Gray II <james@grayproductions.net> wrote:
That little challenge made me wish for some Ruby 1.9 elements, like
an ordered Hash.
> That little challenge made me wish for some Ruby 1.9 elements, like
> an ordered Hash.
> James Edward Gray II
I've been wondering what the real usefulness of an ordered hash is.
Lately I've found that when I initially think of an ordered hash I
really want one of the following constructs
(1) An array of pairs
Slow lookup times.
(2) A hash with multiple keys for a value.
How does that behave like an ordered hash?
Thanks,
T.
···
On Nov 13, 3:53 pm, "Devi Web Development" <devi.webmas...@gmail.com> wrote:
On Nov 12, 2007 7:56 AM, James Edward Gray II <ja...@grayproductions.net> wrote:
all the time. if you use a hash the report will have varying order both within and between runs. ruby queue uses this for job output, which looks like this:
···
On Nov 13, 2007, at 1:53 PM, Devi Web Development wrote:
What I really want to know is, is there some usefulness to ordered
pairs I am missing?
it's *really* disorienting for users when jobs come out in different orders job to job, and the next run dumps out something different yet again. make using 'diff' extremely frustrating.
the other use case is for something like a database tuple or a set of columns (mapped by name) displayed on an interface: you want to use them by name, for instance
interface.columns['ssn']
but also want to say
interface.columns.each{|k,c| render c}
and have that come out in order. arrayfields (gem install arrayfields) skins this cat from the other direction: allowing normal arrays to support keyword acccess.
regards.
a @ http://codeforpeople.com/
--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama
facets/dictionary, brought to you by jan molic might say you some
time. unless you're writing it in c of course --speaking if which and
good c implementations out there?
T.
···
On Nov 21, 2:51 pm, "Ralph Siegler" <ralphsieg...@gmail.com> wrote:
On Nov 13, 2007 2:53 PM, Devi Web Development <devi.webmas...@gmail.com> wrote:
> I've been wondering what the real usefulness of an ordered hash is.
writing one write now to deal with csv text files, like to use "column
names" internally but have to respect the proper order when writing
out.
No, for most people, based on quite a long thread referenced by Bill
Kleb, it's a normal hash except that the order that elements are
yielded by each, each_key, each_value... is defined to be the temporal
order of insertion into the hash.
In Ruby 1.8 the enumeration order of a Hash is undefined, in Ruby 1.9,
unless it's been backed out recently, it's defined as above.
···
On Nov 14, 2007 7:01 AM, Devi Web Development <devi.webmaster@gmail.com> wrote:
On Nov 13, 2007 4:03 PM, Trans <transfire@gmail.com> wrote:
> > (2) A hash with multiple keys for a value.
>
> How does that behave like an ordered hash?
An Ordered hash presumably serves the purpose of lookup of a value by
an integer, like an array, or by a normal arbitrary key
thank you for pointing me at the facets project, I've been away from
following ruby-lang for awhile, some great and useful data structure
handling in there. But of course the docs and install have some
issues which I have to figure out (typical of anything gem related)
sudo task/install
task/install:18:in `initialize': No such file or directory -
meta/project.yaml (Errno::ENOENT)
from task/install:18:in `open'
from task/install:18:in `start_install'
from task/install:92
*sigh*
Ralph Siegler
···
On Nov 21, 2007 2:29 PM, Trans <transfire@gmail.com> wrote:
facets/dictionary, brought to you by jan molic might say you some
time. unless you're writing it in c of course --speaking if which and
good c implementations out there?
thanks for bringing useful in future project to my attention ( http://fastercsv.rubyforge.org/ ) , but for what I'm doing now I'm
actually reading in a sort of "outline" and constructing multiple
product & option cvs files for database tables, the ordered hash of
facets/dictionary.rb is quite sufficient & dirty-quick
···
On Nov 26, 2007 12:49 PM, James Edward Gray II <james@grayproductions.net> wrote:
FasterCSV does this, if you just want an out-of-the-box solution.
An Ordered hash presumably serves the purpose of lookup of a value by
an integer, like an array, or by a normal arbitrary key
No, for most people, based on quite a long thread referenced by Bill
Kleb, it's a normal hash except that the order that elements are
yielded by each, each_key, each_value... is defined to be the temporal
order of insertion into the hash.
Well, that's just /one/ way to order a Hash. You could as well order a Hash by the key's natural order (<=>).
In Ruby 1.8 the enumeration order of a Hash is undefined, in Ruby 1.9,
unless it's been backed out recently, it's defined as above.
Does Ruby 1.9 really impose the overhead to maintain insertion order for *every* Hash?
Kind regards
robert
···
On 14.11.2007 13:34, Rick DeNatale wrote:
On Nov 14, 2007 7:01 AM, Devi Web Development <devi.webmaster@gmail.com> wrote:
On Nov 13, 2007 4:03 PM, Trans <transfire@gmail.com> wrote:
Ah, Thanks for reporting this! Sorry for the inconvenience. I'll have
a fix out this afternoon.
HTG,
T.
···
On Nov 21, 9:15 pm, "Ralph Siegler" <ralphsieg...@gmail.com> wrote:
On Nov 21, 2007 2:29 PM, Trans <transf...@gmail.com> wrote:
> facets/dictionary, brought to you by jan molic might say you some
> time. unless you're writing it in c of course --speaking if which and
> good c implementations out there?
thank you for pointing me at the facets project, I've been away from
following ruby-lang for awhile, some great and useful data structure
handling in there. But of course the docs and install have some
issues which I have to figure out (typical of anything gem related)
sudo task/install
task/install:18:in `initialize': No such file or directory -
meta/project.yaml (Errno::ENOENT)
from task/install:18:in `open'
from task/install:18:in `start_install'
from task/install:92
I asked matz about that on ruby-core. The overhead turns out to be very
small; 1.9 maintains a doubly-linked list of hash elements, which has
constant-time insertion and removal. Memory overhead is two words per
hash element.
We may implement the 1.9 ordering in JRuby soon, as it solves a number of
problems with concurrency and iterator stability.
-mental
···
On Thu, 22 Nov 2007 05:25:07 +0900, Robert Klemme <shortcutter@googlemail.com> wrote:
In Ruby 1.8 the enumeration order of a Hash is undefined, in Ruby 1.9,
unless it's been backed out recently, it's defined as above.
Does Ruby 1.9 really impose the overhead to maintain insertion order for
*every* Hash?
> thank you for pointing me at the facets project, I've been away from
> following ruby-lang for awhile, some great and useful data structure
> handling in there. But of course the docs and install have some
> issues which I have to figure out (typical of anything gem related)
The gem install should be okay. The docs are not generated
automatically on purpose btw, b/c Facets has special doc requirements.
You can find them on-line (http://facets.rubyforge.org/learn.html\).
They still have some rough edges, but I'm working on an update this
week.
> sudo task/install
> task/install:18:in `initialize': No such file or directory -
> meta/project.yaml (Errno::ENOENT)
> from task/install:18:in `open'
> from task/install:18:in `start_install'
> from task/install:92
Ah, Thanks for reporting this! Sorry for the inconvenience. I'll have
a fix out this afternoon.
New release 2.1.2, should fix it for you.
Let me know if you had any other problems.
T.
···
On Nov 22, 6:16 am, Trans <transf...@gmail.com> wrote:
wow, thanks much for very speedy and surprising response! It does
indeed work and well.
another minor change for it's README on next version would be to
instruct to run task/install not task/setup
I had wimped out that day and instead of using my ruby from source
installed my distro's ruby (which of course was spread over many
packages) and it's gems and then installed facets that way. An
amazing and useful collection it is.
···
On Nov 22, 2007 5:16 AM, Trans <transfire@gmail.com> wrote:
Ah, Thanks for reporting this! Sorry for the inconvenience. I'll have
a fix out this afternoon.
>> In Ruby 1.8 the enumeration order of a Hash is undefined, in Ruby 1.9,
>> unless it's been backed out recently, it's defined as above.
>
> Does Ruby 1.9 really impose the overhead to maintain insertion order for
> *every* Hash?
I asked matz about that on ruby-core. The overhead turns out to be very
small; 1.9 maintains a doubly-linked list of hash elements, which has
constant-time insertion and removal.
Yeah, clearly.
Memory overhead is two words per
hash element.
I'm less concerned with the CPU overhead but rather the memory overhead.
We may implement the 1.9 ordering in JRuby soon, as it solves a number of
problems with concurrency and iterator stability.
Hm, concurrently iterating and modifying is a bad idea anyway IMHO.
But I can see how some issues can be resolved with this. I just think
that making this impl. the default for all Hashes might have some
adversary effects. I'd rather leave the old impl as is and add
another (sub) class that has the ordered behavior.
Kind regards
robert
···
2007/11/21, MenTaLguY <mental@rydia.net>:
On Thu, 22 Nov 2007 05:25:07 +0900, Robert Klemme <shortcutter@googlemail.com> wrote:
--
use.inject do |as, often| as.you_can - without end
> Well, that's just /one/ way to order a Hash. You could as
> well order a
> Hash by the key's natural order (<=>).
Yes, but nothing extra needs to be added to Hash to get a
natural order enumeration - A hash.sort.each sorts that out.
Which would still be something different than a Hash that
automatically maintains this order. Granted, insertions would be
O(log(N)) instead of O(1) but lookups could still be O(1). And you
save the memory overhead of Hash#sort.
An ordered hash almost always refers to insertion order, as
that's the order that is unrecoverable from a regular hash.
I just find the terminology a bit muddy because "ordered" in itself is
too ambiguous. That's all I wanted to point out all the time.
Kind regards
robert
···
2007/11/23, Daniel Sheppard <daniels@pronto.com.au>:
--
use.inject do |as, often| as.you_can - without end