Re: Lua Basics: tables as lists?

[Warren Merrifield <wmerrifield@...>]

Oops -- just reread that code, and that doesn't work. Sorry. In that
case, a for loop or reverse look-up table is the normal way to go.

mylist = {"a", "b", "c"};
a = "a"
for i,v in ipairs(mylist) do
   if v == a then
      print "a is in the list."
   end
end

_OR_ the reverse look-up table method:

function buildrev(tbl)
   local t = {}
   for i,v in ipairs(tbl)
      t[v] = true
   end
   return t
end

mylist = {"a", "b", "c"};
a = "a"

local revlist = buildrev(mylist)
if revlist[a] == true then
    print "a is in the list."
end

you could then, if you wanted to get a bit more fancy, set up
metamethods on mytable so that it creates and stores the reverselist
internally and updates it automatically when mylist is changed.


On 23/08/05, Warren Merrifield <wmerrifield@gmail.com> wrote:
> I may be getting the wrong end of the stick here, but isn't it as
> simple as writing:
> 
> Python:
> a = "a"
> if a in ["a", "b", "c"]:
>    print "a is in the list"
> 
> Lua:
> mylist = {"a", "b", "c"};
> a = "a"
> if mylist[a] ~= nil then
>    print "a is in the list"
> end
> 
> Warren
> 
> On 23/08/05, Rici Lake <lua@ricilake.net> wrote:
> >
> > On 22-Aug-05, at 9:52 PM, William Trenker wrote:
> >
> > > It's easy to set up lua lists:
> > > mylist = {"a", "b", "c"}
> > > What I'm wondering is what is the design-intended best practice for
> > > testing for list membership.  And what is the fastest way to do this?
> >
> > If you don't actually care about the order of the objects (which is a
> > surprisingly common case), then do it like this:
> >
> > myset = {a = true, b = true, c = true}
> >
> > -- is an object in the set?
> >    if myset[obj] then ...
> >
> > -- get all the objects out of the set (in undetermined order):
> >    for k in pairs(myset) do ...
> >
> > Note that you cannot add objects to the set during the iteration, which
> > is a bit annoying if you're doing a workqueue. However, you can fake it
> > by using three sets.
> >
> > This assumes that we're storing a digraph as a table of sets, such that
> > digraph[node_a][node_b] is true if there is a line node_a -> node_b.
> > Then the following function computes the set of nodes reachable from a
> > given node.
> > It may not be the fastest way of doing it, but it seemed like a simple
> > example:
> >
> > function reachable(digraph, node)
> >    local empty = {}
> >    local done, work, pending = {}, {}, {}
> >    local function insert(stateset)
> >      if not done[stateset] then
> >        done[stateset], pending[stateset] = true, true
> >      end
> >    end
> >
> >    insert(node)
> >
> >    repeat
> >      pending, work = {}, pending
> >      for node in pairs(work) do
> >        for next_node in pairs(digraph[node] or empty) do
> >          insert(next_node)
> >        end
> >      end
> >    until not next(pending)
> >
> >    return done
> > end
> >
> > ("not next(pending)" is true if pending is empty, assuming that false
> > is not a possible key. If false were possibly you'd have to say "until
> > nil == next(pending)", which would be more readable but slightly
> > slower.)
> >
> >
> > > Assuming that for-loops are run-time expensive for large lists, is
> > > something like this considered good practice?
> >
> > For loops are not expensive
> >
> > > myList = {"a", "b", "cde"}
> > > myListString = "|" .. table.concat(myList, "|") .. "|"
> > > a = "cde"
> > > if string.find(myListString, "|"..a.."|") then
> > >     print("found!")
> > > else
> > >     print("not found")
> > > end
> >
> > That is very expensive
> >
> >
> 
> 
> --
> ()()       Warren Merrifield
> ( '.')
> (")_(")   wmerrifield@gmail.com
> 


-- 
()()       Warren Merrifield
( '.')
(")_(")   wmerrifield@gmail.com