• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java floats  RSS feed

 
Josh Theisen
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey guys - so I was asked to do a little assignment here... and we're supposed to use the data type float (32 bit floating point).

Here's the assignment: write a program so sum the following sequence:

1.0/1.0 + 1.0/2.0 + 1.0/3.0 + 1.0/4.0 + ... + 1.0/x, where x = 15,000,000.0

Then I'm supposed to loop through it again, but this time, backwards. i.e. (1/15000000.0 + 1/14999999.0 + ... + 1/1)

So I've done that (I think) as seen here:



When going up, I get 15.403683, when going down, I get: 16.117563
Now I know the values are supposed to be different (teacher told us that), but I'm not exactly sure why.

We are also supposed to say which of the two sums is probably the most accurate ...

Guess I'm not sure which one would be more accurate than the other.

Thanks!
 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, your second result is incorrect.
 
Josh Theisen
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:Actually, your second result is incorrect.

Whoops - guessing the 2nd for loop needs to be "for (float i = second; i >= 1.0f; i--) { "
Greater than or equal to one instead of 1...
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josh Theisen wrote:
Paul Clapham wrote:Actually, your second result is incorrect.

Whoops - guessing the 2nd for loop needs to be "for (float i = second; i >= 1.0f; i--) { "
Greater than or equal to one instead of 1...


Did you try it? Did you get different results?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josh Theisen wrote:
Now I know the values are supposed to be different (teacher told us that), but I'm not exactly sure why.

We are also supposed to say which of the two sums is probably the most accurate ...

Guess I'm not sure which one would be more accurate than the other.


Floating point numbers have a fixed number of bits (or digits) of precision, but they're called "floating point" because the scale at which that precision is used can vary. For instance, Java's float type has about 9 decimal digits of precision. That means it can represent 123,456,789,000.0 fairly accurately, and it can represent 0.000123456789 fairly accurately, but it cannot represent 123,456,789,000.000123456789 very accurately. It will get rounded to 123,456,789,000 (or to the closest value to that that float can actually represent).

So, what do you think will happen if you add 0.0001 to 123,456,789,000? And what do you think will happen if you add 0.0001 to 0.000123456789?
 
Josh Theisen
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:Did you try it? Did you get different results?

I did - the second result was increased by 1, which is what I thought would happen.

Jeff Verdegan wrote:So, what do you think will happen if you add 0.0001 to 123,456,789,000? And what do you think will happen if you add 0.0001 to 0.000123456789?

If you ad .0001 to the first number you mentioned, it wouldn't do anything if I'm understanding it right. However, in your 2nd example, .0001 would get added no problem and change the value.

So in my case... if I'm understanding it correctly, the 2nd value should be more accurate.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josh Theisen wrote:
Jeff Verdegan wrote:So, what do you think will happen if you add 0.0001 to 123,456,789,000? And what do you think will happen if you add 0.0001 to 0.000123456789?

If you ad .0001 to the first number you mentioned, it wouldn't do anything if I'm understanding it right. However, in your 2nd example, .0001 would get added no problem and change the value.

So in my case... if I'm understanding it correctly, the 2nd value should be more accurate.


Correct. 100000.0 + 0.00000001 will just give the original 100000.0 back, so adding a bunch smaller values to a much larger value ends up with no net effect, even if you add 0.00000001 enough times that it "should" give you and end result of 200000.0. But adding 0.00000001 to 0.00000001 gives 0.00000002, and continuing to add more numbers of that scale will build up, and if you add enough small numbers to reach the scale of the larger number, that value will have an effect.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote: . . . For instance, Java's float type has about 9 decimal digits of precision.
7 digits. It uses 24 bits for the significand (mantissa) in the “normal” range, which equates to 24 × log2 = 7.225 sig fig
That means it can represent 123,456,789,000.0 fairly accurately, and it can represent 0.000123456789 fairly accurately . . .
No, it can’t.output: 1.23456794E9
It is all right up to the 7th digit, and then goes off completely.

Why on earth anybody would want to do such arithmetic in floats is beyond me, unless it is in order to demonstrate the imprecision of floating-point arithmetic.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Jeff Verdegan wrote: . . . For instance, Java's float type has about 9 decimal digits of precision.
7 digits. It uses 24 bits for the significand (mantissa) in the “normal” range, which equates to 24 × log2 = 7.225 sig fig


Meh. 7 is "about" 9

That means it can represent 123,456,789,000.0 fairly accurately, and it can represent 0.000123456789 fairly accurately . . .
No, it can’t.output: 1.23456794E9
It is all right up to the 7th digit, and then goes off completely.



Okay, you got me.

@OP: I hope you didn't take my post to mean that you'd be guaranteed 9 digits of accuracy with a float. I was just pulling rough numbers out of the air to make a point. The values I used were wrong, but the point applies.

Why on earth anybody would want to do such arithmetic in floats is beyond me, unless it is in order to demonstrate the imprecision of floating-point arithmetic.


"KEEP OFF THIS SIGN"
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have written a program to demonstrate that, if you try hard enough, you can find places where a float is not precise to 1 significant figureIf you add a 3 at the end of that number, making 0.0000000000000000000000000000000000000000000023, you get a slightly different output!
 
Josh Theisen
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for all the replies. So just to make sure I'm understanding this correctly ... in my example, the 2nd number (coming down from 1/15000000) will be more accurate since it has more significant digits due to the way that floats truncate?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Josh Theisen wrote:Thanks for all the replies. So just to make sure I'm understanding this correctly ... in my example, the 2nd number (coming down from 1/15000000) will be more accurate since it has more significant digits due to the way that floats truncate?


They all have the same number of significant digits. But if you start with higher magnitudes, you cannot see any result from adding or subtracting lower magnitude numbers because they are beyond the round-off point.
 
Paul Clapham
Sheriff
Posts: 22844
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Why on earth anybody would want to do such arithmetic in floats is beyond me, unless it is in order to demonstrate the imprecision of floating-point arithmetic.


In this case, that's exactly what it's for.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!