When I learned to round numbers, I learned that if the value is exactly between two integers, you always round up. LabVIEW, however, implements the IEEE754 standard for its math operations, and the default for that is the method known as "Banker's rounding", which rounds the value to the nearest EVEN integer:
If you want to implement the round-up method, the code is fairly simple - just do Round to -INF (X+0.5). Note that this also rounds up for negative numbers, so -3.5 will be rounded to -3.
This piece of code checks whether the click was inside the green rectangle:
Looks nice and simple, doesn't it? If the click is between 20 and 100 X and 30 and 50 Y, you're inside the rectangle. Great.
The only problem is that it's wrong. Clicking under the rectangle returns T, even though we're not in the rectangle.
You see, the In Range & Coerce primitive is set to the Compare Aggregates mode, because I figured that just means that LabVIEW takes the results of all the comparisons in the clusters and ANDs them, providing a nice, clean way of easily comparing an entire array or cluster. Turns out I was wrong. That's not what Compare Aggregates does.
What it actually does is to compare the elements in order, similar to what happens in a dictionary or a phone book. When we do an equality comparison, this is actually the same as ANDing the results, but if we do a greater-than or other inequality comparisons, it isn't.
As an example, consider the following - in a phone book, is "Smith, John" greater than "Smith, Jane"?
The answer is determined by comparing characters until we find the first character which doesn't match. In this case that would be "a" and "o". Since "o" is greater, John is greater than Jane. If John was called Doe instead of Smith, he would not have been greater than Jane, because "D" is not greater than "S".
Looking at it like this, this piece of code is similar to asking whether BR is greater than AZ. Since B is greater than A, we don't even need to check the second letter. Likewise, in the example above, clicking below the rectangle returns T, because the value is between 20 and 100 X.
The compare aggregates mode is naturally tied to the method LV uses to sort arrays of clusters (both are based on the implementation of the comparison operators). That In Range function will simply check that the three clusters are "sorted". Someday I may find a use for that, have not so far.
Change to Compare Elements, slap on a Cluster to Array and And Array elements and you have a nicer implementation of Point in Rect than the one in vi.lib.
Yes, I got bit on this yesterday parseing a file.
Quote= 0x22 ", Open Quote= 0x93 “ Close Quote = 0x94 ” if the file is generated by an editor that knows to open and close quotes.
String indicator displays, at a normal font size, make it pretty hard to distinguish. (“"”)
For Steve from here Getting those screenshot with RCMs and Floaters for anyone else that missed
Alt+PntScrn Kills Floaters and RCMs (I did not know that! )
Ctrl+Alt+PntScrn gets the active window with all RCMs and Floaters showing
Newer LabVIEW version have a great feature: You can right-click on graphs and export to excel (or text, or clipboard) and excel will open with a nice spreadsheet containing all data nicely arranged in columns and labeled.
Here's is the thing that just bit me:
I recently "upgraded" a 12 year old little quick&dirty simulation program because somebody wanted to make some simulations for a presentation. There was no save feature for certain traces shown on the graph, just for the main trace. Of course I get a call in the middle of the night asking how to save the data shown in the other traces.
Me: just right-click the graph and export to excel. (after all, it is now in LV 2010!)
Him (after some wait): Hey, does not work, all the y columns are zero! 😮
Apparently, the numbers are formatted according the the formatting of the respective axis (?). The Y-axis in question was formatted with no decimal places (Who cares, since the axis is not shown anyway, and has "loose fit" disabled, right). The data was <1E-5 and thus truncated to zero during the export. Changing the display format for the hidden y-axis fixed the problem. 🙂