For what value of i does while (i == i + 1) {} loop forever?












115














I ran cross this puzzler from an advanced programming course at a UK university exam.



Consider the following loop, in which i is, so far, undeclared:



while (i == i + 1) {}


Find the definition of i, that precedes this loop, such that the while loop
continues for ever.



The next question, which asked the same question for this code snippet:



while (i != i) {}


was obvious to me. Of course in this other situation it is NaN but I am really stuck on the prior one. Does this have to do with overflow? What would cause such a loop to loop for ever in Java?






java loops types







share|improve this question




















  • 3




    Any possibilities to override .equals() method? Since i is undeclared, we may use any class of what we want.
    – Geno Chen
    Nov 28 '18 at 9:35






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 '18 at 9:56






  • 12




    Fun fact, in C# this also works for nullable numeric types whose values are null, since null == null is true, and null + 1 is null.
    – Eric Lippert
    Nov 28 '18 at 15:38






  • 4




    @EricDuminil: The situation is far worse than you imagine. In many languages, floating point arithmetic must be done in at least the 64 bits of precision specified by a double, which means that it can be done in higher precision at the whim of the compiler, and in practice this happens. I can point you at a dozen questions on this site from C# programmers who are wondering why 0.2 + 0.1 == 0.3 changes its value depending on compiler settings, the phase of the moon, and so on.
    – Eric Lippert
    Nov 28 '18 at 23:38






  • 5




    @EricDuminil: The blame for this mess falls on Intel, who gave us a chip set that does higher-precision and faster floating point arithmetic if the numbers can be enregistered, which means that the results of a floating point computation can change their values depending on how well the register scheduler in the optimizer works today. Your choices as a language designer are then between repeatable computations and fast, precise computations, and the community that cares about floating point math will opt for the latter.
    – Eric Lippert
    Nov 28 '18 at 23:41
















115














I ran cross this puzzler from an advanced programming course at a UK university exam.



Consider the following loop, in which i is, so far, undeclared:



while (i == i + 1) {}


Find the definition of i, that precedes this loop, such that the while loop
continues for ever.



The next question, which asked the same question for this code snippet:



while (i != i) {}


was obvious to me. Of course in this other situation it is NaN but I am really stuck on the prior one. Does this have to do with overflow? What would cause such a loop to loop for ever in Java?






java loops types







share|improve this question




















  • 3




    Any possibilities to override .equals() method? Since i is undeclared, we may use any class of what we want.
    – Geno Chen
    Nov 28 '18 at 9:35






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 '18 at 9:56






  • 12




    Fun fact, in C# this also works for nullable numeric types whose values are null, since null == null is true, and null + 1 is null.
    – Eric Lippert
    Nov 28 '18 at 15:38






  • 4




    @EricDuminil: The situation is far worse than you imagine. In many languages, floating point arithmetic must be done in at least the 64 bits of precision specified by a double, which means that it can be done in higher precision at the whim of the compiler, and in practice this happens. I can point you at a dozen questions on this site from C# programmers who are wondering why 0.2 + 0.1 == 0.3 changes its value depending on compiler settings, the phase of the moon, and so on.
    – Eric Lippert
    Nov 28 '18 at 23:38






  • 5




    @EricDuminil: The blame for this mess falls on Intel, who gave us a chip set that does higher-precision and faster floating point arithmetic if the numbers can be enregistered, which means that the results of a floating point computation can change their values depending on how well the register scheduler in the optimizer works today. Your choices as a language designer are then between repeatable computations and fast, precise computations, and the community that cares about floating point math will opt for the latter.
    – Eric Lippert
    Nov 28 '18 at 23:41














115












115








115


22





I ran cross this puzzler from an advanced programming course at a UK university exam.



Consider the following loop, in which i is, so far, undeclared:



while (i == i + 1) {}


Find the definition of i, that precedes this loop, such that the while loop
continues for ever.



The next question, which asked the same question for this code snippet:



while (i != i) {}


was obvious to me. Of course in this other situation it is NaN but I am really stuck on the prior one. Does this have to do with overflow? What would cause such a loop to loop for ever in Java?






java loops types







share|improve this question















I ran cross this puzzler from an advanced programming course at a UK university exam.



Consider the following loop, in which i is, so far, undeclared:



while (i == i + 1) {}


Find the definition of i, that precedes this loop, such that the while loop
continues for ever.



The next question, which asked the same question for this code snippet:



while (i != i) {}


was obvious to me. Of course in this other situation it is NaN but I am really stuck on the prior one. Does this have to do with overflow? What would cause such a loop to loop for ever in Java?






java loops types




java loops types






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 29 '18 at 11:28









Oleksandr

8,80843770




8,80843770










asked Nov 28 '18 at 9:31









jake mckenzie

715157




715157








  • 3




    Any possibilities to override .equals() method? Since i is undeclared, we may use any class of what we want.
    – Geno Chen
    Nov 28 '18 at 9:35






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 '18 at 9:56






  • 12




    Fun fact, in C# this also works for nullable numeric types whose values are null, since null == null is true, and null + 1 is null.
    – Eric Lippert
    Nov 28 '18 at 15:38






  • 4




    @EricDuminil: The situation is far worse than you imagine. In many languages, floating point arithmetic must be done in at least the 64 bits of precision specified by a double, which means that it can be done in higher precision at the whim of the compiler, and in practice this happens. I can point you at a dozen questions on this site from C# programmers who are wondering why 0.2 + 0.1 == 0.3 changes its value depending on compiler settings, the phase of the moon, and so on.
    – Eric Lippert
    Nov 28 '18 at 23:38






  • 5




    @EricDuminil: The blame for this mess falls on Intel, who gave us a chip set that does higher-precision and faster floating point arithmetic if the numbers can be enregistered, which means that the results of a floating point computation can change their values depending on how well the register scheduler in the optimizer works today. Your choices as a language designer are then between repeatable computations and fast, precise computations, and the community that cares about floating point math will opt for the latter.
    – Eric Lippert
    Nov 28 '18 at 23:41














  • 3




    Any possibilities to override .equals() method? Since i is undeclared, we may use any class of what we want.
    – Geno Chen
    Nov 28 '18 at 9:35






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 '18 at 9:56






  • 12




    Fun fact, in C# this also works for nullable numeric types whose values are null, since null == null is true, and null + 1 is null.
    – Eric Lippert
    Nov 28 '18 at 15:38






  • 4




    @EricDuminil: The situation is far worse than you imagine. In many languages, floating point arithmetic must be done in at least the 64 bits of precision specified by a double, which means that it can be done in higher precision at the whim of the compiler, and in practice this happens. I can point you at a dozen questions on this site from C# programmers who are wondering why 0.2 + 0.1 == 0.3 changes its value depending on compiler settings, the phase of the moon, and so on.
    – Eric Lippert
    Nov 28 '18 at 23:38






  • 5




    @EricDuminil: The blame for this mess falls on Intel, who gave us a chip set that does higher-precision and faster floating point arithmetic if the numbers can be enregistered, which means that the results of a floating point computation can change their values depending on how well the register scheduler in the optimizer works today. Your choices as a language designer are then between repeatable computations and fast, precise computations, and the community that cares about floating point math will opt for the latter.
    – Eric Lippert
    Nov 28 '18 at 23:41








3




3




Any possibilities to override .equals() method? Since i is undeclared, we may use any class of what we want.
– Geno Chen
Nov 28 '18 at 9:35




Any possibilities to override .equals() method? Since i is undeclared, we may use any class of what we want.
– Geno Chen
Nov 28 '18 at 9:35




7




7




@Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
– Andrew Tobilko
Nov 28 '18 at 9:56




@Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
– Andrew Tobilko
Nov 28 '18 at 9:56




12




12




Fun fact, in C# this also works for nullable numeric types whose values are null, since null == null is true, and null + 1 is null.
– Eric Lippert
Nov 28 '18 at 15:38




Fun fact, in C# this also works for nullable numeric types whose values are null, since null == null is true, and null + 1 is null.
– Eric Lippert
Nov 28 '18 at 15:38




4




4




@EricDuminil: The situation is far worse than you imagine. In many languages, floating point arithmetic must be done in at least the 64 bits of precision specified by a double, which means that it can be done in higher precision at the whim of the compiler, and in practice this happens. I can point you at a dozen questions on this site from C# programmers who are wondering why 0.2 + 0.1 == 0.3 changes its value depending on compiler settings, the phase of the moon, and so on.
– Eric Lippert
Nov 28 '18 at 23:38




@EricDuminil: The situation is far worse than you imagine. In many languages, floating point arithmetic must be done in at least the 64 bits of precision specified by a double, which means that it can be done in higher precision at the whim of the compiler, and in practice this happens. I can point you at a dozen questions on this site from C# programmers who are wondering why 0.2 + 0.1 == 0.3 changes its value depending on compiler settings, the phase of the moon, and so on.
– Eric Lippert
Nov 28 '18 at 23:38




5




5




@EricDuminil: The blame for this mess falls on Intel, who gave us a chip set that does higher-precision and faster floating point arithmetic if the numbers can be enregistered, which means that the results of a floating point computation can change their values depending on how well the register scheduler in the optimizer works today. Your choices as a language designer are then between repeatable computations and fast, precise computations, and the community that cares about floating point math will opt for the latter.
– Eric Lippert
Nov 28 '18 at 23:41




@EricDuminil: The blame for this mess falls on Intel, who gave us a chip set that does higher-precision and faster floating point arithmetic if the numbers can be enregistered, which means that the results of a floating point computation can change their values depending on how well the register scheduler in the optimizer works today. Your choices as a language designer are then between repeatable computations and fast, precise computations, and the community that cares about floating point math will opt for the latter.
– Eric Lippert
Nov 28 '18 at 23:41












4 Answers
4






active

oldest

votes


















139














First of all, since the while (i == i + 1) {} loop doesn't change the value of i, making this loop infinite is equivalent to choosing a value of i that satisfies i == i + 1.



There are many such values:



