# Processing 4 Java Bug bad printing of a number

**URL:** <https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398>\
**Category:** Beginners\
**Created:** [May 16, 2025, 12:44am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398 "2025-05-16T00:44:20Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![mvq](https://avatars.discourse-cdn.com/v4/letter/m/9de053/32.png) [@mvq](https://discourse.processing.org/u/mvq)\
**Post date:** [May 16, 2025, 12:44am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/1 "2025-05-16T00:44:20Z")

</div>

Have got a bug - look like its JAVA that freaking.

```Processing
float [][] vDATA = {{45576469, 84.847, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95, }, // tous 253
{45576469, 84.861, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86, }, // tous 254
{45576469, 84.875, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86, }, // tous 255
{45576469, 84.889, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95, }, // tous 256
{45576469, 84.903, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95, }} ; // tous 257

for(int i = 0; i< vDATA.length ; i++) {
  
  println( (int)vDATA[i][0] + ", " + vDATA[i][1] + ", ") ;   

  
  
  
  
}
/*
Result   
45576468, 84.847, // should be 45576469 ????
45576468, 84.861, 
45576468, 84.875, 
45576468, 84.889, 
45576468, 84.903, 
*/

```

---

<div class="post-metadata">

**Author:** ![GoToLoop](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/gotoloop/32/86_2.png) [@GoToLoop](https://discourse.processing.org/u/GoToLoop)\
**Post date:** [May 16, 2025, 12:58am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/2 "2025-05-16T00:58:25Z")

</div>

> **[double / Reference](https://processing.org/reference/double.html)**
>
> Datatype for floating-point numbers larger than those that can be stored in a float. A float is a 32-bit values that can be as large as 3.40282347E+38 and as low as -3.40282347E+38. A

---

<div class="post-metadata">

**Author:** ![mvq](https://avatars.discourse-cdn.com/v4/letter/m/9de053/32.png) [@mvq](https://discourse.processing.org/u/mvq)\
**Post date:** [May 16, 2025, 2:20am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/4 "2025-05-16T02:20:24Z")

</div>

Yes but why

printing 45576469 , 84.847, give 45576468 , 84.847,

---

<div class="post-metadata">

**Author:** ![mvq](https://avatars.discourse-cdn.com/v4/letter/m/9de053/32.png) [@mvq](https://discourse.processing.org/u/mvq)\
**Post date:** [May 16, 2025, 2:35am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/6 "2025-05-16T02:35:29Z")

</div>

Ok Find the solution but I don’t know why Java react like that 🙂

```Processing
float [][] vDATA = {{ 45576469 , 84.847, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }, // tous 253
{ 45576469 , 84.861, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86 }, // tous 254
{ 45576469 , 84.875, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86 }, // tous 255
{ 45576469 , 84.889, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }, // tous 256
{ 45576469 , 84.903, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }} ; // tous 257

for(int i = 0; i< vDATA.length ; i++) {
  
  println( (int)vDATA[i][0] + ", " + vDATA[i][1] + ", ") ;   

  

}

/*
45576468, 84.847, BUG 45576468 --> 69
45576468, 84.861, 
45576468, 84.875, 
45576468, 84.889, 
45576468, 84.903, 
*/

println() ;

int [][] vDATA2 = {{ 45576469 , 84847, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }, // tous 253
{ 45576469 , 84861, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86 }, // tous 254
{ 45576469 , 84875, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86 }, // tous 255
{ 45576469 , 84889, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }, // tous 256
{ 45576469 , 84903, 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }} ; // tous 257

for(int i = 0; i< vDATA2.length ; i++) {
  
  println( vDATA2[i][0] + ", " + vDATA2[i][1]/1000.0 + ", ") ;   

  

}
/*
45576469, 84.847, // Good print
45576469, 84.861, 
45576469, 84.875, 
45576469, 84.889, 
45576469, 84.903,
*/

```

---

<div class="post-metadata">

**Author:** ![scudly](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/scudly/32/5597_2.png) [@scudly](https://discourse.processing.org/u/scudly)\
**Post date:** [May 16, 2025, 4:21am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/7 "2025-05-16T04:21:00Z")

</div>

Floating-point numbers are stored in a format similar to numbers in scientific notation with an exponent and a mantissa (the significant digits) all packed into either 32 bits of space for a `float` or 64 bits for a `double`.

For a `float` data type, the mantissa stores 23 bits with an implied leading 1 as a 24th bit. That means a `float` can only store integer values up to 2^24 or 16777216 before they start losing precision. The other 9 bits in the `float` store the sign and 8 bits for the exponent.

If you try to assign an integer with a value larger than 2^24 into a `float`, the lowest binary digits simply won’t be stored, effectively be zero-ing them out. Printing isn’t the problem. Storing a number with enough precision is the problem.

A `double` stores 53 bits in its mantissa, so it can easily store all the values of a 32-bit integer without loss. Or, as you do, you can store the numbers as integers as long as they are smaller than 2^31 or 2147483648 (leaving the 32nd bit for the sign).

---

<div class="post-metadata">

**Author:** ![GoToLoop](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/gotoloop/32/86_2.png) [@GoToLoop](https://discourse.processing.org/u/GoToLoop)\
**Post date:** [May 16, 2025, 9:58am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/8 "2025-05-16T09:58:21Z")

</div>

Given the index[1] is the only [`float`](https://processing.org/reference/float.html) primitive datatype, you can store it separately:  
`final float[] fDATA = { 84.847, 84.861, 84.875, 84.889, 84.903 };`

Also, the index[0] is the only big [`int`](https://processing.org/reference/int.html) value. For the other indices, a [`byte`](https://processing.org/reference/byte.html) is just enough:

```auto
final int[] iDATA = { 45576469, 45576469, 45576469, 45576469, 45576469 };

final float[] fDATA = { 84.847, 84.861, 84.875, 84.889, 84.903 };

final byte[][] vDATA = {
  { 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }, // tous 253
  { 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86 }, // tous 254
  { 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 87, 88, 89, 91, 92, 93, 94, 95, 96, -86 }, // tous 255
  { 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 }, // tous 256
  { 45, 57, 64, 69, 73, 76, 79, 81, 83, 85, 86, 87, 88, 89, 91, 92, 93, 94, 95 } // tous 257
};

for (int i = 0; i < vDATA.length; i++)
  println(i + ":", iDATA[i] + ",", fDATA[i] + ",", join(str(vDATA[i]), ", "));

```

---

<div class="post-metadata">

**Author:** ![Max\_Normal](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/max_normal/32/20757_2.png) [@Max\_Normal](https://discourse.processing.org/u/Max_Normal)\
**Post date:** [May 17, 2025, 8:09am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/9 "2025-05-17T08:09:52Z")

</div>

IEEE 754 floating point representation is a way of storing an **approximation** of a floating point value.  
Plug the numbers in at: [IEEE-754 Floating Point Converter](https://www.h-schmidt.net/FloatConverter/IEEE754.html)

The error is 2.1941146866818489163783179429718e-8 : don’t use floating point when you want integers.

---

<div class="post-metadata">

**Author:** ![glv](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/glv/32/18785_2.png) [@glv](https://discourse.processing.org/u/glv)\
**Post date:** [May 17, 2025, 8:07pm UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/10 "2025-05-17T20:07:53Z")

</div>

Hello @Max_Normal ,

> [@Max\_Normal](#):
>
> The error is 2.1941146866818489163783179429718e-8 : don’t use floating point when you want integers.

Please provided details to reproduce this.

Thanks!

`:)`

---

<div class="post-metadata">

**Author:** ![Max\_Normal](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/max_normal/32/20757_2.png) [@Max\_Normal](https://discourse.processing.org/u/Max_Normal)\
**Post date:** [May 18, 2025, 1:15am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/11 "2025-05-18T01:15:55Z")

</div>

Plug 45576469 into the floating point converter, you’ll see that it is stored as 45576468 – an error of 1. 1/45576469 = … 2.194e-8

---

<div class="post-metadata">

**Author:** ![Max\_Normal](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/max_normal/32/20757_2.png) [@Max\_Normal](https://discourse.processing.org/u/Max_Normal)\
**Post date:** [May 18, 2025, 6:15am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/12 "2025-05-18T06:15:45Z")

</div>

double will work but the Processing procedures need a cast to float so using nf(…) to tidy the output means that the value will still be off by one. Using Java string formatting (implicitly imported) gets round this…

double foo = 45576469;  
float bar = 45576469;

String stringyNum = String.format(“%.0f”, foo);  
println("Java formatted double: " + stringyNum);  
println("nf(…) cast to float: " + nf((float)foo));

stringyNum = String.format(“%.0f”, bar);  
println("Java formatted float: " + stringyNum);

> > Java formatted double: 45576469  
> > nf(…) cast to float: 45576468  
> > Java formatted float: 45576468

---

<div class="post-metadata">

**Author:** ![GoToLoop](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/gotoloop/32/86_2.png) [@GoToLoop](https://discourse.processing.org/u/GoToLoop)\
**Post date:** [May 18, 2025, 8:53am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/13 "2025-05-18T08:53:32Z")

</div>

> [@Max\_Normal](#):
>
> double foo = 45576469;

Make sure to suffix every `double` literal w/ a `d` or `D` inside a “.pde” file:  
`final double foo = 45_576_469d;`

---

<div class="post-metadata">

**Author:** ![Max\_Normal](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/max_normal/32/20757_2.png) [@Max\_Normal](https://discourse.processing.org/u/Max_Normal)\
**Post date:** [May 18, 2025, 9:37am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/14 "2025-05-18T09:37:15Z")

</div>

> [@GoToLoop](#):
>
> Make sure to suffix every `double` literal w/ a `d` or `D` inside a “.pde” file:  
> `final double foo = 45_576_469d;`

Makes no difference here, the underlying issue is that IEEE-754 stores approximate values and in most cases the errors are (cough) within acceptable bounds. Big integers don’t play well with floating point formats.

I’m not so sure that the ‘d’ suffix is that necessary for a declare and assign statement, double foo = 45576469; and double foo = 45576469d; are not equivalent but they are functionally similar, in the former call the base number will be treated as an integer and converted implicitly to a double.

Little things like this are why we test everything that we write 🙂

---

<div class="post-metadata">

**Author:** ![GoToLoop](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/gotoloop/32/86_2.png) [@GoToLoop](https://discourse.processing.org/u/GoToLoop)\
**Post date:** [May 18, 2025, 10:04am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/15 "2025-05-18T10:04:53Z")

</div>

> [@Max\_Normal](#):
>
> … the base number will be treated as an integer and converted implicitly to a double.

Indeed, for an `int` literal, the `d` suffix is totally unneeded.

But for a literal, intended to be a `double`, includes a dot `.` or an `e`, we have to suffix it w/ a `d` inside a “.pde” file, so the Processing IDE (PDE)'s pre-processor won’t suffix it w/ an `f`!

---

<div class="post-metadata">

**Author:** ![Max\_Normal](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/max_normal/32/20757_2.png) [@Max\_Normal](https://discourse.processing.org/u/Max_Normal)\
**Post date:** [May 18, 2025, 10:18am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/16 "2025-05-18T10:18:31Z")

</div>

I understand your point but wouldn’t a floating point value be range checked at compile time and cast upwards if necessary? Try typing float foo = 3e96; Parser catches badness, caught before compile time and the compiler will be at least as smart.

One of the beauties of Processing is hmmm, unsure about this – start IDE, simple sketch, rattle off a few test cases – shiny, back to main task.

---

<div class="post-metadata">

**Author:** ![GoToLoop](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/gotoloop/32/86_2.png) [@GoToLoop](https://discourse.processing.org/u/GoToLoop)\
**Post date:** [May 18, 2025, 10:30am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/17 "2025-05-18T10:30:32Z")

</div>

Processing’s “Java Mode” has a pre-processor that acts upon all files w/ the “.pde” extension.

If a literal containing any of the characters “.”, “e” or “E”, will automatically be suffixed w/ an “f”, unless it’s already suffixed.

---

<div class="post-metadata">

**Author:** ![Max\_Normal](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/max_normal/32/20757_2.png) [@Max\_Normal](https://discourse.processing.org/u/Max_Normal)\
**Post date:** [May 18, 2025, 10:53am UTC](https://discourse.processing.org/t/processing-4-java-bug-bad-printing-of-a-number/46398/18 "2025-05-18T10:53:57Z")

</div>

Good point…

> double foo = 3e66; // not so good, 3e66 read as float, range error flagged  
> double foo = 3e66d; // dandy! [edit – added semicolon]

Still caught pre-compile [edit – added this line].

Little things like this are why we test everything that we write 🙂