Specific units of IEC 60027-2 A.2 and ISO/IEC 80000

[Wolfram_Zahnow]

I would like to suggest a new feature concerning prefixes of numeric values like ist is done already when using the "SI notation" setting.

In the world of bits and bytes, prefixes like M(ega) and G(iga) does mean 1024² respective 1024³ bytes.

While in the rest of the world M(ega) and G(iga) does mean 1000² respective 1000³ lets say Hz.

I may refer to a Wikipedia article:

For the English people:    http://en.wikipedia.org/wiki/Binary_prefix

Here in German:              http://de.wikipedia.org/wiki/Bin%C3%A4rpr%C3%A4fix

I would see this in the formatting of numbers similar to the SI formatting. In my screen shot you can see how an implementation could look like:

This should work for string formatting, too.

---

Optional it could probably be implemented by introducing a UNIT "byte" or "bit" which could handle the differences. But you would have to thing about it.

---

Regards,

-WZ

[labview4steve]

I like this idea...

You could have a notation that takes a number and converts it into bits, bytes or even nibbles (or hexits (hexidecimal) - ie 4 bits or half a single byte))
this would logically go just under the current "decimal, Hexadecimal, Octal, Binary" perhaps?

you can have options with the current ones as well ie for hexidecimal you could express this in hexits or half bytes - as they are identical

and octals could be expressed in 3 bits etc

there are a HUGE amount of combinations you could have.

how about BCD as well and the option to swap from big endian to little endian... this could get confusing but is up the programmer what he is doing with the output.

[Wolfram_Zahnow]

Well, quite a few years passed since posting this.

Is there any hope for it to be implemented?

Regards,

Wolfram

[AristosQueue (NI)]

> Is there any hope for it to be implemented?

Very unlikely for LabVIEW. As for LabVIEW NXG, it currently has no unit support at all; the dev leads have not decided what they want to do about that. Units are rarely used in LabVIEW code, and there is some dispute about whether that's because no one needs them or because they aren't finished enough in LabVIEW to make them really usable. But regardless of why, because they are rarely used, they've not been a priority for LabVIEW NXG. I will let them know that you're interested.

[wiebe@CARYA]

I use units. It's actually more a misuse, but still. Not often, but when I do, it's a lot of work to work around.

Note that this idea is not about units, and units are not required. It's about how 1 Mi should be 1024*1024, while 1 M is 1000*1000.

[Wolfram_Zahnow]

I actually use units quite often.Especially when you read data from an API / device which gives you physical data like frequency, temperatures, angles etc..

In almost any following step you are to calculate with these data. Using units in LabVIEW gives you one additional layer (eg. you cannot add a temperature to a length) of code verification.

just that several functions cannot handle units. But still, the advantage of having units beats those inconviniences.

[wiebe@CARYA]

Loosing units also means another +1 for C++. IIRC, C++ has native units, although perhaps even more controversial as in LabVIEW. Not that we need to compare, of course. 

Again, as I see it, this idea is not about units.

EDIT: Can only find the proposal, but I think I first read it in the C++11 stdlib reference book (which is not available to me right now). So C++ actually added it, while LV is removing it?

[AristosQueue (NI)]

To be explicitly clear: LabVIEW NXG may do units at some point, but they have not been a priority as NXG tries to catch up with 30+ years of functionality. If you use units, I encourage you to use the Feedback link inside LabVIEW NXG to request the feature. (I did flag this conversation for the product leads, but every avenue exercised helps build the case for a feature.)

[wiebe@CARYA]

I (mis)use units to convert orders of magnitude. I get\set my values by reference (using the labels). Sometimes the user wants to see mm\mg\m*, and m\g\* are (previously) stored or vice versa. Setting the unit to m* (or k*) will do the trick very well. Units don't change the value that is stored, just the visualization to the user. The alternative is to 'encode' the offset\multiplier in the label, but that's a hassle. It's also not easy to change dynamically, while units are.

I'd actually prefer a offset\multiplier property for control\indicators. Just like the graph scales. That should be much easier to implement, and it would serve my needs. It will only work for linear conversions of course... At some point I might post it as an idea.