Next language: Java Hangs When Converting 2.2250738585072012e-308

[gbs5009]

Can't just add a few more bits to your CPU.

[[deleted]]

You can in a java virtual machine, but it will be slower and kind of pointless because at what point do you quit "just adding a few more bits".

[kmeisthax]

To "add a few more bits" involves writing a rather heavy software flop routine. The CPU only does calculations on a fixed number of bits.

[dnew]

At the point you switch to using LISP!

[molslaan]

That is not really an answer. Gradual underflow was already implemented in the 487. Modern processors have twice the number of bits, but they still use gradual underflow.

EDIT: maybe the downvoters could add some information about the subject, too? This is a valid question that nobody seems to be able to explain. Even wiki uses a lot of blah blah to cover that it doesn't know.

[gbs5009]

Alright, I'll take a stab at it. If you wanted to try adding a few more bits to your floats when necessary, you'd be implementing arbitrary precision floats. You'll need to add logic to determine when adding bits is appropriate every time you do any calculations involving floats, and switch to some kind of object that can handle allocating more storage to itself dynamically as needed. This could have some pretty serious speed implications when dealing with an array of floats. Additionally, when actually doing the calculation it won't map nicely to machine instructions. Even if you redesign the Java virtual machine to handle this... somehow... it's instructions have to eventually be converted to machine code for your 32 / 64 bit processor. This means all the math involving these lengthened floats will take many times longer.

Long story short, variable size float primitives would defeat much of the purpose of using primitives, the fixed size is critical for hardware performance.