About Processing automatically converting double literals to floats

Hi everyone,

In regular Java and other programming languages, this is well known that you can write :

System.out.println(0.1 + 0.2 == 0.3);

which gives false!!

This is due to floating point precision and how computers store float values : https://0.30000000000000004.com/

Now typing the same in Processing gives this :

System.out.println(0.1 + 0.2); // -> 0.3

So at first I was very intrigued! :thinking:

But looking at the exported application, I saw the packaged code :

import processing.core.*; 
import processing.data.*; 
import processing.event.*; 
import processing.opengl.*; 

import java.util.HashMap; 
import java.util.ArrayList; 
import java.io.File; 
import java.io.BufferedReader; 
import java.io.PrintWriter; 
import java.io.InputStream; 
import java.io.OutputStream; 
import java.io.IOException; 

public class precision extends PApplet {
  public void setup() {
System.out.println(0.1f + 0.2f);
    noLoop();
  }

  static public void main(String[] passedArgs) {
    String[] appletArgs = new String[] { "precision" };
    if (passedArgs != null) {
      PApplet.main(concat(appletArgs, passedArgs));
    } else {
      PApplet.main(appletArgs);
    }
  }
}

Which shows that Processing is adding the letter f to each double literal value automatically.

Actually in the Java section it shows that using floats solve this issue.

Thought, this is nice for us :

Is the fact that float values avoid some precision errors the only reason behind Processing changing things behind the scene?

Also how much does the Processing IDE hide code pre processing for us? (I know that it wraps the whole code inside the PApplet class :wink: )

Float is far less accurate than double - they’re not removing precision errors, they’re adding them.

1 Like

@neilcsmith Yes you are totally right, the fact that float values have more rounding error (and got it right with the addition above) is confusing because you can think that they are more precise that double ! :wink:

So is this the reason why sometimes this happens?

float a = 123;
int b = 2;
float c = a + b;
println(c); // prints ->  125.00000000003

Yes, see the website linked above - https://0.30000000000000004.com/ (I’d missed @josephh has posted this link until Discourse warned me I was posting the same thing! :smile: )

The funny thing is that at times float might look more accurate, because the error is so small it doesn’t fit in a float. It looks correct because it’s more imprecise.

Processing’s decision to use floats instead of doubles is one of my pet hates - it makes little sense in most cases, and the preprocessor needed to transpile is one of the reasons Processing is so far behind Java in its syntax. PraxisLIVE actually uses double throughout its Processing wrapper API for this reason.

2 Likes

@neilcsmith Do you know what part in the the source code is responsible for the transpiling part? I couldn’t find it :thinking:

@josephh see here and other code in that package processing/PdePreprocessor.java at master · processing/processing · GitHub

1 Like

If you really need your floating literals to be double instead of float inside a “.pde” file just suffix them w/ the letter d or D: :bulb:
static final double PI_DOUBLE_PRECISION = 3.141592653589793d;

1 Like