Let's start with the "exotic" ones:



double i = Double.POSITIVE_INFINITY;


or



double i =  Double.NEGATIVE_INFINITY;


The reason for these values satisfying i == i + 1 is stated in
JLS 15.18.2. Additive Operators (+ and -) for Numeric Types:




The sum of an infinity and a finite value is equal to the infinite operand.




This is not surprising, since adding a finite value to an infinite value should result in an infinite value.



That said, most of the values of i that satisfy i == i + 1 are simply large double (or float) values:



For example:



double i = Double.MAX_VALUE;


or



double i = 1000000000000000000.0;


or



float i = 1000000000000000000.0f;


The double and float types have limited precision, so if you take a large enough double or float value, adding 1 to it will result in the same value.






share|improve this answer



















  • 9




    Or (double)(1L<<53) -- or float i = (float)(1<<24)
    – dave_thompson_085
    Nov 28 '18 at 9:43






  • 3




    @Ruslan: Any mathematician would disagree. Floating point numbers make very little sense. They are non-associative, non-reflexive (NaN != NaN), and not even substitutable (-0 == 0, but 1/0 != 1/-0). So most of the machinery of algebra is inapplicable.
    – Kevin
    Nov 28 '18 at 16:35






  • 2




    @Kevin while floating-point numbers can't indeed make too much sense in general, the behavior of infinities (which is what is described in that sentence) was designed to make sense.
    – Ruslan
    Nov 28 '18 at 16:38








  • 4




    @Kevin To be fair to floats, if you deal with infinities or undefined values you can't assume the properties you listed in algebra either.
    – Voo
    Nov 28 '18 at 17:11








  • 2




    @Kevin: IMHO, floating-point maths could have made a lot more sense if they'd replaced the concepts of "positive and negative zero" sign positive, negative, and unsigned "infinitesimals" along with one "true zero", and made NaN equal to itself. True zero could behave as an additive identity in all cases, and something operations involving division by infinitesimals would lose their bias towards assuming the infinitesimals are positive.
    – supercat
    Nov 28 '18 at 17:15



















64














These puzzles are described in detail in the "Java Puzzlers: Traps, Pitfalls, and Corner Cases" book by Joshua Bloch and Neal Gafter.



double i = Double.POSITIVE_INFINITY;

while (i == i + 1) {}


or:



double i = 1.0e40;

while (i == i + 1) {}


both will result in an infinite loop, because adding 1 to a floating-point value that is sufficiently large will not change the value, because it doesn't "bridge the gap" to its successor1.



A note about the second puzzle (for future readers):



double i = Double.NaN;

while (i != i) {}


also results in an infinite loop, because NaN is not equal to any floating-point value, including itself 2.




1 - Java Puzzlers: Traps, Pitfalls, and Corner Cases (chapter 4 - Loopy Puzzlers).



2 - JLS §15.21.1






share|improve this answer



















  • 7




    There should be a seperate hell for everyone that uses i as a non integer variable. Or a as a counter at all... Not your fault I know...
    – Kami Kaze
    Nov 29 '18 at 8:56










  • @KamiKaze Especially since several high-level languages have i defined as sqrt(-1) by default and you end up overloading -- actually overriding -- this value.
    – Carl Witthoft
    Nov 29 '18 at 16:10



















1














Just an idea: what about booleans?



bool i = TRUE;


Isn't this a case where i + 1 == i?






share|improve this answer





















  • depends on the language. Many languages automatically coerce booleans to ints when combined with an int. Others do as you suggest - coercing the int to a boolean.
    – Carl Witthoft
    Nov 29 '18 at 16:12






  • 6




    This question is a Java question, and your suggestion doesn't pass compilation in Java (which has no + operator that takes a boolean and an int as operands).
    – Eran
    Nov 30 '18 at 9:05










  • @Eran: that's the whole idea of operator overloading. You can make Java booleans behave like C++ ones.
    – Dominique
    Nov 30 '18 at 9:26






  • 2




    Except that Java doesn't support operator overloading, so you can't.
    – CupawnTae
    Dec 5 '18 at 9:33



















1














double i = Double.POSITIVE_INFINITY;






