Something strange about the"Search 1D Array" function,if there is some kind of bug of LabVIEW?

[James.M]

The Threshold 1D Array function solves the problem perfectly. You can convert to an I32 integer and it will round to the closest if there's not a match.

[Munna232]

---

@billko wrote:

---

@Munna232 wrote:
Try to use "Threshold 1D Array" If search element is not exists in array, it gives nearest fraction Index.

---

This isn't going to work if you have instances where the next element is less than the one before it.  I guess you could sort the elements is ascending order, though.

I think that comparing integers is the better way to go because it is scalable and you can exactly the same comparison that you wanted to do in the first place.

---

Hi @billko ,

Thanks for reply.

As per @daed post, data is already in ascending order so I thought we can use Threshold 1D Array approach.

[James.M]

If you want to make sure the search came up with an approximate exact match, you can do something like this:

I expanded the indicators to show the rounding offsets. That's what you're dealing with when you work with DBLs building off of each other.

[JÞB]

AHA, I found a project I had put togeher a while back based on expansion of code found on the forums

I am showing this example for the documentation referances

the whole project with polymorpic vis for =, <= and >= (SGL, DBL and EXT instances) is attached

[billko]

---

@James.M wrote:

The Threshold 1D Array function solves the problem perfectly. You can convert to an I32 integer and it will round to the closest if there's not a match.

---

While I do agree that this does solve the perceived problem, the actual problem is that the OP did not understand the issues associated with floating point numbers; therefore, I believe the "brute force" method of comparing floating point numbers is more appropriate in this case, as the "brute force" method teaches the OP how to handle floating point comparisons in general.

Wow, how's THAT for a run-on sentence???

[billko]

---

@JÞB wrote:

AHA, I found a project I had put togeher a while back based on expansion of code found on the forums

I am showing this example for the documentation referances

the whole project with polymorpic vis for =, <= and >= (SGL, DBL and EXT instances) is attached

---

Wow!  That's ummmm... pretty involved.  It's more like a debate on what "equal" really means, not a straight "yes" or "no" answer.  😉

[OEM_Dev]

---

@JÞB wrote:

AHA, I found a project I had put togeher a while back based on expansion of code found on the forums

I am showing this example for the documentation referances

the whole project with polymorpic vis for =, <= and >= (SGL, DBL and EXT instances) is attached

---

Related to this, whats the benefit of this approach? When comparing floating point numbers for equality I've been using the following, is this incorrect?

[altenbach]

---

OEM_Dev wrote:

---

Related to this, whats the benefit of this approach? When comparing floating point numbers for equality I've been using the following, is this incorrect?

---

Yes. For example of you would compare 1e-30 and 1e-40, your code would say they are equal, even if they are 10 orders of magnitude different. 😄

[OEM_Dev]

I suppose that's what I get for trusting inherited code, not that I frequently check floating point numbers for equality. I did find a rather interesting article that seems to explain why someone before me did it that way and why I should not continue to follow it

http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

[hmarcano]

Hello OEM_Dev

You might want to try something like this. Just enter the precision desired!