Regression for time series/controller data?

[tremblap]

@balintlaczko

I just can’t imagine what would happen to 90 numbers squished through 32 nodes and then 90 more in the output layer.

that is the beauty of autoencoders: they can be used for error reduction. This post by @weefuzzy points at a few references but my favourite are those, in that order of explanations

• Auto-Encoder: What Is It? And What Is It Used For? (Part 1) | by Will Badr | Towards Data Science
• Deep inside: Autoencoders. Autoencoders (AE) are neural networks… | by Nathan Hubens | Towards Data Science
• PCA vs Autoencoders. In this tutorial I will explain about… | by Ori Cohen | Towards Data Science
• https://www.deeplearningbook.org/contents/autoencoders.html

[balintlaczko]

Thanks a lot!! I’ll go through these now. This website together with machinelearningmastery.com are pure gold, most of my current knowledge comes from either of the two…

[rodrigo.constanzo]

@balintlaczko

So we have a 10 step memory. From this perspective the input data is almost “only” idle, with a few ramp ups/downs every now and then. I trained with the button data included (even though the 9th dim never had a single “on” state - [right?]), but as I expected, the network didn’t pick too much up from it.

This crossed my mind the other day, that if the “memory” is just 10 steps, and each step is 1ms (at the moment), that a lot will be missed out. This also includes the spare button stuff as you’re seeing there. I guess I didn’t press all the buttons while setting it up, though I could have sworn I have.

That being said, the output does look “controller-y”, so that’s something!

@balintlaczko

I think the data needs to be represented in a better way, filtering out the idle stuff (and possibly dropping the button data or representing it in some other way). Everything has to be represented so that this simple mlp - having a “memory” of N steps - can have an overview of the whole dataset somehow. Maybe it would be worth to try training this with the idle parts filtered out, and then training another network on the same data, that should learn when to be active and when to idle.

That’s an interesting one because I guess if you filter out the “idle” stuff, you’re modelling back-to-back gesture, all the time. I guess that’s what this model wants and expects, and can produce, but that would then presumably mean it would then spit that out as well. I guess having another simpler network that is “play” and “don’t play” could be an interesting solution to that. That could maybe be problematic with sparse states, or changes in trajectories that span any given chunk.

Is this particular “problem” unique to this approach (faking memory via chunking), or is it a problematic feature of auto regression in general? Like, if there was ESN or LSTM, would the same be the case? Or does the feedback (or however it works) build that variability into the network structure?

@weefuzzy

Perhaps I should dust it off…

It would likely go quite over my head, but it does sound promising.

[jamesbradbury]

I read a tonne of this guy’s material at the start of my PhD to learn more. Super good stuff

[tremblap]

Hello @balintlaczko

I’m looking at your gest.record~ and I wonder if you considered averaging, or getting the peak/trough of all the values you might get in each period of your ‘time resolution’ ? Do I understand well the current code which overwrites the given index until it is incremented by the clocker?

[balintlaczko]

Hello @tremblap ages later… Yes, as you probably noticed it is a super primitive tool, and it just writes value X to index Y. The averaging is an interesting idea, for example if I have time res = 100 but my incoming data rate is at 1 ms, it should average all 100 values. Almost like a real-time downsampling? I will put it in the next release.

[tremblap]

check the real speed of your input to start with, with [change] and then timing. then you could use running average or running median filter to remove outliers…

fun stuff!