share|improve this answer





















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53516189%2ffor-what-value-of-i-does-while-i-i-1-loop-forever%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    4 Answers
    4






    active

    oldest

    votes








    4 Answers
    4






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    139














    First of all, since the while (i == i + 1) {} loop doesn't change the value of i, making this loop infinite is equivalent to choosing a value of i that satisfies i == i + 1.



    There are many such values:



    Let's start with the "exotic" ones:



    double i = Double.POSITIVE_INFINITY;


    or



    double i =  Double.NEGATIVE_INFINITY;


    The reason for these values satisfying i == i + 1 is stated in
    JLS 15.18.2. Additive Operators (+ and -) for Numeric Types:




    The sum of an infinity and a finite value is equal to the infinite operand.




    This is not surprising, since adding a finite value to an infinite value should result in an infinite value.



    That said, most of the values of i that satisfy i == i + 1 are simply large double (or float) values:



    For example:



    double i = Double.MAX_VALUE;


    or



    double i = 1000000000000000000.0;


    or



    float i = 1000000000000000000.0f;


    The double and float types have limited precision, so if you take a large enough double or float value, adding 1 to it will result in the same value.






    share|improve this answer



















    • 9




      Or (double)(1L<<53) -- or float i = (float)(1<<24)
      – dave_thompson_085
      Nov 28 '18 at 9:43






    • 3




      @Ruslan: Any mathematician would disagree. Floating point numbers make very little sense. They are non-associative, non-reflexive (NaN != NaN), and not even substitutable (-0 == 0, but 1/0 != 1/-0). So most of the machinery of algebra is inapplicable.
      – Kevin
      Nov 28 '18 at 16:35






    • 2




      @Kevin while floating-point numbers can't indeed make too much sense in general, the behavior of infinities (which is what is described in that sentence) was designed to make sense.
      – Ruslan
      Nov 28 '18 at 16:38








    • 4




      @Kevin To be fair to floats, if you deal with infinities or undefined values you can't assume the properties you listed in algebra either.
      – Voo
      Nov 28 '18 at 17:11








    • 2




      @Kevin: IMHO, floating-point maths could have made a lot more sense if they'd replaced the concepts of "positive and negative zero" sign positive, negative, and unsigned "infinitesimals" along with one "true zero", and made NaN equal to itself. True zero could behave as an additive identity in all cases, and something operations involving division by infinitesimals would lose their bias towards assuming the infinitesimals are positive.
      – supercat
      Nov 28 '18 at 17:15
















    139














    First of all, since the while (i == i + 1) {} loop doesn't change the value of i, making this loop infinite is equivalent to choosing a value of i that satisfies i == i + 1.



    There are many such values:



    Let's start with the "exotic" ones:



    double i = Double.POSITIVE_INFINITY;


    or



    double i =  Double.NEGATIVE_INFINITY;


    The reason for these values satisfying i == i + 1 is stated in
    JLS 15.18.2. Additive Operators (+ and -) for Numeric Types:




    The sum of an infinity and a finite value is equal to the infinite operand.




    This is not surprising, since adding a finite value to an infinite value should result in an infinite value.



    That said, most of the values of i that satisfy i == i + 1 are simply large double (or float) values:



    For example:



    double i = Double.MAX_VALUE;


    or



    double i = 1000000000000000000.0;


    or



    float i = 1000000000000000000.0f;


    The double and float types have limited precision, so if you take a large enough double or float value, adding 1 to it will result in the same value.






    share|improve this answer



















    • 9




      Or (double)(1L<<53) -- or float i = (float)(1<<24)
      – dave_thompson_085
      Nov 28 '18 at 9:43






    • 3




      @Ruslan: Any mathematician would disagree. Floating point numbers make very little sense. They are non-associative, non-reflexive (NaN != NaN), and not even substitutable (-0 == 0, but 1/0 != 1/-0). So most of the machinery of algebra is inapplicable.
      – Kevin
      Nov 28 '18 at 16:35






    • 2




      @Kevin while floating-point numbers can't indeed make too much sense in general, the behavior of infinities (which is what is described in that sentence) was designed to make sense.
      – Ruslan
      Nov 28 '18 at 16:38








    • 4




      @Kevin To be fair to floats, if you deal with infinities or undefined values you can't assume the properties you listed in algebra either.
      – Voo
      Nov 28 '18 at 17:11








    • 2




      @Kevin: IMHO, floating-point maths could have made a lot more sense if they'd replaced the concepts of "positive and negative zero" sign positive, negative, and unsigned "infinitesimals" along with one "true zero", and made NaN equal to itself. True zero could behave as an additive identity in all cases, and something operations involving division by infinitesimals would lose their bias towards assuming the infinitesimals are positive.
      – supercat
      Nov 28 '18 at 17:15














    139












    139








    139






    First of all, since the while (i == i + 1) {} loop doesn't change the value of i, making this loop infinite is equivalent to choosing a value of i that satisfies i == i + 1.



    There are many such values:



    Let's start with the "exotic" ones:



    double i = Double.POSITIVE_INFINITY;


    or



    double i =  Double.NEGATIVE_INFINITY;


    The reason for these values satisfying i == i + 1 is stated in
    JLS 15.18.2. Additive Operators (+ and -) for Numeric Types:




    The sum of an infinity and a finite value is equal to the infinite operand.




    This is not surprising, since adding a finite value to an infinite value should result in an infinite value.



    That said, most of the values of i that satisfy i == i + 1 are simply large double (or float) values:



    For example:



    double i = Double.MAX_VALUE;


    or



    double i = 1000000000000000000.0;


    or



    float i = 1000000000000000000.0f;


    The double and float types have limited precision, so if you take a large enough double or float value, adding 1 to it will result in the same value.






    share|improve this answer














    First of all, since the while (i == i + 1) {} loop doesn't change the value of i, making this loop infinite is equivalent to choosing a value of i that satisfies i == i + 1.



    There are many such values:



    Let's start with the "exotic" ones:



    double i = Double.POSITIVE_INFINITY;


    or



    double i =  Double.NEGATIVE_INFINITY;


    The reason for these values satisfying i == i + 1 is stated in
    JLS 15.18.2. Additive Operators (+ and -) for Numeric Types:




    The sum of an infinity and a finite value is equal to the infinite operand.




    This is not surprising, since adding a finite value to an infinite value should result in an infinite value.



    That said, most of the values of i that satisfy i == i + 1 are simply large double (or float) values:



    For example:



    double i = Double.MAX_VALUE;


    or



    double i = 1000000000000000000.0;


    or



    float i = 1000000000000000000.0f;


    The double and float types have limited precision, so if you take a large enough double or float value, adding 1 to it will result in the same value.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 29 '18 at 8:22

























    answered Nov 28 '18 at 9:33









    Eran

    280k37453539




    280k37453539








    • 9




      Or (double)(1L<<53) -- or float i = (float)(1<<24)
      – dave_thompson_085
      Nov 28 '18 at 9:43






    • 3




      @Ruslan: Any mathematician would disagree. Floating point numbers make very little sense. They are non-associative, non-reflexive (NaN != NaN), and not even substitutable (-0 == 0, but 1/0 != 1/-0). So most of the machinery of algebra is inapplicable.
      – Kevin
      Nov 28 '18 at 16:35






    • 2




      @Kevin while floating-point numbers can't indeed make too much sense in general, the behavior of infinities (which is what is described in that sentence) was designed to make sense.
      – Ruslan
      Nov 28 '18 at 16:38








    • 4




      @Kevin To be fair to floats, if you deal with infinities or undefined values you can't assume the properties you listed in algebra either.
      – Voo
      Nov 28 '18 at 17:11








    • 2




      @Kevin: IMHO, floating-point maths could have made a lot more sense if they'd replaced the concepts of "positive and negative zero" sign positive, negative, and unsigned "infinitesimals" along with one "true zero", and made NaN equal to itself. True zero could behave as an additive identity in all cases, and something operations involving division by infinitesimals would lose their bias towards assuming the infinitesimals are positive.
      – supercat
      Nov 28 '18 at 17:15














    • 9




      Or (double)(1L<<53) -- or float i = (float)(1<<24)
      – dave_thompson_085
      Nov 28 '18 at 9:43






    • 3




      @Ruslan: Any mathematician would disagree. Floating point numbers make very little sense. They are non-associative, non-reflexive (NaN != NaN), and not even substitutable (-0 == 0, but 1/0 != 1/-0). So most of the machinery of algebra is inapplicable.
      – Kevin
      Nov 28 '18 at 16:35






    • 2




      @Kevin while floating-point numbers can't indeed make too much sense in general, the behavior of infinities (which is what is described in that sentence) was designed to make sense.
      – Ruslan
      Nov 28 '18 at 16:38








    • 4




      @Kevin To be fair to floats, if you deal with infinities or undefined values you can't assume the properties you listed in algebra either.
      – Voo
      Nov 28 '18 at 17:11








    • 2




      @Kevin: IMHO, floating-point maths could have made a lot more sense if they'd replaced the concepts of "positive and negative zero" sign positive, negative, and unsigned "infinitesimals" along with one "true zero", and made NaN equal to itself. True zero could behave as an additive identity in all cases, and something operations involving division by infinitesimals would lose their bias towards assuming the infinitesimals are positive.
      – supercat
      Nov 28 '18 at 17:15








    9




    9




    Or (double)(1L<<53) -- or float i = (float)(1<<24)
    – dave_thompson_085
    Nov 28 '18 at 9:43




    Or (double)(1L<<53) -- or float i = (float)(1<<24)
    – dave_thompson_085
    Nov 28 '18 at 9:43




    3




    3




    @Ruslan: Any mathematician would disagree. Floating point numbers make very little sense. They are non-associative, non-reflexive (NaN != NaN), and not even substitutable (-0 == 0, but 1/0 != 1/-0). So most of the machinery of algebra is inapplicable.
    – Kevin
    Nov 28 '18 at 16:35




    @Ruslan: Any mathematician would disagree. Floating point numbers make very little sense. They are non-associative, non-reflexive (NaN != NaN), and not even substitutable (-0 == 0, but 1/0 != 1/-0). So most of the machinery of algebra is inapplicable.
    – Kevin
    Nov 28 '18 at 16:35




    2




    2




    @Kevin while floating-point numbers can't indeed make too much sense in general, the behavior of infinities (which is what is described in that sentence) was designed to make sense.
    – Ruslan
    Nov 28 '18 at 16:38






    @Kevin while floating-point numbers can't indeed make too much sense in general, the behavior of infinities (which is what is described in that sentence) was designed to make sense.
    – Ruslan
    Nov 28 '18 at 16:38






    4




    4




    @Kevin To be fair to floats, if you deal with infinities or undefined values you can't assume the properties you listed in algebra either.
    – Voo
    Nov 28 '18 at 17:11






    @Kevin To be fair to floats, if you deal with infinities or undefined values you can't assume the properties you listed in algebra either.
    – Voo
    Nov 28 '18 at 17:11






    2




    2




    @Kevin: IMHO, floating-point maths could have made a lot more sense if they'd replaced the concepts of "positive and negative zero" sign positive, negative, and unsigned "infinitesimals" along with one "true zero", and made NaN equal to itself. True zero could behave as an additive identity in all cases, and something operations involving division by infinitesimals would lose their bias towards assuming the infinitesimals are positive.
    – supercat
    Nov 28 '18 at 17:15




    @Kevin: IMHO, floating-point maths could have made a lot more sense if they'd replaced the concepts of "positive and negative zero" sign positive, negative, and unsigned "infinitesimals" along with one "true zero", and made NaN equal to itself. True zero could behave as an additive identity in all cases, and something operations involving division by infinitesimals would lose their bias towards assuming the infinitesimals are positive.
    – supercat
    Nov 28 '18 at 17:15













    64














    These puzzles are described in detail in the "Java Puzzlers: Traps, Pitfalls, and Corner Cases" book by Joshua Bloch and Neal Gafter.



    double i = Double.POSITIVE_INFINITY;
    
