BreakPoint
Rube Goldberg Code
At first I thought you made that one yourself! Since i joked about transforming to strings when we talked the worst possible way to update a control about a week ago! 
Truth is stranger than fiction, indeed.
/Y
A new meaning for "Vestigial For Loop" was created here on an otherwise impressive-sounding test:
(For reference, a "Vestigial For Loop" may safely be removed by leveraging scalar/array polymorphism of the primitives inside the loop, resulting in no difference in the output of the code. However, an astute programmer will realize that performance varies between the two, and one method will provide better efficiency based on the size of the array. Laymen such as myself need not sweat such niggles, however: this only becomes relevant when squeezing out highest performance possible from a system with either limited RAM or CPU. Here's an example of a legitimate Vestigial For Loop:
)
@JackDunaway wrote:
(For reference, a "Vestigial For Loop" may safely be removed by leveraging scalar/array polymorphism of the primitives inside the loop, resulting in no difference in the output of the code.
... Not to be confused with vestigial while loops. 😄
Sometimes it is interesting to look inside vi.lib for some baffling rube goldberg code sighting.
Have a look at "Newton raphson Inner Part numeric derivate.vi" (called inside newton raphson zero finder (VI model))
or "Newton Raphson Inner Part.vi" ( called inside newton Raphson Zero finder (formula)).
(See code fragment in upper part of image)
You would think there should be an easier way to divide a value by two, one possible alternative is shown in the lower part of the image.
I can only imagine that this code is from the stone ages of early labview ... Is there any other explanation?
Yes, the two algorithms are not entirely equivalent: The only difference I can tell, is that the upper version is more limited, because it blows up for negative inputs, so it only works for about 50% of all numbers. However, the calling program already checks for positive conditions of "h", so we won't need to worry about that here.. 😉
I have been warning about the pitfalls of the NR method with numerically calculated derivatives for quite some time now. And that was before I realized they went and Rubed it as well. 
I tried to give the benefit of the doubt and see if that was some clever way of keeping precision, but it doesn't seem to be. Besides, division is not really a precision killer. I think someone was just a little goofy.
