fl.deltas~ object added

[fearn-e]

Per @AlexHarker's request

Object info and help file to come later today.

Has 2 parameters to control what happens with the initial element (filled with a zero, the difference from zero, or the wrapped difference from the final element), and which direction each element compares towards.

[fearn-e]

@AlexHarker I've added a help file and tidied things up now, let me know if anything needs changing!

[AlexHarker]

Thanks for this! You've definitely covered most of the main variants although I'll need to think through all the cases (e.g. inputs of one / whether someone might want only the differences and hence a shorter output.

However, before that it seems inefficient to always calculate one way and then swap for the other. I would just make a functor to calculate the other way round using the stl call (and branch outside of that). As an aside looks like you try to avoid multiply zero by one. I wouldn't bother as -0 is 0. Also, marginally quicker to do a = -a rather than a *= 1.

That stuff won't be there if you make a functor but maybe useful in future to know.

[fearn-e]

@AlexHarker have added all the changes discussed!

[AlexHarker]

OK - hopefully the final code shape change (although there will be name changes/docs clean-up).

I think there should be an additional parameter that sets whether the fill (for everything other than drop mode) is at the start or end. Right now that's tied to "compare" but I don't think that makes sense - it should be a separately controllable thing.

That will involve futzing a little with the fill code and the iterators. Once that's done I will make suggestions for naming parameters - at the moment the names need to be thought out a little more (particularly compare as a subtraction is not a comparison, and it's hard to figure out which is "left" and which is "right" - something like "direction" and "forward" / "reverse" might be easier, but I need to think some more).

[fearn-e]

I think there should be an additional parameter that sets whether the fill (for everything other than drop mode) is at the start or end. Right now that's tied to "compare" but I don't think that makes sense - it should be a separately controllable thing.

@AlexHarker To me, the fill is picking what kind of behaviour you want for the one element that can't have a diff since there is no element before it, so I'm not 100% sure what this is requesting.

[AlexHarker]

There is no specific reason for the fill to be at the start or end - you have linked this to left/right but I believe it should be a separate choice.

The two choices are then (other than the fill mode)

1 - which direction does the subtraction go 2 - where does the fill sample go (start or end)

Does this make sense?

[fearn-e]

Got it working, just going to do some more cleanup because I think I can make it a bit neater.

[AlexHarker]

Cool - I think the call to pad() could be moved out of the if structures unless I am mistaken.

[fearn-e]

Yup, just did a lot of cleanup and consolidation. Pushed now.

[AlexHarker]

OK - everything works perfectly - just some naming things and code layout that I will put in a review.

Likely I will later update the help patch a bit, but that's fine for now (there are other new objects without help files yet).