Return to Answer

As far as I know, it is not a bug and thanks to @Gordon's comment, I dig up a bit more in the subject and figured out that it's actually more complicated that what I thought it was.

What is happening here is, as @Gordon and @Gorgeous said, a Floating point precision problem.

Float numbers are stored as bits with 3 parts : the sign bit, the exponent bits and the mantissa bits. The mantissa bits (sometimes it can be called a sinificand) are the ones that give the actual precision to the number while the exponent bits tell how big the number is. Basically, the bigger the exponent is the lower the precision is going to be.

It's explained by this chart

which I took from this page.

The second column indicates the range of the represented number and the 4th column gives the amount of precision you'll get if you represent that number as a float, if the difference between two numbers is less than the number in that column then they will be considered to be the same.

You can have an exact precision for whole numbers up to $16777217$ (which is $2^{24}$) but if you go beyond that, whole numbers will not be represented accurately anymore. You can try typing 16777217 for example and you'll see that it'll get "round down" to 16777216.

And contrarily to the previous answer I wrote 12345678910 is not the larger number Blender can handle, it can go as far as 340282346638528859811704183484516925440 (it will be considered as inf) but as explained earlier, accuracy will suffer a lot at that range.

As far as I know, it is not a bug and thanks to @Gordon's comment, I dig up a bit more in the subject and figured out that it's actually more complicated that what I thought it was.

What is happening here is, as @Gordon and @Gorgeous said, a Floating point precision problem.

Float numbers are stored as bits with 3 parts : the sign bit, the exponent bits and the mantissa bits. The mantissa bits (sometimes it can be called a sinificand) are the ones that give the actual precision to the number while the exponent bits tell how big the number is. Basically, the bigger the exponent is the lower the precision is going to be.

It's explained by this chart

which I took from this page.

The second column indicates the range of the represented number and the 4th column gives the amount of precision you'll get if you represent that number as a float, if the difference between two numbers is less than the number in that column then they will be considered to be the same.

You can have an exact precision for whole numbers up to $16777216$ (which is $2^{24}$) but if you go beyond that, whole numbers will not be represented accurately anymore. You can try typing 16777217 for example and you'll see that it'll get "round down" to 16777216.

And contrarily to the previous answer I wrote 12345678910 is not the larger number Blender can handle, it can go as far as 340282346638528859811704183484516925440 (it will be considered as inf) but as explained earlier, accuracy will suffer a lot at that range.

As far as I know, it is not a bug and thanks to @Gordon's comment, I dig up a bit more in the subject and figured out that it's actually more complicated that what I thought it was.

What is happening here is, as @Gordon and @Gorgeous said, a Floating point precision problem.

Float numbers are stored as bits with 3 parts : the sign bit, the exponent bits and the mantissa bits. The mantissa bits (sometimes it can be called a sinificand) are the ones that give the actual precision to the number while the exponent bits tell how big the number is. Basically, the bigger the exponent is the lower the precision is going to be.

It's explained by this chart

which I took from this page.

The second column indicates the range of the represented number and the 4th column gives the amount of precision you'll get if you represent that number as a float, if the difference between two numbers is less than the number in that column then they will be considered to be the same.

You can have an exact precision for whole numbers up to $8388608$ (which is $2^{23}$) but if you go beyond that, whole numbers will not be represented accurately anymore. You can try typing 16777217 for example and you'll see that it'll get "round down" to 16777216.

And contrarily to the previous answer I wrote 12345678910 is not the larger number Blender can handle, it can go as far as 340282346638528859811704183484516925440 (it will be considered as inf) but as explained earlier, accuracy will suffer a lot at that range.

As far as I know, it is not a bug and thanks to @Gordon's comment, I dig up a bit more in the subject and figured out that it's actually more complicated that what I thought it was.

What is happening here is, as @Gordon and @Gorgeous said, a Floating point precision problem.

Float numbers are stored as bits with 3 parts : the sign bit, the exponent bits and the mantissa bits. The mantissa bits (sometimes it can be called a sinificand) are the ones that give the actual precision to the number while the exponent bits tell how big the number is. Basically, the bigger the exponent is the lower the precision is going to be.

It's explained by this chart

which I took from this page.

The second column indicates the range of the represented number and the 4th column gives the amount of precision you'll get if you represent that number as a float, if the difference between two numbers is less than the number in that column then they will be considered to be the same.

You can have an exact precision for whole numbers up to $16777217$ (which is $2^{24}$) but if you go beyond that, whole numbers will not be represented accurately anymore. You can try typing 16777217 for example and you'll see that it'll get "round down" to 16777216.

And contrarily to the previous answer I wrote 12345678910 is not the larger number Blender can handle, it can go as far as 340282346638528859811704183484516925440 (it will be considered as inf) but as explained earlier, accuracy will suffer a lot at that range.

As far as I know, it is not a bug and thanks to @Gordon's comment, I dig up a bit more in the subject and figured out that it's actually more complicated that what I thought it was.

What is happening here is, as @Gordon and @Gorgeous said, a Floating point precision problem.

Float numbers are stored as bits with 3 parts : the sign bit, the exponent bits and the mantissa bits. The mantissa bits (sometimes it can be called a sinificand) are the ones that give the actual precision to the number while the exponent bits tell how big the number is. Basically, the bigger the exponent is the lower the precision is going to be.

It's explained by this chart

which I took from this page.

The second column indicates the range of the represented number and the 4th column gives the amount of precision you'll get if you represent that number as a float, if the difference between two numbers is less than the number in that column then they will be considered to be the same.

You can have an exact precision for whole numbers up to $16 777 216$ (which is $2^{24}$) but if you go beyond that, whole numbers will not be represented accurately anymore. You can try typing 16 777 217 for example and you'll see that it'll get "round up" to 16 777 216.

As far as I know, it is not a bug and thanks to @Gordon's comment, I dig up a bit more in the subject and figured out that it's actually more complicated that what I thought it was.

What is happening here is, as @Gordon and @Gorgeous said, a Floating point precision problem.

Float numbers are stored as bits with 3 parts : the sign bit, the exponent bits and the mantissa bits. The mantissa bits (sometimes it can be called a sinificand) are the ones that give the actual precision to the number while the exponent bits tell how big the number is. Basically, the bigger the exponent is the lower the precision is going to be.

It's explained by this chart

which I took from this page.

The second column indicates the range of the represented number and the 4th column gives the amount of precision you'll get if you represent that number as a float, if the difference between two numbers is less than the number in that column then they will be considered to be the same.

You can have an exact precision for whole numbers up to $8388608$ (which is $2^{23}$) but if you go beyond that, whole numbers will not be represented accurately anymore. You can try typing 16777217 for example and you'll see that it'll get "round down" to 16777216.

And contrarily to the previous answer I wrote 12345678910 is not the larger number Blender can handle, it can go as far as 340282346638528859811704183484516925440 (it will be considered as inf) but as explained earlier, accuracy will suffer a lot at that range.