So with @weefuzzy’s great abstraction for managing fluid.dataset~-level chunks of data, I had commented that it’s still a bit complicated for things at that descriptors and stats level.
In response to a question from @alicee at this last week’s geekout session, @tremblap responded that after a few times you start to memorize what indices/channels are what, and I have to say that even after a couple of years of involvement, each time I do it, I have to stop and count and think.
I think a big part of this is, that by default, you get loads of stuff you don’t ask for from every object along the way, and then there’s a (confusing and error prone) pruning step before you get onto to flattening.
So what I’m proposing is having something like an @output attribute for the descriptors and stats objects where you specify what what you want them to return.
If I’m after the mean of centroid only, I could then have fluid.spectralshape~ @output centroid -> fluid.bufstats~ @output mean, and that would save a whole load of pruning and “indices math” after the fact.
As it is, it’s a bit confusing, but manageable to to remember what order the 7 stats come in, and the 7 spectral moments, but once you start wanting only a specific stat of a specific moment, it gets a bit messy, particularly if you get into derivatives where you have to work out some maths to iterate over the stats to leapfrog from derivative to derivative.
Also, given the small amount of stats (and spectral moments), one could use words to refer to the outputs you want (e.g. @output flatness or @output 6 if you prefer (I think that’s flatness?), and/or @output mean std min max or the @tremblap method @output 0 1 4 6)).
With something like this in place, you could skip a big part of the pruning process (for 90% of the use cases), and then use @weefuzzy’s names abstraction for things once you get up to a fluid.dataset~ level.
And in an ideal world, this would also skip computing the descriptors/stats you don’t ask for (even if they are generally interrelated).