-- Bug description --
lstsize() is bugged and looks useless. It is supposedly more efficient than size() that can also be applied to all types of lists and derived types like cells, structures, etc. Actually, lstsize()
1) it is bugged while size() gives the right result. This bug looks similar to bug 7205
2) it wrongly counts the 1st technical "typing and fieldnaming" field of tlists and mlists, as size() does, while it could be its only usefulness compared to size().
IMO, lstsize() should be removed, and size() improved to not count the list(1) element of t- and m-lists.
-- Scilab error message --
-->T=tlist(["type" "num" "txt" "poly"],%pi,"Hello",%z^2);
-->lstsize(T)
ans =
4.
-->size(T)
ans =
4.
// In both cases, ans=3 would be more useful!
// ------------------------------------------------
-->L=list(1,'aqsdf',list(%pi,rand(2,2)));
-->lstsize(L)
ans =
3.
-->size(L)
ans =
3.
// Where is the advantage of lstsize() over size()???
// ------------------------------------------------
-->clear s; s(7,3).a="test"
s =
7x3 struct array with fields:
a
-->lstsize(s)
ans =
3.
-->size(s)
ans =
7. 3.
// size() works fine, lstsize()'s result is wrong
// Where is the advantage to maintain a bugged duplicate ?
// ------------------------------------------------
-->c=cell(3,4)
c =
!{} {} {} {} !
!{} {} {} {} !
!{} {} {} {} !
-->lstsize(c)
ans =
3.
-->size(c)
ans =
3. 4.
// No more comment..
-- How to reproduce the bug --
L=list(1,'aqsdf',list(%pi,rand(2,2)));
lstsize(L)
size(L)
// --------------
T=tlist(["type" "num" "txt" "poly"],%pi,"Hello",%z^2);
lstsize(T)
size(T)
// --------------
clear s; s(7,3).a="test"
lstsize(s)
size(s)
// --------------
c=cell(3,4)
lstsize(c)
size(c)