Talk:Array (data structure)

message: Is there benefit of arrays?
: Good point; perhaps the headings could be refactored to include the word "benefits", for better style or compatability with other articles. --Mike Van Emmerik 21:42, 5 September 2005 (UTC)
thread_title: array

message: "In computer programming, a group of homogeneous elements of a specific data type is known as an array, one of the simplest data structures" is false for Ruby; "Ruby's arrays can accomodate diverse object types". -Ruby User's Guide
Is the definition of arrays inaccurate, or are Ruby arrays not strictly arrays?
--Wootery 20:44, 3 October 2006 (UTC)
replies: text: "Array" is one of those slippery terms. The usual definition is from C terminology, where, of course, arrays are always homogenous. As far as I know, 'array' originaly was more or less synonymous with 'list' in the computer science literature to mean a collection of things ordered by index. I'm not sure where computer science comes down on this issue today. --Apantomimehorse 04:59, 10 October 2006 (UTC)

text: Ruby's arrays can be seen as arrays of variant types. The homogenity of type is not quite as essential as the uniformity of element size, which is necessary for ordinary address computation. It appears someone has added this in addition to the existing wording, which says "usually" and is now redundant. Argh. Deco 09:39, 10 October 2006 (UTC)
thread_title:  'of a specific data type' 

message: I'm looking for a place to rant and rave (as objectively as possible of course :-)) about the C++ vector<bool> specialisation standard-that-is-not-really-a-standard. Where would I go about writing such an article? Or do I just write a vector<bool> article and let someone else move it / splice it later? --The Extremist 09:14, 6 January 2006 (UTC)
replies: text: How about bit array? Deco 06:53, 14 June 2006 (UTC)
thread_title:  Managed arrays 

message: QUESTION:
A company is seeking to determine the optimum length of the guarantee period on its product, a device whose reliability and propensity to failure can be predicted with a high degree of accuracy.
It is known that the failure rate of the device can be adequately approximated in terms of a constant function of time i.e. about 10% of the devices sold will fail each year until all have failed at the end of 10 years.
The company makes a profit of $2.80 on each unit sold. If it offers no guarantee, it can expect to sell 100 units annually. The length of the guarantee is of some importance to customers however, and some empirical studies have suggested that its effect on sales may be shown by the following equation;
Q=100+5t
Where Q=Quantity sold (in units)
And
T=Length of guarantee (in years)
The company sustained a cost of $1.00 for each unit which it had to repair under terms of the guarantee.
In view of this and in view of the fact that 10% of Q would be expected to fail each year, it was believed that the cost of making guaranteed repairs under a guarantee period of length t would be;
		C=$1.00X0.1QT
		  =0.1QT
Profit in this analysis can be regarded merely as the gross profit from sales less the cost of making guaranteed repairs.
It will be noted that certain simplifying assumptions have been made in the foregoing exposition.
The assumed constant failure rate has already been mentioned. Also, it should be noted that constant sales volume has been assumed, and the effect on sales of all variables other than that of the guarantee period has been disregarded.
RFEQUIRED:
Determine the optimum length of the guarantee period in order to maximize profits.
:Congratulations. You win the most bizarre question asked on a computer science talk page award. Deco 06:52, 14 June 2006 (UTC)
thread_title:  Differentiation 

message: In the "Array system cross-reference list", why are C and C++ listed as having Dimension = 1?  What do they lack compared to languages listed under Dimension = n?  Certainly both multidimensional arrays (arrays of arrays) and arrays of references (Iliffe vectors) are used in C and C++. --Spoon! 03:25, 25 July 2006 (UTC)
replies: text: Two dimensional slices like Slice (5 .. 20, 5 .. 20) - of course since C/C++ don't support array slices to begin with you won't notice the difference.  --Krischik T 11:53, 30 January 2008 (UTC)

