Unit support

[MatthieuDartiailh]

Should we have unit support ? And if so, what library do we use ? I am favor of supporting unit and of using pint (https://github.com/hgrecco/pint) to do so. @alexforencich suggested we use some kind of flag to avoid converting queried values to value with unit, I am not sure this is a real good idea but we should discuss it.

[hgrecco]

I think unit support is really useful and, of course, central to any measuring application.

Obviously, I am in favor of using Pint :-D

[alexforencich]

If we can make unit support really clean, then maybe. Right now it seems like a bunch of extra overhead and complexity and it doesn't seem very clean, especially in terms of stripping off the units to just get a plain floating point number. Otherwise I think there should be a way to turn it off and just work in base units.

[MatthieuDartiailh]

One things we can do is have a global switch whose state but be set before loading any driver to switch on or off unit support. I say we first focus on subsystem and the most basic Feature aspect (including the name) so that I start some clean code with tests and then we discuss in more details how to support units.

[arsenovic]

i think dealing with units further on down the road, is wise, but for the record, i like having the ability to use units, but with the default behavior being unitless.

in scikit-rf, i actually have a class dedicated to a frequency band , and the unit-handling is a major feature.

Would implementing units require all returned types to be Quantities ? because i can imagine a lot of cases, where this might present a hurdle for users.

[MatthieuDartiailh]

For most operations pint.Quantites are fairly well behaved so getting one from the return value of a Float feature should not be much of an issue. There is currently an issue opened on pint to allow using .m and .u to retrieve the magnitude and the unit of a Quantity which would seem a reasonable compromise to me.

[crazyfermions]

I think the question whether units should be included or not is the question about what is lantz going to be like. If the idea is to make lantz a complete measurement suite, it should be definitely in there at some point -- units are really important and hey, from my experience, pint works really well. If you want lantz to be a hands-on framework to build on top of which you would build your own measurement program, it may be worthwhile considering to drop unit support, but it only makes sense if it would reduce the overhead in performance and the complexity of the code significantly.

I have only worked a little bit with pint and I think the complexity of the code is not a big issue -- the magic is done behind the scenes and converting units or getting magnitudes and dimensions is really straightforward. I do not know so much about its performance, but I think the typical use case of lantz is that all the actions by the operating computer are fast compared to sending signals to and retrieving them from the device. For example, setting a dc voltage takes typically ~100 ms, while the computer takes maybe 1 ms or even less to compute everything necessary for this operation. I think the performance is not really an issue here. Can someone else comment on the performance aspect?

[MatthieuDartiailh]

I have actually done so work on Pint to improve the performance and I think we got pretty decent conversion time (<1 ms) when the conversion is already known (ie some cache exists) We could perhaps go even further but losing the pure python aspect. I would however point that some communications (simple ones can be much faster than 100 ms (rather in the 10 ms or so) in some cases. That's why we should be able to directly send raw float that the instrument assume to be in the right unit to avoid the overhead. Nice to see other people being interested @crazyfermions. Don't hesitate to comment on other aspects and if you want to get more involved let us know.

[hgrecco]

Just to get some context. In a TDS1002B connected through USB. Querying the *IDN? takes ~ 66 ms. Converting from meter to km takes ~ 100 us. Converting from meter to meter (i.e the user provides the right units takes ~ 10 us). So I think it is not a problem. The safety of using units is worth it and the complexity of the code is not a problem. Pint handles things for you.

[bilderbuchi]

Hasn't Lantz gained unit support in the meantime, i.e. can this issue be closed?

[MatthieuDartiailh]

Lantz (the original package) always has had unit support, this was merely a discussion about how to do it in the split version.