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

Donald Steven t6sn7gt@REDACTED
Mon Jan 28 21:26:25 CET 2019


Thanks Jesper, that's most helpful to know.  Is there a particular way 
to print it in io:format that will *not* show the 'extra stuff'. (I used ~p)

Best,

Don

On 1/28/2019 11.01 AM, Jesper Louis Andersen wrote:
> On Sat, Jan 26, 2019 at 6:29 PM Fred Youhanaie <fly@REDACTED 
> <mailto: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.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190128/decab0aa/attachment.htm>


More information about the erlang-questions mailing list