Wikipedia talk:WikiProject Computer science

State Machine Replication a subtopic of Replication but does not reference it

Add a link from replication (computing) to state machine replication. The other direction is covered. This is also an opportunity to improve consistency between these two related articles.

Draft: Brainchip

could someone review the Draft:Brainchip page? Birdmanoftech (talk), 13 January 2023 (UTC)

Good article reassessment for PHP

PHP has been nominated for a good article reassessment. If you are interested in the discussion, please participate by adding your comments to the reassessment page. If concerns are not addressed during the review period, the good article status may be removed from the article. Sohom (talk) 08:25, 2 February 2024 (UTC)

Rename Associative array -> Dictionary (abstract data type)

(Not an experienced editor, if this is the wrong place/if you have advice let me know!) In 2022, there was a request to move the article Associative array to Dictionary (data type). (Also see the previous sections on the talk page.)

The result of the move request was: (non-admin closure) NO CONSENSUS User:力 (powera, π, ν) 23:46, 5 February 2022 (UTC)

There is quite a bit of discussion here, but nothing resembling consensus for any particular move -- and the discussion is too broad for a re-list to solve this. This should be discussed on a WikiProject before there is a re-nomination, but no prejudice against a re-nomination in March. User:力 (powera, π, ν) 23:46, 5 February 2022 (UTC)

I'd like to start said discussion. The 2022 renamings involved other things; I just want to focus on Associative array. This is important because a map/dictionary is not an array; for instance, while the PHP associative array is ordered, while general map/dictionaries are frequently unordered. In functional languages, a map may not even have an underlying Array/List, but is frequently a tree.

The obvious question is that this datatype has 2 common names: Map and Dictionary. Both are, in my view, better than the current, and I'd be happy to see it changed to either. To propose one (just to get the ball rolling), I'd like to suggest renaming Associative array → Dictionary (abstract data type) and Comparison of programming languages (associative array) → Comparison of programming languages (dictionary). The (abstract data type) is in keeping with most other data types articles:

• Set (abstract data type)
• Stack (abstract data type)
• Queue (abstract data type)

(Tree (data structure) and Array (data type) are the exceptions to this pattern.)

My argument for changing Associative Array:

