Gammon Forum : MUSHclient : Lua : Lua tables -Continue

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Lua

Lua tables -Continue

Lua tables -Continue

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Dandrade (5 posts)

Date

Sun 05 Nov 2006 12:25 PM (UTC)

Message

Hello, read all topics about utilization tables. Is good

Add news problems: Request solve, manipulation tables

FIFO- First In Fisrt Out
See for understand http://www.google.com/search?hl=en&q=define%3A+FIFO&btnG=Google+Search
LIFO Last In Fisrt Out
http://www.google.com/search?hl=en&lr=&q=define%3A+LIFO&btnG=Search

1.0)Question. Implementation FIFO and LIFO for vetor

var={} and lim={n=10}

2.0)Question. Implementation FIFO

begin matriz

var={{1,2,3},{4,5,6}}
after 2 interations FIFO value =99
var={{99,99,1},{4,5,6}}
after 6 interations FIFO value =99
var={{99,99,99},{4,5,6}}

OR select matriz

var={{1,2,3},{4,5,6}}
after 2 interations FIFO value =55
var={{1,2,3},{55,55,4}}
after 6 interations FIFO value =55
var={{1,2,3},{55,55,55}}

OR all matriz

var={{1,2,3},{4,5,6}}
after 2 interations FIFO value =33
var={{33,33,1},{2,3,4}}
after 5 interations FIFO value =55
var={{33,33,33},{33,33,1}}

3.0)Question. Repet 2.0 question used concept LIFO

4.0)Ring. Implementation
m={1,2,3,4,5}
right rotate
m{5,1,2,3,4}

5)Question: About question 2.0. Have limit for use
matriz [2][3][4] or matriz [10][3][2][5], etc

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #1 on Sun 05 Nov 2006 08:00 PM (UTC)

Message

Quote:

Implementation FIFO and LIFO for vetor

FIFO (queue)

You can simply implement FIFO by using table.insert to add new items, and table.remove to remove the first one, like this:


t = {}

table.insert (t, "a")  --> insert an item
table.insert (t, "b")  --> insert another

x = table.remove (t, 1)  --> remove first item
print (x)  --> a

x = table.remove (t, 1)  --> remove first item
print (x)  --> b

LIFO (stack)

A small change implements last in, first out:


t = {}

table.insert (t, "a")  --> insert an item
table.insert (t, "b")  --> insert another

x = table.remove (t)  --> remove last item
print (x)  --> b

x = table.remove (t)  --> remove last item
print (x)  --> a

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Dandrade (5 posts)

Date

Reply #2 on Mon 06 Nov 2006 01:40 PM (UTC)

Message

Ok. And for limit the influence insert and remove?
Is possible? Like and need, get this resource.

table={1,2,3,4,5,6,7,8,9,10}

After table.insert only position range 3-6
value=100
table={1,2,100,3,4,5,7,8,9,10} table[6]=5
value=200
table={1,2,200,100,3,4,7,8,9,10} table[6]=4
value=300
table={1,2,300,200,100,3,7,8,9,10} table[6]=3
value=400
table={1,2,400,300,200,100,7,8,9,10} table[6]=100

The question 2.0, dont know implement, get like reply

Posted by Ked Russia (524 posts) bio

Date

Reply #3 on Mon 06 Nov 2006 02:00 PM (UTC)

Amended on Mon 06 Nov 2006 02:01 PM (UTC) by Ked

Message

This should work:



function range_insert(first, last)
  local func = function (tab, val)
    local tab = tab
    assert(last > first, "Illegal range - first index is greater than last.")
    assert(#tab >= last+1, "Last index in the range is greater than the length of the table.")
    table.insert(tab, first, val)
    table.remove(tab, last+1)
    return tab
  end
  return func
end

tab = {1,2,3,4,5,6,7,8,9,10}

insertf = range_insert(3,6)
insertf(tab, 100)
insertf(tab, 200)
insertf(tab, 300)
insertf(tab, 400)

Posted by

David Haley USA (3,881 posts)

Date

Reply #4 on Tue 07 Nov 2006 12:46 AM (UTC)

Message

Out of curiosity is this the same person/question as was on the Lua-L mailing list? :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #5 on Tue 07 Nov 2006 01:04 AM (UTC)

Message

Must be, I think. The wording is virtually identical.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Dandrade (5 posts)

Date

Reply #6 on Wed 08 Nov 2006 08:49 PM (UTC)

Message

Very very tranks the atention and best reply, never the get the result.Intesresting, now know new method implementation function.

Here is get more attetion, moment abandoned the acess list lua, here more simple and clear.

Posted by

Dandrade (5 posts)

Date

Reply #7 on Fri 17 Nov 2006 09:49 PM (UTC)

Message

Ked. Now request tiny alteration.
(It important for understand and make others functions)

How to implement sum, values for the range?

tab = {1,2,3,4,5,6,7,8,9,10}

insertf = range_insert(3,6)
insertf(tab, 100)
k=insertf.sum()
print (k) -- k= 100+4+5+6 k=115

-----------Make it and have error

function range_insert(first, last)
local func = function (tab, val)
local tab = tab
table.insert(tab, first, val)
table.remove(tab, last+1)
return tab
end
return {
sum = function()
for a=first,last,1 do
k=tab[a]+k
end
return k
end,
}
end

Posted by David Haley USA (3,881 posts) bio

Date Reply #8 on Sat 18 Nov 2006 02:33 AM (UTC)

Message

Please use the [code] forum tag when posting code, it makes things a lot easier to read and therefore easier for us to help you.

I'm not sure what exactly you are trying to achieve. You could help us help you by giving more information than simply saying you wrote the code and got an error; for instance you could say what error you got.

However, regardless of what you are trying to do, your code is not consistent. You have set up range_insert to return a table, one member of which is a function. You store the result in insertf. Then you write: insertf(tab, 100). That is an error because you are trying to treat a table as a function.

Furthermore your range_insert sub-function 'sum' isn't doing at all what you think it is. The variable 'tab' is not visible to 'sum' so you'll be summing over the global table tab instead of the table you created just before. Of course, it's very hard to debug this without understanding precisely what your range_insert idea is about in the first place.

Why can't you just write a separate function to sum the values in a table? Or, just make range_insert return two functions. The Lua manual explains how to return more than one parameter, it's really quite easy:


function foo() return 1,2 end
a,b = foo()

print(a) --> "1"
print(b) --> "2"

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Ked Russia (524 posts) bio

Date Reply #9 on Sat 18 Nov 2006 05:36 AM (UTC)

Message

I think what Dandrade wants is something like a list object, with all the range manipulation methods defined directly on it. Which makes sense, but certainly won't work with the way range_insert() is set up.

For it to work range_insert would need to return a table with a __call metamethod. It would also be better to pass the table you intend to work with to range_insert.


function range_insert(tab, first, last)
  local work_tab = tab
  local t = {}
  local mt = {}
  local check_tab = function()
    assert(last > first, "Illegal range - first index is greater than last.")
    assert(#work_tab >= last+1, "Last index in the range is greater than the length of the table.")
  end
  mt.__call = function (o, val)
    check_tab()
    table.insert(work_tab, first, val)
    table.remove(work_tab, last+1)
    return work_tab
  end
  setmetatable(t, mt)
  t.sum = function()
    check_tab()
    local res = 0
    for i=first,last,1 do
      res = res + work_tab
    end
    return res
  end
  return t
end

Additionally, either type checks to ensure that the table contains only integers, or some sort of boilerplate to allow any types to be used as table values, are needed.

Posted by

David Haley USA (3,881 posts)

Date

Reply #10 on Sat 18 Nov 2006 07:56 AM (UTC)

Message

That sounds like a plausible explanation of what the setup is supposed to do. I think, though, that if what you want is really a list object, you should go ahead and make it an actual object using the full metatable functionality. Not just the __call method, I mean, but a proper class table and all that stuff. It's about the same amount of work, and it is much clearer than this strange setup where we have constructor functions that are returning things with metatables but creating closures as we go.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Ked Russia (524 posts)

Date

Reply #11 on Sat 18 Nov 2006 08:42 PM (UTC)

Message

Right, but I figured keeping close to the original function would have more of an educational value :)

The general approach of using a factory function and building the table object inside of it is just as good as doing it through the OOP framework, in my opinion. But having the insert method defined on an object's __call metamethod leaves it a bit one-sided. So I myself don't see how this would be more useful than a standard List.remove/add/sum/reverse/etc object that you are suggesting.

But this seemed like what he wanted, though knowing the purpose of it would be interesting.

Posted by

David Haley USA (3,881 posts)

Date

Reply #12 on Sun 19 Nov 2006 02:38 AM (UTC)

Message

Oh, nothing is wrong with factories. The issue is one of consistency. This function is returning a table that behaves at once like some kind of operator or function, and like an object in an OOP system. Again, it's hard to gauge what is right or wrong or maybe or neutral in this system without knowing the bigger picture. But in general you don't want interfaces that are inconsistent like this. If you're going to go to the trouble of making a .sum() method, then the insertion call (which appears to be what the function call is for) should be a .insert() method.

What concerns me is that it appears that we're creating an object where there shouldn't be one. The code seems to aim at a way of inserting stuff into the middle of a table, removing elements if they get shifted out of that range. That's fine; why do we need a specialized object to do that? And furthermore, why do we need a specialized object in order to sum the values of the table from one position to the other?

And then there's the issue of the function names not corresponding to what they're really doing. range_insert for example isn't inserting anything, it's creating an object that upon subsequent calls will insert (or sum) things for you.

It just seems like a whole lot of complication and I'm not sure why it's there. Again, maybe this all makes sense in a bigger framework.

Here's an example of why this might be bad. So we get this table back, that sums and inserts over itself with a metatable. Now we're stuck with that table's metatable if we want it to keep working that way. We cannot change it, for example, to be some other kind of object that happens to use a table as a backing store. Now, if there was a very good reason to give the table this metatable, that would be ok. But I'm not sure there is such a reason except that the function is trying to stick with the original (broken and based on a misunderstanding of the system, I believe) way it was designed.

Sorry, I just get really edgy about things being implemented in order to be consistent with mistakes. :-) If something is a mistake or not right, it really should be fixed; designing more code around it is just compounding the problem.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Ked Russia (524 posts) bio

