03-18-2012 06:24 PM
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.
03-19-2012 04:49 AM - edited 03-19-2012 04:49 AM
@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.)
03-19-2012 09:38 AM
I think it is if didactic importance to show that ...
03-19-2012 11:58 AM
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)
03-19-2012 12:00 PM - edited 03-19-2012 12:00 PM
@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...
03-19-2012 12:31 PM
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. 😉
03-19-2012 01:47 PM
@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. 😉
03-19-2012 07:49 PM
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...
03-20-2012 08:11 AM
@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
03-21-2012 08:48 AM
@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