• Popularity. Dictionary and Map are both more popular searches. (Using "python dictionary" and "HashMap" to underestimate their popularity and exclude the normal uses of the words.) StackOverflow has 3,200 questions tagged associative-array and 85,949 questions tagged dictionary (of which "map" is an alias).
• The aforementioned accuracy issue. Arrays are ordered, while maps (AWK & Bash's associative arrays included) are frequently not.
• "Associative arrays" seem most common in languages where the map and list/array data types are collapsed into one object (e.g. AWK and PHP), where {0 =>"cat", 1=>"dog"} is the representation of ["cat", "dog"].

Briefly, considerations of Map (again, I like both.):

• + Used in many more languages (C++, Java, JS, Go, Rust, etc) and immediately connected with Hash map etc.
• + In keeping with Map (mathematics) (though a mathematics mapping would also include, eg, any pure function)
• - Ambiguous with Map (higher-order function)

The arguments for/against Dictionary:

• + Unambiguous (though the article disambiguates it with Data dictionary, which I don't think I've ever seen used.)
• + Consensus as the less-ambiguous term. NIST Dictionary of Algorithms and Data Structures uses dictionary (though I wouldn't hold it up as a source of good unambiguous definitions). StackOverflow uses dictionary to refer to the common term (though as of 2015 there was some disagreement about that).

("Association table"/"Symbol table" is potentially a 3rd alternative that appears in some algorithms textbooks, but I'm not fond of it.)

KenyonP (talk) 06:46, 27 February 2024 (UTC)

I created a topic on Talk:Associative_array mentioning this. Question of wiki etiquette: Would it be polite/appropriate to ping the people who participated in that discussion(s) (and if so, is there a bulk-notify template?) KenyonP (talk) 06:57, 27 February 2024 (UTC)

This topic has many names, as our article makes clear. The one I typically use is "dictionary", but that may be out of familiarity with Python. That said, WP:NCDAB appears relevant: "When there is another term (such as Apartment instead of Flat) or more complete name (such as English language instead of English) that is unambiguous, commonly used in English (even without being the most common term), and equally clear, that term is typically the best to use." Here, "dictionary" and "map" are clearly ambiguous, while "associative array" is not. That suggests that we should continue to use it rather than changing to a title that would require disambiguation. —David Eppstein (talk) 08:22, 27 February 2024 (UTC)

That's a fair point (and I'm happy to go with it if that's what people decide), but I think that "associative array" is sufficiently uncommon and less clear that those priorities might win out.

It's also arguably still ambiguous: NIST's page says If [a linear search of key-value pairs] is too slow, and you access the array by number, too, you must create and maintain an index into the array. The index is a dictionary, organized by the content, of indexes into the array. That seems to indicate some people use "associative array" to mean specifically an array of (key, value) tuples, like Association list. (I also think the fact that "Association array" is nothing close in meaning to the array-equivalent of "Association list" is a source of confusion.) KenyonP (talk) 08:57, 27 February 2024 (UTC)

As pointed out on the talk page, renaming Associative array to Dictionary (...) is problematic:

• Dictionary (data structure) is problematic since there is a possible correlation to implementation structures of the dictionary concept. That is, the term might incorrectly suggest (at least to some computer scientists like David Eppstein) that the article is concerned with data structures that implement associative arrays, or even that there is just one such implementation structure.
  Note: The NIST's page referenced by the article is subtitled "(data structure)".
• Dictionary (data type) is problematic because the article does not provide a definition (or description) of such a data type so that dictionaries from Python (or JavaScript / Ruby) would be compliant with such a definition.
• Dictionary (abstract data type) is problematic for similar reasons like Dictionary (data type). Moreover, such a term might incorrectly suggest that the article is about a "value domain" where dictionaries are devoid of identity (i.e. distinct dictionaries must represent different maps - in particular, there must be exactly one empty dictionary).

Hundblue (talk) 20:07, 27 February 2024 (UTC)

I'm trying to avoid getting bogged down in the naming of the (...) part by going with existing consensus. A Set feels like the closest analogy, since it's conceptually a Map without keys. In that case, we have Set (abstract data type), and I think all your concerns about the structure/type/ADT distinction apply there as well, right? (I'm happy to discuss a broader renaming in a separate thread, though.)

KenyonP (talk) 02:38, 29 February 2024 (UTC)

Yes, you are right, my concerns about the "abstract data type" terminology are applicable to other articles as well. In particular, I have objections against statements of the form

In computer science, a foo is an abstract data type ...

At present, this is the introductory sentence for the following foos: list, stack, set, associative array, graph, tree. First and foremost, a list (, stack, ...) in computer science is NOT a data type. Instead, it is an instance of a data type. This is what the Data type article says at present:

In computer science and computer programming, a data type (or simply type) is [...] usually specified by a set of possible values, a set of allowed operations on these values, and/or a representation of these values [...].

Is a list (, stack, ...) specified by a set of values plus operations? No, it is just one of the values or a representation of one of the values.

One can point out that the exact term used in the articles' introductory sentence is "abstract data type" rather than just "data type". But this makes things even worse. Quoting from Abstract data type:

In computer science, an abstract data type (ADT) is a mathematical model for data types [...]

This would mean: In computer science, a list (, stack, ...) is a mathematical model for data types. Which sounds nonsensical. Moreover, the qouted definition of Abstract data type raises doubts about whether an abstract data type is a data type in the first place.

On the whole, the term "abstract data type" is not established enough to provide a suitable base for definition or description of other terms. Until the issues are settled, IMHO, references to ADT should be avoided as much as possible. In this regard, the term Associative array provides a protection against the ADT mess.

Perhaps the key question about the proposed renaming to Dictionary (abstract data type) is whether a Python dictionary should be a prominent exemplar of the notion described by the article. If so then ask whether there is an ADT so that Python dictionaries are instances of that ADT. The description of an ADT as provided by the #Properties section has the following issues:

1. The description is based on NIST's dictionary which cannot be regarded as a reliable source.
2. The description lacks input-output signatures of operations. What kind of entity is returned by insert(j,v,D)?
3. It is not clear whether identity of dictionaries is supported. Is new() = new() satisfied? Are there more than one empty dictionaries?
   Note: In an old version, the Properties section contained an E symbol that denoted "the empty dictionary". This was later removed in favor of the new operator.
4. It is not clear whether dictionaries with circularities are supported. In Python (or JavaScript / Ruby) executing x = {}; x["a"] = x results in a circular dictionary. Is such a dictionary an instance of the described ADT?

Until these issues are settled the connection between Python dictionaries and ADT should be regarded as not yet established. Hundblue (talk) 16:11, 29 February 2024 (UTC)

I'm not claiming that a Python dictionary is the exemplar of the map/dictionary. (In particular, Python dictionaries are explicitly order-preserving.) Python is maybe the most notable modern user of 'dictionary' as a term, but other languages/libraries/textbooks use it too. Again, I'm happy with Map as well if it feels more language-agnostic.

I don't think we should hold off on changing the name because the current one avoids the "(abstract data type)" name--if that's an issue, we should make a new thread and discuss what a proper parenthetical would be and (if supported) apply it to ALL such pages. (Including Associative array.)

I'd be happy to work on the Properties section, but that's not something I need WikiProject consensus for. KenyonP (talk) 22:13, 29 February 2024 (UTC)

If I understand you correctly, you don't regard a Python dictionary as the exemplar of the notion described by the article. This is surprising. Does it mean you disagree with mentioning Python as one of the languages that support associative arrays? Quoting from the Language support section:

Most modern scripting languages, starting with AWK and including Rexx, Perl, PHP, Tcl, JavaScript, Maple, Python, Ruby, Wolfram Language, Go, and Lua, support associative arrays as a primary container type.

If a Python dictionary is not the exemplar of the article's subject then all my objections to the proposed name change are pointless. Hundblue (talk) 18:43, 2 March 2024 (UTC)

Requested move at Talk:Artificial intelligence art#Requested move 28 February 2024

There is a requested move discussion at Talk:Artificial intelligence art#Requested move 28 February 2024 that may be of interest to members of this WikiProject. Vanderwaalforces (talk) 08:02, 29 February 2024 (UTC)

FAC for Cross-site leaks

I've nominated Cross-site leaks (a while back) for promotion to a Featured article. Reviews, comments and suggestions are welcomed at the nomination page :) Sohom (talk) 21:35, 9 March 2024 (UTC)

Requested move at Talk:TACL#Requested move 12 March 2024

There is a requested move discussion at Talk:TACL#Requested move 12 March 2024 that may be of interest to members of this WikiProject. Brusquedandelion (talk) 01:04, 13 March 2024 (UTC)

Invitation for discussion

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § AI for WP guidelines/ policies. ExclusiveEditor _{Notify Me!} 14:39, 18 March 2024 (UTC)

Requested merger at Talk:List of fictional computers#Merger proposal 18 March 2024

There is a requested merger discussion at Talk:List of fictional computers#Merger proposal 18 March 2024 that may be of interest to members of this WikiProject. Dash77 (talk) 22:53, 18 March 2024 (UTC)