Anyway: I’m happy that lookups are fast. But 99% of the time,
my hashes are small enough that the time savings is probably
very small in terms of program execution time.
Unfortunately for you some of us do things that involve searching
through 30,000 sales records to pull out Joe Bob’s statistics.
Sometimes you just don’t want to do that on the production database,
it just uses far too many resources. Using an ordered hash for one
person’s benefit would kill the speed and jack up memory usage.
Your point is well taken.
However, it remains to be seen whether it would kill the speed.
Personally I doubt it would be significant, but I’ve seen no
numbers one way or the other.
Memory I would consider a more serious issue. Every pair in the
hash would occupy an extra N bytes (addmitedly a low value of N,
like 4). In the case of 30,000 pairs, that’s an additional (say)
120K of RAM used.
As for “one person’s benefit” – it’s true that the people
wanting this functionality are in the minority. But we are
far more than one person.
I know an ordered associative array (which I think is a better
description of the functionality) would make some things very easy,
but replacing the Hash is not the way to go.
That is definitely a better description of the finctionality.
I would even say that “associative array” alone would be a sufficient
term, since “array” implies order. (But I may be wrong there.)
I’d be happy with a separate class for that functionality IF there
were a convenient notation for literals. (For example, the combination
of square brackets and arrows that I mentioned previously, which Ruby
currently interprets as an array with a single element which is a hash.)
Without the literal notation, it would be to me just another kludge.
I would even say that “associative array” alone would be a sufficient
term, since “array” implies order. (But I may be wrong there.)
I’d be happy with a separate class for that functionality IF there
were a convenient notation for literals. (For example, the combination
of square brackets and arrows that I mentioned previously, which Ruby
currently interprets as an array with a single element which is a hash.)
Without the literal notation, it would be to me just another kludge.
+1 for Hal
Also, while not a full fledged class in it’s own right, you might find
Facets’ association.rb useful. Ex.
c = [ :a >> 1, :b >> 2 ]
c.each { |k,v| puts "#{k} associated with #{v} }
I’d be happy with a separate class for that functionality IF there
were a convenient notation for literals. (For example, the combination
of square brackets and arrows that I mentioned previously, which Ruby
currently interprets as an array with a single element which is a hash.)
Without the literal notation, it would be to me just another kludge.
In the case that Hal is talking about, and in the case where
PDF::Writer uses an ordered hash, this would be inappropriate.
Insertion-ordered associations are generally better. I will probably
be modifying PDF::Writer a bit to make it clear that it’s using an
ordered association, not an ordered “hash”, but it would be useful to
have an ordered association. Maybe we could take advantage of a
literal for this:
Either (=>) or [=>] would be fine with me. I’d slightly prefer
the latter.
But the big question is, what would the class be called? I dislike
long names such as Association or AssociativeArray or even
OrderedHash. (I suppose the last might be best of those.)
I once suggested Map – a nice short name – but there was some
reason this wasn’t acceptable.
I’d even suggest (gasp) letting it inherit from Hash.
Either (=>) or [=>] would be fine with me. I’d slightly prefer
the latter.
Or we could use another %?{ } constructor, which are, after all, being
reserved for future expansion.
But the big question is, what would the class be called? I dislike
long names such as Association or AssociativeArray or even
OrderedHash. (I suppose the last might be best of those.)
OHash or Assoc or even Dict (though the latter at least implies an O(1)
lookup).
OHash or Assoc or even Dict (though the latter at least implies an O(1) lookup).
Wouldn’t it be the same as Hash lookup? It’s still got every other
characteristic of a Hash; it just guarantees an order that defaults to
insertion order.
True, I suppose you could do it with a doubly linked list overlaid on
a hash. Was thinking of sorted order.
OHash or Assoc or even Dict (though the latter at least implies an O(1) lookup).
Wouldn’t it be the same as Hash lookup? It’s still got every other
characteristic of a Hash; it just guarantees an order that defaults to
insertion order.
OHash or Assoc or even Dict (though the latter at least implies an O(1)
lookup).
Wouldn’t it be the same as Hash lookup? It’s still got every other
characteristic of a Hash; it just guarantees an order that defaults to
insertion order.
That too is a point that needs definition. I’d like to have two
behaviors.
I call the first one static, and the second one dynamic (and I describe
the
second one first of course).
Than I would like to be able to write, I do not need literals, but that
is
another story that shall be told another day.
dyn = D.new( :a => 42, :b => 42, :c => 42 ) #using future named params
of
course
dyn[:b] = 42
puts dyn.keys.join(“") = > "acb"
while the static bersion would of course result in => "ab*c”
Even the static version has no memory of course and
static[k]=static.delete(k) would become a very meaningful statement,
suddenly
Cheers
Robert
BTW
Do you think one(*42) can generalize Hash values to 42? I think that
would
be a nice Set(up).
Where keyseq is just an array that is updated whenever keys are
added/deleted?
It’s a little more complex than that, but that’s pretty much what all
existing implementations do. We’re talking about wanting a way of
having an ordered associative list (that defaults to insert ordering,
but can be changed to a sorted ordering, perhaps) in the Ruby core
language with a literal constructor, because there is value for it.
We’re talking about wanting a way of
having an ordered associative list (that defaults to insert ordering,
but can be changed to a sorted ordering, perhaps) in the Ruby core
language with a literal constructor, because there is value for it.
Yep, I understand the need for the literal constructor. It is a bit
awkward to do:
OHash.new [ [1,2], [3,4], [4,5] ]
or something similar. Random ideas:
%o{ 1 => 2, 3 => 4 }
%o{ 1,2,3,4 }
{1,2,3,4}! # the ! indicates that order is important!
!{1,2,3,4}
%!{1,2,3,4}
There have been numerous occasions when I wanted an
ordered hash, but usually I can’t remember to write
them down.
Here’s my latest one[1]:
I had a string with a bunch of tagged “tolerance fields”,
e.g., >>1+/-10% ‘tag’<< (a mini DSL?). Based on some sort
of distribution function, e.g., uniform or Gaussian,
I generated an array of samples for each tagged field.
A regular hash was a perfect fit,
samples[tag] = [ sample1, sample2, … ]
until another requirement came up: to present the tags
in order of appearance.
until another requirement came up: to present the tags
in order of appearance.
I’ve had to deal with this (interestingly, in something that was intended as a DSL). Just add another field to the structure you
store in the hash and have it increment a global sequence number when
you create it. A little clunky but later you can say:
OHash or Assoc or even Dict (though the latter at least implies an
O(1) lookup).
Wouldn’t it be the same as Hash lookup? It’s still got every other
characteristic of a Hash; it just guarantees an order that defaults to
insertion order.
OHash lookup should be as fast as Hash lookup.
Insertion would be slightly slower, and iteration (and to_a) would
be slowed down more.
