So someone asked me what the output would be for this program, so I decided to run it and show them a screen shot; however for some reason some funky stuff is going on...
For some reason @ 7 it goes 70000005 then 8000001??? What is up with that...?
Soo..... That's incredibly bad..... Doubles do the same thing? Why even use them if they have an extreme possibility of messing up... Especially with a JOKE example like this.....
I'm a bit saddened by this, but what do you suggest happens when we encounter this? Do a decimal format or something to ensure it doesn't do this again?
Jay Orsaw wrote:
I have a program that I need to convert a VB single into a Java Float, but the VB uses a different EET??? Standard than Java does... :'(
I thought that Visual Basic uses the same floating point standard as Java -- that is, IEEE 754.
Jay Orsaw wrote:Why even use them if they have an extreme possibility of messing up... Especially with a JOKE example like this.....
This is a limitation of the hardware - how computers store numbers. It is impossible to accurately store most decimal numbers EXACTLY. For most applications, floats are 'close enough'.
When they are not, you have the option of using a BigDecimal, but that has other limitations.
As with just about everything in programming, there are tradeoffs you make.
Never ascribe to malice that which can be adequately explained by stupidity.
Jay Orsaw wrote:
I have a program that I need to convert a VB single into a Java Float, but the VB uses a different EET??? Standard than Java does... :'(
I thought that Visual Basic uses the same floating point standard as Java -- that is, IEEE 754.
Henry
I'll have to dig up the thread, but I was converting some data form VB to Java and the floats gave wrong answers for everything I.E., 32.3432423 would be 25.239483290 or something random like that.. Funny how when I search google for "VB Single to Java Float" I get my thread :P http://www.coderanch.com/t/565650//java/Deserializing-Visual-Basic-files-Java Note this was a year ago and I have learned a lot more since then so I apologize for any noob remarks in there.... I did however look the IEEE standard back up and I guess you were right, I thougth I found it to be different... What would explain my issue then?
fred rosenberger wrote:
Jay Orsaw wrote:Why even use them if they have an extreme possibility of messing up... Especially with a JOKE example like this.....
This is a limitation of the hardware - how computers store numbers. It is impossible to accurately store most decimal numbers EXACTLY. For most applications, floats are 'close enough'.
When they are not, you have the option of using a BigDecimal, but that has other limitations.
As with just about everything in programming, there are tradeoffs you make.
I guess... never thought there would be such a big issue, thanks though!!
Bear Bibeault wrote:Calling it a "joke" is just naive. That's just the nature of fixed-register arithmetic.
I don't know why it would create an error like that for such an easy problem, but hey if that's how we have to live our float lives....
Bear Bibeault wrote:Calling it a "joke" is just naive. That's just the nature of fixed-register arithmetic.
I don't know why it would create an error like that for such an easy problem, but hey if that's how we have to live our float lives....
That depends on what you would call "an easy problem". For example, can you give us an exact answer to what is one divided by three? After all, 0.333333333 isn't very accurate is it? Why can't do give an exact answer for something as easy as one divided by three?
The problem is that you judge everything from your world of base 10 arithmetic. For floating point, your decimals are base ten, and times TEN, to an exponent that is also base ten. For the computer (and the IEEE definition), it is based two, and times TWO, to an exponent that is also base two. What seems easy to you, and what seems like it will need to be rounded off, are not necessarily the same as what seems easy and needs to be rounded off to the IEEE standard.
Also, while 32 bits sounds like lots of storage -- remember that a floating point number contains two numbers, a mantissa and an exponent, which must share the 32 bit space. A 32 bit floating point number has much less precision than a 32 bit integer.
It's not an "error" per se, but a rounding approximation. The reason is well understood and is the best that can be done with fixed-register arithmetic.
Bear Bibeault wrote:Calling it a "joke" is just naive. That's just the nature of fixed-register arithmetic.
I don't know why it would create an error like that for such an easy problem, but hey if that's how we have to live our float lives....
That depends on what you would call "an easy problem". For example, can you give us an exact answer to what is one divided by three? After all, 0.333333333 isn't very accurate is it? Why can't do give an exact answer for something as easy as one divided by three?
The problem is that you judge everything from your world of base 10 arithmetic. For floating point, your decimals are base ten, and times TEN, to an exponent that is also base ten. For the computer (and the IEEE definition), it is based two, and times TWO, to an exponent that is also base two. What seems easy to you, and what seems like it will need to be rounded off, are not necessarily the same as what seems easy and needs to be rounded off to the IEEE standard.
Also, while 32 bits sounds like lots of storage -- remember that a floating point number contains two numbers, a mantissa and an exponent, which must share the 32 bit space. A 32 bit floating point number has much less precision than a 32 bit integer.
0
![[Thumbnail for float issue.png]](/t/602981/a/3942/float issue.png "Filename: float issue.png
Description:")
