Rosetta Code:Village Pump/Arrays: Difference between revisions
No edit summary |
No edit summary |
||
Line 13:
:I think it would be fine to merge [[Creating an Array]], [[Assigning Values to an Array]], and [[Retrieving an Element of an Array]], mostly as a way to show off a language's built-in syntax for native arrays. I think some of the higher order array tasks ([[Select from Array]], [[Apply a callback to an Array]], [[Sorting an Array of Integers]], etc.) should instead operate on the most convenient collection available to the language, no matter whether it is an array, list or some other collection object. --[[User:IanOsgood|IanOsgood]] 17:16, 30 July 2009 (UTC)
::This is OK, with this we can show array syntax in a language and separate "fixed length" and "dyanamic arrays" in a single task. --[[User:Guga360|Guga360]] 17:47, 30 July 2009 (UTC)
I created a small [[Arrays]] page. It's something like this. This sounds OK. We should merge [[Creating an Array]], [[Assigning Values to an Array]], and [[Retrieving an Element of an Array]] to [[Arrays]] showing dynamic arrays, or we should delete [[Arrays]] and don't change anything? --[[User:Guga360|Guga360]] 18:13, 30 July 2009 (UTC)
|
Revision as of 18:13, 30 July 2009
In RC, Array tasks are not very organized. Let's see: Array, Creating an Array, Array Initialization, Collections, and a lot of examples in Creating an Array (mostly dynamic languages like Python) aren't really using Arrays, they are using just Lists, Vectors and etc. Arrays are not dynamic. A solution is create a Creating a List or etc. But other languages call it in a different way. This is not really a solution.
A real idea is merging Assigning Values to an Array, Creating an Array and all Array related tasks in an single task. (Arrays), and creating another task for any "dynamic array" (Lists/Vectors/Sets) called Dynamic Arrays, showing how to create and append values to it. There is a lot of confusion on array tasks in RC. This really need to be changed. --Guga360 02:35, 30 July 2009 (UTC)
- I don't like the single task idea. That single task could become very bloated when people try to show all the possible things you can do with an array (and all the ways you can do them). Creating an Array and Array Initialization already have efforts in the works to combine them (not really combine them...more like get rid of Array Initialization completely after all of its information has been reviewed by people who understand the examples that are left). There might be another way to simplify all of the array tasks without making them into one gigantic, memory-hogging, uneditable task. --Mwn3d 02:53, 30 July 2009 (UTC)
- I understand. But, about "dynamic arrays", what do you think? Python example is using Lists, but Python has an "array" module. C++ example is using both: arrays and vectors, C# example is showing only arrays, but C# has a List class. There is no OCaml example to create and append values to "dynamic arrays" in RC. I think splitting arrays and dynamic arrays it's a good idea. Arrays are not dynamic. But a lot of examples are using dynamic arrays (Lists/Vectors/Sets). This is not exactly right. --Guga360 03:05, 30 July 2009 (UTC)
- I prefer that we set tasks that allow some flexibility in how they are accomplished w.r.t. language datatypes. What if a languages array type were dynamic in that it could automatically grow in length to accommodate any index, but always used a computed offset into contiguous memory for indexing? What if an array could use two or more regions of memory and the array indexing take account of the fact that, for example, different ranges of indices might be in separate memory blocks? It shouldn't matter too much, unless the task is, (like in the number of sort tasks), how memory is used in the array, rather than a data-structure that is accessed roughly in a certain way. Conversely. If a task were to interface to a C function that took a pointer to a C array as an argument, then the language would have to make sure to send a pointer to a contiguous region of memory set with appropriate values - but the language in normal use may not use such 'arrays' except for interfacing to C. Why punish the language in this case? --Paddy3118 04:43, 30 July 2009 (UTC)
I advise being very careful. The problem is that language terminology varies wildly and permitted operations is, if anything, even more differentiated across the languages. What is an obvious merger for one might be a loss of an important subtlety for another. (It was the “aren't really using Arrays” that triggered this message, as it indicated that the author of it might be projecting how one language does things onto others, which is usually a mistake.) —Donal Fellows 09:56, 30 July 2009 (UTC)
- I agree with this entirely. (Also, if we're going to be specific about the kind of data structure, I would suggest (as opposed to "contiguous memory"): consecutive numeric indexing, arbitrary size, and no greater than O(log n) element access time.) --Kevin Reid 11:35, 30 July 2009 (UTC)
- I think it would be fine to merge Creating an Array, Assigning Values to an Array, and Retrieving an Element of an Array, mostly as a way to show off a language's built-in syntax for native arrays. I think some of the higher order array tasks (Select from Array, Apply a callback to an Array, Sorting an Array of Integers, etc.) should instead operate on the most convenient collection available to the language, no matter whether it is an array, list or some other collection object. --IanOsgood 17:16, 30 July 2009 (UTC)
- This is OK, with this we can show array syntax in a language and separate "fixed length" and "dyanamic arrays" in a single task. --Guga360 17:47, 30 July 2009 (UTC)
I created a small Arrays page. It's something like this. This sounds OK. We should merge Creating an Array, Assigning Values to an Array, and Retrieving an Element of an Array to Arrays showing dynamic arrays, or we should delete Arrays and don't change anything? --Guga360 18:13, 30 July 2009 (UTC)