#2263 property(QDataSet,DEPEND_0) in scripts, dimension properties

[Jeremy Faden]

For a long time it's bothered me to explain things like "ds.property(QDataSet.DEPEND_0).property(QDataSet.CADENCE)" because it's not easily read, fails to check for null, and assumes a QDataSet return type. I think it makes scripts more difficult to read as well, and exposes a bit too much about QDataSets. It just occurred to me that a rule I could use for this is to only use property in scripts to get "dimension" properties like UNITS and LABEL.

All QDataSet semantics would be hidden with a set of routines which can have documentation attached to them, and one can clearly identify which routines they are comfortable with.

These might include:
xtags -- extract the rank 1 tags for a dataset.
ytags -- extract the rank 1 or rank 2 tags for a dataset.
ztags -- extract the rank 1 or rank 2 tags for a dataset.
unbundle -- function exists already, allows extraction by named and of high-rank bundled data.
unjoin -- like slice but maybe does additional verification.
tagsAsBins -- returns the extent of each bin, considering cadence, and BINS_1 property.
deltaPlus -- returns the standard error in the positive direction or zeros.
deltaMinus -- returns the standard error in the negative direction or zeros.

So instead of

print z.property(QDataSet.DEPEND_0).property(QDataSet.CADENCE)

the scientist would use

print xtags(z).property(QDataSet.CADENCE)

[K Paulson]

I like this idea, it would definitely make things clearer to read and easier to type out quick scripts without having to bounce around on the shift key. Would this then work as :

epoch = timeGen
xtags(z).putProperty(epoch)

or is it preferred to write:

z = link(epoch,z)

I don't know a lot about the implications of syntax differences, but is there a reason to use
xtags(z)
instead of
z.xtags()

Does using z.xtags() imply running a function on z rather than pulling a property of z?

[Ivar Christopher]

I think I'm neutral on this, on balance. I like the idea of a well-documented way to access these commonly-used properties. But, on the other hand, I've spent several years training myself to think in the QDataSet world, so I'm relatively comfortable with, and almost competent at, using the existing accessors.

I think it's a good idea to have a simple (and again--well-documented) interface for these properties for science users to use. I'm just not sure how quickly I'd shift to using them.

[Jeremy Faden]

Kristoff, you are thinking about next steps beyond what I was thinking about. These probably wouldn't work, though. So I think you would still use the link command. But if the goal is to use commands which have documentation to build the abstrations, commands more specific than "link" would be a good idea. For example there are all the "dataset schemes" in http://www-pw.physics.uiowa.edu/~jbf/autoplot/doc/org/das2/qds/examples/Schemes.html. Maybe there could be corresponding functions which assemble datasets of any scheme. This would be like the "bundle" command, I guess, which knows how to assemble a bundle correctly so you don't have to.

[Jeremy Faden]

Ivar, I wouldn't remove anything and would just be adding helper functions that do verification, sort of like using

ds= putProperty( ds, QDataSet.UNITS, 'nT' )

instead of

ds.putProperty( QDataSet.UNITS, Units.nT )

[Jeremy Faden]

Another one would be getting the dimensions of something known to be a QUBE. For example:

img= getDataSet('https://www.edenbrothers.com/store/media/Seeds-Flowers/resized/SFFOR113-1_medium.jpg')
from org.das2.qds import DataSetUtil
dims= DataSetUtil.qubeDims(img)

simplifying code to be:

img= getDataSet('https://www.edenbrothers.com/store/media/Seeds-Flowers/resized/SFFOR113-1_medium.jpg')
dims= qubeDims(img)

(just avoiding the import).