NI Home > Community > NI Discussion Forums

BreakPoint

Reply
Active Participant X.
Active Participant
X.
Posts: 1,823

Re: Rube Goldberg Code

Sure... But to gently introduce a newby who may not have the FDS (needed for Riffle) and may have had good reasons to use DBL rather than I32 (why not U8?) to some basic LV concepts (while loop, search array, etc), I still think Ravens Fan and my suggestion may have been more didactic. It does not remove anything to the elegance of time stamp code. There is some risk of obfuscation by concision at some point though.

Active Participant
jcarmody
Posts: 1,925

Re: Rube Goldberg Code

[ Edited ]

X. wrote:

[...] may have been more didactic. It does not remove anything to the elegance of time stamp code. There is some risk of obfuscation by concision at some point though.


+1 for using three 50¢ words in one post.  (Although, obfuscation is common on these forums and, as such, should be discounted slightly.)

Jim

You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
Knight of NI
altenbach
Posts: 26,884
0 Kudos

Re: Rube Goldberg Code

I think it is if didactic importance to show that ...

 

  1. Once you have found one possible algorithm, try to think of at least two more alternative algorithms. They could be better.
  2. There is always more than one way to do things and some ways are prettier more efficient than others.
  3. It is important to think outside the box.
  4. The beginner always seems to pile on more code to fix things, while most VIs posted in the forum can actually be improved by removing stuff and simplifying.
  5. ...

LabVIEW Champion . Do more with less code and in less time .

Active Participant
SnowMule
Posts: 890
0 Kudos

Re: Rube Goldberg Code

Hardest part about LabVIEW, for me, is knowing what all the tools *do*.  Pull down the programming pallete and there's a lot of stuff there... knowing what all those tools do and understanding when to use them and when not to took me a few years to figure out.

 

I could post a lot of my older projects here, then solve my own rubes... comes with experience. 

(Learning how to use those "reference" thingys was a big step forward in cleaning code... :umph)

Active Participant X.
Active Participant
X.
Posts: 1,823

Re: Rube Goldberg Code

[ Edited ]

@Altenbach: My point was that it was a bit unfair to plaster our code as far from optimal when that was not the point of our contributions (if I can take the liberty to speak for Ravens Fan).

I know that is probably not your intention, but your style can sometimes be construed as a flabbergastering mix of horripilating paternalism and sophomoric geekerism... (insert whichever emoticon you wish here).

And yes, this could be expressed more shortly...

Member
Anthony_de_Vries
Posts: 187
0 Kudos

Re: Rube Goldberg Code

I think Altenbach's solution shows some very nice out-of-the-box thinking.   Not so much because he uses the add-on functionality, but because he approaches the problem from the other side.

 

In stead of first creating a random number, and then checking wether it's a duplicate, he first creates the non-duplicate numbers, and then randomizes them, and picks 6.  

 

Such different point of view can sometimes be very usefull when writing algorithm's.    I also think you should interprete his comments in that way, and not as bashing of the other solutions. 

 

You could easily program the riffle function yourself with standard array subvi's.   Make a for loop, in which you switch the values of two random index locations.   Ofcourse, then the orange wires reappear.    Could hide them by making the randomizer a sub vi's. ;-)

Knight of NI
altenbach
Posts: 26,884

Re: Rube Goldberg Code


X. wrote:

@Altenbach: My point was that it was a bit unfair to plaster our code as far from optimal when that was not the point of our contributions (if I can take the liberty to speak for Ravens Fan).


From a learning point of view, it is a nice collection of code that shows different approaches to the same problem. Like a stretching exercise, doing a side-by-side comparison frees up the mind and encourages to always search for alternatives.

 

I only called the original code a montrosity and I don't think I ridiculed your or Ravens solution. They both work and produce the correct result. I highly respect your coding skills.

 

I am sorry if it came across in any other way. :smileywink:


LabVIEW Champion . Do more with less code and in less time .

Active Participant X.
Active Participant
X.
Posts: 1,823

Re: Rube Goldberg Code

I have let a piece of code from the late 90's grow beyond fixability and keep posponing its translation into modern LV.

What encourages me to procrastinate is that despite being unwieldy (its diagram won't even fit into my 2M pixel screen) it still does the job and I can still write some quick additions whenever I need a new functionality.

For what it's worth, here is a snapshot of it (actually a scaled down image I got from the "Get Image Scaled" Method):

 

BD.png

 

It makes abundant use of global and local variables, is full of race conditions, wires zigzag all over the place, you name it.

BTW, there are about 50 cases in the main case structure and a dozen or so other case structures around it (and many more within), each one pretty much testing some UI change (there was no Event Structure at the time). I won't mention how many stacked sequences there is in it...

Knight of NI
Posts: 18,064
0 Kudos

Re: Rube Goldberg Code


X. wrote:

I have let a piece of code from the late 90's grow beyond fixability and keep posponing its translation into modern LV.

What encourages me to procrastinate is that despite being unwieldy (its diagram won't even fit into my 2M pixel screen) it still does the job and I can still write some quick additions whenever I need a new functionality.

For what it's worth, here is a snapshot of it (actually a scaled down image I got from the "Get Image Scaled" Method):


Reminds me of... http://en.wikipedia.org/wiki/File:Jenga.gif

Active Participant
James_W
Posts: 418
0 Kudos

Re: Rube Goldberg Code


X. wrote:

 

I have let a piece of code from the late 90's grow beyond fixability and keep posponing its translation into modern LV.

What encourages me to procrastinate is that despite being unwieldy (its diagram won't even fit into my 2M pixel screen) it still does the job and I can still write some quick additions whenever I need a new functionality.

For what it's worth, here is a snapshot of it (actually a scaled down image I got from the "Get Image Scaled" Method):

 

 

It makes abundant use of global and local variables, is full of race conditions, wires zigzag all over the place, you name it.

BTW, there are about 50 cases in the main case structure and a dozen or so other case structures around it (and many more within), each one pretty much testing some UI change (there was no Event Structure at the time). I won't mention how many stacked sequences there is in it...


What were people giving Kudos to here, the admission of a monstrosity, or the admission of fear/laziness when it comes to cutting the beast down to size and improving code quality/documentation?

 

James