reference-based loops<\/a>. Older iterator-based syntaxes — where static termination conditions are defined — leave much more responsibility in the hands of the developer. Consider the following loops written in JavaScript:<\/p>\n\/\/ define a value for n\r\nlet n = 5;\r\n\r\n\/\/ A: loops n-many times\r\nfor (let i = 0; i < n; i++){}\r\n\r\n\/\/ B: loops n-1 times\r\nfor (let i = 1; i < n; i++){}\r\n\r\n\/\/ C: loops n+1 times\r\nfor (let i = 0; i <= n; i++){}<\/pre>\nn-times<\/h3>\n
In the first loop A<\/code> we see the value of i<\/code> incremented until it is of value n-1<\/code> such that a value of n<\/code> terminates the loop. This produces a loop of n<\/code> values because our iterator i<\/code> is initialized to a starting value of 0<\/code> such that 0, 1, 2, 3, 4<\/code> are 5 unique values, equal to the value assigned to n<\/code>.<\/p>\nn-1 times<\/h3>\n
In the second loop B<\/code> we see the value of i<\/code> incremented until it is of value n-1<\/code> as well. However, in this case, i<\/code> was initialized with a value of 0 such that the only valid values are 1, 2, 3, 4<\/code> or 4 total — 1 fewer than the value 5 which is assigned to n<\/code>.<\/p>\nn+1 times<\/h3>\n
In the third loop C<\/code>, we see the value of i<\/code> incremented until it is <=<\/code> the value of n<\/code> which, in this case, will continue the loop until i<\/code> reaches a value of 6. This includes the values 0, 1, 2, 3, 4, 5<\/code> given i<\/code> was initialized to 0<\/code> such that there are a total of 6 or n+1<\/code> elements given the value of n<\/code> is 6.<\/p>\nExample: Index Errors<\/h2>\n
In cases where one accesses elements of an array iteratively OBOE’s result from using the <=<\/code> operator or initializing a iterator to a non-zero value. Depending on the language, these issues may or may not cause an issue. Let’s take a look at an example in Python:<\/p>\n# define a list of 6 total values\r\nn = [0, 1, 2, 3, 4, 5]\r\n\r\n# Define an iterator variable\r\ni = 0\r\nwhile i <= len(n):\r\n\r\n # print the value of i\r\n print(\"i = \", i)\r\n\r\n # print the value of the ith element of n\r\n print(\"n[i] = \", n[i])\r\n\r\n # increment the iterator\r\n i += 1\r\n<\/pre>\nHere we have a list of 6 values and enter a while loop that will access each element via the iterator variable i<\/code> which gets incremented each iteration via the i += 1<\/code> segment. The printout is as follows:<\/p>\ni = 0\r\nn[i] = 0\r\ni = 1\r\nn[i] = 1\r\ni = 2\r\nn[i] = 2\r\ni = 3\r\nn[i] = 3\r\ni = 4\r\nn[i] = 4\r\ni = 5\r\nn[i] = 5\r\ni = 6\r\nTraceback (most recent call last):\r\n File \"C:\/Users\/pc\/Desktop\/mercator\/scatch.py\", line 13, in <module>\r\n print(\"n[i] = \", n[i])\r\nIndexError: list index out of range\r\n<\/pre>\nHere we see no issue in incrementing the value of i<\/code> to 6 but when we try to access the 6th element of n we cause a IndexError<\/code> exception — keep in mind our list is 0-indexed. This code tries to access an element of n<\/code> that doesn’t exist and Python throws an exception as a result. Let’s consider a similar example using JavaScript:<\/p>\n\/\/ Create an array of 6 elements\r\nlet n = [0, 1, 2, 3, 4, 5]\r\n\r\n\/\/ iterate until i <= 6\r\nfor (let i = 0; i <= n.length; i++){\r\n console.log(\"i = \", i);\r\n console.log(\"i = \", n[i]);\r\n}<\/pre>\nThe logic is identical to the above Python code but written here in JavaScript syntax. We have an array n<\/code> with 6 items and we loop until our iterator i<\/code>‘s value is greater than 6. This produces the following output to the console:<\/p>\ni = 0\r\nn[i] = 0 \r\ni = 1 \r\nn[i] = 1 \r\ni = 2 \r\nn[i] = 2 \r\ni = 3 \r\nn[i] = 3 \r\ni = 4 \r\nn[i] = 4 \r\ni = 5 \r\nn[i] = 5 \r\ni = 6 \r\nn[i] = undefined\r\n<\/pre>\nThe last line where the n[i]<\/code> syntax was used attempts to access an element of n<\/code> that doesn’t exist. JavaScript doesn’t throw an exception here however and simply returns an undefined<\/code> object. This can be useful in cases where crashes should be avoided but also infuriating in cases where one would\u00a0expect<\/em> such a logical error to cause an issue.<\/p>\nCommon Causes<\/h2>\n
In languages like C, there are certain functions like strcat<\/code> in which the first n<\/code> characters of a source string are used to create a second string. However, this function also appends a terminator character after the operation such that there must be n+1<\/code> bytes available in a buffer allocated for the copy operation.\u00a0Aside from such less common issues, the following checklist is a good guide for avoiding off-by-one errors:<\/p>\n\n- Iterators that are initialized to non-zero values<\/li>\n
- Termination conditions that use
==<\/code> or <=<\/code> operators<\/li>\n<\/ul>\nFinal Thoughts<\/h2>\n
Off-By-One errors are often products of simple typos but can also reflect larger logical flaws. Loop conditions and iterator initialization values are common causes but certainly not exclusive sources of OBOE’s. OBOE’s aren’t exclusive to computer programming and can appear in general calculations as well.<\/p>\n
Consider the case of creating a fence that spans 25ft such that there is a fencepost every foot. How many total fence posts would be needed? An easy mistake is to answer 25 posts — there will be 25 posts needed for each 1ft span but there will also be an initial post needed to start. This would bring the total to 25 + 1 post!<\/p>\n","protected":false},"excerpt":{"rendered":"
An Off-By-One Error (OBOE) is common among any system in which discrete elements are found. In programming and computer science, these errors pop up often during loops and memory allocation. Off-by-one errors happen when there are n-many elements expected and either n+1 or n-1 elements are present. Termination conditions set using <= instead of < […]<\/p>\n","protected":false},"author":2,"featured_media":2959,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[186,260],"tags":[538],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/2957"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=2957"}],"version-history":[{"count":4,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/2957\/revisions"}],"predecessor-version":[{"id":2962,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/2957\/revisions\/2962"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/2959"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=2957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=2957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=2957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}