while (i == i + 1) {}


    or:



    double i = 1.0e40;
    
while (i == i + 1) {}


    both will result in an infinite loop, because adding 1 to a floating-point value that is sufficiently large will not change the value, because it doesn't "bridge the gap" to its successor1.



    A note about the second puzzle (for future readers):



    double i = Double.NaN;
    
while (i != i) {}


    also results in an infinite loop, because NaN is not equal to any floating-point value, including itself 2.




    1 - Java Puzzlers: Traps, Pitfalls, and Corner Cases (chapter 4 - Loopy Puzzlers).



    2 - JLS §15.21.1






    share|improve this answer



















    • 7




      There should be a seperate hell for everyone that uses i as a non integer variable. Or a as a counter at all... Not your fault I know...
      – Kami Kaze
      Nov 29 '18 at 8:56










    • @KamiKaze Especially since several high-level languages have i defined as sqrt(-1) by default and you end up overloading -- actually overriding -- this value.
      – Carl Witthoft
      Nov 29 '18 at 16:10
















    64














    These puzzles are described in detail in the "Java Puzzlers: Traps, Pitfalls, and Corner Cases" book by Joshua Bloch and Neal Gafter.



    double i = Double.POSITIVE_INFINITY;
    
while (i == i + 1) {}


    or:



    double i = 1.0e40;
    
