Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
Why does Peek starts with 0 and Fieldvalue with 1?
Thanks in advance.
All merryness aside, there may be a logical albeit boringly technical explanation for this "discrepancy"...
In programming languages, common sense dictates that the first element in an enumerable collection/list/array has index value 1. So all functions that provide access to a linear series of items from the first to the last, should start at index value 1. QlikView Script isn't any different in that respect. Seems very intuitive to me, but as Stefan already explained, opinions may vary.
In the matter of function peek(), this presents a serious practical problem. You see, peek() is that handy function that overlays a linear series of records with a circular buffer concept to make it easier to get to the last record without knowing the actual number of records in a table. Using sequential index values, you can get to any row in one of two ways: either by their (positive) row number, or by a negative index mechanism (that lets you start from the end).
But what happens if you retain index 1 for the first record? How do you get to the previous row in that circular buffer? Using index -1, you create a hole in the indexing mechanism because index value 0 is skipped. Which adds additional calculation code to make sure that index values correctly translate to the corresponding rows. And because QlikView sacrifices everything on the altar of performance, I don't think this was something the designers liked too much.
(I won't even mention what happens if you keep index value 0 to indicate the last row in a table, causing index value -1 to point to the next-to-last row. It's not worth it.)
The small compromise they accepted was to have a different indexing mechanism for this single function that guarantees a consistent linear index without addiing additional code to make it work.
So I don't really think the difference between for example RowNo() output and Peek() row values was caused by religous zealotry without a proper inquisition. AFAIK the QlikView script language doesn't have too many inconsistencies. It's just that it often serves a different master than the God of Clean Orthogonal Design.
I guess that's because there are basically two types of software developers, the ones with the 'an index starts with 0' gene and the ones with the 'an index starts with 1' gene.
If you create a mixed team of the two species and forget to install a master (you can call it an architect) that is entitled to decide in religious wars, you can end up with these kind of inconsistencies.
Lol, thanks for the prompt answer.
All merryness aside, there may be a logical albeit boringly technical explanation for this "discrepancy"...
In programming languages, common sense dictates that the first element in an enumerable collection/list/array has index value 1. So all functions that provide access to a linear series of items from the first to the last, should start at index value 1. QlikView Script isn't any different in that respect. Seems very intuitive to me, but as Stefan already explained, opinions may vary.
In the matter of function peek(), this presents a serious practical problem. You see, peek() is that handy function that overlays a linear series of records with a circular buffer concept to make it easier to get to the last record without knowing the actual number of records in a table. Using sequential index values, you can get to any row in one of two ways: either by their (positive) row number, or by a negative index mechanism (that lets you start from the end).
But what happens if you retain index 1 for the first record? How do you get to the previous row in that circular buffer? Using index -1, you create a hole in the indexing mechanism because index value 0 is skipped. Which adds additional calculation code to make sure that index values correctly translate to the corresponding rows. And because QlikView sacrifices everything on the altar of performance, I don't think this was something the designers liked too much.
(I won't even mention what happens if you keep index value 0 to indicate the last row in a table, causing index value -1 to point to the next-to-last row. It's not worth it.)
The small compromise they accepted was to have a different indexing mechanism for this single function that guarantees a consistent linear index without addiing additional code to make it work.
So I don't really think the difference between for example RowNo() output and Peek() row values was caused by religous zealotry without a proper inquisition. AFAIK the QlikView script language doesn't have too many inconsistencies. It's just that it often serves a different master than the God of Clean Orthogonal Design.
So, by that logic, does that mean that Peek function was created afterwards Fieldvalue?
No, because whether the Peek() function was introduced before or after FieldValue() function doesn't change the technical reason for having a different indexing mechanism. IMHO Peek() simply is an exception to the golden rule of starting the array/record/sequence index at number 1.
Brilliant explanation Peter!
-Rob
Thanks, Rob.