Processing: Why is the "double" data type is not supported, but made available?

[processing-bugs]

_Original author: [email protected] (February 04, 2011 18:52:19)_

Why is the "double" datatype not supported? The documentation on the reference page doesn't explain this, and it's a bit mystifying: as Processing relies on the standard JRE functionality, and java.lang.Math supports double just fine, there is no reason I can think of to force people to use the less accurate float datatype.

In order to force float-only behaviour pretty much all of java.lang.Math would have had to be either completely custom-written, in which case supporting doubles will mostly mean "stop using that code and just point to java.lang.Math", or there's a check to make sure that everything's a float before it's passed on to java.lang.Math, which generates doubles as output, which are then cast back to float before being returned... which would make even less sense. Removing that would make people who care that their numbers are correct much happier.

Alternatively, the double datatype could be removed from the reference and the parser made to throw a syntax error.. although this would make far less sense than updating the Processing functions so that doubles are properly supported. Regardless the system they run on, any JVM can work with them.

_Original issue: http://code.google.com/p/processing/issues/detail?id=532_

[processing-bugs]

_From [email protected] on February 04, 2011 20:43:00_
Because we're idiots, of course.

But aside from that:

1. A double uses 2x the memory as a float.
2. Computation with doubles is slower, sometimes significantly slower.
3. It would mean additional version of API calls to support doubles.
4. And perhaps most important as a practical matter, it's not necessary for 95-99% of the work done with Processing. Or at least with the API methods in Processing itself.

Now, in the time since the decision was made, some of those things have changed a bit (lots of machines are 64-bit, computation may not be slower, and JVM implementations use 64-bits to store a float), but that's only on the desktop, and it's very, very different between JVM implementations, OS version, architectures, etc. It would be a very complicated and time consuming task to sort all of that out, and it still would not solve #4.

Further, all these issues were re-introduced when we started supporting Android. So there's little motivation to sort out whether to make the switch, when doubles are significantly slower again, memory is scarce, and so on. I don't have time to document and work out two different versions of the API.

For what it's worth, if you want to see things changed/improved/implemented, writing me a rhetorical lecture, seemingly with the attitude that we're morons in the first place, is really not the way to do it. I do this in my free time, help us out.

[processing-bugs]

_From [email protected] on February 04, 2011 22:56:27_
The intention was not to make you seem morons, I just work with doubles a lot on the desktop and couldn't figure out why a project that's based on JVMs didn't offer the same precision as java's native java.lang.Math.

Those four points as to why people shouldn't use the double on http://processing.org/reference/double.html would probably be a good idea.

As a small extra, when I file a bug here I don't expect a specific person to pick it up, it's filed for whoever is part of the dev team really. If you get every individual bug and it sounds like I'm addressing you personally, apologies - I don't. I'll bear it in mind the next time I file one, though.

[processing-bugs]

_From [email protected] on February 05, 2011 16:59:51_
Ha, whether it's a "specific" person or not has nothing to do with being polite about it. Processing isn't done by an army of people (I do 90% of the code, for instance), and dealing with things like this is what prevents us from having time to do things like the documentation you request.

[processing-bugs]

_From [email protected] on February 05, 2011 17:38:57_
I believe you're reading my lack of courtesy words too much as "being rude", I fear. I'm curt in bug reports because I don't want to waste time - I state my findings, my (pre)conceptions about it, and if it's a code bug, what I think might be the problem or if it's an incompleteness, what I think might be needed. Your reactions however highlight the fact that this is not appreciated by everyone. I was under the impression this was a several member dev team, for which I tend not to tailor my reports because some people want reports to be as blunt as possible, so as not to waste time, and some want them written as if told in person, being as nice as possible about it. If it's primarily you, then I shall apologise for my reporting style up to now and stick to your preferred form.

Again, apologies if it has sounded like I'm assaulting you in writing. I'm Dutch. The cultural pattern we're raised with is "speak up and be direct". It tends to be the first pattern I use before moving on to more "pleasant" styles on request.

[processing-bugs]

_From [email protected] on November 08, 2012 21:50:43_
Indeed most of the time "double" is not necessary. However, when I need(or say "would like to try") to implement HMMs in Processing, I have to use "double" datatype, otherwise I will get the probability of 0.0. "float" is not enough.

[processing-bugs]

_From [email protected] on November 08, 2012 21:59:36_
You can use doubles all you want, there are just no Processing APIs (such as line() or rect()) that support them specifically. You can do all your HMM work using doubles, but when drawing to the screen, you'll need to cast to floats. A double is not needed for on-screen drawing.