* Understanding table debugging

[DavidNewton]

Let me say that this question is about understanding tables and debugging and not specifically about the example I am using.

I have constructed a local table of individuals indexed by Ahnentafel number relative to a root using entries of the form AN[Anumber]=pi:Clone(). When I break the script at the end of the table construction and examine the variables the entry reads:
AN,,local,(table #107,121).
Reading the help file states that this means the number of array elements is 107 and the total number of elements is 121. Does this mean there are 14 elements of the table which are not array elements? If so, where are they?

I have examined the table and every row has an entry similar to
[1] (item) => individual David Newton
I have not manually counted them but I expect there to be 121, a companion index table constructed simultaneouslly is described as (table #121).

I'm sure I'm missing something obvious so if you can explain this to me as a beginner I would be grateful.

David

[tatewise]

OK David, Lua tables are extremely powerful and complex data structures that can be used in many different ways.

There is a summary in the FH Plugins > How to Write Plugins > Introduction to Lua > Lua Quick Guide > TABLES

However, fundamentally tables hold two types of entry: Arrays and Dictionaries.

Arrays are indexed by consecutively numbered entries starting at 1 and accessed using ipairs.
e.g.
local tblTest = {}
tblTest[1] = "A"
tblTest[2] = "B"
tblTest[3] = "C"
or simply
local tblTest = {"A","B","C"}

Dictionaries are indexed by anything (including numbers) and accessed using pairs.
e.g.
local tblTest = {}
tblTest[1] = "A"
tblTest["X"] = "1"
tblTest["Alpha"] = "2"

The debug display for a table identifies the number of Array entries using #99 and Dictionary entries using .99.
So (table #107, .121) means there are 107 Array entries numbered 1 - 107 and 121 Dictionary entries.

To see the 107 Array entries use :

Code: Select all

for i,j in ipairs (tblTest) do
	print(i,j)
end

To see the 121 Dictionary entries (which includes the Array entries) use :

Code: Select all

for i,j in pairs (tblTest) do
	print(i,j)
end

In terms of Ahnentafel numbers, this means that the first 107 are consecutive, but the last 14 are not consecutive, which is quite normal.

[DavidNewton]

Mike

Many thanks for the clear explanation. It is a great help to be able to understand the debugging variable lists.

David

[DavidNewton]

Mike

Sorry but I still have a problem. I inserted your ipairs code immediately after the table was constructed and it gave me 53 entries. On checking the table again the first gap in fact occurs at 54 so that is consistent with a consecutive array of 53 elements but not an array of 107 (is the fact that 107=2*53+1 at all relevant?. After that there are of course longer gaps and the index is not only not consecutive but also not in order of entry, which I have to say surprised me as I thought in the absence of any instruction to the contrary tables were constructed as a last in first out queue.

David
.

[tatewise]

Presumably the last part of your question is related to the for i, j in pairs (tblTest) do mode of retrieval.
When I give a Help reference may I suggest you go and read it thoroughly. It says:

Note: that there's no guarantee as to the order in which keys will be stored in a table when using dictionaries so the order of retrieval of keys using pairs() is not defined.

I cannot explain the 53 versus 107 discrepancy. (nothing to do with 2*53+1). Are there 121 entries in total?
Are you sure that if you break within the for i, j in pairs (tblTest) do statement that the tblTest does show #107 and not #53 bearing in mind it is possible to have more than one table with the same name but different scope.

Perhaps you could post the table listing and its debug entry here.

[DavidNewton]

MIke

I have of course read the reference that you gave me. The script I am using works perfectly well I was simply trying to understand the table debugging for future reference. Thank you for your help.

David

[tatewise]

David, the Help I quoted answered your question about the order of Dictionary table entries using pairs.
Was that explanation clear?

It would be nice to resolve why the table debug info does not match your pairs table listing.
It might help me answer future questions.

[DavidNewton]

Mike

The explanation was quite clear but it does not prevent me being surprised at the order. There is no other table of the sme name. The debugging details are as I said in my first post.

I have constructed a list of the index numbers from an inspection of the table. In the table these numbers are followed by (item) => Individual 'name' and are one per line.

AN => (table #107, .121)
[1], [2] ,[3] ,[4] ,[5] ,[6] ,[7] ,[8] ,[9] ,[10] ,[11] ,[12] ,[13] ,[14] ,[15] ,[16] ,[17] ,[18] ,[19] ,[20] ,[21] ,[22] ,[23] ,[24] ,[25] ,[26] ,[27] ,[28] ,[29] ,[30] ,[31] ,[32] ,[33] ,[34] ,[35] ,[36] ,[37] ,[38] ,[39] ,[40] ,[41] ,[42] ,[43] ,[44] ,[45] ,[46] ,[47] ,[48] ,[49] ,[50] ,[51] ,[52] ,[53] ,[56] ,[57] ,[58] ,[59] ,[60] ,[62] ,[63] ,[64] ,[65] ,[66] ,[67] ,[68] ,[69] ,[70] ,[71] ,[72] ,[73] ,[76] ,[77] ,[78] ,[79] ,[82] ,[83] ,[84] ,[85] ,[88] ,[89] ,[92] ,[93] ,[96] ,[97] ,[100] ,[101] ,[102] ,[103] ,[104] ,[105] ,[106] ,[107] ,[193] ,[147] ,[213] ,[186] ,[372] ,[194] ,[136] ,[140] ,[373] ,[591] ,[590] ,[187] ,[374] ,[195] ,[137] ,[141] ,[375] ,[390] ,[391] ,[275] ,[192] ,[295] ,[294] ,[274] ,[146] ,[212] ,[272] ,[132] ,[133]

As you can see they are consecutive up to 53 and that is what the ipairs(AN) brings out. My only other observation is that after the gap at 54,55 the numbers are the in order up to 107 and pretty much random after that.

David

[tatewise]

The Plugins Help How to Write Plugins > 6. Debugging > The Variable Pane (and A Brief Introduction to Functions) confirms my explanation near the end:

As well as the word table, you should see either a dot followed by a number (e.g. “(table .3)”), or a hash followed by a number (e.g. “(table #4)”, or both (e.g. “table #6, .7”). A number preceded by a dot gives the number of elements in the table (e.g. ‘.3’). In Lua tables can be used as arrays. If a given table is being used as an array, the number of array elements is given as a number preceded by the hash character (e.g. ‘#4’). Where a table is shown with both a dot value and a hash value, this means that the table has both array elements and non-array elements. The hash value gives the number of array elements, whereas the dot value gives the total number of elements.

However, I have been experimenting, and just like you the displays do NOT agree with this description.
From the description the hash (#) value cannot exceed the dot (.) value, but I have easily achieved that:
tblNumb => (table #16, .14)
[1] (item) => Individual: Ian Stephen MUNRO
[2] (item) => Individual: Anthony Edward MUNRO
[3] (item) => Individual: Susan Isabel DOWLING
[5] (item) => Individual: Catherine REARDON
[6] (item) => Individual: Richard DOWLING
[8] (item) => Individual: Charles William MUNRO
[9] (item) => Individual: Margaret PLEASANCE
[10] (item) => Individual: James REARDON
[11] (item) => Individual: Elda COLE
[12] (item) => Individual: George DOWNLING
[13] (item) => Individual: Caroline WALLINGTON
[16] (item) => Individual: Arthur Michael MUNRO
[123] (item) => Individual: Ian Stephen MUNRO
[122] (item) => Individual: Ian Stephen MUNRO
I shall report this problem to Calico Pie.

BTW: You can double-click on any variable name in the variable pane to display its details, particularly useful for tables.

[DavidNewton]

Mike

Thanks for persisting with this. This is not good news and I hope that Calico Pie will quickly resolve the problem.

David

[tatewise]

I have solved the above apparent problem.
The table hash (#) size debug number is not always as defined by the Plugins Help that I identified above, and perhaps needs revising, which I shall mention to Calico Pie.

It is in fact the length of the array as given by the # operator, which has several alternative values when there are gaps in the integer indices. As stated by the Lua 5.1 Reference Manual 2.5.5 The Length Operator:

The length of a table t is defined to be any integer index n such that t[n] is not nil and t[n+1] is nil; moreover, if t[1] is nil, n can be zero. For a regular array, with non-nil values from 1 to a given n, its length is exactly that n, the index of its last value. If the array has "holes" (that is, nil values between other non-nil values), then #t can be any of the indices that directly precedes a nil value (that is, it may consider any such nil value as the end of the array).

[DavidNewton]

Mike

Well that is interesting, so this is not a problem in FH but a consequence of a well-defined operation in Lua with no guarantee as to the result. In the example I gave you the # could just as easily have been returned as 53, or in fact various numbers, including the 107 given, up to 595.
So I guess the # is best ignored when debugging and writing code unless you are certain you have a fully indexed table, starting at 1, with no gaps.

David

[tatewise]

Exactly correct David.

BTW: I know you were only using it as an example, but did you know that FH will calculate Ahnentafel numbers for you?

[DavidNewton]

Mike

I did know that and I used the built-in function to calculate my ancestors by scanning the file looking for ahnentafel numbers - very inefficient I now know but the only method I could think of at the time. Once I had a working script I tweaked it by using a direct method to calculate the ancestral tree and the numbers came out in the wash, as it were. There was also a major speed-up in the processing and other advantages. It was while tweaking that I started to wonder about the meaning of the # etc.

David