Rube Goldberg Code

[Ray.R]

---

@altenbach wrote:

Two Index arrays, two subtractions, two squaring, addition, square root, etc. to get a distance between two point in 2D. (seen here).

Complex math IS simpler! 😄

 

---

I vote for the above solution..  🙂

This thread is required reading for every new recruit at our company.  They are encouraged to post in this thread when they do their own RG code.  Heck, I've posted a few that code snippets being sure there was a better way to do it.  Often, there was.  Altenbach is absolutely amazing with his solutions.  I highly recommend his style and approach. 

[Neil@Home]

If I was doing a code review and somebody presented Altenbach's solution I would strongly encourage them to add some comments to that code to explain to mere mortals (you know, not everybody has done complex maths) what the clever piece of code does.

I still do not think the original code is a good example of RG code... it is a perfectly acceptable piece of code, if it was wrapped in a sub-VI and you looked at it you certainly would not fall off your chair laughing...

[Norbert_B]

No, the original code is RG as it duplicates code unnecessarily. tst posted the non-RG version which is recommended (given that the code is correct) if not going for complex math.

Norbert

PS: Nobody is laughing. That is not the purpose of the RG thread, as it was stated several times. Sure, some piece of code makes one giggle, but in most cases, the reason for the code is that the implementer simply "didn't know any better". Hence we try to fill that gap in this thread......

[JÞB]

I'll be totally honest.  Altenbach's post was at the bottom of the page when I brought the thread up this morning.  I INSTANTLY tagged the post so I could find that example again! 

Was a laughing at the originator of the code?  No, I learned some technique that I likely will use in a future solution I will deliver.  That's not the first time this thread has helped me do that.

[tst]

I don't think any of the methods is bad (other than the typecast, which I don't like for safety and clarity reasons), and that includes the original, which has a minimal amount of duplicated code, but I would document every single one with them, even with a simple comment like "calculate distance using Pythagorean theorm" or "calculate distance using the complex plane".

[Todd_Lesher]

---

Neil@Home wrote:

If I was doing a code review and somebody presented Altenbach's solution I would strongly encourage them to add some comments to that code to explain to mere mortals (you know, not everybody has done complex maths) what the clever piece of code does.

I still do not think the original code is a good example of RG code... it is a perfectly acceptable piece of code, if it was wrapped in a sub-VI and you looked at it you certainly would not fall off your chair laughing...

---

Mortality is relative. The RG thread teaches LV. For example, which of the following Index Array implementations is better, and why?:

Answer: it depends. But if I only knew one way to do it, I wouldn't have an option. So I don't care if code posted is _actually_ RG.

[Darin.K]

And keep in mind that tst's version and the OP's version are NOT functionally equivalent.  There are two very common mistakes which could be at play here:  it is very common to over-specify code, and also very common to replace code by incorrect or unchecked assumptions about the input.

Only the OP knows the real intentions, but it is important to consider that perhaps the OP really wanted only the first two elements, and also that perhaps the OP was being too-specific in the code.

And yes I have 99 uses for Type Cast but this ain't one.  (2D is way too restrictive, most of my Euclidean distances are in 100's of dimensions).

This is also why I have TD clusters to represent 2D and 3D points when I really want 2D or 3D points.  If a user is TypeCasting or squeezing or otherwise shoe-horning something into the input, inside my functions I at least have control over what makes it in.  This puts a finite bound on my input validation, often meaning I require no input validation.

[JÞB]

---

@tst wrote:

I don't think any of the methods is bad (other than the typecast, which I don't like for safety and clarity reasons), and that includes the original, which has a minimal amount of duplicated code, but I would document every single one with them, even with a simple comment like "calculate distance using Pythagorean theorm" or "calculate distance using the complex plane".

---

What Comment do you want?  The labels (and a  remembrance that Greek philosophers have historically run naked in the streets) really hit the mark here.  Perhaps some wire labels would be nice if this was inline with other code but, WHY? that would make a good candidate for an "inlinable reuse vi" [Given size limits on the arrays] .  Don't bother cluttering the BD with knowledge commonly taught in grade school.  If you really want too though... post some referances to basic math texts in the VI Documentation.

[Anthony_de_Vries]

Please correct me if i'm wrong, but I think that for the Labview interpreter, there's no difference between the right three Index Array implementations...

And if I understand de Labview compiler well, the first one would cause a copy of the array in old versions of Labview.  But I think the current compiler is smart enough to see that it doesn't need to do that. 

As for the distance code...  I think that readability is of paramount importance in code.  The type caste is very clever, but also difficult to understand. I would never use that, unless it would solve a time critical issue.

[JÞB]

---

@Anthony_de_Vries wrote:

As for the distance code...  I think that readability is of paramount importance in code.  The type caste is very clever, but also difficult to understand. I would never use that, unless it would solve a time critical issue.

---

Its not the type cast that is clever.  Its the detail about how absolute Values are calculated that is "Clever"  From the HELP FILE for Abs Val

Casting to Complex "Opens the door"   WE don't need to code the Pathagorean Theorm- Its already built into a primitive!

While the type cast may not be the ideal way to create a scalar CDB from an array of DBLs expanding it "To CDB" portion via decimate array and Re/Im to complex (Or whatever is convienient) would suit.