dear community,
In ruby I think the Array is just a List.
Is there a real Array class in Ruby such as the one C or Java has?
ありがとう
えりな
In ruby I think the Array is just a List.
Is there a real Array class in Ruby such as the one C or Java has?
How would you define a "real" Array class?
Under the hood for a Ruby Array "a separate C array is allocated in memory to keeps pointers to each array element." [1]
Likewise, in JRuby, a [Ruby]Array has an underlying Java array. [2]
Assuming the elements are homogeneous,
[1] Looking into Array memory usage in Ruby - ivo's awfully random tech blog
[2] https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyArray.java#L526
ありがとう
いつでもどうぞ
···
"Yamadaえりな" <yamoerina@gmail.com> wrote:
I would suggest you take a look at IO::Buffer from Ruby 3.1
For the record, IO::Buffer is basically an interface around mmap(2)
···
On 1/13/22 03:48, Yamadaえりな wrote:
dear community,
In ruby I think the Array is just a List.
Is there a real Array class in Ruby such as the one C or Java has?ありがとう
えりなUnsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
I think what you mean. For the real array, you can use the Narray library.
Do Ittashi mashite,
saji
···
On Thu, Jan 13, 2022 at 11:49 AM Yamadaえりな <yamoerina@gmail.com> wrote:
dear community,
In ruby I think the Array is just a List.
Is there a real Array class in Ruby such as the one C or Java has?ありがとう
えりなUnsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
This very much depends on your definition of what you mean by "Array",
what you mean by "List", and what makes an Array "real" in your
opinion. Without a clear, precise, unambiguous, objective
specification of what, *exactly*, you mean by those three terms, the
question is essentially meaningless.
As you can see, you have received an answer which says that Ruby's
Arrays are definitely real Arrays and you have received an answer
which says that Ruby's Arrays are definitely *not* real Arrays.
Neither of these two answers provides a definition of those terms,
either, so those answers are mostly meaningless as well, since there
is no way of knowing whether the answerer's definition of "real Array"
and your definition of "real Array" are the same or whether you are
maybe just talking about two completely different things.
Fact is: the Ruby Language Specification (and it doesn't matter
whether you consider that to be the ISO Ruby Language Specification,
the ruby/spec, the Ruby Programming Language book by Flanagan and
matz, or the documentation of YARV) does not specify any particular
implementation strategy for Arrays nor does it specify any particular
performance guarantees. If an implementor wanted to implement array
methods by printing out the array on paper and faxing it to a
sweatshop in the Philippines to have the result calculated by hand,
that would be completely valid. It would be very stupid and morally
reprehensive and possibly violate some labor laws, but it would be a
valid implementation of Arrays.
However, *all* current mainstream Ruby implementations use roughly the
same implementation with the same performance guarantees. And any new
Ruby implementation that does not give the same guarantees would
probably not be accepted by the community. All current mainstream Ruby
implementations use what is commonly known as a "dynamic / resizable
array with geometric resizing"
(Dynamic array - Wikipedia) which has the following
performance guarantees:
* Random read: Θ(1) worst-case step complexity.
* Random write: Θ(1) worst-case step complexity.
* Iterating over a contiguous run of k elements: Θ(k) worst-case step
complexity.
* Deleting k elements from the end: Θ(1) worst-case step complexity.
* Deleting k elements in the middle at index i: Θ(n - k - i)
worst-case step complexity.
* Appending k elements at the end: O(n + k) worst-case step complexity
(but with a very rare worst-case), Θ(k) amortized worst-case step
complexity (almost all the time).
* Prepending k elements at the beginning: O(n + k) worst-case step
complexity, with a rare best-case step complexity of Θ(k).
* Inserting k elements in the middle at index i: O(n + k) worst-case
step complexity, Θ(n + k - i) amortized worst-case step complexity.
* Concatenating two arrays: O(n + m) worst-case step complexity, with
a rare best-case step complexity of Θ(m).
* Splicing an array into another array at index k: O(n + m) worst-case
step complexity, with a rare best-case step complexity of Θ(n + m -
k).
Also, Ruby arrays are generally allocated as one contiguous chunk of memory.
Note that everything I wrote also applies to Python as well. The fact
that Python calls them "lists" does not change the fact that they are
dynamic arrays: Python's lists have all of the performance
characteristics of dynamic arrays, they have none of the performance
characteristics of lists, and they are implemented almost like a
textbook example of dynamic arrays.
In other words, these are more or less the same performance guarantees
you get from an array in C or Java, so *personally*, I would consider
this "real enough".
Cheers.
···
Yamadaえりな <yamoerina@gmail.com> wrote:
In ruby I think the Array is just a List.
Is there a real Array class in Ruby such as the one C or Java has?
Jorg, you’re absolutely right. When asking if something is a “real” something, you have to describe the characteristics in which you are interested. Is it the architecture, the performance, the existence of certain methods, or how the comments read in the source code? Maybe you’re interested in knowing that it is stored as one contiguous block of memory, so that you can call C-level code that manipulates it as such.
Best guess is OP is interested in performance, as that’s usually the most significant difference between Array and List, and that is well answered by many others in this thread already. But be careful in the future to ask the question you really want answered, rather than the one that is likely to generate the “most" answers. 
···
On Jan 16, 2022, at 6:39 AM, Jörg W Mittag <ruby-talk@joergwmittag.de> wrote:
Yamadaえりな <yamoerina@gmail.com> wrote:
In ruby I think the Array is just a List.
Is there a real Array class in Ruby such as the one C or Java has?This very much depends on your definition of what you mean by "Array",
what you mean by "List", and what makes an Array "real" in your
opinion. Without a clear, precise, unambiguous, objective
specification of what, *exactly*, you mean by those three terms, the
question is essentially meaningless.As you can see, you have received an answer which says that Ruby's
Arrays are definitely real Arrays and you have received an answer
which says that Ruby's Arrays are definitely *not* real Arrays.
Neither of these two answers provides a definition of those terms,
either, so those answers are mostly meaningless as well, since there
is no way of knowing whether the answerer's definition of "real Array"
and your definition of "real Array" are the same or whether you are
maybe just talking about two completely different things.Fact is: the Ruby Language Specification (and it doesn't matter
whether you consider that to be the ISO Ruby Language Specification,
the ruby/spec, the Ruby Programming Language book by Flanagan and
matz, or the documentation of YARV) does not specify any particular
implementation strategy for Arrays nor does it specify any particular
performance guarantees. If an implementor wanted to implement array
methods by printing out the array on paper and faxing it to a
sweatshop in the Philippines to have the result calculated by hand,
that would be completely valid. It would be very stupid and morally
reprehensive and possibly violate some labor laws, but it would be a
valid implementation of Arrays.However, *all* current mainstream Ruby implementations use roughly the
same implementation with the same performance guarantees. And any new
Ruby implementation that does not give the same guarantees would
probably not be accepted by the community. All current mainstream Ruby
implementations use what is commonly known as a "dynamic / resizable
array with geometric resizing"
(Dynamic array - Wikipedia) which has the following
performance guarantees:* Random read: Θ(1) worst-case step complexity.
* Random write: Θ(1) worst-case step complexity.
* Iterating over a contiguous run of k elements: Θ(k) worst-case step
complexity.
* Deleting k elements from the end: Θ(1) worst-case step complexity.
* Deleting k elements in the middle at index i: Θ(n - k - i)
worst-case step complexity.
* Appending k elements at the end: O(n + k) worst-case step complexity
(but with a very rare worst-case), Θ(k) amortized worst-case step
complexity (almost all the time).
* Prepending k elements at the beginning: O(n + k) worst-case step
complexity, with a rare best-case step complexity of Θ(k).
* Inserting k elements in the middle at index i: O(n + k) worst-case
step complexity, Θ(n + k - i) amortized worst-case step complexity.
* Concatenating two arrays: O(n + m) worst-case step complexity, with
a rare best-case step complexity of Θ(m).
* Splicing an array into another array at index k: O(n + m) worst-case
step complexity, with a rare best-case step complexity of Θ(n + m -
k).Also, Ruby arrays are generally allocated as one contiguous chunk of memory.
Note that everything I wrote also applies to Python as well. The fact
that Python calls them "lists" does not change the fact that they are
dynamic arrays: Python's lists have all of the performance
characteristics of dynamic arrays, they have none of the performance
characteristics of lists, and they are implemented almost like a
textbook example of dynamic arrays.In other words, these are more or less the same performance guarantees
you get from an array in C or Java, so *personally*, I would consider
this "real enough".Cheers.
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
I think Yamada's original question was very well qualified:
*> In ruby I think the Array is just a List.*
*> Is there a real Array class in Ruby such as the one C or Java has?*
Even without this, the CS concepts of Arrays and (Linked) Lists make it
possible to provide a useful answer to the question.
No more is required of the questioner.
This question resonated with me because when I was new to Ruby I assumed
Array was implemented as a List. At that time I had not seen its features
(dynamic sizing, generics, Enumerable) in Arrays from other languages. A
talk by Aaron Patterson about Ruby internals enlightened me. His talks
about Ruby internal operations often answer questions I do not know I have
.
I enjoyed your question Yamada, ありがとう.
-gf-
···
On Sun, Jan 16, 2022 at 2:50 PM Jack Royal-Gordon <jackrg@pobox.com> wrote:
Jorg, you’re absolutely right. When asking if something is a “real”
something, you have to describe the characteristics in which you are
interested. Is it the architecture, the performance, the existence of
certain methods, or how the comments read in the source code? Maybe you’re
interested in knowing that it is stored as one contiguous block of memory,
so that you can call C-level code that manipulates it as such.Best guess is OP is interested in performance, as that’s usually the most
significant difference between Array and List, and that is well answered by
many others in this thread already. But be careful in the future to ask the
question you really want answered, rather than the one that is likely to
generate the “most" answers.> On Jan 16, 2022, at 6:39 AM, Jörg W Mittag <ruby-talk@joergwmittag.de> > wrote:
>
> Yamadaえりな <yamoerina@gmail.com> wrote:
>
>> In ruby I think the Array is just a List.
>> Is there a real Array class in Ruby such as the one C or Java has?
>
> This very much depends on your definition of what you mean by "Array",
> what you mean by "List", and what makes an Array "real" in your
> opinion. Without a clear, precise, unambiguous, objective
> specification of what, *exactly*, you mean by those three terms, the
> question is essentially meaningless.
>
> As you can see, you have received an answer which says that Ruby's
> Arrays are definitely real Arrays and you have received an answer
> which says that Ruby's Arrays are definitely *not* real Arrays.
> Neither of these two answers provides a definition of those terms,
> either, so those answers are mostly meaningless as well, since there
> is no way of knowing whether the answerer's definition of "real Array"
> and your definition of "real Array" are the same or whether you are
> maybe just talking about two completely different things.
>
> Fact is: the Ruby Language Specification (and it doesn't matter
> whether you consider that to be the ISO Ruby Language Specification,
> the ruby/spec, the Ruby Programming Language book by Flanagan and
> matz, or the documentation of YARV) does not specify any particular
> implementation strategy for Arrays nor does it specify any particular
> performance guarantees. If an implementor wanted to implement array
> methods by printing out the array on paper and faxing it to a
> sweatshop in the Philippines to have the result calculated by hand,
> that would be completely valid. It would be very stupid and morally
> reprehensive and possibly violate some labor laws, but it would be a
> valid implementation of Arrays.
>
> However, *all* current mainstream Ruby implementations use roughly the
> same implementation with the same performance guarantees. And any new
> Ruby implementation that does not give the same guarantees would
> probably not be accepted by the community. All current mainstream Ruby
> implementations use what is commonly known as a "dynamic / resizable
> array with geometric resizing"
> (Dynamic array - Wikipedia) which has the following
> performance guarantees:
>
> * Random read: Θ(1) worst-case step complexity.
> * Random write: Θ(1) worst-case step complexity.
> * Iterating over a contiguous run of k elements: Θ(k) worst-case step
> complexity.
> * Deleting k elements from the end: Θ(1) worst-case step complexity.
> * Deleting k elements in the middle at index i: Θ(n - k - i)
> worst-case step complexity.
> * Appending k elements at the end: O(n + k) worst-case step complexity
> (but with a very rare worst-case), Θ(k) amortized worst-case step
> complexity (almost all the time).
> * Prepending k elements at the beginning: O(n + k) worst-case step
> complexity, with a rare best-case step complexity of Θ(k).
> * Inserting k elements in the middle at index i: O(n + k) worst-case
> step complexity, Θ(n + k - i) amortized worst-case step complexity.
> * Concatenating two arrays: O(n + m) worst-case step complexity, with
> a rare best-case step complexity of Θ(m).
> * Splicing an array into another array at index k: O(n + m) worst-case
> step complexity, with a rare best-case step complexity of Θ(n + m -
> k).
>
> Also, Ruby arrays are generally allocated as one contiguous chunk of
memory.
>
> Note that everything I wrote also applies to Python as well. The fact
> that Python calls them "lists" does not change the fact that they are
> dynamic arrays: Python's lists have all of the performance
> characteristics of dynamic arrays, they have none of the performance
> characteristics of lists, and they are implemented almost like a
> textbook example of dynamic arrays.
>
> In other words, these are more or less the same performance guarantees
> you get from an array in C or Java, so *personally*, I would consider
> this "real enough".
>
> Cheers.
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>