Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
julioarriaga
Creator II
Creator II

Why does Peek starts with 0 and Fieldvalue with 1?

Hi,

Why does Peek starts with 0 and Fieldvalue with 1?

Thanks in advance.

1 Solution

Accepted Solutions
Peter_Cammaert
Partner - Champion III
Partner - Champion III

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.

View solution in original post

8 Replies
swuehl
MVP
MVP

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.

julioarriaga
Creator II
Creator II
Author

Lol, thanks for the prompt answer.

sunny_talwar

Peter_Cammaert
Partner - Champion III
Partner - Champion III

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.

julioarriaga
Creator II
Creator II
Author

So, by that logic, does that mean that Peek function was created afterwards Fieldvalue?

Peter_Cammaert
Partner - Champion III
Partner - Champion III

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.

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

Brilliant explanation Peter!

-Rob

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Thanks, Rob.