Leaderboard

Please see the above link to download the videos The NIWeek 2016 Videos are uploaded to the ftp server. Please see this link for information on downloading the videos. https://lavag.org/topic/19154-ni-week-2015-videos/#comment-115444

That's the way I've been thinking about it for now. Since the goal is to select the right subdiagram at type prop time it should work fine. The compiler should eliminate the dead code so there would be no performance penalty. For the future I'm considering a more general solution. When you wire something to the To Variant primitive the output is very close to a type type. If the data portion of the variant were eliminated it could work exactly like a type type. It would be a compile time constant so any computations with it could be constant folded away. The only other puzzle piece that would be needed would be a pseudo-primitive (TypeErr) whose only purpose would be to generate a typeprop-time error if its boolean-constant-valued input were true. The technique for making a subdiagram specific to certain types would be to connect the input to the To Variant* producing a type type constant. Check this against the valid types and generate a type prop error if it doesn't match. All the type checking code should get constant folded away so performance would not be affected.

To further pique your interest in macros, there is a new one in LabVIEW 2016 / User Libraries / macros called Norm.vim. It is not meant to be rigorous from a mathematical perspective (it's just my best guess) but rather to illustrate a new (experimental) structure, a variant of the Diagram Disable Structure, called a Type Enabled Structure. It has some interesting properties when used within a macro. Here is how it works. When an instance of the macro is inlined and types are propagated to the inputs, each subdiagram attempts to propagate types; the first subdiagram (in subdiagram order) which successfully propagates types without any errors is enabled and all the others are disabled; the enabled subdiagram is the one which is compiled for this instance of the macro. The new structure is not in any palette yet, nor is there any documentation. It isn't quite ready for prime-time, but you can copy it from Norm.vim and experiment with it and give us feedback.

So I embarked on a little journey this morning. Many times when developing code I have the need to search an array of string for some pattern. Usually I am looking for some set of characters in a string and then I need to get the whole string, and possibly the index that the string was found in the array. There are many different ways to do what I just mentioned, some more obvious then others, and I wanted to know which was the methods that should not be used for larger arrays, and which method appears to be the best, on a Windows machine with time to process being the only thing to judge on. So attached you'll find a VI (saved in 2011) which generates an array of strings. Each string will be between 5 and 15 characters long and the array size is controllable from the front panel. For approximately half the elements in the array, a string will be appended to the front of the generated string. These are the values we will search for. We then search the array looking for the indexes that contain the string we are looking for. In this example the string is appended to the front, but I would like to make this generic and I am assuming the string we are looking for could be any where in the string not just the beginning. I use 6 different methods for finding the indexes and calculate the time it took to find them. I noticed for arrays of 1000 elements or less it doesn't matter too much. Each of the 6 methods take 0 or 1 milliseconds to complete. For 10,000, or 100,000 the winner is Method 2, which uses the Search/Split String, combined with the OpenG Conditional Auto-Indexing Tunnel. I know this is such a simple task, and for most cases it doesn't matter, but I was wondering what others have found. Is there a method that is generally preferred more? My thoughts would be that Method 1 would have been the fastest, since we only have to iterate over the items once, instead of an OpenG method, but I do realize the Build Array is an operation which can be bad for memory. Search Array Of Strings.vi