while (i == i + 1) {}


    both will result in an infinite loop, because adding 1 to a floating-point value that is sufficiently large will not change the value, because it doesn't "bridge the gap" to its successor1.



    A note about the second puzzle (for future readers):



    double i = Double.NaN;
    
while (i != i) {}


    also results in an infinite loop, because NaN is not equal to any floating-point value, including itself 2.




    1 - Java Puzzlers: Traps, Pitfalls, and Corner Cases (chapter 4 - Loopy Puzzlers).



    2 - JLS §15.21.1






    share|improve this answer



















    • 7




      There should be a seperate hell for everyone that uses i as a non integer variable. Or a as a counter at all... Not your fault I know...
      – Kami Kaze
      Nov 29 '18 at 8:56










    • @KamiKaze Especially since several high-level languages have i defined as sqrt(-1) by default and you end up overloading -- actually overriding -- this value.
      – Carl Witthoft
      Nov 29 '18 at 16:10














    64












    64








    64






    These puzzles are described in detail in the "Java Puzzlers: Traps, Pitfalls, and Corner Cases" book by Joshua Bloch and Neal Gafter.



    double i = Double.POSITIVE_INFINITY;
    
while (i == i + 1) {}


    or:



    double i = 1.0e40;
    
while (i == i + 1) {}


    both will result in an infinite loop, because adding 1 to a floating-point value that is sufficiently large will not change the value, because it doesn't "bridge the gap" to its successor1.



    A note about the second puzzle (for future readers):



    double i = Double.NaN;
    
while (i != i) {}


    also results in an infinite loop, because NaN is not equal to any floating-point value, including itself 2.




    1 - Java Puzzlers: Traps, Pitfalls, and Corner Cases (chapter 4 - Loopy Puzzlers).



    2 - JLS §15.21.1






    share|improve this answer














    These puzzles are described in detail in the "Java Puzzlers: Traps, Pitfalls, and Corner Cases" book by Joshua Bloch and Neal Gafter.



    double i = Double.POSITIVE_INFINITY;
    
while (i == i + 1) {}


    or:



    double i = 1.0e40;
    
while (i == i + 1) {}


    both will result in an infinite loop, because adding 1 to a floating-point value that is sufficiently large will not change the value, because it doesn't "bridge the gap" to its successor1.



    A note about the second puzzle (for future readers):



    double i = Double.NaN;
    
