Problem with VI - unidentified cause - possible race condition.

[J.Mamakos]

Okay, I have two arrays.  (I shall use truncated examples to demonstrate my problem)

Array 1a:

 -80, -79, -78, -77, -76, -75, -74, -73, -72, -71, -70

Array 1b (possible modifications of Array 1a):

Version 1:     -83, -82, -81, -80, -79, -78, -77, -76, -75, -74, -73, -72, -71, -70  (extended downwards)

Version 2:     -80, -79, -78, -77, -76, -75, -74, -73, -72, -71, -70, -69, -68  (extended upwards)

Version 3:     -82, -81, -80, -79, -78, -77, -76, -75, -74, -73, -72, -71, -70, -69, -68, -67  (extended in both directions)

Version 4:     -78, -77, -76, -75, -74, -73, -72, -71, -70  (truncated at bottom)

......

Version 7:     -77, -76, -75, -74, -73, -72, -71, -70, -69, -68  (truncated at bottom, and extended upwards)

......

etc.

Array 2:

2.0, 2.0, 2.0, 2.0, 2.0, 2.5, 2.5, 2.5, 2.5, 1.5, 1.5

 Arrays 1a and 2 have the same number of elements.  The elements in Array 1a (and Array 1b) range between -85 and +10 (approximately) and count up in a defined step (can vary for each instance, but not within the array itself).  The elements in Array 2 range between +/- 4 (ish), but are only ever all positive or all negative.  The different versions of Array 1b demonstrate the different ways in which Array 1a can be modified.  The elements of Array 2 are 'associated' (on a graph elsewhere - essentially x and y values) with those in Array 1a.

I want to be able to work out how much (if anything) Array 1 has been extended or truncated at either end, and perform the same action to Array 2 by copying (or deleting) its first or last element(s) by however much is needed to replicate the size and position of the points in the modified Array 1.

Please let me know if anything is not completely clear, and i will try to explain it differently.

Thank you in advance for any help you can give.

James

[smercurio_fc]

Oh, I finally understood what you were asking for. I was just giving you a hint.

The mechanism for doing what you want isn't complicated, but it is cumbersome. I've written a VI to do it, but I don't have LabVIEW 6, which is what you're using. I have 8.2. I don't have my virtual machines running right now so I can't backsave, and even if I did, the farthest back that I could go would be 7. I'm attaching it in case someone else can back-save it. A bit of the code is repetitive and can probably be streamlined, but hey, it's free. 

[J.Mamakos]

Thank you.  I tried to think of a way to do it, but my code just kept getting bigger and bigger and bigger without seeming to get any closer to my aim!  Now to just wait for someone to come along who can convert it down for me... 

[J.Mamakos]

I'm okay for now - I sent the VI to a colleague using LabVIEW 8.5 and they printed it off for me so I can replicate it all.  They're not usually that generous!

By the way, what do you mean by "All uses of Equal? function should be replaced by a VI that performs the correct operation for floating point values"?  I know what you're talking about, but don't they perform the correct operation already?

[johnsold]

The equality primitive may not give the answers you expect because of the finite representation of floating point numbers in the computer. Two numbers which look equal on a 3-digit display might be different in the 15th or 16th digit in the internal representation and, therefore, not equal.  Comparison of two floating point values should always include some tolerance to account for these tiny differences.  

Several ways of doing this have been discussed on the Forum over the years.

Lynn 

[J.Mamakos]

smercurio_fc, just a minor question about the VI...

There is a wire going from before the first 'array max & min' to the first case statement.  It has nothing on the end of it - is it just left over from a previous modification or is it actually doing something and I just can't see it?  It's not transferring data, and it doesn't force an order of operation either...?! This is probably me just being overly picky, but I wanted to be sure. 🙂

[smercurio_fc]

Leftover wire.

Side-note: You will also notice that some of the array functions do not have a constant wired to them. That is because in LabVIEW 8.x some inputs have default values. For example, for Index Array, the default value for the first index is zero, so one does not need to wire a constant of zero to the first index input. 

[J.Mamakos]

When writing it out in 6.1 I didn't connect the indexes either.  Despite them being 'required' my VI didn't grumble, and everything seems to be working all right.  Can I leave the indexes unwired, or is this a problem just waiting to jump out at me?  In the help, I can't find any mention of default values, but I'm wondering if it does it anyway...?

[smercurio_fc]

Can't really answer that question since I don't remember. I know that in earlier version is was an absolute requirement that you had to have it wired. Somewhere along the line the functions got changed so it wasn't necessary if you wanted to pull off starting at the first index. I have no recollection as to when that happened.

[J.Mamakos]

---

johnsold wrote:

The equality primitive may not give the answers you expect because of the finite representation of floating point numbers in the computer. Two numbers which look equal on a 3-digit display might be different in the 15th or 16th digit in the internal representation and, therefore, not equal.  Comparison of two floating point values should always include some tolerance to account for these tiny differences.  

Several ways of doing this have been discussed on the Forum over the years.

Lynn 

---

Would a way round this be to divide one number by the other, and then see if both the quotient and remainder are equal to zero?  ...or does this function have the same 'problem'?