It appears that the x^2 node does not handle units correctly. If the input units are m for example, the output units should be m^2, but are actually m. This seems like a bug. Can someone confirm this?
The Square primitive (as other primitives) only operates on the number, not the unit. This isn't a bug, but just the way it works, and it makes sense since some operations don't translate for physical units. For example, let's say you use the Square Root. What's the proper unit for the square root of the unit "meter"?
@smercurio_fc wrote: The Square primitive (as other primitives) only operates on the number, not the unit. This isn't a bug, but just the way it works, and it makes sense since some operations don't translate for physical units. For example, let's say you use the Square Root. What's the proper unit for the square root of the unit "meter"?
The proper unit would be sqrt(m). I am in agreement with the poster. If NI allows a transaction on a unit, it should modify the units properly. If it can't then it should not allow values with units to be input into the function. There are several primitives and functions which restrict access. If the multiplying two numbers with units m results in m^2, then the x^2 primitive should too.
If I am doing calculations, I should expect the units to be handled correctly if LabVIEW's primitives and functions allow me to use them with units.
Message Edited by Matthew Kelton on 12-19-200704:06 PM
My question regarding the square root was more rhetorical. I know that it woult technically be sqrt(m), but I don't quite know what that means physically. Looks like you're indeed right about the "Square" function, and I spoke too soon. The "Square Root", by the way, behaves the same way. As well as the "Scale by Power of 2". Probably a few more in there.
Before categorically calling it a bug, however, it seems that there may have been an underlying reason for this given that several primitives exhibit this behavior. Perhaps someone at NI can shed some light?
I'm surprised this post was missed by us until now! My apologies.
This behavior is in fact a bug and is being addressed by R&D through Corrective Action Requests #44236 and #47360.
The current work around for the square primitive would be to use a multiply primitive. Using the sqrt primitive would use a little more creative programming to get around at this point. I tried using a property node to just change the units once the calculation had been performed but it throws an error. My best idea at this point would be to perform the sqrt operation and then multiply by 1 afterwards (using this moment to introduce the needed units to produce the correct end result).
I'll keep an eye on this thread in case anybody has additional questions,
David_B Applications Engineer National Instruments
We don't release the status of CARs until we have finallized the release of products. At that time we will include in the README what CARs have been resolved in that release. As of 8.6.1 these CARs have not been fixed.
As of 2009 SP1 this is still not addressed, however the "Square Root" function has gained the ability to correctly compute the units as the square root of the input units. This may have been gained in 2009 itself, I didn't check that.
interesting that the sqrt function does work, although if you try:
"united array-->square function-->sqrt function"
You get a broken wire between the square function and the sqrt function. If you use the work around (wire the array into both sides of the multiply primitive) then the sqrt function works fine.
