LabVIEW
Find combination of values closest to a desired value
@Dom_N wrote:Input 16.3 into total mass, and 2 into number of holes to see an example of what I'm trying to explain.
Did you know that you can set default values for all controls?
After a quick look, your code is not safe due to glaring race conditions and blatant overuse of local variables. I'll have a closer look later once I am on a bigger screen. Lots of other very questionable code (based on logic, not messiness! ;))
Maybe you can explain in a few words what you are trying to do. Your VI is hard to decipher.
@Dom_N wrote:
Hope this makes the VI make more sense.
OK, so you have an array diagram constant with 37 DBLs (not sure why you have several copies of that same constant elsewhere, e.g. inside one if the inner loops for H=2 and H=4. There is also a copy in an array control! Seems redundant! One set should be sufficient.).
I guess these array values are the available "weights".
It seems we need to pick a subset of those (2, 4, 8, ?) so their sum matches a given input most closely.
Can each value be picked only once or are duplicates allowed?
Even if we select e.g. 8 holes, is it OK to use fewer if the target can be reached equally well?
This is a simple combinatorial problem that can be solved using general algorithms. No need to split the problem based on the number of holes. How fast does this have to be? (With larger input sizes, the problem will become quite expensive!)
Can you explain the two stacks of case structures on the right?
Thanks for the extra details. I'll have a look at it later.
Some quick comments:
@Dom_N wrote:The number of holes case structures tells it to multiple by 2 for 4 holes, and 4 for 8 holes so that all holes would actually be filled. This is because the balance mass system can either have 1,2,4, or 8 holes filled to keep everything as symmetric as possible. 1 hole can do 5g up to 9.99g, 2 holes can do 10g to 31.6g, 4 holes can do 31.61g to 63.2g, and 8 holes can do 63.21g to 120g. So if the number of holes equals 4 or 8 I divide the Total Mass by 2 or 4 so that 2 parts is all that can be used (For 4 holes there are 2 pairs of 2 parts for a total of 4 parts to fill the 4 holes and the same logic is used for 8 Holes.)
So why is the number of holes a control? Since these ranges don't overlap, the weight input uniquely defines the number of holes and should be the only user input. For any given weight, the number of holes is a given.
@Dom_N wrote:
You are right the array of 37 DBLs are the available weights and that the serval copies and a copy in an array control are redundant. Although I think the array control is necessary because other people may need to look at the program and I wanted to try and have it make more sense then just having array constant there. Also I would love to know how to get around the use of local variables.
You want the array as a control if the user is allowed to change the values at random. Since I think the values are fixed, a diagram constant is safer. If you want the user to see the actual values, you can connect an indicator to display the values. In any case, there should be only exactly one instance. What if you notice that one of the values is wrong? Currently you need to make identical changes in four different places and if you forget one by accident, you might get unexpected results that are difficult to debug.
@Dom_N wrote:
For the program this VI is apart of I definitely need to cut down on the use of local variables, but I just want to have a mess of wires running across the program because its harder for me and others to understand and follow the program.
You got that backwards! With local variables, you have no idea what happens and in what order. I.e. a big "mess"! LabVIEW is highly parallel and execution order is only defined by dataflow, not by e.g. horizontal position on the diagram. Have a look at your "2,4,8 Holes Second Array" indicator and the local variable. You cannot guarantees that the local variable only gets read once the indicator has received data. There is a good chance that the local gets read first, meaning it will have stale data from the previous run. Race condition!
When using a wire, you can be 100% sure where the data comes from and where it is going. (If you are using local variables, it might require lots of detective work to figure out what part of the diagram updated it last.) In this particular case, a wire can even eliminate the array indicator entirely, saving you a lot of memory. Much cleaner! No mess!
