Talk:Associative array/Archive 1
From Wikipedia, the free encyclopedia
| This is an archive of past discussions about Associative array. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 |
References as Keys
In a tree where each node is an associative array, the keys can be references to other nodes in the tree rather than using a textual name. This can be implimented with the Tie function.
- I'm implimenting a distributed one of these and wondering if anyone knows of any other implimentations or documentation about this kind of data structure, or whether it goes by any specific names etc. Nad 21:21, 31 January 2006 (UTC)
Hmmm, Do you mean that the values can be references to other associative sub-arrays, rather than the keys? For example, if I had to represent a Unix directory tree of just sub-directories, files and links to sub-directories then I would first walk the directory tree ignoring any links. Each directory would become an associative array,(AA), with directory entry names as keys and either file 'objects' as values for each file; or sub-AAs to represent sub-directories. A second walk of the directory tree would allow my to insert references to appropriate AA's as values for keys representing directory links.
In Python, AA values can be any object, so an AA with a recursive value example is just:
*** Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32. ***
>>> dir1 = { 'file1': 'file1' } # AA creation with one file
>>> dir1
{'file1': 'file1'}
>>> dir1['link1'] = dir1 # The recursive link
>>> dir1
{'file1': 'file1', 'link1': {...}}
>>> dir1['link1'] # Accesses through the reference
{'file1': 'file1', 'link1': {...}}
>>> dir1['link1']['link1']
{'file1': 'file1', 'link1': {...}}
>>> dir1['link1']['link1']['file1']
'file1'
Again in Python; all non-mutable types are able to be AA keys. Other user-defined types can be used as AA keys if they define a hashing method. (The main mutable built-in type affected by the restriction is the Python list type. Lists are easily converted to the non-mutable tuple type for use as dictionary keys). --Paddy 07:39, 30 April 2006 (UTC)
Delete reference to TAWK?
Thomson Automation are nolonger selling there version of AWK. (follow the link). Sould it be removed from the AWK entry --Paddy 17:22, 22 September 2006 (UTC)
Removed "Map" from the "Data structures" section
I undid a good-faith edit by User:Irishjugg that added a new section titled "Maps" and went as follows:
- The map (associative array) is a structure with no stored order, similar to an orderless list. Values are stored by certain key values in the form mapname[keyvalue] = value. In C++ implementations, such as the STL, the maps are templated and can have values of any standard or user defined type. Insertion into a map is is O(1) time, while for accessing elements it is O(nlogn) as it mush search for the keys. The STL implementation uses a Red Black tree to handle the key searches which ensures worst case O(nlogn). Maps are at the heart of associative arrays.
I have a number of issues with this addition, as follows:
- A map is just another name for an associative array, so saying you can implement an associative array as a map is pretty vacuous
- The most insightful point in this section, that the STL map is implemented as a red-black tree, was already covered; mention of self-balancing trees is under "Efficient representations"
- Insertions into a tree (if you don't provide a good hint to the insert function) is O(log n), not O(1)
- Accessing elements is O(log n), not O(n log n)
- Saying that the STL implementation is red black trees is not really correct, since an implementor is free to choose any structure that satisfies the appropriate complexity requirements. An AVL tree, various variants of B-trees, skip lists, and probably many other structures would all be reasonably appropriate as a backing store, and would result in a reasonable STL implementation.
EvanED 22:07, 10 December 2007 (UTC)
Edited again for a minor fix, and additional objection, EvanED 22:10, 10 December 2007 (UTC)
- That all sounds correct to me. Dcoetzee 03:06, 16 June 2008 (UTC)
Associative array X Regular array
The article says the following about the difference:
While a regular array maps an index to an arbitrary data type such as integers, other primitive types, or even objects, an associative array's keys can be arbitrarily typed. The values of an associative array do not need to be the same type, although this is dependent on the programming language.
However, in my opinion, the difference between arrays and maps/dictionaries/hash tables lies on keys, not on values. At least in the programming languages I've programmed on so far, a traditional array is (conceptually) a special kind of map where indices are integers that are immediately consecutive (without "holes" or "jumps").
Comments? --Antonielly (talk) 19:06, 20 October 2008 (UTC)
Association lists
The section under Association lists defines these to be a linked list of key-value pairs. This is consistent with the common definition of the term in Lisp/Scheme -- for example, . The DADS page at notes that the term is primarily associated with Lisp and the AI community.
User:Pgr94 recently made an edit that doubts this, and the edit comment states that "decent implementations use balanced trees which give O(log n) look up time". However, the article itself lays out a contrast between efficient implementations -- balanced trees and hash tables -- in the immediately preceding section, and the inefficient linked-list-based implementation commonly called an association list. The DADS page, cited by User:Pgr94, makes no specific claim as to efficiency of an association list, and notes that they are often much smaller than general dictionaries. Indeed, an a-list is semantically equivalent to a tree-based dictionary, and the first page cited above notes that an a-list in practice (in one implementation) is in fact a true linked list.
There are two possible solutions to this -- either the claim that an association list might be tree-based is wrong, in which case User:Pgr94's edit should be reverted, or else the rest of the article needs to be made consistent with this new fact, since its structure sets up a contrast between linear-time and log-time implementations. My understanding of a-lists leans toward the former, i.e., that a true a-list is always a linked list and anything else is a dictionary but not an a-list. Thoughts?
cfallin|(talk) 11:33, 21 December 2008 (UTC)
- I am questioning whether association lists have to be linked lists.
- The DADS page says "dictionary" and "association list" are synonyms.
- It would be good to have some more sources, specifically data-structure textbooks. Unfortunately, the books I have to hand don't mention the topic. pgr94 (talk) 12:03, 21 December 2008 (UTC)
- Unfortunately I couldn't find anything in my data structures book (Cormen et al, Intro to Algorithms 2nd ed) either. But here's a mention of association lists in an O'Reilly book on Haskell: Real World Haskell, pg 299 (Google Books preview). This states "An association list is just a normal list containing (key, value) tuples." My understanding of the DADS page connection between association lists and dictionaries is that an association list and a dictionary are equivalent at the semantic level -- thus, the operations listed on the page are implemented by both -- but that association list implies a particular underlying structure, namely, a simple list. The two citations I've given -- the O'Reilly book and the CMU lisp page -- both support this common usage. Here's another Lisp page that describes an alist specifically as a true list: www.faqs.org/faqs/lisp-faq/part2/section-2.html LISP FAQ part 2 section 2. Again, I'd be interested in any examples of a tree-based alist you could find (some casual Googling didn't turn up anything on my end). If not, I'd be glad to incorporate some of these citations into the article and make the Lisp connection more clear. cfallin|(talk) 22:29, 21 December 2008 (UTC)
- There are two definitions of "assocation list" floating around. One is a synonym for associative array; the other refers to a specific implementation of an associative array usign a simple unordered linked list of key-value pairs. I think the latter is more useful, since otherwise there is no simple term for such an implementation, but we could potentially mention both, at the risk of introducing confusion. Dcoetzee 22:04, 22 December 2008 (UTC)
- I'm not sure. An association list is, by name, a sort of list, and certainly not a hash table or a tree. I would discourage readers from confusing the abstract data type "associative array" from any of its common implementations -- including association lists, hash tables, or various sorts of trees. --FOo (talk) 07:20, 24 December 2008 (UTC)
- You're right. I was hesitant to force this at first, but the distinction between the semantic level (at which an alist and a dictionary are synonyms) and implementation level is what I was arguing above. Given this and the fact that pgr94's only objection was a citation of the DADS page, which makes no claim on implementation, I've brought the paragraph into close alignment with the original, but with a few citations. cfallin (talk) 21:51, 24 December 2008 (UTC)
Hashes
Please don't confuse hash-tables with hashes. They are very different things. —Preceding unsigned comment added by 203.222.167.145 (talk) 02:19, 8 September 2009 (UTC)
Confused with Ordering vs Sorting
I find this phrase confusing:
Ordering preservation: Balanced binary trees and skip lists preserve ordering — allowing one to efficiently iterate over the keys in order or to efficiently locate an association whose key is nearest to a given value. Hash tables do not preserve ordering and therefore cannot perform these operations as efficiently (they require the data to be sorted in a separate step).
I feel that the phrase should refer to the preservation of the "insertion order" when iterating over the collections of Keys or Values. But "key is nearest to a given value" supposes a kind order in the set of keys, and this is not part of the contract for the associative array abstract type. Note that Java JDK1.5 includes the class LinkedHashMap that preserves insertion order when browsing the map.
For the same reason I don't see the point to mention "range queries" for associative arrays, as they are not part of the contract. Maybe you could include among the "Specialized representations" the ones with sorted key sets. I mean, to define the abstract subtype "Sorted Associative Array" that would allow for range queries, and would exclude the simple has table implementations. —Preceding unsigned comment added by 83.43.153.47 (talk) 20:53, 20 November 2009 (UTC)
Redirects are a bit of a mess
Hi. Between this article ("Associative array") and the article Attribute–value pair, some redirects are a bit messy:
These four redirects above currently point to Associative array.
- Key-value pair
- Key Value Pair
- Name-value pair
- Arbitrary key-value pairs
- Arbitrary key-value pair
- Arbitrary key value pair
- Attribute-value pair
- Key-value
- Key value
These nine redirects above currently point to Attribute–value pair.
Previously, some of these redirects pointed to NoSQL, which I felt wasn't appropriate. This all seems a bit messy. Perhaps someone could take a look? --MZMcBride (talk) 19:20, 27 January 2013 (UTC)
PHP
Where is the PHP example??
- Sign your edits. Wouter Lievens 08:56, 31 May 2005 (UTC)
"In PHP all arrays can be associative, except that the keys are limited to integers and strings and can only be a single level of subscripts."
Maybe I'm just reading this wrong, but can someone explain to me what this above statement means? --CheesyPuffs144 (talk) 02:27, 15 June 2008 (UTC)
- The PHP example is at comparison of programming languages (mapping)#PHP.
- CheesyPuffs144, I agree that the above statement is confusing and probably incorrect. The associative array#Language support section of this article currently says
- "In PHP, all arrays can be associative, except that the keys are limited to integers and strings."
- which as you probably already know means that, in PHP, each key must be either an integer, or a string -- in PHP, you can't anything else as a key -- a float, an array, etc.
- The comparison of programming languages (mapping)#PHP includes an example
$phonebook['contacts']['Sally Smart']['number'] = '555-9999';
<source lang="PostScript"> ... </source>
Or at least I would if I could, but "PostScript" is not a recognised source language...
actionscript, ada, apache, applescript, asm, asp, autoit, bash, blitzbasic, bnf, c, c_mac, caddcl, cadlisp, cfdg, cfm, cpp, cpp-qt, csharp, css, d, delphi, diff, div, dos, eiffel, fortran, freebasic, gml, groovy, html4strict, idl, ini, inno, io, java, java5, javascript, latex, lisp, lua, matlab, mirc, mpasm, mysql, nsis, objc, ocaml, ocaml-brief, oobas, oracle8, pascal, perl, php, php-brief, plsql, python, qbasic, rails, reg, robots, ruby, sas, scheme, sdlbasic, smalltalk, smarty, sql, tcl, text, thinbasic, tsql, vb, vbnet, vhdl, visualfoxpro, winbatch, xml, xpp, z80
Any suggestions how to remedy this? nemo 11:35, 4 October 2007 (UTC)
It appears to be a recognized language now:
% Level 1 declaration
3 dict dup begin
/red (rouge) def
/green (vert) def
/blue (bleu) def
end
See Help: Wiki markup#Text formatting and Wikipedia: syntaxhighlight. --DavidCary (talk) 02:59, 24 May 2015 (UTC)
search tree
A recent edit() makes this article say that both hash tables and search trees can solve the dictionary problem.
Previous versions of this article implied that there are some cases where a search tree cannot solve the dictionary problem (but a hash table could solve the problem).
Are there really cases where a search tree cannot solve the problem (forcing us to use hash tables in those cases)? If so, what are those cases? --DavidCary (talk) 15:50, 31 July 2016 (UTC)
- It's usually more about abstract data types than actual information-theoretic impossibility, and happens when you have objects of data types that can be compared for equality and hashed but don't have a total order. For instance the equality test could be something defined within another data type that you have no access to, so it might not be either address comparison or bitwise data comparison, but that other data type for whatever reason hasn't defined ordered comparisons. —David Eppstein (talk) 16:16, 31 July 2016 (UTC)
- This is backwards. If you have a comparison and an equality operation, you can use a search tree. If you have some way of assigning a number or a bitstring to every object, then you can use a hash table. Of course, once you have a number or bitstring, you can also use a search tree, though the ordering may have no "meaning" in terms of the abstract data type; so things like range queries will no longer be meaningful.
Bash 4.0
is it missing information about Bash 4.0? Tech201805 (talk) 15:15, 25 June 2018 (UTC)
Protected
I have temporarily edit-protected this article (in, of course, the wrong version) because of the edit-warring going on over its lead. Please discuss the lead here rather than repeatedly reverting to your preferred versions. —David Eppstein (talk) 03:27, 9 August 2019 (UTC)
- Thank you! This article needs protecting. Which is what I've tried to do. The editor refused to accept obvious consensus, and kept adding changes that had been reverted by multiple other editors. I tried to get the editor to read and respect Wikipedia policy, by repeatedly linking to the applicable sections. I even tried putting information about 3RR on the editor's talk page.
- The lead should identify the topic and summarize the body of the article with appropriate weight. It should not summarize an unreferenced "body of research", or be original research. Claims should cite reliable sources, not unspecified schoolbooks. Repeated incoherent edits where the only arguments are about an apparent war with the "C++ people" and their alleged "grandiose cooky reason", unintelligible claims that every "definition must be defined by set theory" in computer science article, et cetera, are disruptive. Is there an actual coherent argument, for why these edits are constructive and in line with Wikipedia policy, and what's allegedly wrong with the time-tested revision? I have yet to see one.
- 185.213.154.172 (talk) 11:29, 9 August 2019 (UTC)
- Clarification: I'm not claiming that the time-tested revision is inherently correct, just because it's time-tested and vetted by many editors/readers. I'm claiming that there is no coherent argument for blatant attacks like: "The article as previously was written had some huge holes in it big enough to fit a ship through. You can't just put up a definition in Wikipedia that is wrong on its face."
- 185.213.154.172 (talk) 12:56, 9 August 2019 (UTC)
- Consensus: Edits were incompetent or vandalism?
- Either way they were clearly disruptive, and a total waste of time. There ought to be at least a pending changes protection on this page, for the editor in question, since it's recurring behavior (with about a week between episodes). There is an obvious obsession with the "C++ people" and "set theory" here, and no apparent respect for Wikipedia policy.
- 185.213.154.172 (talk) 17:56, 10 August 2019 (UTC)