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
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
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
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)
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
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"
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.
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.
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.
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.
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:
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.