LabPy / labpy-discussion

Ghost repo for discussion aboput the LabPy projects.
11 stars 0 forks source link

Unit support #8

Open MatthieuDartiailh opened 9 years ago

MatthieuDartiailh commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 6 years ago

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

MatthieuDartiailh commented 6 years ago

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