3062: Off By One - Revision history

FaviFake: /* Explanation */

2025-06-16T14:30:47Z

‎Explanation

FaviFake: /* Explanation */ complete

2025-06-16T14:30:32Z

‎Explanation: complete

FaviFake: /* Explanation */

2025-03-26T15:57:16Z

‎Explanation

Alexis J. Morganza: /* Explanation */ add tangible explanations of three error classes; also fixed typo "fhis"

2025-03-25T21:39:53Z

‎Explanation: add tangible explanations of three error classes; also fixed typo "fhis"

172.70.58.5: Fixed use of "complimentary" for "complementary"

2025-03-19T12:49:07Z

Fixed use of "complimentary" for "complementary"

172.70.163.34: /* Explanation */

2025-03-14T00:38:29Z

‎Explanation

172.69.195.4: /* Explanation */

2025-03-13T23:51:13Z

‎Explanation

AgentMuffin at 23:15, 13 March 2025

2025-03-13T23:15:50Z

AgentMuffin at 23:06, 13 March 2025

2025-03-13T23:06:40Z

AgentMuffin at 23:05, 13 March 2025

2025-03-13T23:05:31Z

@@ Line 26: / Line 26: @@
 [[Cueball]] has attempted to combat off-by-one errors in his new programming language by introducing off-by-40-to-50 errors, which will indeed ensure that a simple reference to a value is never off by one (only a further, ''nearly'' complementary invocation of the ±[40..50] error will produce such a seemingly simple error). This severe change would introduce immediate failures in almost every program that does not have efficient error-catching and fault-tolerance. A programmer attempting to correct such failures would end up completely removing direct comparison with the end value of a range, the usual cause of off-by-one errors, but would have to account for the possibilities of all of their values being at least 50 off from the intended value in every elemental variable read/write (possibly multiple cases of this per statement, or line). For example, a normal loop can miss many elements (and possibly revisit others more than once, and/or out of order), not just possibly omit or over-extend one of the endpoints.
-The title text states the obvious; by changing every number by 40 to 50, any number will be 40 to 50 off. This will compound further as the change can happen many times on a single line, as well as further by existing unforced off-by-one errors (or itself being left ill-defined or misunderstood, depending on whether "between" here is being understood as inclusive or exclusive) leading to potential off-by-39-to-51 errors.
+The title text states the obvious; by changing every number by 40 to 50, any number will be 40 to 50 off. This will compound further as the change can happen many times on a single line, as well as further by existing unforced off-by-one errors (or itself being left ill-defined or misunderstood, depending on whether "between" here is being understood as inclusive or exclusive) leading to potential off-by-39-to-51 errors. The title text can be used to infer that the 40-to-50 range is inclusive on both ends, despite the word "between" also possibly implying an exclusive range, in different contexts.
 ==Transcript==

@@ Line 10: / Line 10: @@
 ==Explanation==
