Darin's Weakly Nugget - 2/8/11

[Darin.K]

Probably all of us have done this, compare two DBLs using our old friend Equals?  We know we are treading on thin ice.  On the one hand we might wind up asking why '2+2' doesn't equal 4, on the other hand tossing epsilon and In Range and Coerce? around makes one feel a little nerdy and Rube Goldberg-ish.  I will never advocate Equals? meaning anything other than all 64-bits matching for DBLs, but, as in horseshoes and hand grenades, 'close' is often good enough.  A couple of VIs will help with the DBL comparison issue, although neither is fully satisfactory.

The two contenders:

vi.lib\picture\smith.llb\Almost Equal.vi

vi.lib\Waveform\WDTOps.llb\Check for Equality.vi

Almost Equal.vi:

Pros: Snappy Icon, precision controllable via control.

Cons:  Does not handle +/- Inf, not polymorphic, issue with small non-zero values for n1 and n2, epsilon terminal wire stub has a gap (just kidding, who else cares about that?)

Check for Equality.vi:

Pros:  Handles Inf, returns precision of match (most times)

Cons: Not polymorphic, 6 digits chosen to represent equality, does not always handle two small, non-zero values well, precision of match retrurns 10 in cases of exact match, less snappy icon.

It would probably be nice to slap the Almost Equal icon onto Check for Equality, fix the bugs, allow the precision to be set by a control, and add polymorphism (mix and match scalars and arrays).  That's not a lot to ask, is it?  For now, I have the Almost Equal Icon slapped on my homebrew version.  I have an option to compare both values to zero, so if a and b are both approximately zero then I consider a approximately equal to b.  As is, both are often preferable to Equals? and crossing your fingers.

As a bonus, check out the Almost In Range.vi in smith.llb.

[altenbach]

Also check out this discussion from Dec 2005, especially the VI Equal DBL.vi. (Ignore the icon, it's for DBL ;))

There is even a link for some easy reading. 😄

[altenbach]

For those who have not run into problems comparing DBLs, here's an illustrative example.

Only the lower loop (using the VI shown in the above post) stops at the correct iteration.

The upper loop is an accurate simulation of the Energizer Bunny. 😄

[Lucither]

Hi Darin,

Quite uncanny the Almost Equals vi, not too long ago i made an 'Approx Equals' Vi which looks almost identical. The only difference is i added an input for accuracy to #decimal places and an input for whether it rounded up/down/Nearest:

I suppose if your going to write a vi to do this its not a massive suprise that the icons look similar 

Rgs,

Lucither.

[DFGray]

It's amazing how your sins return to haunt you.  I "fixed" the Check for Equality.vi for LabVIEW 6i almost eleven years ago.  It was specifically designed to determine if the dt values of waveform datatypes were close enough to call them equal when trying to merge.  I would guess it has not been touched since.  I was aware of its limitations at the time, but they did not need fixing for its intended purpose, so they stayed. You are running into one of the limitations of using VIs not exposed on the palette - some have very specific purposes that do not scale well, but could with a bit of work.

I would encourage you to post an "almost equal" function idea on the idea exchange.  LabVIEW does need it.

[Cory_K]

One way to make it more flexible would be the method used to check the "close-ness".

Rather than checking to an arbitrary number of decimals, perhaps it would be better to check to a number of significant digits.

This could handle both very large numbers as well as very small numbers.

Example (checking for 6 sig figs rather than 6 decimals):

2244660000000 = 2244660000012 would be true

0.00000000000246123342 = 0.00000000000246123819 would also be true

In these cases, you are assuming you are looking at a very small % difference, which you would assume to be negligible

[Darin.K]

---

@DFGray wrote:

It's amazing how your sins return to haunt you.  I "fixed" the Check for Equality.vi for LabVIEW 6i almost eleven years ago. 

I would encourage you to post an "almost equal" function idea on the idea exchange.  LabVIEW does need it.

---

Idea posted here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Almost-Equal-quot-functions-for-Float-comparisons...

Warts and all, Check for Equality is a vast improvement over Equals.  I would not have known or really cared about returning 10 digits for the match if you hadn't mentioned it.  Fixing 6 digits was a bit of a pain, but 1 ppm is probably good for 99+% of all comparisons.  But let's hope it is deprecated in the next 11 years....

[altenbach]

I really think the algorithm should be based on bit differences near LSB when cast as integers as in my posts above. Of course ot would need to be "polymorphisized" for SGL, EXT, etc.

I agree it would be best to incorporate it into the plain equal in order not to clutter the palette. It should get substituted whenever at least one input is floating point.

Of course there are other functions that would equally benefit from a "floating point aware" treatment, for example the boundaries for "in range and coerce" (if we "include" the boundary the result is random because we could be a hair above or below the wired value). Another candidate is "search array". There are probably others.

Maybe these functions should also automatically get a small glyph when used with DBLs (e.g. a small red exclamation mark).

[kgolden]

Forgive this being off topic but how do I post code screenshots similar to Lucither and Daren's above?

[Cory_K]

Those are "code snippets".

They are created using LabVIEW 2009 or later.

It creates a PNG image of your code, which can be dragged and dropped onto a block diagram.

This drag 'n drop feature will only work on LabVIEW 2009 or later as well.