How to measure LSBits-of-difference between floats (if possible)

Dynamik · ‎11-18-2005

Hi,

This question is related to the other thread http://forums.ni.com/ni/board/message?board.id=170&message.id=152287, which discusses how to compare two floats (SGLs or DBLs) for equality.

It was suggested to calculate a difference and compare it to a tolerance, but to make such a comparison work over the set of all possible SGLs (or DBLs) seems to require three external inputs to the comparison - unless the tolerance can be derived from the two principal inputs.

I need this function too!

but instead of hijacking the other thread for an answer to my question (sorry

) here it is in its own thread:

Is it possible and/or practical to determine the difference between floats...

... as measured in least-significant-bits in the mantissa of the float?

Thanks!

When they give imbeciles handicap-parking, I won't have so far to walk!

Dynamik · ‎11-18-2005

... though not looking specifically at bits-of-mantissa, maybe this is close enough(?) - if you see a problem, please share.

Message Edited by Dynamik on 11-18-2005 11:11 PM

Message Edited by Dynamik on 11-18-2005 11:12 PM

When they give imbeciles handicap-parking, I won't have so far to walk!

altenbach · ‎11-19-2005

Well, I think it would be simpler to just divide the two numbers and see how close to 1 the result is. 🙂 See image.

(Of course you could turn the the "Tolerance" into a diagram constant of suitable value for a DBL).

Message Edited by altenbach on 11-19-2005 01:07 AM

LabVIEW Champion.

chilly_charly · ‎11-19-2005

altenbach a écrit:

Well, I think it would be simpler to just divide the two numbers and see how close to 1 the result is. 🙂 See image.

Hummmfff.... err... ahhh...

And what happens when X 2 is equal to zero (of course with X 1 = to something time 10 to the minus whatever you want ) ? 😉 😄

Chilly Charly (aka CC)

Xu · ‎11-19-2005

Hi Dynamik,

I think this is what you want.

Xu

altenbach · ‎11-19-2005

@chilly charly wrote:
And what happens when X 2 is equal to zero (of course with X 1 = to something time 10 to the minus whatever you want ) ? 😉 😄

... edge effects. It will never happen ;). (True, maybe I should not be coding after midnight. 🐵

With the chance that this example is equally bad, here's a version that deals with the possibility that at least one of the inputs is zero. 😄

LabVIEW Champion.

altenbach · ‎11-19-2005

@Xu wrote:
I think this is what you want.

Xu,

Your method will work most of the time but it would fail if the two numbers are very, very close but have a different exponent. It can happen.

You would also have to be careful if the data has just been cast from something else:

In the most general case, it will not work for NaNs as you state, because a NaN is only defined as having and exponent of all "1" and a nonzero mantissa. There is a huge number of possible NaN bit patterns, e.g. as utilized in obfuscated code . 😄
Another problem could occur if the bit representation is denormalized for one of the numbers (exponent is all zeroes, but mantissa is not).
...

Now with LabVIEW 8.0 supporting 64bit integers, we could utilize a similar method for DBLs (again with the same limitations as mentioned above). 🙂

LabVIEW Champion.

Dynamik · ‎11-19-2005

Thank you for the responses!

Thanks XU, for seriously considering an LSB-arithmatic approach.

Hi Altenbach, your first example was bit humiliating, because it was so simple compared to mine! But there are a few substantive differences. Your most recent example requires a multiply and a divide (in most cases.) The example I posted does a lot of comparing, but has only one multiply. These operations require different amounts of time, right? Then again, simplicity's good too!

The need for this compare originally came up when configuration-settings were sent to an instrument then read-back for confirmation. The float sent (as ASCII) didn't always equal the float, converted from ASCII, read back. So the goal of the compare was to ignore conversion noise. For the record, that's why my example treats only same-sign inputs (- sign-change can't be explained by conversion noise.)

Until/unless someone else posts a candidate, I'll probably modify Altenbachs original example to fit my needs (and CC's observations

)

Cheers

When they give imbeciles handicap-parking, I won't have so far to walk!

Xu · ‎11-21-2005

Hi Altenbach,

You wrote: Your method will work most of the time but it would fail if the two numbers are very, very close but have a different exponent. It can happen.

Could you give an example (if the two numbers are very, very close but have a different exponent) ?

You wrote: 2. Another problem could occur if the bit representation is denormalized for one of the numbers (exponent is all zeroes, but mantissa is not).

As my understand, my vi works for denormalized ones. Could you give an example?

I noted another problem in my VI's comment: "tolerance: 1, 2, ..., cannot be too large." should be "tolerance: 0, 1, 2, ..., cannot be too large."

Thank you for your comments,

Xu

altenbach · ‎11-21-2005

@Xu wrote:

Could you give an example (if the two numbers are very, very close but have a different exponent) ?

Try for example x1=2 and x2=2-delta (where delta is a very small number)

(SGL example: x1=2, x2=1.99989998, tolerance=any (0..32!). Your VI says they are not equal.)

I said it does not work if one number is denormalized and the other is normalized and you try to compare them. Even if their value is identical, your VI would flag them as different (see e.g. http://stevehollasch.com/cgindex/coding/ieeefloat.html )

LabVIEW Champion.

LabVIEW