-{{incomplete|The explanation is too technical and hard to understand for normal readers.}}
+In computer programming and computer science, an {{w|off-by-one error}} is a very common human mistake made by an engineer who instructed the computer to process one too many or one too few items than are actually present. This can arise from a number of sources, including:
-In computer programming and computer science, an {{w|off-by-one error}} is a very common human mistake made by an engineer who instructed the computer to process one too many or one too few items than are actually present. This can arise from a number of sources, including:
+* Confusion between {{w|Zero-based numbering|zero-}} and one-based indexing of {{w|Array (data type)|arrays}} in code, either by convention or by definition in the code. Often, when numbering (indexing) elements in programming, counting starts from 0, so the initial element is not the "first" but actually the "zeroth". When using an {{w|Array (data structure)|array data structure}}, where elements are stored at equally spaced {{w|memory address}}es, zero-indexing lets you calculate the address of the <var>i</var>th element more easily: address(<var>i</var>) = address(<var>array</var>) + <var>spacing</var> &times; <var>i</var>. However, not all programming languages do this.
-*Mistakenly using a ≤ (less than or equals) comparison where a < (less than) comparison was needed to terminate a {{w|Loop (programming)|loop}}, or vice versa (or, alternately, ≥ mixed up with >) (Imagine a literal interpretation of "when you get to the last task you are done" as opposed to "when you have completed the last task you are done".)
-*Confusion between {{w|Zero-based numbering|zero-}} and one-based indexing of {{w|Array (data type)|arrays}} in code, either by convention or by definition in the code. Often, when numbering (indexing) elements in programming, counting starts from 0, so the initial element is not the "first" but actually the "zeroth". When using an {{w|Array (data structure)|array data structure}}, where elements are stored at equally spaced {{w|memory address}}es, zero-indexing lets you calculate the address of the <var>i</var>th element more easily: address(<var>i</var>) = address(<var>array</var>) + <var>spacing</var> &times; <var>i</var>. However, not all programming languages do this. (More tangibly, imagine a set of detailed instructions for washing dishes using a loop that starts with "put away any dish in your hands and pick up the next dish".  If you read the instructions with a dish already in your hand, that first dish will never get washed.)
+: Imagine a set of detailed instructions for washing dishes using a loop that starts with "put away any dish in your hands and pick up the next dish".  If you read the instructions with a dish already in your hand, that first dish will never get washed.
-*{{w|Fencepost error}}s (which some consider to be synonymous with off-by-one errors). These are often related to the norm, in programming language loop constructs, to require inclusivity on the lower side of the range but exclusivity on the upper side [<var>min</var> ≤ <var>i</var> < <var>max</var>). Consider the length of a range, such as the whole numbers from 4 to 6. If this is considered inclusive on one side and exclusive on the other, then the correct length is 2, to count the set {4, 5}. This is easily obtained via the subtraction <var>max</var> &minus; <var>min</var>. However, if the range is considered inclusive on both sides, as when placing fenceposts to hold a length of fence, then the correct length is 3, to count the set {4, 5, 6}. This is one more than the difference, and one more than the length usually used in software engineering, so the formula for this case is actually <var>max</var> &minus; <var>min</var> + 1.  (A more concrete explanation: imagine that you are building a fence, with 1 meter panels between fenceposts.  To build a 10 meter fence you need 11 fenceposts, as you need an "extra" one at the end.  If you assume that a 10 meter fence needs 10 fenceposts, one per panel, you have a fencepost error -- the correct algorithm is that you need one fencepost plus one per panel.)
 [[Cueball]] has attempted to combat off-by-one errors in his new programming language by introducing off-by-40-to-50 errors, which will indeed ensure that a simple reference to a value is never off by one (only a further, ''nearly'' complementary invocation of the ±[40..50] error will produce such a seemingly simple error). This severe change would introduce immediate failures in almost every program that does not have efficient error-catching and fault-tolerance. A programmer attempting to correct such failures would end up completely removing direct comparison with the end value of a range, the usual cause of off-by-one errors, but would have to account for the possibilities of all of their values being at least 50 off from the intended value in every elemental variable read/write (possibly multiple cases of this per statement, or line). For example, a normal loop can miss many elements (and possibly revisit others more than once, and/or out of order), not just possibly omit or over-extend one of the endpoints.

@@ Line 10: / Line 10: @@
 ==Explanation==
-{{incomplete|The explanation is currently too hard to understand for non-technical readers.}}
+{{incomplete|The explanation is too technical and hard to understand for normal readers.}}
 In computer programming and computer science, an {{w|off-by-one error}} is a very common human mistake made by an engineer who instructed the computer to process one too many or one too few items than are actually present. This can arise from a number of sources, including:

@@ Line 12: / Line 12: @@
 {{incomplete|The explanation is currently too hard to understand for non-technical readers.}}
