Numpy...should it actually be a requirement?

[scasagrande]

So while I was working away at Python 3 support, I started thinking about numpy and how it is currently a dependency. I'm not sure if having it as a strict dependency is providing any benefit.

Pros to keeping:

• Waveforms from oscilloscopes are given to the user as numpy arrays, immediately making them ready for analysis
• Same for most other binary data (see Agilent34410a.r)
• Handy assert array equals helper method for unit tests
• Helpful for running example code

Cons to keeping:

• Largest dependency by far
• Requires python-dev (for python.h) to be installed for each version of Python that you want to build numpy for (this makes running a suite of unit tests a pain)
• If we migrate to tox for running tests (which is my plan right now), then numpy will have to be setup in each virtualenv.
• None of the actual features are being used, so it feels like dead weight that's just being carried around

Thoughts?

[CatherineH]

Is there a way to make numpy only a requirement for examples?

[scasagrande]

It could be listed under the extras_requires of setup.py, but I'm not sure if that field is really being used by the community any more. Redoing the setup.py file is near the top of my list so I'll find out then.

Its not like the examples aren't using other libs right now, numpy would just be another on that list. For example in https://github.com/Galvant/InstrumentKit/blob/dev/instruments/doc/examples/ex_qubitekkcc.py I see matplotlib and Tkinter

[scasagrande]

So I had a bit of a chat last night with @cgranade before I had to go to sleep about this. I forgot that quantities depends on numpy. We then briefly discussed switching from quantities to pint, which I think might be a good idea. I'll make another issue about that later, but the tldr of switching to pint is that they support temperature units conversion, they want to support log units (eg dBm), and do not depend on numpy. Based on the push-back we've gotten from the quantities devs (see python-quantities/python-quantities#58 for an example) over these issues that pint is trying to address it might be worth the effort to switch.

Anyways, assuming we weren't using quantities, should we drop numpy?

[CatherineH]

hmm, this is my first attempt to use pint:

import pint
quantities = pint.UnitRegistry()
room_temp = 22*quantities.degC
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/pint/unit.py", line 159, in mul
return self._REGISTRY.Quantity(1, self._units) * other
File "/usr/local/lib/python2.7/dist-packages/pint/quantity.py", line 727, in mul
return self._mul_div(other, operator.mul)
File "/usr/local/lib/python2.7/dist-packages/pint/quantity.py", line 682, in _mul_div
getattr(other, 'units', ''))
pint.errors.OffsetUnitCalculusError: Ambiguous operation with offset unit (degC).

[scasagrande]

Just gave it a go, you have to do this:

foo = 293 * quantities.Kelvin
foo = foo.to(quantities.degc)

On Mar 9, 2016 9:53 AM, "Catherine Holloway" notifications@github.com
wrote:

hmm, this is my first attempt to use pint:

import pint
quantities = pint.UnitRegistry()
room_temp = 22_quantities.degC
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/pint/unit.py", line 159, in
*mul_
return self.
_REGISTRY.Quantity(1, self.units) * other File
"/usr/local/lib/python2.7/dist-packages/pint/quantity.py", line 727, in
_mul
return self._mul_div(other, operator.mul)
File "/usr/local/lib/python2.7/dist-packages/pint/quantity.py", line 682,
in _mul_div
getattr(other, 'units', ''))
pint.errors.OffsetUnitCalculusError: Ambiguous operation with offset unit
(degC).

—
Reply to this email directly or view it on GitHub
#91 (comment)
.

[CatherineH]

Minor issue - it's lower-case kelvin, not Kelvin.

It seems like you need to first define things as kelvins, which is not intuitive. But maybe we could simply modify our util functions to handle the offset units.

[scasagrande]

Blame my phone keyboard for the case mismatch

Also checking in py34 real quick it seems you can straight assign to degC
and don't have to do this intermediate Kelvin assignment
On Mar 9, 2016 10:28 AM, "Catherine Holloway" notifications@github.com
wrote:

Minor issue - it's lower-case kelvin, not Kelvin.

It seems like you need to first define things as kelvins, which is not
intuitive.

—
Reply to this email directly or view it on GitHub
#91 (comment)
.

[scasagrande]

Never mind I was wrong. Both just seem to work if you go 1 * quantities.degC
On Mar 9, 2016 11:14 AM, "Steven Casagrande" scasagrande@galvant.ca wrote:

Blame my phone keyboard for the case mismatch

Also checking in py34 real quick it seems you can straight assign to degC
and don't have to do this intermediate Kelvin assignment
On Mar 9, 2016 10:28 AM, "Catherine Holloway" notifications@github.com
wrote:

Minor issue - it's lower-case kelvin, not Kelvin.

It seems like you need to first define things as kelvins, which is not
intuitive.

—
Reply to this email directly or view it on GitHub
#91 (comment)
.

[scasagrande]

With #92 done, I'm making good progress on this. Right now I'm making it an optional dep: if numpy is installed, then continue returning numpy.ndarrays. Otherwise, just return lists. The tests are being setup to (hopefully) validate both cases.

[trappitsch]

if numpy is installed, then continue returning numpy.ndarrays. Otherwise, just return lists.

I really like this idea since it would be nice for oscilloscopes especially to return data as numpy.ndarrays. The last big addition to the instrument test suite is the newportesp301 (see #246) that I'm working on right now (it's a beast), but there's no numpy dependency in there.

One issue to keep in mind is that many np.testing... are used in the test suite, especially to compare arrays, so those need to be setup accordingly as well.

[scasagrande]

All those np.testing... calls are being removed so no worries there. I'll end up adding another travis stage (and tox env) such that we test without numpy installed at all.