Talk:Data Structures - Revision history

Mcroft at 21:40, 4 July 2023

2023-07-04T21:40:24Z

← Older revision		Revision as of 21:40, 4 July 2023
Line 1:		Line 1:
			==To Do==
			We really should consider moving things like Veracity's guide to Maps either to the wiki or to GitHub.
			--[[User:Mcroft\|Mcroft]] ([[User talk:Mcroft\|talk]]) 21:40, 4 July 2023 (UTC)
			==Records==
	I thought that the Records section would've been helpful in figuring out multidimensional maps -- maybe not; Veracity might've gone a bit too far with that example (which I understand, as she was trying to cover all her bases with one single unifying example). --[[User:Heeheehee\|Heeheehee]] 06:42, 10 March 2010 (UTC)		I thought that the Records section would've been helpful in figuring out multidimensional maps -- maybe not; Veracity might've gone a bit too far with that example (which I understand, as she was trying to cover all her bases with one single unifying example). --[[User:Heeheehee\|Heeheehee]] 06:42, 10 March 2010 (UTC)

Grotfang at 12:50, 3 March 2013

2013-03-03T12:50:00Z

← Older revision		Revision as of 12:50, 3 March 2013
Line 1:		Line 1:
	I thought that the Records section would've been helpful in figuring out multidimensional maps -- maybe not; Veracity might've gone a bit too far with that example (which I understand, as she was trying to cover all her bases with one single unifying example). --[[User:Heeheehee\|Heeheehee]] 06:42, 10 March 2010 (UTC)		I thought that the Records section would've been helpful in figuring out multidimensional maps -- maybe not; Veracity might've gone a bit too far with that example (which I understand, as she was trying to cover all her bases with one single unifying example). --[[User:Heeheehee\|Heeheehee]] 06:42, 10 March 2010 (UTC)

	==An attempt at explaining maps== (by [[User:Grotfang\|Grotfang]])		==An attempt at explaining maps==
			(by [[User:Grotfang\|Grotfang]])

	A map consists of two types of component.		A map consists of two types of component.

Grotfang at 12:49, 3 March 2013

2013-03-03T12:49:44Z

← Older revision		Revision as of 12:49, 3 March 2013
Line 1:		Line 1:
	I thought that the Records section would've been helpful in figuring out multidimensional maps -- maybe not; Veracity might've gone a bit too far with that example (which I understand, as she was trying to cover all her bases with one single unifying example). --[[User:Heeheehee\|Heeheehee]] 06:42, 10 March 2010 (UTC)		I thought that the Records section would've been helpful in figuring out multidimensional maps -- maybe not; Veracity might've gone a bit too far with that example (which I understand, as she was trying to cover all her bases with one single unifying example). --[[User:Heeheehee\|Heeheehee]] 06:42, 10 March 2010 (UTC)

	==An attempt at explaining maps==		==An attempt at explaining maps== (by [[User:Grotfang\|Grotfang]])

	A map consists of two types of component.		A map consists of two types of component.

Grotfang: /* Multiple Keys */

2010-03-12T23:18:31Z

Multiple Keys

