[erlang-questions] Spurious '100' in array:new

[Jesper Louis Andersen]

On Sat, Jan 26, 2019 at 6:29 PM Fred Youhanaie <fly@REDACTED> wrote:

> That's part of the internal structure of the array module, the data
> structure is opaque and should not be relied upon.
>
>
For full reference, you can glean on the internal structure:

Erlang/OTP 21 [erts-10.2.1] [source] [64-bit] [smp:8:8] [ds:8:8:10]
[async-threads:1] [hipe] [dtrace]

Eshell V10.2.1  (abort with ^G)
1> rr(array).
[array]
2> array:new(19, {default, {0, unspecified, 0}}).
#array{size = 19,max = 0,
       default = {0,unspecified,0},
       elements = 100}
3> array:new(9, {default, {0, unspecified, 0}}).
#array{size = 9,max = 0,
       default = {0,unspecified,0},
       elements = 10}

Here is what is happening: In Erlang, an Array is a very flat tree with a
branching factor of 10. It is stored in `elements`. But instead of storing
a tree, you may store an integer encoding how much more space is allowed in
this part of the tree when it is expanded. You have created a tree of size
19, which means it needs two expansions of size 10, or 100---though not all
of those expansions will be used, as it is extra padding. If you had
created an array of size 101, it would have been 1000, and so on. It is
always the next log10 ceiling value. In the example with size 9, only one
expansion is needed in which case we have a `10` in the elements.

You might ask why it isn't represented as a traditional array. This is
because of persistence in data structures: older versions of the tree can
be kept alive, so you cannot overwrite an older array. It is useful in a
number of situations, the most important one being that you can know the
state of a crashing process before it crashed, and what event led to said
crash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190128/db820168/attachment.htm>