Simple sort of table array

[vortizee]

zorg wrote: When called, table.sort internally calls that sorting function with elements from pcs.A; whether it’s consecutive in order or not, i don't know and frankly don't care, the point is it should sort the table.

I’m just trying to understand how it works so I can write other sorting functions when required. It does sort the table nicely, adding valuable finesse that was missing. As for the nomenclature, I’m an old brain in a new game, so the sequential table made an ambitious stretch of my capabilities easy to reach and understand. Thanks for the explanations, I love you guys. But. . . are you saying my sorting by the third element example (id as a string) in my last post was wrong!?

And ivan, thanks for the cache idea as it reminded me of a number of areas I missed caching that could benefit immensely from it.

[zorg]

But. . . are you saying my sorting by the third element example (id as a string) in my last post was wrong!?

If you mean this:

Code: Select all

table.sort(pcs.A, function (a,b)
  return a[3] < b[3]
end)

I believe that < works on strings too like you'd expect (lexicographically), so it should be good.

[vortizee]

Then I learned something, thanks!

[Positive07]

You should also note that, the code you wrote:

Code: Select all

table.sort(pcs.A, function (a,b)
  return a[3] < b[3]
end)

Is sorting the values inside of pcs.A and not those inside pcs. a and b are elements of pcs.A (any two elements) and are expected to be tables since you are indexing them. If you understand this and know what I'm talking about then you have got the idea of how table.sort works!

[vortizee]

Not quite there in a deep sense. I understand what’s happening in these simple sorts, but I’ll be hunting for more complicated examples in the web to gain further understanding. My interpretation is that the sort expects pcs.A to be a table to be sorted by the third element of the table (because the function references that index) in ascending order.

If I parse lines w (a table indexed by line number), split each line into a table of 9 elements by a split_by_space function where 3 is an xPosition and 4 is a yPosition, I could sort it as so?

Code: Select all

table.sort ( w, function( a, b )
	return kwikDistance ( a[3], a[4], xo, yo ) < kwikDistance ( b[3], b[4], xo, yo )
end)

If that would work then I’m making progress! Hey, I just discovered the EXPAND VIEW and COLLAPSE VIEW buttons in this forum!

What I could use is a sort of a more complicated structure built as

w[1][1] = { (9 elements where 3 and 4 are an xPos and yPos, and element 6, say, is a size) }
w[1][2] = { ( a table as above) }
w[1][3] = { (ditto) }
w[2][1] = { (ditto) }, w[2][2] = { (ditto) }, w[2][3] = … etc.

First sort by size when w[1] is fully populated before w[2] is created seems simple to do

Code: Select all

table.sort( w[1], function (a,b) return a[6] < b[6] end )

Then sort by distance of w[1][1] versus w[2][1] by the largest elements of each w only, without losing the first sort result

Code: Select all

table.sort( w, function (a,b ) return kwikDistance( a[1][3], a[1][4], xo, yo ) < kwikDistance ( b[1][3], b[1][4] )  end)

Wanting the result where w[1][6] > w[2][6] > w[3][6] … then ordered as w[1]s are nearer to xo, yo than w[2]s and w[2]s nearer than w[3]s as sorted only by the kwikDistance of w[1]. At this point I’m better off testing the output by trial and error. Seems I need a stand-alone interpreter to play with.

But if the table were to be created without the intermediate sort, and I wanted to sort it all in the end, then it gets even more interesting.

[s-ol]

Is this for a continuous/tile-based map? If your xPositions go from 1 to X and each appears once, and the same happens for yPosition, why use table.sort at all? Just iterate over lines and do

Code: Select all

if not map[xPosition] then map[xPosition] = {} end
map[xPosition][yPosition] = cell

Anyway, if this is not the case your example above looks correct to me.

I would recommend to use string keys wherever you split your lines so your code becomes readable instead of being a confusing mess of [3] and [4]s.

Just set it like

Code: Select all

w[1][1] = { x=12, y=14, size=636... }

This doesn't really impact performance and improves code readability a lot IMO.

[vortizee]

Thanks, s-ol Not tile based, unfortunately. I have to and do use string keys for the more complicated stuff, but when reading external data by lines I’m only comparing a few data points or building a hash file from it and so split the line by the file delimiter in the simplest way.