← Older revision		Revision as of 23:18, 12 March 2010
Line 130:		Line 130:
	d bd</pre>		d bd</pre>

	As you can see, my_map["a","b"], which has "b" as key2 is NOT included in the aggregate return~~. This is where the concept of dimensions comes from~~. The more keys, the more level of control you have, but you cannot return (I don't think) a map of key1 that shares key2. It's a one-way structure. Of course, you could work around this with a new map that had the keys in reverse.		As you can see, my_map["a","b"], which has "b" as key2 is NOT included in the aggregate return. The more keys, the more level of control you have, but you cannot return (I don't think) a map of key1 that shares key2. It's a one-way structure. Of course, you could work around this with a new map that had the keys in reverse.

Grotfang: /* Multiple Keys */

2010-03-11T16:46:43Z

Multiple Keys

← Older revision		Revision as of 16:46, 11 March 2010
Line 89:		Line 89:

	<pre>key1 key2 value		<pre>key1 key2 value
	a b ab</pre>		a b ab</pre>

	As you might expect. Here we specified a map with two keys and one value. We assigned a value "ab" to the combination of key1 ("a") and key2 ("b"). When we retrieved the value for that combination, we got "ab". So far, so unsurprising.		As you might expect. Here we specified a map with two keys and one value. We assigned a value "ab" to the combination of key1 ("a") and key2 ("b"). When we retrieved the value for that combination, we got "ab". So far, so unsurprising.
Line 118:		Line 118:

	<pre>key1 key2 value		<pre>key1 key2 value
	a b ab		a b ab
	b c bc		b c bc
	b d bd		b d bd
	c d cd		c d cd
	e f ef</pre>		e f ef</pre>

	The setup for my_map2 (containing only entries that have "b" as key1) is:		The setup for my_map2 (containing only entries that have "b" as key1) is:

	<pre>key value		<pre>key value
	c bc		c bc
	d bd</pre>		d bd</pre>

	As you can see, my_map["a","b"], which has "b" as key2 is NOT included in the aggregate return. This is where the concept of dimensions comes from. The more keys, the more level of control you have, but you cannot return (I don't think) a map of key1 that shares key2. It's a one-way structure. Of course, you could work around this with a new map that had the keys in reverse.		As you can see, my_map["a","b"], which has "b" as key2 is NOT included in the aggregate return. This is where the concept of dimensions comes from. The more keys, the more level of control you have, but you cannot return (I don't think) a map of key1 that shares key2. It's a one-way structure. Of course, you could work around this with a new map that had the keys in reverse.

Grotfang: /* Multiple Keys */

2010-03-11T16:45:55Z

Multiple Keys

@@ Line 85: / Line 85: @@
 <pre>ab</pre>
 As you might expect. Here we specified a map with two keys and one value. We assigned a value "ab" to the combination of key1 ("a") and key2 ("b"). When we retrieved the value for that combination, we got "ab". So far, so unsurprising.
@@ Line 109: / Line 114: @@
 <pre>bc
 bd</pre>
 As you can see, my_map["a","b"], which has "b" as key2 is NOT included in the aggregate return. This is where the concept of dimensions comes from. The more keys, the more level of control you have, but you cannot return (I don't think) a map of key1 that shares key2. It's a one-way structure. Of course, you could work around this with a new map that had the keys in reverse.

Grotfang: /* Multiple Keys */

2010-03-11T16:42:00Z

Multiple Keys

← Older revision		Revision as of 16:42, 11 March 2010
Line 70:		Line 70:
	1 Hi there! Grotfang</pre>		1 Hi there! Grotfang</pre>

	=Multiple Keys=		===Multiple Keys===

	This is more complex. Maps with single keys are easy to understand how they will return - specify the map and key and you return the value (you need to specify which value you want if you use a record, but the principle is the same).		This is more complex. Maps with single keys are easy to understand how they will return - specify the map and key and you return the value (you need to specify which value you want if you use a record, but the principle is the same).

Grotfang at 16:41, 11 March 2010

2010-03-11T16:41:44Z

← Older revision		Revision as of 16:41, 11 March 2010
Line 70:		Line 70:
	1 Hi there! Grotfang</pre>		1 Hi there! Grotfang</pre>

	--[[~~User:Grotfang\|Grotfang~~]] 16:12, ~~11 March 2010~~ (~~UTC~~)		=Multiple Keys=

			This is more complex. Maps with single keys are easy to understand how they will return - specify the map and key and you return the value (you need to specify which value you want if you use a record, but the principle is the same).

			More than one key is where maps get truly interesting. To all extents and purposes, multiple keys tend to be a way to categorise data into groups and subgroups. The return values get more complicated, though.

			Whenever you add a value to a map, all keys MUST be specified. However, when you are retrieving data this is not the case. This works best with an example:

			<pre>string [string , string] my_map;
			my_map["a","b"] = "ab";
			print(my_map["a","b"]);</pre>

			This returns:

			<pre>ab</pre>

			As you might expect. Here we specified a map with two keys and one value. We assigned a value "ab" to the combination of key1 ("a") and key2 ("b"). When we retrieved the value for that combination, we got "ab". So far, so unsurprising.

			However, the natural question arises, what if we try to retrieve a value while only specifying one of the keys? The answer is that we need to change our perspective of the map to what I suggested earlier - that of groups and sub-groups.

			The way I visualise this is to imaging key1 represents a group and key2 is a subgroup. If two map entries have the same key1, then you should perceive them as having some commonality. What happens when you retrieve using key1 only is that you return a map of all the map entries that have the specified value of key1. This means (as you are returning an aggregate) you need to specify a new map for the values to be placed in. The following example illustrates this:

			<pre>string [string , string] my_map;
			my_map["a","b"] = "ab";
			my_map["b","c"] = "bc";
			my_map["b","d"] = "bd";
			my_map["c","d"] = "cd";
			my_map["e","f"] = "ef";

			string [string] my_map2 = my_map["b"];

			foreach x in my_map2 {
			print( my_map2[x] );
			}</pre>

			The output is:

			<pre>bc
			bd</pre>

			As you can see, my_map["a","b"], which has "b" as key2 is NOT included in the aggregate return. This is where the concept of dimensions comes from. The more keys, the more level of control you have, but you cannot return (I don't think) a map of key1 that shares key2. It's a one-way structure. Of course, you could work around this with a new map that had the keys in reverse.

Grotfang at 16:12, 11 March 2010

2010-03-11T16:12:40Z

← Older revision		Revision as of 16:12, 11 March 2010
Line 69:		Line 69:
	int message recipient		int message recipient
	1 Hi there! Grotfang</pre>		1 Hi there! Grotfang</pre>

			--[[User:Grotfang\|Grotfang]] 16:12, 11 March 2010 (UTC)

Grotfang at 16:09, 11 March 2010

2010-03-11T16:09:51Z

← Older revision		Revision as of 16:09, 11 March 2010
Line 43:		Line 43:
	<pre>key value1 value2		<pre>key value1 value2
	int message recipient</pre>		int message recipient</pre>

			So far, so simple. The next bit is where it gets interesting. We can no longer assign a value to the map as a whole. Without a record, we can do the following:

			<pre>string [int] message;
			message[1] = "Hi there!";</pre>

			This makes the string "Hi there!" our value for key = 1:

			<pre>key value
			1 Hi there!</pre>

			With a record, we can no longer assign a value to a key alone; we have more than one value and we need to specify which one it is we want to assign something to. So using the record above, to assign a message we would have to do the following:

			<pre>record kmailer{
			string message;
			string recipient;
			}
			kmailer [int] my_messages;
			my_messages[1].message = "Hi there!";
			my_messages[1].recipient = "Grotfang";</pre>

			Both values are assigned to our "1" key, but we must specify the value we are assigning. The following details what is going on in the map:

			<pre>key value1 value2
			int message recipient
			1 Hi there! Grotfang</pre>