www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - T[][T] -> [(k1, v1), ..., (k1, vn), ..., (kn, v1), ..., (kn, vn)]

reply "Tobias Pankrath" <tobias pankrath.net> writes:
I've got a hash map T[][T] with keys of T and values of T[]. For 
some reason, I'll need a range of tuples (t1, t2), where t1 is a 
key and t2 is an element of the array t1 maps to. To have them in 
order would be great, but is not necessary.

I just wrote my own range type and it works. But I wonder how 
would I do it with phobos utilities?

I came up with this:

int[][int] hash = [1 :[1,2,3,4], 2:[3,1,2,3], 4:[2,3,1,3]];
auto x = hash.keys.map!(x => tuple(x, hash[x]))
                   .map!(x => zip(repeat(x[0]), x[1]));

Is there any other way to create a range of simple (key,value) 
pairs for the array, but needs to allocate (hash.keys return an 
array of keys) and then again look up every key.

We can loop over (key,value) pairs of the AA with foreach, but I 
guess there is no standard way to create a range from a 
foreach-compatible delegate? Or even get a hand on this delegate?
Feb 13 2014
parent reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Thursday, 13 February 2014 at 11:00:17 UTC, Tobias Pankrath 
wrote:
 I've got a hash map T[][T] with keys of T and values of T[]. 
 For some reason, I'll need a range of tuples (t1, t2), where t1 
 is a key and t2 is an element of the array t1 maps to. To have 
 them in order would be great, but is not necessary.

 I just wrote my own range type and it works. But I wonder how 
 would I do it with phobos utilities?
A byPair range has been proposed long ago: https://d.puremagic.com/issues/show_bug.cgi?id=5466
 I came up with this:

 int[][int] hash = [1 :[1,2,3,4], 2:[3,1,2,3], 4:[2,3,1,3]];
 auto x = hash.keys.map!(x => tuple(x, hash[x]))
                   .map!(x => zip(repeat(x[0]), x[1]));

 Is there any other way to create a range of simple (key,value) 
 pairs for the array, but needs to allocate (hash.keys return an 
 array of keys) and then again look up every key.
import std.algorithm : zip; import std.traits : isAssociativeArray; auto byKeyValuePair(AA)(AA aa) if (isAssociativeArray!AA) { return zip(aa.byKey, aa.byValue); }
Feb 13 2014
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 Is there any other way to create a range of simple (key,value) 
 pairs for the array, but needs to allocate (hash.keys return 
 an array of keys) and then again look up every key.
import std.algorithm : zip; import std.traits : isAssociativeArray; auto byKeyValuePair(AA)(AA aa) if (isAssociativeArray!AA) { return zip(aa.byKey, aa.byValue); }
That byKey and byValue adhere to the same order is not backed up by the documenation, I suppose?
Feb 13 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Tobias Pankrath:

 That byKey and byValue adhere to the same order is not backed 
 up by the documenation, I suppose?
Right. It's a bet (unlike in Python, that has this rule in the docs). Bye, bearophile
Feb 13 2014
parent reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Thursday, 13 February 2014 at 12:30:29 UTC, bearophile wrote:
 Tobias Pankrath:

 That byKey and byValue adhere to the same order is not backed 
 up by the documenation, I suppose?
Right. It's a bet (unlike in Python, that has this rule in the docs).
Yup. And given how Walter and Andrei don't like breaking code, we should just previde enough usage so it would become a rule too :D
Feb 13 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Stanislav Blinov:

 Yup. And given how Walter and Andrei don't like breaking code, 
 we should just previde enough usage so it would become a rule 
 too :D
That's not the rational way a language should be designed. Tester Driven Development (http://en.wikipedia.org/wiki/Tester_driven_development ) is bad enough already. Bye, bearophile
Feb 13 2014
parent "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Thursday, 13 February 2014 at 12:43:00 UTC, bearophile wrote:
 Stanislav Blinov:

 Yup. And given how Walter and Andrei don't like breaking code, 
 we should just previde enough usage so it would become a rule 
 too :D
 That's not the rational way a language should be designed. 
 Tester Driven Development 
 (http://en.wikipedia.org/wiki/Tester_driven_development ) is 
 bad enough already.
I did put a smiley in there, right? My comment was a joke ;) It's just that often the desire to "not break code" adheres to that very pattern :(
Feb 13 2014