Make units work all the way or skip them!

[Albert.Geven]

Hi

A recent discussion on the forum "why not everybody uses units" explains this much better than I can.

http://forums.ni.com/t5/LabVIEW/Why-do-very-few-programmers-use-LabVIEW-unit-labels/m-p/1802644#M621...

But for faster readers, several bugs hinder the universal use of units in LabVIEW.

It is a wonderful system but should be completed in a way (at least the square function should be using it) but all the other remarks found in that thread like the identical look of the expression node and the unit, not working formula nodes etc. should at least be taken seriously.

I lik the system but for now it is hindered by too many bugs.

[Ben]

The main issue (aside from the bugs) is arrays since I seldom acquire data from only one type of sensor so I need to be able to use MIXED units with arrrays*.

Ben

* I seldon know at development time the types of sensors and the appropriate units.

[Albert.Geven]

As for arrays only accept values of the same type, we need a new datatype: maybe call it UNITED...

[Ben]

"

As for arrays only accept values of the same type, we need a new datatype: maybe call it UNITED...

"

Or allow attributes to be unique within an array.

Ben

[drjdpowell]

"maybe call it UNITED..."

Or maybe "array of variants"?  "Array of (sensor) objects?"  

[Ben]

I would prefer a non-variant approach. It is hard as #$%^ to do anything with a variant that does not invoke a buffer allocation and my high-speed apps can not tolerate such.

ben

[drjdpowell]

I doubt one could create a "UNITED" datatype without some similar performance penalty.  There are always tradeoffs; in some cases the tradeoffs are unacceptable.  Personally, I use lots of objects and variants, but understand what I'm giving up.  I just thought it was funny you guys were discussing inventing a new datatype that's already been invented, twice.

[johnsold]

Ben,

For the mixed units situation I would consider creating a separate Units (strings or enums) array.  I suspect that you do relatively little calculating on the mixed arrays before separating the data into groups of identical or very similar units, so the extra bookkeeping prior to the separation should not be too much.  Of course it requires allocation of another buffer, but any of the other options likely would require as much memory and this way you have complete control.  With variant attributes or built-in units, who knows where the extra data is going?

Lynn

[rolfk]

I tink requiring units to be possibly different in arrays is an absolute sure killer for such a feature. Units are already very complicated to manage correctly as is for the LabVIEW developers and adding the request for arbitrary units in arrays simply makes it a to easy idea to dismiss altogether, since in fact there is no good solution for this. Aside from the problem of adding support for individual array element attributes, it also requires runtime error handling for mathematical unit operations or alternatively that one can't perform any mathematic operations on unit arrays. Units in LabVIEW are static, meaning they are known at the time of compilation so the LabVIEW compiler can do all the checking and flag errors. When array elements can have arbitrary units they are not known at compilation time and therefore a whole new runtime check system has to be introduced. Since mathematical nodes don't have error clusters this is more or less impossible. And NO, automatic runtime error dialogs is absolutely no option. They have no right to exist in a production type application!!

But fixing the known errors for units sure would be helpful in making them more useful. As they are now there are to many errors to use them. Because of that I found myself to many times converting between unit and non unit numbers throughout the code to consider them useful in any way.

I think I know why the developers didn't add support for units to the square function, but this is a solvable problem, although not trivial. But it is factors simpler than adding arbitrary array unit support, and IMHO ithis is really an impossible idea to solve right.

[Ben]

Rolf wrote;

---

I tink requiring units to be possibly different in arrays is an absolute sure killer for such a feature.

---

Good point Rolf.

I can withdraw my desire to use mixed units in an array but then their usefulness to me would also go away.

I am not trying to be difficult, just pragmatic.

Take care,

Ben

[Brian_Powell]

Once upon a time, I managed the team in LabVIEW R&D that owned units.  Like many of you, I believe they are a great feature with several shortcomings.

Among the features I would have liked to have seen...

* User-defined units -- let me define any unit I want (such as "cows"), and let me define my own derived units from it, if I want.

* Support for non-linear units -- I always thought that decibels would be a nice unit, but we can't support it with the current architecture.

* Support both static and dynamic units -- The current architecture requires units to be known at compile time.  Why not pull out the unit engine so that I could invoke it at runtime?  I think I would primarily use this for displaying values.