Gp/feat/aman arbitrary path

[iparask]

This PR updates AxisManager __getitem__ and __setitem__ based on the slack discussion.

__setitem__ raises an ValueError when the value is not another AxisManager and uses wrap to add it to the main object. I selected wrap because it seemed more complete compared to merge.

[mhasself]

Looks good -- a couple of requests though:

• get and __contains__ have not been changed. I think we should support the same treatment for keys provided there (but this is probably debatable).
• The tests don't test very much right now... please expand.
• Mention this behavior in the docs (see axisman.rst, add a few lines after paragraph of "Note the boresight entry is marked with")

Thanks!

[skhrg]

I think mattew covered everything I had in mind.

I think the answer to this is "not enough that we care" or "not enough to measure" but is there any noticeable slowdown from accessing children in this way?

Expanding the test case so show that the values that we get and set are correct I think is important.

[iparask]

• get and __contains__ have not been changed. I think we should support the same treatment for keys provided there (but this is probably debatable).

Get is a combination of __contains__ and __getitem__ the way it is implemented. It's behavior change is a side effect of the rest of the changes.

I think the answer to this is "not enough that we care" or "not enough to measure" but is there any noticeable slowdown from accessing children in this way?

Yes, this is measurable but how many levels down do you want to go?

[skhrg]

Yes, this is measurable but how many levels down do you want to go?

I think most people will never go beyond triple nested so if that slowdown is in the noise then I think we are good. If it somehow matters this seems like a case where we could cache the mapping from the full path to where they point to alleviate things (but I really dont think it will end up being an issue).

[mhasself]

• get and __contains__ have not been changed. I think we should support the same treatment for keys provided there (but this is probably debatable).

Get is a combination of __contains__ and __getitem__ the way it is implemented. It's behavior change is a side effect of the rest of the changes.

Having changed __getitem__, we need to think about whether to change .keys (no?) and __contains__ (yes?).

It is nice to be able to check if k in aman -- answering the question "will aman[k] raise a KeyError"?

[iparask]

It is nice to be able to check if k in aman -- answering the question "will aman[k] raise a KeyError"?

>>> from sotodlib import core
>>> import numpy as np
>>> dets = ["det0", "det1", "det2"]
>>> n, ofs = 1000, 0
>>> aman = core.AxisManager(
...     core.LabelAxis("dets", dets), core.OffsetAxis("samps", n, ofs)
... )
>>> child = core.AxisManager(
...     core.LabelAxis("dets", dets + ["det3"]),
...     core.OffsetAxis("samps", n, ofs - n // 2),
... )
>>> aman.wrap("child", child)
AxisManager(child*[dets,samps], dets:LabelAxis(3), samps:OffsetAxis(500))
>>> "child.samps" in aman
True
>>> "child.something" in aman
False
>>> 

Is this what you mean? It is in the commit that addresses the comments. I'm trying to get them all in a single push.

[mhasself]

Is this what you mean? It is in the commit that addresses the comments. I'm trying to get them all in a single push.

Yes, that's what I mean. Thanks.

[iparask]

I am not sure if the test makes sense in terms of operations. Let me know if I need to update it in a way that reflects the correct usage of the AxisManager class.

[mhasself]

Thanks.

I think what's missing in the test is just a simple data field, such as a shape=(samps,) array, in child or child2. Check that accessing, and setting, that field using 'child.child2.target' works properly.

[iparask]

I updated the tests and added a _fields tod to the test. I'm really confused as to why __setattr__ and __setitem__ have different functionalities. It seems like a bug.

I also timed them, using timeit and 1000 iterations and these are the results:

(simonsobs) iparask@simons1:~/git/sotodlib$ python tests/simple_example.py
Time to access aman['child.child2.tod'] from this branch: 0.0009413734078407288

(simonsobs) iparask@simons1:~/git/sotodlib$ python tests/simple_example.py
Time to access aman.child.child2.tod from sotodlib master branch: 0.0019882768392562866

I consider these to be the same time.

[skhrg]

Looks good to me, I like the test a lot.
I have one minor issue with the docs and one potential feature to add but overall I think this is good to go.

[iparask]

@mhasself can you take another look?

[mhasself]

Thanks -- a few more comments.

[mhasself]

Looks good, thanks for the iterations.

Obviously we need to get CI working again but otherwise this is good to go.

Remember to squash on merge.

[skhrg]

Looks great to me!