Makes sense, cause double can represent way bigger numbers than integers.
Only to 2^54. The amount of integers representable by a long is more. But it can and does represent every int value correctly
*long long, if we’re gonna be taking about C types. A long is commonly limited to 32 bits.
A double can represent numbers up to ± 1.79769313486231570x10^308, or roughly 18 with 307 zeroes behind it. You can’t fit that into a long, or even 128 bits. Even though rounding huge doubles is pointless, since only the first dozen digits or so are saved, using any kind of Integer would lead to inconsistencies, and thus potentially bugs.
How does that work? Is it just because double uses more bits? I’d imagine for the same number of bits, you can store more ints than doubles (assuming you want the ints to be exact values).
No, it has an exponent component: https://en.m.wikipedia.org/wiki/Double-precision_floating-point_format
No, I get that. I’m sure the programming language design people know what they are doing. I just can’t grasp how a double (which has to use at least 1 bit to represent whether or not there is a fractional component) can possibly store more exact integer vales than an integer type of the same length (same number of bits).
It just seems to violate some law of information theory to my novice mind.
It’s the same in the the standard c library, so Java is being consistent with a real programming language…
Java has many abstractions that can be beneficial in certain circumstances. However, it forces a design principle that may not work best in every situation.
I.e. inheritance can be both unnatural for the programmer to think in, and is not representative of how data is stored and manipulated on a computer.
You don’t have to use inheritance with Java. In fact, in most cases it’s better that you don’t. Practically all of the Java standard library doesn’t require the use of inheritance, same with most modern libraries.
On the contrary, I think inheritance is a very natural way to think. However, that doesn’t translate into readable and easy to maintain code in the vast majority of the cases.
I am not sure what you mean by how it’s stored or manipulated on a computer. A garbage collected language like Java manages the memory for you. It doesn’t really care if your code is using inheritance or not. And unless you’re trying to squeeze the last drops of performance out of your code, the memory layout shouldn’t be on your mind.
Java is, of course, Turing Complete™️ but when you have to hide all the guns and knives in jdk.internal.misc.Unsafe something is clearly wrong.
I do not like Java but this is a strange argument. The people that invented Java felt that most of the C language should be wrapped in unsafe.
Opinions can vary but saying Java is not a real language is evidence free name calling. One could just as easily say that any language that does not allow you to differentiate between safe and unsafe baheviour is incomplete and not a “real” language. It is not just the Java and C# people that may say this. As a C fan, I am sure you have heard Rust people scoff at C as a legacy language that was fine for its day but clearly outclassed now that the “real” languages have arrived. Are you any more correct than they are?
Doubles have a much higher max value than ints, so if the method were to convert all doubles to ints they would not work for double values above 2^31-1.
(It would work, but any value over 2^31-1 passed to such a function would get clamped to 2^31-1)
To avoid a type conversion that might not be expected. Integer math in Java differs from floating point math.
Math.floor(10.6) / Math.floor(4.6) = 2.5 (double)
If floor returned a long, then
Math.floor(10.6) / Math.floor(4.6) = 2 (long)
If your entire code section is working with doubles, you might not like finding Math.floor() unexpectedly creating a condition for integer division and messing up your calculation. (Have fun debugging this if you’re not actively aware of this behavior).
Because even a long (64-bit int) is too small :)
A long can hold 2^64-1 = 1.84E19
A double can hold 1.79E308
Double does some black magic with an exponent, and can hold absolutely massive numbers!
Double also has some situations that it defines as “infinity”, a concept that does not exist in long as far as I know (?)
yeah that would be pretty effective. could also go to three just to be safe
Makes sense, how would you represent floor(1e42) or ceil(1e120) as integer? It would not fit into 32bit (unsigned) or 31bit (signed) integer. Not even into 64bit integer.
It would be kinda dumb to force everyone to keep casting back to a double, no? If the output were positive, should it have returned an unsigned integer as well?
The CPU has to do real work to convert between float and int types. Returning an int type would just be giving the CPU extra work to do for no reason
I think one of the main reason to use floor/ceilling is to predictably cast a double into int. This type signature kind of defeats this important purpose.
I don’t know this historical context of java, but possibly at that time, people see type more of a burden than a way to garentee correctness? (which is kind of still the case for many programmers, unfortunately.
You wouldn’t need floor/ceil for that. Casting a double to an int is already predictable as the java language spec explicitly says how to do it, so any JVM will do this the exact same way.
The floor/ceil functions are simply primitive math operations and they are meant to be used when doing floating point math.
All math functions return the same type as their input parameters, which makes sense. The only exception are those that are explicitly meant for converting between types.
“predictable” in the sense that people know how it works regardless what language they know.
I guess I mean “no surprise for the reader”, which is more “readability” than “predictability”
