10-08-2008 12:41 AM - edited 10-08-2008 12:45 AM
Formatting a number as 12 bit binary with leading zeros needs:
Needs to be seen to be appreciated:
The last state is classic Rube!

10-08-2008 01:08 AM - edited 10-08-2008 01:11 AM
I like this little bit of code from Christian's example above.
Let's split the wire to the case selector and a tunnel. Compare with 3 and send the result to the "3" boolean (unlabeled, of course), but since it is in the 3 case, if this calculates it is always true!

It also shows what Christian talked about as a way to avoid using those nasty autoindexing tunnels.![]()
10-08-2008 05:23 AM
Ravens Fan wrote:...
Let's split the wire to the case selector and a tunnel. Compare with 3 and send the result to the "3" boolean (unlabeled, of course), but since it is in the 3 case, if this calculates it is always true!
I think the result is not always true. If your double value is 3.1, the case 3 will be called, but the comparison in the case will be false! In my opinion checking a double value for equality is a bit risky and I always try to avoid it.
Uli
10-08-2008 05:42 AM - edited 10-08-2008 05:44 AM
Some Rube Code from me.
In an old VI we use, I found the following code which simply calculates the mean of the elements. 
Every Express-VI "Formelxx" calculates (x1+x2+x3)/3, except "Formel41" which calculates (x1+x2+x3+x4+x5+x6+x7+x8)/8.
Uli

10-08-2008 08:39 AM - edited 10-08-2008 08:40 AM
UliB wrote:I think the result is not always true. If your double value is 3.1, the case 3 will be called, but the comparison in the case will be false! In my opinion checking a double value for equality is a bit risky and I always try to avoid it.
Good catch.  
  Yes, you are correct in that the double gets rounded to an integer before the case structure makes the comparison, thus case 3 may not actually be a 3 and the comparison would be false.
Actually in this case, the way the rest of the code was created, there was no possibility for a 3.1 as the possible numbers to be used were predefined in an array and by the index numbers of that array. But that code still has the possibility of equality errors when comparing doubles, and that the double representation should not have been used considering the topic was using 12 bit integers.
PS: Thanks for sharing your impressive code as well.
10-09-2008 02:46 PM - edited 10-09-2008 02:47 PM
I work with good people, so I don't often find Rube's code here. But I recently found this instance of converting a number to an array of 0s and 1s.

10-09-2008 03:00 PM - edited 10-09-2008 03:03 PM
tbob wrote:
For added effect, the coercion dot simulates the saying: "...and with a cherry on top" 😄
By the way, your alternative is not quite equivalent, because you start out with 16 bits, but the loop only runs 8 times. It might need a tweak. 😉
10-13-2008 03:13 PM - edited 10-13-2008 03:14 PM
Another example of the "explicit indexing" and "backwards wires" fan club.
The big problem started when he wanted to deal with 100 elements. 😄
(Of course you guessed that this code is supposed to be used for frequency (or period) measurements!!! :o!)
10-13-2008 04:18 PM - edited 10-13-2008 04:19 PM
Forgot to post about this one, where some array gymnastics are done. In order to read a file which consists of 2 columns of data into an XY graph we have to do all of this:
instead of just this:
from here: http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=361078#M361078
10-17-2008 12:29 PM
Can't show the code for this one... It's WAY to wide...
http://forums.ni.com/ni/attachments/ni/170/362300/1/controller_BP.png
From this thread:
http://forums.ni.com/ni/board/message?board.id=170&thread.id=362300
You have to see it...