while (i != i) {}


    also results in an infinite loop, because NaN is not equal to any floating-point value, including itself 2.




    1 - Java Puzzlers: Traps, Pitfalls, and Corner Cases (chapter 4 - Loopy Puzzlers).



    2 - JLS §15.21.1







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 28 '18 at 10:38

























    answered Nov 28 '18 at 10:01









    Oleksandr

    8,80843770




    8,80843770








    • 7




      There should be a seperate hell for everyone that uses i as a non integer variable. Or a as a counter at all... Not your fault I know...
      – Kami Kaze
      Nov 29 '18 at 8:56










    • @KamiKaze Especially since several high-level languages have i defined as sqrt(-1) by default and you end up overloading -- actually overriding -- this value.
      – Carl Witthoft
      Nov 29 '18 at 16:10














    • 7




      There should be a seperate hell for everyone that uses i as a non integer variable. Or a as a counter at all... Not your fault I know...
      – Kami Kaze
      Nov 29 '18 at 8:56










    • @KamiKaze Especially since several high-level languages have i defined as sqrt(-1) by default and you end up overloading -- actually overriding -- this value.
      – Carl Witthoft
      Nov 29 '18 at 16:10








    7




    7




    There should be a seperate hell for everyone that uses i as a non integer variable. Or a as a counter at all... Not your fault I know...
    – Kami Kaze
    Nov 29 '18 at 8:56




    There should be a seperate hell for everyone that uses i as a non integer variable. Or a as a counter at all... Not your fault I know...
    – Kami Kaze
    Nov 29 '18 at 8:56












    @KamiKaze Especially since several high-level languages have i defined as sqrt(-1) by default and you end up overloading -- actually overriding -- this value.
    – Carl Witthoft
    Nov 29 '18 at 16:10




    @KamiKaze Especially since several high-level languages have i defined as sqrt(-1) by default and you end up overloading -- actually overriding -- this value.
    – Carl Witthoft
    Nov 29 '18 at 16:10











    1














    Just an idea: what about booleans?



    bool i = TRUE;


    Isn't this a case where i + 1 == i?






    share|improve this answer





















    • depends on the language. Many languages automatically coerce booleans to ints when combined with an int. Others do as you suggest - coercing the int to a boolean.
      – Carl Witthoft
      Nov 29 '18 at 16:12






    • 6




      This question is a Java question, and your suggestion doesn't pass compilation in Java (which has no + operator that takes a boolean and an int as operands).
      – Eran
      Nov 30 '18 at 9:05










    • @Eran: that's the whole idea of operator overloading. You can make Java booleans behave like C++ ones.
      – Dominique
      Nov 30 '18 at 9:26






    • 2




      Except that Java doesn't support operator overloading, so you can't.
      – CupawnTae
      Dec 5 '18 at 9:33
















    1














    Just an idea: what about booleans?



    bool i = TRUE;


    Isn't this a case where i + 1 == i?






    share|improve this answer





















    • depends on the language. Many languages automatically coerce booleans to ints when combined with an int. Others do as you suggest - coercing the int to a boolean.
      – Carl Witthoft
      Nov 29 '18 at 16:12






    • 6




      This question is a Java question, and your suggestion doesn't pass compilation in Java (which has no + operator that takes a boolean and an int as operands).
      – Eran
      Nov 30 '18 at 9:05










    • @Eran: that's the whole idea of operator overloading. You can make Java booleans behave like C++ ones.
      – Dominique
      Nov 30 '18 at 9:26






    • 2




      Except that Java doesn't support operator overloading, so you can't.
      – CupawnTae
      Dec 5 '18 at 9:33














    1












    1








    1






    Just an idea: what about booleans?



    bool i = TRUE;


    Isn't this a case where i + 1 == i?






    share|improve this answer












    Just an idea: what about booleans?



    bool i = TRUE;


    Isn't this a case where i + 1 == i?







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 29 '18 at 15:09









    Dominique

    1,77441539




    1,77441539












    • depends on the language. Many languages automatically coerce booleans to ints when combined with an int. Others do as you suggest - coercing the int to a boolean.
      – Carl Witthoft
      Nov 29 '18 at 16:12






    • 6




      This question is a Java question, and your suggestion doesn't pass compilation in Java (which has no + operator that takes a boolean and an int as operands).
      – Eran
      Nov 30 '18 at 9:05










    • @Eran: that's the whole idea of operator overloading. You can make Java booleans behave like C++ ones.
      – Dominique
      Nov 30 '18 at 9:26






    • 2




      Except that Java doesn't support operator overloading, so you can't.
      – CupawnTae
      Dec 5 '18 at 9:33


















    • depends on the language. Many languages automatically coerce booleans to ints when combined with an int. Others do as you suggest - coercing the int to a boolean.
      – Carl Witthoft
      Nov 29 '18 at 16:12






    • 6




      This question is a Java question, and your suggestion doesn't pass compilation in Java (which has no + operator that takes a boolean and an int as operands).
      – Eran
      Nov 30 '18 at 9:05










    • @Eran: that's the whole idea of operator overloading. You can make Java booleans behave like C++ ones.
      – Dominique
      Nov 30 '18 at 9:26






    • 2




      Except that Java doesn't support operator overloading, so you can't.
      – CupawnTae
      Dec 5 '18 at 9:33
















    depends on the language. Many languages automatically coerce booleans to ints when combined with an int. Others do as you suggest - coercing the int to a boolean.
    – Carl Witthoft
    Nov 29 '18 at 16:12




    depends on the language. Many languages automatically coerce booleans to ints when combined with an int. Others do as you suggest - coercing the int to a boolean.
    – Carl Witthoft
    Nov 29 '18 at 16:12




    6




    6




    This question is a Java question, and your suggestion doesn't pass compilation in Java (which has no + operator that takes a boolean and an int as operands).
    – Eran
    Nov 30 '18 at 9:05




    This question is a Java question, and your suggestion doesn't pass compilation in Java (which has no + operator that takes a boolean and an int as operands).
    – Eran
    Nov 30 '18 at 9:05












    @Eran: that's the whole idea of operator overloading. You can make Java booleans behave like C++ ones.
    – Dominique
    Nov 30 '18 at 9:26




    @Eran: that's the whole idea of operator overloading. You can make Java booleans behave like C++ ones.
    – Dominique
    Nov 30 '18 at 9:26




    2




    2




    Except that Java doesn't support operator overloading, so you can't.
    – CupawnTae
    Dec 5 '18 at 9:33




    Except that Java doesn't support operator overloading, so you can't.
    – CupawnTae
    Dec 5 '18 at 9:33











    1














    double i = Double.POSITIVE_INFINITY;






    share|improve this answer


























      1














      double i = Double.POSITIVE_INFINITY;






      share|improve this answer
























        1












        1








        1






        double i = Double.POSITIVE_INFINITY;






        share|improve this answer












        double i = Double.POSITIVE_INFINITY;







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 9 '18 at 19:17









        Farcas George

        211




        211






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid …



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid …



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53516189%2ffor-what-value-of-i-does-while-i-i-1-loop-forever%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            -

            Popular posts from this blog

            How to make a Squid Proxy server?

            Image
            1 I want to set up squid proxy server for monitoring user activity in a network and Internet Web URL filtering for user. I also want to configure the user login, user log, user access group, and block unwanted web sites in my network. Please help me and guide me the full process to do this. server proxy squid share | improve this question edited Jul 31 '12 at 14:45 Jorge Castro 37.1k 107 422 617 asked Jul 31 '12 at 5:16 Goivind Tiwari Goivind Tiwari
            Read more

            Is this a new Fibonacci Identity?

            Image
            6 1 $begingroup$ I have found the following Fibonacci Identity (and proved it). If $F_n$ denotes the nth Fibonacci Number, we have the following identity begin{equation} F_{n-r+h}F_{n+k+g+1} - F_{n-r+g}F_{n+k+h+1} = (-1)^{n+r+h+1} F_{g-h}F_{k+r+1} end{equation} where $F_1 = F_2 = 1$ , $r leq n$ , $h leq g$ , and $n, g, k in mathbb{N}$ . It is not too hard to show that this identity subsumes Cassini's Identity, Catalan's Identity, Vajda's Idenity, and d'Ocagne's identity to name a few. I have done a pretty thorough literature review, and I have not found anything like this, but I am still wondering if anyone has seen this identity before? I found this by accident after noticing some patterns in some analysis work I was doing, so if this is already known I would be curious to see w
            Read more

            19世紀

            Image
            この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。 （ 2012年3月 ） 千年紀: 2千年紀 世紀: 18世紀 - 19世紀 - 20世紀 十年紀: 1800年代 1810年代 1820年代 1830年代 1840年代 1850年代 1860年代 1870年代 1880年代 1890年代 19世紀に君臨した大英帝国。 19世紀 （じゅうきゅうせいき）は、西暦1801年から西暦1900年までの100年間を指す世紀。 目次 1 19世紀の歴史 1.1 国民国家の成立 1.2 帝国主義の興隆 1.3 列強の植民地争奪戦 2 できごと 2.1 1800年代 2.2 1810年代 2.3 1820年代 2.4 1830年代 2.5 1840年代 2.6 1850年代 2.7 1860年代 2.8 1870年代 2.9 1880年代 2.10 1890年代 2.11 1900年代 3 文化 3.1 文学 3.2 音楽 3.3 思想 3.4 科学 3.5 技術 4 人物 4.1 ヨーロッパ 4.1.1 政治家・王族 4.1.1.1 フランス 4.1.1.2 オーストリア＝ハンガリー 4.1.1.3 ロシア 4.1.1.4 イギリス 4.1.1.5 ドイツ（プロイセンほかドイツ領邦を含む） 4.1.1.6 北欧 4.1.1.7 イタリア 4.1.1.8 スペイン 4.1.1.9 ベルギー 4.1.1.10 ギリシア 4.1.2 軍人 4.1.3 実業家 4.1.4 科学と技術 4.1.5 思想と哲学・人文諸学 4.1.6 宗教 4.1.7 文学 4.1.8 美術 4.1.9 音楽 4.1.10 社会事業家 4.1.11 探検家・旅行家 4.1.12 料
            Read more