Date Reply #13 on Sun 19 Nov 2006 03:59 AM (UTC)

Message

Quote:
If you're going to go to the trouble of making a .sum() method, then the insertion call (which appears to be what the function call is for) should be a .insert() method.

Yep, that's what I said also. Right now it's some sort of a weird "insert" object, that operates on a copy of a table, so you can't even make one "insert" and one "remove" object for the same table.

Quote:
Now we're stuck with that table's metatable if we want it to keep working that way. We cannot change it, for example, to be some other kind of object that happens to use a table as a backing store. Now, if there was a very good reason to give the table this metatable, that would be ok.

The first statement is not true - you could substitute that metatable with a different one using a setmetatable() call on the returned object. Though why would you want to do that? And when? For changing the object at runtime? If that's the case then creating a different object seems to be a better solution.

And the reason to give it a metatable in the first place is to have an object that is both callable and has methods. To my knowledge, in Lua only a table can be used that way, and the only way to make it behave that way is with a __call metamethod. I'll admit that the purpose of this particular object being callable (and working in this particular way) escapes me also, but that's what the original poster was trying to do.

Quote:
The issue is one of consistency. This function is returning a table that behaves at once like some kind of operator or function, and like an object in an OOP system.

That I can't agree with. It is indeed incosistent in this particular case, but not in general. For example in Python all functions are such objects:


def test(): pass
def test1(): pass
test.test1 = test1
test.test1()

Posted by

David Haley USA (3,881 posts)

Date

Reply #14 on Sun 19 Nov 2006 06:45 AM (UTC)

Message

Quote:
Right now it's some sort of a weird "insert" object, that operates on a copy of a table,

Actually, the way it's set up, it doesn't even copy the table. It aliases the table name, but doesn't actually copy the table. That makes it all the more weird.

Quote:
The first statement is not true - you could substitute that metatable with a different one using a setmetatable() call on the returned object

Well, yes, you could do that, but then you would lose the whole range-inserting functionality. So if you want to keep it, you're stuck with that metatable. Since this functionality has no reason to be encapsulated in an object, it seems not worth the trouble to get stuck with one metatable.

Quote:
That I can't agree with. It is indeed incosistent in this particular case, but not in general.

Yes, I meant to say that it's inconsistent in this case. Also operator overloading in general is very tricky. Just because you can do something doesn't mean you should. A lot of people think that operator overloading in C++ is the spawn of the devil and should be avoided whenever possible. This is a fairly tame form of operator overloading, but I think that you should think very carefully before overloading a table to be both a "function" and a table. There is a case where that paradigm is very appropriate, and that is for function objects, i.e. functions that need to carry some degree of state around with them.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

31,395 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )