 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / March 2008How many float values in range 0f - 1f inclusive?
How many float values can be represented in the range of 0f through 1f inclusive?  SignatureYes, I've had elementary arithmetic, but it was a long time ago, and I probably wasn't paying enough attention. > How many float values can be represented > in the range of 0f through 1f inclusive? Each bit pattern in the range Float.floatToIntBits(0f) through Float.floatToIntBits(1f) corresponds to a float value in the specified range. Patricia > > How many float values can be represented > > in the range of 0f through 1f inclusive? [quoted text clipped - 4 lines] > > Patricia It's not quite correct. It's not Java question. It's about how float numbers are represented in the memory. This link provides good explanation: http://en.wikipedia.org/wiki/IEEE_754 So, (don't forget normalization, which actually prevents such things, but the DO exist in memory) we need to know what are exponent (2*e) and fraction (1.+ .f) in our implementation. In Java float is 32 bites. So, e has 8 bits and f has 23. Anything which is less then half of 2 is 1. So, All e<0 (127) are between 0 and 1. That's 2**23 * 127 And last number - don't forget +0 and -0 which are two different representation of one number 0. So, we have +1 for -0 in total calculation. You do the math. Alex. http://www.myjavaserver.com/~alexfromohio/ >>> How many float values can be represented >>> in the range of 0f through 1f inclusive? [quoted text clipped - 5 lines] > > It's not quite correct. Perhaps you could identify a bit pattern in that range that does not represent a floating point number, or a bit pattern outside the range I gave that corresponds to a floating point number in 0f through 1f. > So, (don't forget normalization, which actually prevents such things, > but the DO exist in memory) we need to know what are > exponent (2*e) and fraction (1.+ .f) in our implementation. > In Java float is 32 bites. > So, e has 8 bits and f has 23. Normalized floats in IEEE754 do not store the leading 1 bit. However, the positive denomalized floats, bit patterns 0x00000001 through 0x007fffff, are also in the specified range. > And last number - don't forget +0 and -0 which are two different > representation of one number 0. So, we have +1 for -0 in total > calculation. To the limited extent that they are distinct values, I would not think of -0 as being in the range. -0 seems to me more like a placeholder for negative values that underflow to zero. On the other hand, if they are the same value then including -0 makes no difference in the count of float values. Patricia > Perhaps you could identify a bit pattern in that range that does not > represent a floating point number, or a bit pattern outside the range I > gave that corresponds to a floating point number in 0f through 1f. Alex.From.Ohio.Java@gmail.com wrote: >> So, (don't forget normalization, which actually prevents such things, >> but the DO exist in memory) we need to know what are >> exponent (2*e) and fraction (1.+ .f) in our implementation. >> In Java float is 32 bites. >> So, e has 8 bits and f has 23. So there are 31 bits, plus the sign bit. Alex.From.Ohio.Java@gmail.com wrote: >> Anything which is less then half of 2 is 1. So, All e<0 (127) are >> between 0 and 1. >> That's 2**23 * 127 2 ** 23 * (2 ** 7 - 1 ) = 2 ** 30 - 2 ** 23 Your calculations already are on the order of 2 ** 30. > Normalized floats in IEEE754 do not store the leading 1 bit. However, > the positive denomalized floats, bit patterns 0x00000001 through > 0x007fffff, are also in the specified range. SignatureLew > > Perhaps you could identify a bit pattern in that range that does not > > represent a floating point number, or a bit pattern outside the range I [quoted text clipped - 24 lines] > -- > Lew OK, OK. Little tiny hint doesn't work. Let's use brutal force: float f; long i=0, c=0; for(; (i&0x100000000L)==0; i++){ f=Float.intBitsToFloat((int)i); if (f<=2f&&f>=0f){ c++; } } System.out.println(c+" "+i); System.out.println(Math.pow(2, 30)); and output is: 1073741826 4294967296 1.073741824E9 As you can see float range from 0 to 1 inclusively is 2**30 + 2 (which are -0 and 1). Sincerely, Alex. http://www.myjavaserver.com/~alexfromohio/ >>> Perhaps you could identify a bit pattern in that range that does not >>> represent a floating point number, or a bit pattern outside the range I [quoted text clipped - 31 lines] > f=Float.intBitsToFloat((int)i); > if (f<=2f&&f>=0f){ I don't understand this test. Why "f<=2f" rather than "f<=1f"? 1.5f is exactly representable and is less than 2f, but is not in the required range. > c++; > } [quoted text clipped - 12 lines] > Sincerely, Alex. > http://www.myjavaserver.com/~alexfromohio/ > I don't understand this test. Why "f<=2f" rather than "f<=1f"? 1.5f is > exactly representable and is less than 2f, but is not in the required range. > > 1073741826 4294967296 > > 1.073741824E9 You are right. I played with it a little and forgot to change back. 1065353218 4294967296 1.073741824E9 Alex. >> I don't understand this test. Why "f<=2f" rather than "f<=1f"? 1.5f is >> exactly representable and is less than 2f, but is not in the required range. [quoted text clipped - 7 lines] > > Alex. This differs by one from 1065353217, the result of my original suggestion: "Each bit pattern in the range Float.floatToIntBits(0f) through Float.floatToIntBits(1f) corresponds to a float value in the specified range.". The difference is a matter of question interpretation. Should zero be counted once, because it is one value, equal to itself, or twice because it has two representations that behave differently in some ways? Patricia >> How many float values can be represented >> in the range of 0f through 1f inclusive? > > Each bit pattern in the range Float.floatToIntBits(0f) through > Float.floatToIntBits(1f) corresponds to a float value in the specified > range. Well, anyone reading this thread is already convinced of my mathematical naivety, so continuing without embarrassment ... Can I say that there are 0x007fffff float values that can be represented in the range? Can I say that 1f/0x007fffff is the first float value that can be represented in this range, and that 2f * 1f/0x007fffff will be the second? This all came about because I am using a JSlider control to pick values for an java.awt.Color, where the arguments to the Color constructor are values between 0f - 1f. Because JSlider only operates with integer values I was using a range of 0 - 10000 and then multiplying by .0001 to get my float value. I was trying to find a better range of integers to use for my JSlider range so that when I display the value I've picked with the slider I don't get ugly .50168 or some such for .5. I guess I'll probably be better off dealing with that on the display end using printf or decimalFormat or such. Thanks for the info. JH > Patricia [...] > This all came about because I am using a JSlider control to pick > values for an java.awt.Color, where the arguments to the Color [quoted text clipped - 6 lines] > be better off dealing with that on the display end using printf or > decimalFormat or such. Indeed, you should keep the model (rational approximation of a floating point number) separate from the view (meaningful decimal format). It's also useful to recall that a slider models an analog device: it reports the ratio of two screen coordinates with a resolution no greater than that provided by the mouse, roughly one pixel. Given a slider 1000 pixels long, the accuracy can never be more than one part in 10^3, corresponding to an accuracy of three significant digits (sd). The accuracy is proportionally less for a shorter slider: Math.floor (Math.log10 (length)). You can "pin" the slider's value to a particular tick size using an expression such as Math.rint (value / tickSize) * tickSize. You can adjust the tick size according to the slider's longest dimension: say 0.01 for a 100 to 1000 pixels, and 0.001 for > 1000 pixels. Would a custom color chooser provide a better abstraction? <http://java.sun.com/docs/books/tutorial/uiswing/components/colorchooser. html> John SignatureJohn B. Matthews trashgod at gmail dot com home dot woh dot rr dot com slash jbmatthews [...] > Would a custom color chooser provide a better abstraction? Well, that was inspirational! While playing around with the ColorChooserDemo, and in particular the Hue pane, I began to wonder how do they possibly expect to get the 255*255*255 RGB colors with only 360*100*100 when it dawned upon me that the *hue angle* is cyclic so that there are really 360*6*100*100 HSB values represented in that control! My apparent numerical/ conversion problems were all the result of my misunderstanding the parameters to Color.getHSB(hsb), I was attempting to represent the hue parameter as a percentage rather than a hue angle. Now, armed with that revelation I can simply put a mapping in between the java.awt.Color conversion methods and my display and now HSB .5,.5,.5 should equal 128,128,128 RGB. :-) Thanks, JH > John Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.