VI of the Day (8/24/2009)

[Darin.K]

Today, a function that I find very useful: "In Range and Coerce"

This is invaluable for avoiding the inevitable floating point math errors.  Don't believe me, ask LV if 1.2 - 0.1 is equal to 1.1. (BTW this is not a bug, search the forum for interesting discussions of FP math)

To make comparisons I typically use this function with a "small" fudge factor, or arrange my math so I am comparing the absolute value of the result to "zero" (a small number considered to be zero).

Kudos to the tipster who points out what "small" means for the different representations (SGL,DBL,EXT).

[RavensFan]

It is also important to know what the diamonds on the inputs mean.  An empty diamond means the input is NOT included in the range while a filled diamond means it IS included in the range.  So 0-1 with both diamonds filled means a 0 and a 1 are in the range.  A 0-1 with empty diamonds means a 0 and a 1 are considered outside the range.

One thing I've never understood is why the default behavior when you drop this function is that the lower diamond is filled meaning the lower end of the range is included while the upper diamond is not filled meaning the upper limit of the range is not included in the range.

Anyone have a good explanation as to why that would be the default behavior?  I would think the more natural default would be to have both ends inclusive.

[dan_u]

---

Ravens Fan wrote:

One thing I've never understood is why the default behavior when you drop this function is that the lower diamond is filled meaning the lower end of the range is included while the upper diamond is not filled meaning the upper limit of the range is not included in the range.

Anyone have a good explanation as to why that would be the default behavior?  I would think the more natural default would be to have both ends inclusive.

---

I would prefer for the default to include both ends, too. My explanation for the default behavior: Imagine if you want to test for a value between 0 and 1, 1 and 2, 2 and 3, 3 and 4, ... then you need to treat one end as not included or a 3, for instance, will be in 2 ranges. 

Daniel

[Darin.K]

---

Ravens Fan wrote:

Anyone have a good explanation as to why that would be the default behavior?  I would think the more natural default would be to have both ends inclusive.

---

Just a guess on my part, but when I first saw one open and one filled it led me to guess (correctly) that those diamonds were actually functional.  I think if I had seen both filled or both empty I would have assumed it was part of the icon.  That is nice exactly once, after that I find myself clicking the upper diamond to make both limits inclusive almost every time I use this function.

Of course, I could have read the help and known that right away...

[Ben]

---

Darin.K wrote:

...

Kudos to the tipster who points out what "small" means for the different representations (SGL,DBL,EXT).

---

Nobody taking a crack at this bonus Q?

Hint see LabVIEW_Rounding tag cloud.

Ben

[DFGray]

A similar VI which does mostly the same thing is <vi.lib>\Waveform\WDTOps.llb\Check for Equality.vi.  It also handles infinities and NaNs.  Of course, you need to be willing to use unexposed VIs to use it .  Recommend you copy and modify as needed.  Bonus points if you can point out a glaring error in the implementation.

[Cory_K]

I love the in range and coerce function. It is a great way to remove outliers from data.

[Ben]

---

DFGray wrote:
A similar VI which does mostly the same thing is <vi.lib>\Waveform\WDTOps.llb\Check for Equality.vi.  It also handles infinities and NaNs.  Of course, you need to be willing to use unexposed VIs to use it .  Recommend you copy and modify as needed.  Bonus points if you can point out a glaring error in the implementation.

---

NaN is Not Equal to NaN ?

Ben

[DFGray]

Good guess, but no.  Technically, NaN is neither equal nor not equal to anything, including another NaN.  It is not a number, so you have no information about it.  Think precision...

[muks]

no ben