Duplicate Values in Arrays not being Deleted

[AnthonyMN]

Hey everyone,

I'm working on writing a program that takes information from a main VI and grabs all the relevant values before the testing begins so that I can just pick out a value from an array rather than do separate calculations every time. I've attached the VI I'm working with here.

The problem is that in test mode == 1, the program is supposed to create all unique current values using the given step size and including the min and max. If CoC is checked yes, it's also supposed to include the multiples for the Code of Conduct (multipliers are set in the array). The next portion of the block is supposed to delete any duplicate values. I am running my test cases right now just to be sure it's building the arrays right, but it appears to be generating duplicate maximum values, despite having an assurance in the while loops to stop at the max values and the deletion of duplicate values afterwards.

I've attached the VI, and screenshots of both the inputs and block diagram to generate the double max error. Has anybody encountered this issue, or does anyone have any guidance?

Thank you,

Anthony

[Bob_Schor]

I suspect (but haven't tested this with your code) that the problem is a mis-understanding of the representation of non-integer numeric data (such as Dbl).  The Dbl representation is a 53-bit approximation of a (mathematically) real number that has an infinite decimal representation.  One consequence of this is that when you display a Dbl value, you almost never say "Show this to me with 20 significant digits so I can be sure I know (almost) exactly what it is" -- instead, you show "0.7, 0.8, 0.9, 1", and might represent the (different) numbers 0.99 and 1.01 as "1".

Try changing the precision by which you view your sorted list and see if that fixes things.

Bob Schor

[RavensFan]

It is helpful if you save values in your controls as default before saving and posting the VI so we can start running and testing your VI with typical data rather than guessing what should be in there.

Some things are very confusing.  What is the difference between "Max Load" and "Load Max"?

Wouldn't it be easier to use the Ramp function that is already built into LabVIEW?

I think the problem may be that you are continually adding values to each other and then stopping based on a comparison.  Well floating point numbers in a binary system can't always precisely match what you think the number would be.  You may be accumulating small errors that cause the loop to execute one extra time.

You'd be better off multiplying the loop iteration by the step and adding to the min value rather than using a running accumulator.  But by the time you do that, you would be doing what the Ramp function already does.

[GerdW]

Hi Anthony,

set the display formatting of your "currents out" array to "%.17f" and you will notice the underlying problem.

It's not a good idea to add up fractions using floating point numbers. It's really not a good idea!

(Please google for "floating point resolution", "floating point precision" and similar topics. You will even find threads here discussing this in detail.)

[crossrulz · Accepted solution]

Your problem is an issue with the accuracy of floating point numbers, a problem all computer languages have.  If you change your display to show 16 digits of precision, you will see that your calculated 1 is actually 0.9999999999999999.  If this is an issue for you, after you sort do a comparison with the value and the previous value.  If the difference is small enough, delete that element.

[AnthonyMN]

Thank you everyone for the help! Just as Bob suspected and everyone else confirmed, it had to do with a super small error in rounding, how "1" wasn't equal to 1. While I realize it's maybe not the correct way to fix it, I added a subtract 0.0001 (one order smaller than the smallest precision I need) to the lower end of the comparison in order to open up the constraints a little. Since the values can't be defined on the load past 10^-3, this allows the space needed to make the correct calculations for this test.

In answer to Ravens question about Max Load and Load Max, they're separate functions in the main VI, it just happened to be the easier way to keep track of them while trying to make the UI nice as well. I haven't used the ramp function before, but I'll be sure to look into it.

Thank you everyone!

[RavensFan]

Yes definitely look into Ramp function.

As for "load max" and "max load", I'm commenting on the from a user interface point of view.  Despite the words being reversed, they seem to indicate the same thing.  So if they are different functions, they should have names that help differentiate the functions.

[AnthonyMN]

They sort of indicate the same thing. They're similar values used in different control schemes housed on different tabs. The main state of my VI allows the user to change tabs according to which test type they'd like to run, and the load maxes are values used for the same type of function just in different test states. Is there a way to include multiple controls in the front panel mapped to the same value in different places? I've just been using separate controls for separate places.

[RavensFan]

Your attached VI didn't include a tab control.  Perhaps you just stripped down some of the other code and front panel.

If these are two different controls on different pages of a tab control, then the tab page itself is the differentiator, then there would be no confusion to a user of your full VI.

There is no really easy way to have multiple controls map to the same value.  There are things you could do with event structures and "hidden" controls or functional global variables.  But I wouldn't get into messing with them until you have a specific use case that might require them.

[AnthonyMN]

Yeah this was just a subVI. I use globals instead of the indicators in the application. Just like what you said, I've got the tabs tied to a "selector" control (the test mode in the main VI). There should be no confusion during use as the two will never be present at the same time, and they never interact with each other in the program. Thank you Ravens!