text: The article goes far enough in allowing that c/c++ supports arrays. Essentially, "c arrays" are just pointers (with weak, compile-time type support) to chunks of memory.  —Preceding unsigned comment added by 188.126.207.212 (talk) 12:46, 16 March 2011 (UTC)
thread_title:  C & C++ have Dimension = 1? 

message: :1-Dimensional or Linear Array
:An array that consists of elements which can be sorted either horizontally or vertically is known as a linear array or 1-dimensional array. The elements are sorted in only one direction (horizontal or vertical), that means the variable can hold only a single value.
Does this make any sense to anyone?  What does "sorted" have to do with 1-dimensional arrays? (maybe it's "stored"?)  And what does "horizontal" or "vertical" have to do with 1-dimensional arrays? --Spoon! 11:30, 25 August 2006 (UTC)
replies: text: That segment is now deleted.  It basically repeated what the introduction said about arrays, using confusing language.
137.112.141.152 07:34, 19 October 2006 (UTC)
thread_title:  "1-Dimensional or Linear Array" makes no sense 

message: Howcome PHP isn't on the Array system cross-reference list? -Dan Leveille 22:09, 17 November 2006 (UTC)
replies: text: Perhaps because PHP arrays aren't actually arrays, but a bizarre array-hashtable hybrid data structure that can be used to emulate traditional arrays. JulesH 19:45, 17 February 2007 (UTC)
thread_title:  PHP Arrays? 

message: Don't know if this is a big deal, but MATLAB is column-major as well.  Should we update the table of programming languages/array characteristics to indicate whether that language is row- or column-major?--Andrew Blackburn 16:20, 01 December 2006 (UTC)
thread_title:  Programming language array attributes table - show row- or column-major? 

message: So the article used to talk about how insertion/deletion in an array requires linear time - an editor recently pointed out that insertion/deletion in an array doesn't really make sense, as it's fixed in size. While I'm sure there's no issue with describing insertion/deletion in the context of dynamic arrays, I've still seen many algorithm books and references describe arrays as requiring linear time for insertion and deletion in contexts such as insertion sort, where a list of bounded size is stored inside an array. I attempted to explain this with the following paragraph, but it may not have been sufficiently clear:
:Use of arrays in an algorithm (eg, sorting) does not alter the behavior of the arrays access (ie, it has constant time for all elements of a static array) to be that of the algorithm.  Inserting a new element into an already sorted list requires a variable amount of time (the proportionality factor will depend on the algorithm used).  This is a property of the algorithm, not of the array access.  Dynamic array access will  depend on  the algorithm used to implement dynamic array accesses. Derek farn 00:43, 27 July 2007 (UTC)
replies: text: If there is an upper bound on the size of a list, the list may be stored in a subrange of an array, typically at the beginning. This enables constant-time insertions and deletions at the end of the list, but requires Ω(n) time to insert or delete in an arbitrary location, whereas a linked list can do this in constant time.
I would appreciate any feedback on how better to organize and express this point. Dcoetzee 23:38, 26 July 2007 (UTC)

text: I think the article should cover both statically and dynamically sized arrays, after all it is about arrays.  However, it should point out that statically sized is by far the most common and so spend more time discussing this case.  There are commonly used languages (eg, awk) where all arrays are dynamically sized.  The article currently contains general statements that are in fact only true for certain languages.  These need to be corrected.  In fact the whole article could do with a rewrite. Derek farn 00:43, 27 July 2007 (UTC)
replies: text: Dynamic arrays are not the same thing as dynamically-sized (runtime allocated) arrays - they're an entirely separate data structure built on top of fixed-size arrays (which include both static- and dynamically-sized arrays). We should not conflate these distinct concepts. Dcoetzee 00:52, 27 July 2007 (UTC)
replies: text: All arrays are dynamic in that storage for them is allocated during program execution (ok, this might be during program startup).  I guess there are two kinds of arrays that might be called dynamic, rather than static.  Arrays whose size is only known when the storage is allocated (ie, it is not known at compile time) and arrays whose size can increase as more elements are added (some languages use a different term to describe these arrays).  Arrays whose size is known at compile time are often called static arrays (of course, just to make life complicated, in C++ the term static array is used to refer to a particular kind of fixed sized array). Derek farn 10:53, 27 July 2007 (UTC)
replies: text: Yeah, there'a bunch of conflicting terminology usage common to different language communities, as evidenced by the multitude of names for the dynamic array and the whole static/dynamic mix-up. I'm leaning towards agreeing with MisterSheik that it's more appropriate to compare linked lists with dynamic arrays, since they actually support the same operation set, and that the storage of a list in a subarray is what dynamic arrays do also. I will add a bit of text to link appropriately. Dcoetzee 00:44, 28 July 2007 (UTC)
thread_title:  Linear time insertion/deletion 

message: Hoped I could fit this all in an edit summary. The attempted merge of array and dynamic array, followed by an incomplete cleanup, left the article in an odd state. I reverted and merged in unrelated changes. Then I discovered the article was still attempting to assert the nonstandard position that "dynamic arrays are a type of array", which is controversial at best, so I've eliminated any claim one way or the other and added a suitable disclaimer. I'm not happy with a number of other changes, like the new informal-to-the-point-of-misleading characterization of multidimensional arrays, but one problem at a time. The modified section title "comparison with linked lists" was modified again to fit my changes and the bizarre introduction of out-of-bounds accesses as only a "source of bugs" was moved and rewritten. Dcoetzee 10:06, 1 August 2007 (UTC)
thread_title:  More cleanup 

message: The first section of the article was rather bizarre:

==Arrays==
Variables normally only store a single value but, in some situations, it is useful to have a variable that can store a series of related values - using an array. For example, suppose a program is required that will calculate the average age among a group of six students. The ages of the students could be stored in six integer variables in C programming language:
<source lang="c">
int age1;
int age2;
int age3;
...
</source>
However, a better solution would be to declare a six-element array:
<source lang="c">int age[6];</source>
This creates a six element array; the elements can be accessed as <code>age[0]</code> through <code>age[5]</code> in C.
(Note: in [[Visual Basic .NET]] the similar declaration <code>Dim age(6) as Integer</code> will create a seven element array, accessed as <code>age(0)</code> through <code>age(6)</code>.)
===Implicit array===
A new array object is implicitly created when an array initializer expression is evaluated; this can occur when a class or interface is initialized, when a new instance of a class is created, or when a local variable declaration statement is executed.

At best, this (excluding paragraph before and after the subsection "Implicit array") is an elementary example of use of an array, but it's probably not complete enough to be useful for anyone who doesn't already know what it seeks to explain. (A more realistic example could be to compute the average score over 6 tests.) If the section is reinserted, it should probably be named "Example" or similar.
The Visual Basic .NET paragraph hints at the split (similar to 0/1/n-based indexing) over whether the number in an array declaration should be the size of the array or the index of the last element. This would be useful to mention in the article, but not in such a specialised context.81.231.33.217 (talk) 12:48, 30 June 2008 (UTC)
thread_title:  "Array" section of article 

message: The article contains one reference, so is it appropriate to remove the Unreferenced tag?
Also, would it be appropriate to increase its quality rating? It seems to meet C-class criteria easily. 81.231.34.61 (talk) 21:10, 10 September 2008 (UTC)
thread_title:  Remove Unreferenced tag? 

message: The article states:
:"The 0-based/1-based debate is not limited to just programming languages. For example, the ground-floor of a building is elevator button "0" in France, but elevator button "1" in the USA."
Which is wrong. In french, there is a word rez-de-chaussée meaning "groung floor", while étages are levels over the ground floor. Thus, on elevator buttons, étages are pointed to by ordinals from 1 up, while the unique rez-de-chaussée is (rather logically) referenced either by "RdC" or  "0". In other words, what is adressed by the article's statement is a difference of word semantic scope. While it obviously tried to state that : "There are cases in real life where zero is used as an ordinal". Which may be right (?) -- yet precisely not in the case cited as a typical instance!
For couter-arguments, just watch languages. In english, ordinals and cardinals are equally called "numbers" -- compare with german Nummer/Zahl or french numéro/nombre. Yet one may still notice that zero's novelty is witnessed by the everyday use (actually un-use): people don't say "zero apple", "zero person", or "zero time"..., do they? Rather "no apple", "nobody", "never"...
--Denispir (talk) 21:31, 8 October 2008 (UTC)
thread_title:  Index of the first element / example in french elevators 

message: In Array#Index_of_the_first_element I'd like to add the point that zero-base is also more natural for applications where an arbitrary subscript is reduced to the appropriate range with a mod operator; but I don't see where it will fit well.  Comments?  —Tamfang (talk) 08:12, 1 November 2008 (UTC)
replies: text: Do you have a good example? Rgrig (talk) 01:24, 24 April 2009 (UTC)
replies: text:  For example, some kinds of hash table often reduces a number to the appropriate range of array index (the range varies over time with dynamic resizing) with a mod operator. --DavidCary (talk) 08:32, 23 January 2021 (UTC)
thread_title:  modulation 

message: I did an extensive cleanup of the article, trying to clearly distinguish the two concepts "array data structure" (language-independent stuff) and "array data type" (language-dependent stuff).  While much remains to be done, I now think that the article should be split along that line.  The two concepts are clearly separable and each has enough meterial to fill a large article.  The separation should also help reduce editorial conflicts, that often seem to arise from confusion between the two concepts.  What do you think? All the best, --Jorge Stolfi (talk) 04:53, 12 May 2009 (UTC)
replies: text: Just to clarify, would this be a fair characterization of the 2 topics?: Array-the-datatype is the C-like low-level datatype implemented as a sequential block of memory. Array-the-data-structure is the more abstract notion of an ordered collection of items accessible by integer indices (without regard to the underlying implementation; e.g. it is represented using an associative array in some languages, though this is uncommon); these sorts of arrays are often also Lists. --Cybercobra (talk) 05:44, 12 May 2009 (UTC)
replies: text: No, "array data type" would be about the many ways that programming languages define array-like *types*, and (broadly) how they implement them. In that page one would discuss 0-based vs 1-based vs n-based, A(i) vs A[i], syntax for array declarations, slicing and array construcutors, parameter passing, static vs. runtime-sized arrays, etc. That page would be the present "Array data types" section, duly expanded."Array data strcuture" would be mostly about the concrete data strcuture that consists of a collection of elements whose addresses are computed from integer index tuples — without mentioning programming languages, compilers, libraries, type systems, etc..  (That is, stuff that Von Neumann could have written back in 1954. 8-)  It may still retain a section on "Abstract array data structure" which is what you mentioned above (like the section in the present article), but probably augmented with slicing operations and performance requirements that will practially exclude hash table implementations.In short, one is about the high-level-language-programmer's view, the other is about the machine-language-programmer's view.  Makes sense? --Jorge Stolfi (talk) 07:08, 12 May 2009 (UTC)
replies: text: Ok, that seems reasonable but I'm a bit iffy on the proposed page titles/nomenclature. I would have thought that the datatype article would cover the low-level view and the structure article would cover the high-level view, since datatypes are generally lower-level than data structures.--Cybercobra (talk) 09:13, 12 May 2009 (UTC)
replies: text: Funny, I have exaclty the opposite view ( perhaps for being in the other hemisphere? 8-).  To me, data structures are low-level, language-independent concepts that existed well before high-level languages and type systems, and can be perfectly described, implemented and analyzed without ever using the word "type". (That was indeed a conscious decision that Knuth made in the ACP books.  Perhaps not good for marketing, but made for a more concrete and precise view.) Data types are high-level concepts that exist only within a specific programming language and its compiler, and were invented precisely to hide the implementation details of data strcutures such as integers, arrays, records, strings, etc..  Thus, for example, the distinction between signed and unsigned integers is meaningful mostly when discussin data types in particular languages; as data structures, they are the same (N-bit arrays packed into a word so that the ADD instruction can operate on them).  When implementing a data structure in a high level language, one must necessarily do so through that language's type abstractions, but that does not mean that the data strcuture is built "from" the data types -- rather, it is built "through" them, or even "emulated" with them.Perhaps you are thinking of "abstract data type" and "abstract data structure", which are the same concept (as far as I can tell) but quite distinct from both "data type" and "data structure".  ADTs are theoretical concepts, much as real numbers or linear operators. All the best, --Jorge Stolfi (talk) 18:17, 12 May 2009 (UTC)
replies: text: I agree with Jorge Stolfi. "Data type" tells you what operations are supported, but not how. So you can have a data type of finite sets, supporting element insertion and deletion and test for membership. This data type has many possible implementations, which have different efficiency characteristics. It is possible that a processor directly realizes the operations of a given data type, but that is only exceptionally the case. A "data structure" specifies a specific way of laying out the storage of a container data type in linear RAM memory using pointers and such, thereby giving an implementation for that data type. For example, the article Heap (data structure) tells us: "The several variants of heaps are the prototypical most efficient implementations  of the abstract data type  priority queues."  --Lambiam 21:49, 17 May 2009 (UTC)
thread_title:  Proposal to split the article 

message: The abstract array axioms in the current version are:
::get(set(A,I, V), I) = V
::get(set(A,I, V), J) = get(A, J) if I ≠ J
:for any array state A, any value V, and any tuples I, J for which the operations are defined.
Methink that this is not OK because:
*To write an sbtract algorithm that scans an array, one needs to know the set of valid indices.  This requires additional operations and possibly other axioms.
*These axioms say nothing about time and space costs, so they allow implementations where the cost of get/set is proportional to the size of A (or worse). This is not good when analyzing the performance of algorithms that use arrays.
*The axioms also allow an Awk-style array that creates any element that gets assigned to, but fails when reading a non-existent element.
*In fact they are satisfied by a "pea-brained" Awk array where each set(A,I,V) creates A[I] and destroys all other elements.
My idea for fixing the last two bugs was to introduce a "FAIL" value to be the result of accessing an invalid index,  and postulate that get(FAIL,I) = set(FAIL,I,V)=FAIL for all I,V; and then remove the phrase "for which the operations are defined".  However then the first axiom is violated if I is an invalid index.
Does the paper say anythng about these problems? --Jorge Stolfi (talk) 02:54, 13 May 2009 (UTC)
replies: text: The axioms are pretty standard (at least in the research communities dealing with program correctness), except the names used are typically not get and set. Let's take your complaints one by one. (1) Yes, you will need additional axioms to specify particular types of arrays. These axioms only capture the essence of an array. (2) Yes, correctness and efficiency are orthogonal issues. (Although there are attempts to analyze efficiency using logic, but they are rather clumsy at the moment.) (3) Yes. Again, they are supposed to be general enough to describe the essence of what "array" means. (4) No, you are mistaken and I do not see how you reached this conclusion. Finally, regarding your fix: While introducing a special value is certainly possible, note that the current axioms simply cannot be applied to deduce that something is read from a location that was not written, and as such it cannot be proved using this axioms that the read value from an unwritten location is constrained in any way. Just Google for "array axioms" and you will find a plethora of resources, pretty much all using the same axioms. Rgrig (talk) 16:58, 10 September 2009 (UTC)

text: Also, looking at the history of the article I see that at some point it said that I stands for a tuple of integers (!!!) and other such nonsensical things. Perhaps it's better it was removed in the end. Rgrig (talk) 17:08, 10 September 2009 (UTC)
thread_title:  Abstract array axioms 

message: :Feel free to state your position on the renaming proposal by beginning a new line in this section with *Support or *Oppose, then sign your comment with ~~~~. Since polling is not a substitute for discussion, please explain your reasons, taking into account Wikipedia's naming conventions.
*Support per my above rationale. See also data type and note how its classes include comparatively low-level types/concepts. --Cybercobra (talk) 05:44, 16 May 2009 (UTC)
thread_title: Survey

message: The implementation of the iliffe array presented here makes the assumption that each row is allocated separately. However, Numerical Recipes in C provide a version of such vector with better locality by allocating the data as a contiguous memory block and have the indexing array points to beginning of rows in this block. Tests show few to no overhead between this and a traditional Dope vector. Would it be worthwhile to speak of this distinction ?
Joel falcou (talk) 18:27, 4 January 2012 (UTC)
thread_title: iliffe array

message: (Referring to the 3rd paragraph) Arrays are not analogous to mathematical vectors, matrices or tensors, but rather to the objects called tuples in mathematical terminology. I appreciate that they have often been named this way, and there may even be cases where it is helpful to explain them like this, but the statement as it stands is not correct. I believe at the least there should be a mention of tuples. I am not aware of the mathematical term for multidimensional tuples.
Example:
Vectors and the related objects are linear objects. An array of customer details is valid in computer science, but it has no meaning to act on it using coordinate transformations, linear functions, inner products or any of the other machinery associated with linear mathematics. Conversely Maxwell's equations contain vectors but do not contain any arrays (or tuples). When a vector can be represented as a tuple/array, it must have elements that are members of a field, this is not the case for a general array.
I see that the paragraph doesn't have a reference, so unless there is some disagreement or discussion I will delete it, or possibly edit it.
David Drakard  — Preceding unsigned comment added by 86.182.183.171 (talk) 22:20, 2 October 2012 (UTC)
thread_title:  Arrays not analogous to vectors or matrices 

message: I know this is a common myth, but am surprised to see it in a Wikipedia article. Moreover, how can we read both O(n) for indexed access and O(1) for insertion/deletion in the middle, since to insert or delete item #i in a list, one must first get there, meaning perform indexed access.
Can someone expose this better? I would happily do it, but since I have no reference, edits would probably be quickly removed by ll fans, and I don't want to start an edit war (better abstain).
denis 'spir' (talk) 18:09, 9 December 2012 (UTC)
thread_title:  linked list O(1) insertion/deletion in the middle? 

message: ... row- or column-major layout for each array."
Very nice, but in what actual programming language is that possible"
:Several languages and libraries for numeric computing, e.g. NumPy. I'm not aware of compilers that do this. QVVERTYVS (hm?) 10:51, 25 February 2016 (UTC)
thread_title:  "A programmer (or a sophisticated compiler) may use this information to choose between ... 

message: The following Wikimedia Commons file used on this page has been nominated for deletion:
* 
Participate in the deletion discussion at the . —Community Tech bot (talk) 23:38, 26 July 2019 (UTC)
thread_title:  A Commons file used on this page has been nominated for deletion 

message: We should have a section that discusses different conceptual representations of arrays i.e. manifest and delayed. On a high level:
Manifest arrays
* exists in memory; 
* contain trash from the memory without initialisation
* can be hidden behind functions to act as delayed arrays
Delayed arrays
* do not have to actually exist;
* are represented by a function of type (!! :: ix -> a) where ix is the index type and a is the type of the values of the array;
* Multidimensional array access translates to function composition
Delayed arrays seem to become more and more prominent in languages such as Haskell, Accelerate, Single Assignment C, Halide, Repa, Massiv and Futhark.
--Cluzz (talk) 15:33, 21 January 2020 (UTC)
thread_title:  Discuss delayed and manifest arrays