Show by example...

[X.]

Where can you find this brilliant piece of optimized code:

[altenbach]

Is this from a toolkit or shipping example? Most coordinate transform tools of plain LabVIEW are DLL'ified. 🙂

And yes, the code seems quite redundant, but I would guess it makes no difference once it is compiled (e.g. common subexpression elimination). So where did you find it?

I guess another definition of madness is taking the sine of the same number twice in the hope of getting the same results.

I also thought that the sine&cosine function did not exist in early LabVIEW, but maybe I am wrong.

[X.]

what about multiplying the sine by the same value?

It comes from one of the 3D Graphs object accessory VIs. And it is within a nested pair of loops. I hope the compiler is indeed clever enough to optimize this. Still, this is poor G code coming from NI...

[altenbach]

Thanks. I guessed one of the 3D graphs, but it was too hard to dig there. 😉

Error handling seems also a bit odd, creating a unusually named boolean instead of an error code. Besides, the output of the numeric would simply be NaN which almost seem sufficient, even without the boolean.

It is not clear why it does not simply use the existing geometry tools, but I think they are newer than the 3D graphs (?).

Personally, I would probably use complex math for all this. 😄

[X.]

[altenbach]

Here's the code rewritten using removing the duplicate computations (top).

As well as an alternative using complex math (bottom). I prefer complex. 😄

 

(note fully tested, of course. Maybe there are bugs :D)

[Hooovahh]

I'm terrible at coming up with the complex solutions to these math problems.  But I love using them when their performance is significantly better than the alternatives.  In this case we aren't trying to come up with the solution that is the most readable, we are trying to come up with the best solution for an API call, which could be seen as a black box, assuming sufficient documentation tells the user how to use the function.

[X.]

The aggravating  point is that since this calculation is done within a nested loop pair, there is unnecessary repetition of the same calculations over and over and over again.

In other words, as you scan the phi array, the value of theta provided to the subVI is unchanged. Yet, in this approach using a subVI, its sine and cosine are computed for each phi value.

So it is not only absurdly inefficient implementation of math, it is also inefficient implementation of the calculations in a subVI...

[altenbach]

---

@X. wrote:

The aggravating  point is that since this calculation is done within a nested loop pair, there is unnecessary repetition of the same calculations over and over and over again..

---

Yes, it should be done in the calling VI, but that would hurt re-usability. Most likely it is used in several places.

At least this subVI is inlined...

Maybe a new subVI could include the external loop stack?

Sorry, my complex solution above was way too complicated. I have replaced the snippet.

I have not done any benchmarking.

(I also made a honorable mention in the Rube Goldberg thread :D)

[BowenM]

This discussion got me curious so I benchmarked it (5m times)

NI method: 0.0519 sec

removed duplicate calculations: 0.0146 sec

complex math: 0.0104 sec

NI method with formula node: 0.449 sec

... I didn't realize formula node was that slow.