11–20 of 158 posts
Article says 1,056,964,609 / 1,056,964,610 Quick Java program says 1,065,353,216 / 1,065,353,217 Which one is right? Or are Java floats just "different"? static { float a = 0; long count = 0; while (a
Is this not just shorthand, but an actual legitimate Java program these days?
> Of all the float-pointing point numbers your computer can represent, a quarter of them lie in [0,1]. Many people think floating point numbers are magically precise. They're not. They're far more accurate at lower magnitudes and precision fades as you work with larger values.
I actually found something recently on this topic while googling for any alternatives, its called Unum and looks very interesting: https://en.wikipedia.org/wiki/Unum_(number_format)
Does anyone know more about this? Are there any chips out there that support it?
Article says 1,056,964,609 / 1,056,964,610 Quick Java program says 1,065,353,216 / 1,065,353,217 Which one is right? Or are Java floats just "different"? static { float a = 0; long count = 0; while (a
Offtopic, but: Is this not just shorthand, but an actual legitimate Java program these days?
Article says 1,056,964,609 / 1,056,964,610 Quick Java program says 1,065,353,216 / 1,065,353,217 Which one is right? Or are Java floats just "different"? static { float a = 0; long count = 0; while (a
Offtopic, but: Is this not just shorthand, but an actual legitimate Java program these days?
public class Main {
static {
System.out.println("Hello world");
}
public static void main(String[] args) {}
}
Honestly, I think IEEE 754 floating point numbers are a pretty bad way of dealing with real numbers and just cause tons of headaches that every math library has to deal with. Even high level programmers aren't shielded from the NaN nonsense. It would be great if we had an underlying implementation we could ignore and that allowed us to think at a more mathematical level. I actually found something recently on this to…
> Of all the float-pointing point numbers your computer can represent, a quarter of them lie in [0,1]. Many people think floating point numbers are magically precise. They're not. They're far more accurate at lower magnitudes and precision fades as you work with larger values.
It does a variable number of fraction bits, so that the values near 1 are even more densely represented than under the usual IEEE floats, while also providing greater dynamic range (but at reduced precision).
I made a little diagram showing a visual comparison of every represented value in a toy 8-bit version vs. IEEE-style floats: https://groups.google.com/group/unum-computing/attach/e80274...
(Also, this is arguably an exception to Betteridge's Law, and arguably not an exception to Betteridge's Law.)
(I invoke my pedant-pass.) As formulated in the title, "How many floating-point numbers are in the interval [0,1]?" you could argue that this is the cardinality of the Real Numbers. What the article says it is really talking about are single-precision IEEE 754 floating-point numbers. However, I could define any number of my own floating-point representations at various sizes. The cardinality of all possible floating…
I have never seen the term used in anything like that context.
To me, the term “floating point number” is about number representation, not number identity. It is an inherently finite quantity in every instance I’ve ever seen.
Examples of floating point numbers: The sexagesimal cuneiform 42 25 35 written on the Babylonian tablet YBC 7289; 3.1415 × 10⁰; 1.010101010101₂ >> 2.
Not examples of floating point numbers (in my opinion): 1/√2; π, 1/3.