Indexing through a cluster of numeric data with different unit labels

[wiebe@CARYA]

---

@fb35 wrote:

That data should be read as a variant, with no a-priori on the number of data and units.

---

But you can read the values. And you should be able to do (correct) math with the values, because you should know the quantity when reading the quantity.

It's only when you serialize (store\load) (to text) that things go bad... And only if you want to store with the correct unit.

[fb35]

Actually, using OpenG tools, it is possible to recover both the value and the unit of a variant of type "double float with unit".

For recovering the value:

and to recover the unit :

The VarPQ block is to put back "classical" chains of units in standard units:

with the table:

so i have a tool like labview indicators to reconstruct the possible units.

Temperatures are always stored in K (or Cdeg), there is some trouble also for weights as the "k" prefix is already in the base unit. Some other conversions factors can be taken into account.

In the end I obtain:

which is what I wanted to achieve.

[fb35 · Accepted solution]

Here I join the actual version of the software.

I simulate acquisition with random numbers. These numbers are then read to get an ascii line for each acquisition.

There is some possibilty to escape the "base units", for example one can ask to get weigths in g, flows in l/s, etc. These possible transformations are hard coded in the "unit change.vi".

There are not timestamps on the in the data files right now.

[wiebe@CARYA]

---

@fb35 wrote:

Actually, using OpenG tools, it is possible to recover both the value and the unit of a variant of type "double float with unit".

---

It looks to me it takes the quantity, and normalizes it.

It won't detect prefixes, and probably won't distinguish between degK and degC. If you're using SI units, you only loose the prefix. If you have imperial units, you still get SI units.

I don't see why units would be in the data type. It doesn't really belong there, much like the radix isn't in an integer's data type.

In fact, I see that the data type is the same for a double with degC and degF.

The toolkit probably just translates the stored SI to human readable SI (e.g. s^-1 to Hz). Which it nice, but not the used unit in the control that isn't stored in the wire.

If it does what you want, that's great. If you are using SI you probably be OK (except the prefix). But I don't think you're getting the unit.