-In computer programming and computer science, an {{w|off-by-one error}} is a very common human mistake left by an engineer who instructed the computer to process one too many or one too few items than are actually present. This can arise from a number of sources, including:
+In computer programming and computer science, an {{w|off-by-one error}} is a very common human mistake made by an engineer who instructed the computer to process one too many or one too few items than are actually present. This can arise from a number of sources, including:
-*Mistakenly using a ≤ (less than or equals) comparison where a < (less than) comparison was needed to terminate a {{w|Loop (programming)|loop}}, or vice versa (or, alternately, ≥ mixed up with >)
+*Mistakenly using a ≤ (less than or equals) comparison where a < (less than) comparison was needed to terminate a {{w|Loop (programming)|loop}}, or vice versa (or, alternately, ≥ mixed up with >) (Imagine a literal interpretation of "when you get to the last task you are done" as opposed to "when you have completed the last task you are done".)
-*Confusion between {{w|Zero-based numbering|zero-}} and one-based indexing of {{w|Array (data type)|arrays}} in code, either by convention or by definition in the code. Often, when numbering (indexing) elements in programming, counting starts from 0, so the initial element is not the "first" but actually the "zeroth". When using an {{w|Array (data structure)|array data structure}}, where elements are stored at equally spaced {{w|memory address}}es, zero-indexing lets you calculate the address of the <var>i</var>th element more easily: address(<var>i</var>) = address(<var>array</var>) + <var>spacing</var> &times; <var>i</var>. However, not all programming languages do this.
+*Confusion between {{w|Zero-based numbering|zero-}} and one-based indexing of {{w|Array (data type)|arrays}} in code, either by convention or by definition in the code. Often, when numbering (indexing) elements in programming, counting starts from 0, so the initial element is not the "first" but actually the "zeroth". When using an {{w|Array (data structure)|array data structure}}, where elements are stored at equally spaced {{w|memory address}}es, zero-indexing lets you calculate the address of the <var>i</var>th element more easily: address(<var>i</var>) = address(<var>array</var>) + <var>spacing</var> &times; <var>i</var>. However, not all programming languages do this. (More tangibly, imagine a set of detailed instructions for washing dishes using a loop that starts with "put away any dish in your hands and pick up the next dish".  If you read the instructions with a dish already in your hand, that first dish will never get washed.)
-*{{w|Fencepost error}}s (which some consider to be synonymous with off-by-one errors). These are often related to the norm, in programming language loop constructs, to require inclusivity on the lower side of the range but exclusivity on the upper side [<var>min</var> ≤ <var>i</var> < <var>max</var>). Consider the length of a range, such as the whole numbers from 4 to 6. If this is considered inclusive on one side and exclusive on the other, then the correct length is 2, to count the set {4, 5}. This is easily obtained via the subtraction <var>max</var> &minus; <var>min</var>. However, if the range is considered inclusive on both sides, as when placing fenceposts to hold a length of fence, then the correct length is 3, to count the set {4, 5, 6}. This is one more than the difference, and one more than the length usually used in software engineering, so the formula for this case is actually <var>max</var> &minus; <var>min</var> + 1.
+*{{w|Fencepost error}}s (which some consider to be synonymous with off-by-one errors). These are often related to the norm, in programming language loop constructs, to require inclusivity on the lower side of the range but exclusivity on the upper side [<var>min</var> ≤ <var>i</var> < <var>max</var>). Consider the length of a range, such as the whole numbers from 4 to 6. If this is considered inclusive on one side and exclusive on the other, then the correct length is 2, to count the set {4, 5}. This is easily obtained via the subtraction <var>max</var> &minus; <var>min</var>. However, if the range is considered inclusive on both sides, as when placing fenceposts to hold a length of fence, then the correct length is 3, to count the set {4, 5, 6}. This is one more than the difference, and one more than the length usually used in software engineering, so the formula for this case is actually <var>max</var> &minus; <var>min</var> + 1.  (A more concrete explanation: imagine that you are building a fence, with 1 meter panels between fenceposts.  To build a 10 meter fence you need 11 fenceposts, as you need an "extra" one at the end.  If you assume that a 10 meter fence needs 10 fenceposts, one per panel, you have a fencepost error -- the correct algorithm is that you need one fencepost plus one per panel.)
-[[Cueball]] has attempted to combat off-by-one errors in his new programming language by introducing off-by-40-to-50 errors, which will indeed ensure that a simple reference to a value is never off by one (only a further, ''nearly'' complementary invocation of the ±[40..50] error will produce such a seemingly simple error). This severe change would introduce immediate failures in almost every program that does not have efficient error-catching and fault-tolerance. A programmer attempting to correct such failures would end up completely removing direct comparison with the end value of a range, the usual cause of off-by-one errors, but would have to account for the possibilities of all of their values being at least 50 off from the intended value in every elemental variable read/write (possibly multiple cases of fhis per statement, or line). For example, a normal loop can miss many elements (and possibly revisit others more than once, and/or out of order), not just possibly omit or over-extend one of the endpoints.
+[[Cueball]] has attempted to combat off-by-one errors in his new programming language by introducing off-by-40-to-50 errors, which will indeed ensure that a simple reference to a value is never off by one (only a further, ''nearly'' complementary invocation of the ±[40..50] error will produce such a seemingly simple error). This severe change would introduce immediate failures in almost every program that does not have efficient error-catching and fault-tolerance. A programmer attempting to correct such failures would end up completely removing direct comparison with the end value of a range, the usual cause of off-by-one errors, but would have to account for the possibilities of all of their values being at least 50 off from the intended value in every elemental variable read/write (possibly multiple cases of this per statement, or line). For example, a normal loop can miss many elements (and possibly revisit others more than once, and/or out of order), not just possibly omit or over-extend one of the endpoints.
 The title text states the obvious; by changing every number by 40 to 50, any number will be 40 to 50 off. This will compound further as the change can happen many times on a single line, as well as further by existing unforced off-by-one errors (or itself being left ill-defined or misunderstood, depending on whether "between" here is being understood as inclusive or exclusive) leading to potential off-by-39-to-51 errors.

@@ Line 17: / Line 17: @@
 *{{w|Fencepost error}}s (which some consider to be synonymous with off-by-one errors). These are often related to the norm, in programming language loop constructs, to require inclusivity on the lower side of the range but exclusivity on the upper side [<var>min</var> ≤ <var>i</var> < <var>max</var>). Consider the length of a range, such as the whole numbers from 4 to 6. If this is considered inclusive on one side and exclusive on the other, then the correct length is 2, to count the set {4, 5}. This is easily obtained via the subtraction <var>max</var> &minus; <var>min</var>. However, if the range is considered inclusive on both sides, as when placing fenceposts to hold a length of fence, then the correct length is 3, to count the set {4, 5, 6}. This is one more than the difference, and one more than the length usually used in software engineering, so the formula for this case is actually <var>max</var> &minus; <var>min</var> + 1.
