538
Java
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Aug 2023
538 points (92.4% liked)
Programmer Humor
19503 readers
314 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
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?
intcoerces todoubleautomatically, without explicit castingThe 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'm learning so much from this thread and I don't even use Java
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"
Is there any language that doesn’t just truncate when casting from a float to an int?
As far as I know, haskell do not allow coresion of float to int without specifying a method (floor, ceil, round, etc): https://hoogle.haskell.org/?hoogle=Float+-%3E+Integer&scope=set%3Astackage
Agda seems to do the same: https://agda.github.io/agda-stdlib/Data.Float.Base.html