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











up vote
108
down vote

favorite
21












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 at 9:35






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 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 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 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 at 23:41















up vote
108
down vote

favorite
21












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 at 9:35






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 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 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 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 at 23:41













up vote
108
down vote

favorite
21









up vote
108
down vote

favorite
21






21





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 at 11:28









Oleksandr

8,71543768




8,71543768










asked Nov 28 at 9:31









jake mckenzie

677157




677157








  • 3




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






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 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 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 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 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 at 9:35






  • 7




    @Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
    – Andrew Tobilko
    Nov 28 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 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 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 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 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 at 9:35




7




7




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




@Raedwald studying "unprofessional" code makes you more "professional", so... Anyway, it's a good question
– Andrew Tobilko
Nov 28 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 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 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 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 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 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 at 23:41












4 Answers
4






active

oldest

votes

















up vote
135
down vote



accepted










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 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 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 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 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 at 17:15


















up vote
65
down vote













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 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 at 16:10


















up vote
1
down vote













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 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 at 9:05










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






  • 1




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


















up vote
-1
down vote













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',
    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








    up vote
    135
    down vote



    accepted










    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 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 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 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 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 at 17:15















    up vote
    135
    down vote



    accepted










    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 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 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 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 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 at 17:15













    up vote
    135
    down vote



    accepted







    up vote
    135
    down vote



    accepted






    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 at 8:22

























    answered Nov 28 at 9:33









    Eran

    277k37446531




    277k37446531








    • 9




      Or (double)(1L<<53) -- or float i = (float)(1<<24)
      – dave_thompson_085
      Nov 28 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 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 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 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 at 17:15














    • 9




      Or (double)(1L<<53) -- or float i = (float)(1<<24)
      – dave_thompson_085
      Nov 28 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 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 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 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 at 17:15








    9




    9




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




    Or (double)(1L<<53) -- or float i = (float)(1<<24)
    – dave_thompson_085
    Nov 28 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 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 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 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 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 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 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 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 at 17:15












    up vote
    65
    down vote













    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 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 at 16:10















    up vote
    65
    down vote













    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 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 at 16:10













    up vote
    65
    down vote










    up vote
    65
    down vote









    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 at 10:38

























    answered Nov 28 at 10:01









    Oleksandr

    8,71543768




    8,71543768








    • 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 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 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 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 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 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 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 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 at 16:10










    up vote
    1
    down vote













    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 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 at 9:05










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






    • 1




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















    up vote
    1
    down vote













    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 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 at 9:05










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






    • 1




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













    up vote
    1
    down vote










    up vote
    1
    down vote









    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 at 15:09









    Dominique

    1,55641538




    1,55641538












    • 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 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 at 9:05










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






    • 1




      Except that Java doesn't support operator overloading, so you can't.
      – CupawnTae
      Dec 5 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 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 at 9:05










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






    • 1




      Except that Java doesn't support operator overloading, so you can't.
      – CupawnTae
      Dec 5 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 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 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 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 at 9:05












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




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




    1




    1




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




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










    up vote
    -1
    down vote













    double i = Double.POSITIVE_INFINITY;






    share|improve this answer

























      up vote
      -1
      down vote













      double i = Double.POSITIVE_INFINITY;






      share|improve this answer























        up vote
        -1
        down vote










        up vote
        -1
        down vote









        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 at 19:17









        Farcas George

        1




        1






























            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

            Berounka

            Image
            Berounka.mw-parser-output .entete.map{background-image:url("//upload.wikimedia.org/wikipedia/commons/7/7a/Picto_infobox_map.png")} Caractéristiques Longueur 139  km Bassin 8 861  km 2 Bassin collecteur Elbe Débit moyen ? Cours Source Confluence de la Mže et de la Radbuza · Localisation Pilsen · Altitude 305  m · Coordonnées 49° 45′ 13″ N, 13° 23′ 24″ E Confluence Vltava · Localisation Prague · Altitude 187  m · Coordonnées 49° 59′ 43″ N, 14° 24′ 04″ E Géographie Pays traversés   République tchèque modifier   La Berounka est une rivière de la République tchèque. Elle porte le nom de Mže depuis sa source en Allemagne près de la frontière jusqu'à sa confluence avec la Radbuza à Plzeň. Elle continue ensuite sous le nom de Berounka jusqu'à sa confluence avec la Vltava, près de Prague. La rivière est une destination prisée pour les amateurs de canoë, qui appréc...
            Read more

            Sphinx de Gizeh

            Image
            Pour les articles homonymes, voir Sphinx. Sphinx de Gizeh.mw-parser-output .entete.egypte-antique{background-image:url("//upload.wikimedia.org/wikipedia/commons/c/cc/Picto_infobox_ancient_Egypt.png")} Site d'Égypte antique Le visage du sphinx de Gizeh. Noms en arabe أبو الهول , Abou al-Hôl Localisation Région Basse-Égypte Coordonnées 29° 58′ 31″ nord, 31° 08′ 16″ est Géolocalisation sur la carte : Égypte Sphinx de Gizeh modifier   Le sphinx de Gizeh est la statue thérianthrope qui se dresse devant les grandes pyramides du plateau de Gizeh, en Basse-Égypte. Sculpture monumentale monolithique la plus grande du monde [ 1 ] avec 73,5 mètres de longueur, 14 mètres de largeur et 20,22 mètres de hauteur, elle représente un sphinx couchant. Réalisée vers -2500, elle serait attribuée à Djédefrê, l'un des pharaons de la IV e  dynastie, représentant son père le pharaon Khéops. Sommaire 1 Étymologie 2 Desc...
            Read more

            Different font size/position of beamer's navigation symbols template's content depending on regular/plain...

            Image
            3 Let's suppose I'd like to divert the navigation symbols template (e.g. in order replace them by the frame numbers, see this bug report ;) I would be facing troubles regarding the font size/position, depending on regular/plain frames, as shown by the following MCE. How could I get rid of these troubles? documentclass{beamer} usetheme{PaloAlto} setbeamertemplate{navigation symbols}{insertframenumber/inserttotalframenumber} begin{document} begin{frame} frametitle{A regular frame} end{frame} begin{frame}[plain] frametitle{A plain frame} end{frame} end{document} beamer header-footer share | improve this question asked Dec 10 '18 a...
            Read more