BreakPoint
Rube Goldberg Code
nrp@PGS wrote:Setting this aside for now, I still don't really think that picking on the original solution and posting it in a forum for Rube Goldbery code, and then proposing a very esoteric reply claiming it is a much better solution is really a great idea.
I did not mean to offend anybody though, so if I offended Altenbach I apologise.
Nobody can offend me, I am too old for that. 😄
This thread is not meant to "pick" on solutions and nobody qualified one solution as "much better" than the other one in this particular case. (Yes, this thread also contains ridiculously compilicated stuff, but that's more for entertainment). The difference was "hard way" vs "easy way".
This thread is meant to showcase alternative solutions to the same problems (sometimes similar, sometimes a little better, sometimes a lot better) to widen the knowledge of programmers everywhere.
Many programmers in the past considered it a honor to be mentioned here. I would! 😄 Nobody questions Pythagoras and everybody knows his theorem, so the original solution was valid. I have not tested if the complex version is numerically better (temporarily squaring doubles sometimes can lead to a loss in precision), but they are probably similar.
Complex datatypes are way underused and I am trying to change that with babysteps. 😄 The absolute value of a complex vector IS the distance. Another example is a 2D scaling and rotation. You can do a lot of trigonometry (sines, cosines, etc), or you could simply multiply with a complex vector. These things are only esotheric (by definition) if nobody ever post about these tools in the forum. 😄
Is it a good idea for any LabVIEW programmer to add complex numbers to the toolbelt. The LabVIEW palettes are full of usefull little things like that!
Ignoring any efficiency consideration (and the type cast, which I don't like), I think the original code would be easier for most people to understand and it could also be simplified:
I didn't verify the functionality.
@tst wrote:
Ignoring any efficiency consideration (and the type cast, which I don't like), I think the original code would be easier for most people to understand and it could also be simplified:
I didn't verify the functionality.
The nice thing with this solution is that is also works in 3D and higher.
I actually love the typecast in my solution, but some might find ot too esoteric. 😄
Very long ago I did extensive benchmarking and the absolute complex value was clearly superior. Still, this is not releveant unless we need to do it millions of times on huge datasets.
Neil@Home wrote:
I agree it is great to point out nifty things, but this is the RG thread right?
Well, this thread was created for exactly these kinds of discussions. It has no negative connotations.
If we had five different threads showcasing different degrees of RG'ness (0-20%, 20-40%, etc.) we would be forced to do an almost impossible classification attempt before even posting, and we would get even more discussions on what the right place would have been.
Rube Goldberg is a well respected cartoonist and I don't think he ever intended to criticise real engineers.