-[[Cueball]] has attempted to combat off-by-one errors in his new programming language by introducing off-by-40-to-50 errors, which will indeed ensure that a simple reference to a value is never off by one (only a further, ''nearly'' complimentary invocation of the ±[40..50] error will produce such a seemingly simple error). This severe change would introduce immediate failures in almost every program that does not have efficient error-catching and fault-tolerance. A programmer attempting to correct such failures would end up completely removing direct comparison with the end value of a range, the usual cause of off-by-one errors, but would have to account for the possibilities of all of their values being at least 50 off from the intended value in every elemental variable read/write (possibly multiple cases of fhis per statement, or line). For example, a normal loop can miss many elements (and possibly revisit others more than once, and/or out of order), not just possibly omit or over-extend one of the endpoints.
+[[Cueball]] has attempted to combat off-by-one errors in his new programming language by introducing off-by-40-to-50 errors, which will indeed ensure that a simple reference to a value is never off by one (only a further, ''nearly'' complementary invocation of the ±[40..50] error will produce such a seemingly simple error). This severe change would introduce immediate failures in almost every program that does not have efficient error-catching and fault-tolerance. A programmer attempting to correct such failures would end up completely removing direct comparison with the end value of a range, the usual cause of off-by-one errors, but would have to account for the possibilities of all of their values being at least 50 off from the intended value in every elemental variable read/write (possibly multiple cases of fhis per statement, or line). For example, a normal loop can miss many elements (and possibly revisit others more than once, and/or out of order), not just possibly omit or over-extend one of the endpoints.
 The title text states the obvious; by changing every number by 40 to 50, any number will be 40 to 50 off. This will compound further as the change can happen many times on a single line, as well as further by existing unforced off-by-one errors (or itself being left ill-defined or misunderstood, depending on whether "between" here is being understood as inclusive or exclusive) leading to potential off-by-39-to-51 errors.

@@ Line 15: / Line 15: @@
 *Mistakenly using a ≤ (less than or equals) comparison where a < (less than) comparison was needed to terminate a {{w|Loop (programming)|loop}}, or vice versa (or, alternately, ≥ mixed up with >)
 *Confusion between {{w|Zero-based numbering|zero-}} and one-based indexing of arrays in code, either by convention or by definition in the code. Often, when numbering (indexing) elements in programming, counting starts from 0, so the initial element is not the "first" but actually the "zeroth". (However, not all programming languages do this.)
-*{{w|Fencepost error}}s (which some consider to be synonymous with off-by-one errors). These are often related to the norm, in programming language loop constructs, to require inclusivity on the lower side of the range but exclusivity on the upper side [<var>min</var> ≤ <var>i</var> < <var>max</var>). Consider the length of a range, such as the whole numbers from 4 to 6. If this is considered inclusive on one side and exclusive on the other, then the correct length is 2, to count the set {4, 5}, which is easily obtained via the subtraction <var>max</var> &minus; <var>min</var>. However, if the range is considered inclusive on both sides, as when placing fenceposts to hold a length of fence, then the correct length is 3, to count the set {4, 5, 6}, which is one more than the difference, and one more than the length usually used in software engineering. So the formula for this case is actually <var>max</var> &minus; <var>min</var> + 1.
+*{{w|Fencepost error}}s (which some consider to be synonymous with off-by-one errors). These are often related to the norm, in programming language loop constructs, to require inclusivity on the lower side of the range but exclusivity on the upper side [<var>min</var> ≤ <var>i</var> < <var>max</var>). Consider the length of a range, such as the whole numbers from 4 to 6. If this is considered inclusive on one side and exclusive on the other, then the correct length is 2, to count the set {4, 5}. This is easily obtained via the subtraction <var>max</var> &minus; <var>min</var>. However, if the range is considered inclusive on both sides, as when placing fenceposts to hold a length of fence, then the correct length is 3, to count the set {4, 5, 6}. This is one more than the difference, and one more than the length usually used in software engineering, so the formula for this case is actually <var>max</var> &minus; <var>min</var> + 1.
 [[Cueball]] has attempted to combat off-by-one errors in his new programming language by introducing off-by-40-to-50 errors, which will indeed ensure that a simple reference to a value is rarely off by one. This severe change would introduce immediate failures in almost every program. A programmer attempting to correct such failures would end up completely removing direct comparison with the end value of a range, the usual cause of off-by-one errors, but would have to design for all of their values being up to 50 off from correct in every statement or line. For example, a normal loop can miss many elements (and possibly revisit others more than once, and/or out of order), not just possibly omit or over-extend one of the endpoints.