LabVIEW
Execution speed and efficiency of Square function
Solved!
Hi,
I noticed in many places (including LV built in VIs) that Square function in LabView is substituted with multiplication of the same variable twice. The question is - for double precision digits which is more efficient / fast calculation:
1. When using the Square function
2. When multiply the number by itself (multiplication)
Thanks.
If I recall correctly, it has nothing to do with efficiency; rather, there is a peculiar bug in the x^2 function where it doesn't handle numbers with units correctly.
@peter111 wrote:
I noticed in many places (including LV built in VIs) that Square function in LabView is substituted with multiplication of the same variable twice..
No need for conspiracy theories. If you see that a multiplication is used, it means that the code is relatively old and has not been changed (or is is newer code programmed by someone who learned programming before the square was available). Earlier versions of LabVIEW did not have the square function and nobody will go through old code just to update that. Don't touch it if it works correctly!
It is very likely that both versions result in identical binary code under the hood. Use the square function for easier diagram readability and fewer wires.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
Here's yet another option:
But that coerces to floating point (and also upconverts SGL to DBL).
The square function works for integers without coercions (of course you need to be aware of possible range overflow)
@altenbach wrote:
wiebe@CARYA wrote:
Here's yet another option:
But that coerces to floating point (and also upconverts SGL to DBL).
If you wire sgls, the output is sgl.
wiebe@CARYA wrote:
If you wire sgls, the output is sgl.
Sorry. Yes, you are right. I had the exponent still at DBL and got a coercion dot at the lower input, Did not investigate further.
The fun start if you go complex: The x^y function might give you some fuzzy digits. 😉
@altenbach wrote:
wiebe@CARYA wrote:
If you wire sgls, the output is sgl.
Sorry. Yes, you are right. I had the exponent still at DBL and got a coercion dot at the lower input, Did not investigate further.
Yes, I thought that was what happened.
The fun start if you go complex: The x^y function might give you some fuzzy digits. 😉
That's weird, last I checked both 2 and 0 can be represented exactly in binary.
Guess there's some magic going on to support the more generic X^Y case. Good to know, although I probably forgot it by the time I run into it (if ever).
@billko wrote:
If I recall correctly, it has nothing to do with efficiency; rather, there is a peculiar bug in the x^2 function where it doesn't handle numbers with units correctly.
It may not be the reason why it was done this way, but I was right. And it is a bug. I don't know if it's been resolved.
@billko wrote:
@billko wrote:
If I recall correctly, it has nothing to do with efficiency; rather, there is a peculiar bug in the x^2 function where it doesn't handle numbers with units correctly.
It may not be the reason why it was done this way, but I was right. And it is a bug. I don't know if it's been resolved.
It appears that they have fixed it:
