Bear Bibeault wrote:http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

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?

- 1

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.

There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors

Henry Wong wrote:

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....

- 1

Jay Orsaw wrote:

Bear Bibeault wrote:Calling it a "joke" is just naive. That's just the nature of fixed-register arithmetic.

I don't knowwhy 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.

Henry

- 1

Henry Wong wrote:

Jay Orsaw wrote:

Bear Bibeault wrote:Calling it a "joke" is just naive. That's just the nature of fixed-register arithmetic.

I don't knowwhy 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.

Henry

Gotcha! Thanks to you both!!! Any idea about why I am experience a conversion issue in my other link though? I did find this on google as well http://www.bigresource.com/VB-IEEE-754-float-conversion-HoklM0jamF.html#bgjkcKIC0s

Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |