Welcome to the Java Programming Forums
The professional, friendly Java community. 21,500 members and growing!
The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.
>> REGISTER NOW TO START POSTING
Members have full access to the forums. Advertisements are removed for registered users.
LinkBack URL
About LinkBacks
Question about rounding
Is there a way in Java to round a number without using and external class such as Math and the method from the class to round up the number?
And if possible how to round to the nearest integer,while rounding according to the halfway up criteria.
I seen mention in a topic entitled "Mathematics in Java" where a user mentioned using a substring. Also I heard by type casting the number ,if the variable is a float or double, into a long variable. A
Any ideas?
Thank you very much.
Last edited by CoolGuy134; September 26th, 2011 at 08:43 PM.
Related threads:
Re: Question about rounding
Why not use an external class? To use primitives, multiply the floating point variable by a multiplier of 10, cast to an int, cast back to the original type and divide by the same multiplier. Use the following syntax to cast a variable:Is there a way in Java to round a number without using and external class such as Math and the method from the class to round up the number?
float fVal = 1.111f; int iVal = (int)fVal;
Re: Question about rounding
Un-optimized, and probably overkill. However, it will maintain all exponents correctly, and works with the two infinities and NaN.
public static double round(double original_value) { long value = Double.doubleToLongBits(original_value); // extract the exponent long exponent = (value & 0x7FF0000000000000L) >> 52; long mantissa = value & 0x000FFFFFFFFFFFFFL | 0x0010000000000000L; exponent -= 0x3FFL; if (exponent <= -2) { return 0; } else if (exponent == -1) { return 1; } else if (exponent < 52) { long mask = 0xFFFFFFFFFFFFFFFFL >>> 52 - exponent << 52 - exponent; value &= mask; if ((mantissa & 1L << 51 - exponent) != 0) { // round up return Double.longBitsToDouble(value) + 1.; } // round down return Double.longBitsToDouble(value); } else { return original_value; // no rounding needed } }
A similar solution exists for floats.
Last edited by helloworld922; September 27th, 2011 at 12:23 AM.
Re: Question about rounding
I'm not sure - I didn't actually try it - how that would round 1.5 to 2. Does it work?(copeg) multiply the floating point variable by a multiplier of 10
The way I would usually do this is through observing that 'nearest' is a two-way split: it's either next one up or previous one down. If you multiply a floating point number by two, then the integer part is 2x the original integer part for all fractional parts less than 0.5. If the fractional part is 0.5 or greater, the integer part of the doubled number is 2x + 1 the original integer part. If you add 1 to the doubled result and convert it to an integer, this new integer is either 2x + 2 or 2x + 1 depending on whether the original fractional part was greater than 0.5 or less than 0.5. Halving this integer gives you either x + 1 or x, depending on whether ... you know.
I was getting ready to pontificate about 'relying on implementation details', but on reading the API doc I see this method is badly named. Using Double.doubleToIEEE754DoubleBits(double) is of course an entirely reasonable and reliable way of doing it as long as IEEE754 is immutable.Double.doubleToLongBits(
Re: Question about rounding
Well, technically the Java Language Specifications spells out specifically how a double and float are represented. If the IEEE754 standard changes, then the Java Language Specification will just not comply to that standard
Of course, if that happens, a lot of hardware is going to break first since most hardware FPU's implement the current IEEE754 standard (or a previous version, which uses the same bit formatting).
Re: Question about rounding
It does spell out specifically, but not how double and float are implemented:spells out specifically
This is what I expect the Java specification to be: no commitment to implementation details at the binary level. It doesn't matter what the IEEE754 standard is at the binary level - the entire point of the JVM and the JLS is to provide a compatibility layer for the underlying platform on which Java applications run.float and double, which are conceptually associated with the single-precision 32-bit and double-precision 64-bit format IEEE 754 values
A *conceptual* association means you can use it in any way that you would use a 'raw' IEEE754 value, but no promise is made as regards its binary implementation. Note that with doubleToLongBits you are not inspecting the binary implementation of a double, but from the API doc for doubleToLongBits():
- it doesn't matter how double is implemented by the JVM and (as far as I know) no method exists to check its implementation. While doubleToLongBits returns an IEEE754-1985 binary representation from a Java-native double, your method will continue to work, by design.a representation of the specified floating-point value
Your approach is valid - you're obtaining a representation of a value that is no more and no less valid than the original, but which comes with some extra information you can test. It would be bad if you were testing the underlying implementation - but by specification ("conceptually associated") and implication (there's a method to create an IEE754 representation) you're not. Even if a Java double is implemented at the binary level as IEEE754 suggests, it doesn't affect the validity of your method (or my argument as to why your method *is* valid when at first glance it looks like a kludge) because you're not operating on the underlying implementation (which is usually a SlightlyBadThing), but a well-specified representation of that double value.
Are you familiar with JNI? I keep meaning to try out some long-lived compute-intensive code I have with a C++ implementation, but I'm scared of compromising the reliability of a pure-Java implementation. I see from a quick look at the WWW that when you write C++ code to manipulate Java doubles, the C++ code seems to always use a 'jdouble' type that must be from a C++-native library. I would have expected if there was any direct implementation similarity between Java doubles and C++ doubles that there'd be a trivial correspondence between Java double and C++ double. This page at SO makes me think that a lot of programming languages may be using 'conceptual association'!
Is there an open-source c/c++ implementation of IEEE-754 operations? - Stack Overflow
Does it look like I'm arguing with you? I'm still trying to explain why I *nearly* criticised your method, but didn't and still haven't. It's an entirely valid approach to a problem in double, but the reason why is a bit convoluted.
Re: Question about rounding
Ah, true that there's no guarantee of the ordering of the bits, only that they must be able to hold those values
most languages I know of don't actually manipulate floating point numbers (or even integer numbers) at that level normally. Instead, it's handled by hardware. That's the whole purpose of FPU's, which is where I think the "conceptual association" comes from. Personally I'm much more likely to trust hardware than software since many modern hardware companies "prove" their hardware, not just present test cases.
I have worked with JNI a little bit, it's fairly simple to use except for a few minor details which may catch you off guard. As far as I know, doubles in Java and in C++ are represented the same (due to a similar reliance on the underlying hardware implementation).
Re: Question about rounding
Hardware is a big space. Every compiled programming language will provide a maths library or attempt to use maths routines offered by the OS. The amount of work done in software and delegated to hardware will vary enormously from platform to platform. Check out some of these well known platforms:Instead, it's handled by hardware
ARM A9 - FPU is optional?:
Cortex-A9 Processor - ARM
Some embedded x86 have no FPU:Optional NEON™ media and/or floating point processing engine
Using software floating point on x86 linux - Stack Overflow
Partial support on MIPS:
Floating point - LinuxMIPS
The conceptual association in the JLS is certainly from the point of view of use of Java double: it's telling you you can do anything with a Java double you might expect to do with an IEEE754-1985 (not a -2008 one!) double. The nitty-gritty of floating point computation may be delegated by the JVM to whatever support exists on the target platform - but I suspect it could be difficult to guarantee that the results of double computations are identical across all JVMs unless they're carried out in software by the JVM itself.
Are you assuming 'black box so it must work'?much more likely to trust hardwareThis is a great James Gosling article which touches on a lot of the issue brought up by this discussion. You'll never use floating point again:
James Gosling: on the Java Road - Transcendental Meditation
Reply With Quote
