I see that the web is full of people who don't like that design feature of Java, but perhaps you could expand on why it's a problem for you.
Thou shalt not try me. Mom 24:7
Jim Venolia wrote:
I see that the web is full of people who don't like that design feature of Java, but perhaps you could expand on why it's a problem for you.
Err, as an embedded engineer with 40 years experience this strikes me as exactly the wrong attitude to take. In my domain I really want to know when I get underflow so I can deal with it.
Paul Clapham wrote:Well, yeah, the people griping on the web are on your side. But I'm curious about what one would typically do when encountering FP underflow.
Thou shalt not try me. Mom 24:7
Maybe your disagreement isn't with Java® at all, but with IEEE754. I know there are features about IEEE754 which aren't necessarily mathematically sound, including the very existence of remainder operators, but we are stuck with it for better or worse.Mike Simmons wrote:Personally, it's always annoyed me that Java doesn't have safer math operations by default. . . .
I remember being taught that underflow is a problem specific to floating‑point arithmetic.. . . integers, . . . only need to check for overflow, never underflow . . .
I would agree with the notion that 1.0 ÷ 0.0 = ∞, but maybe we should be throwing exceptions instead of producing NaNs.. . . it's not clear whether other conditions like dividing by 0 . . . should be converted to an exception, or whether we can just continue to use values like POSITIVE_INFINITY and NAN . . .
Carey Brown wrote:Perhaps Bob's problems could be reduced or eliminated by similar analysis and optimization of the order of operations being performed. Incorporating a divide() method would serve to highlight cases where analysis and optimization could be applied in a more focused manner.
Let's go to the waterfront with this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|