The team presents the results from the Brighton focus-week retreat.
00:00 Introduction
04:00 Python Upgrade
15:32 Salience Showdown
27:47 Exponential Moving Average Evidence-Bounded Scores
42:06 Compositional Object Test Bedbed
The team presents the results from the Brighton focus-week retreat.
00:00 Introduction
04:00 Python Upgrade
15:32 Salience Showdown
27:47 Exponential Moving Average Evidence-Bounded Scores
42:06 Compositional Object Test Bedbed
So, are you gonna leave us hanging? Who won!?
My personal pick would be Scott & Hojae hands down, both fruitful and entertaining. Plus, it paves the way for better feature extraction.
Compositional models are coming along nicely, keep up the good work. I wonder how BioSaliency would affect the results ![]()
Ramy’s interactive visualizations are awesome, they really put things into perspective. I feel like having multiple time constants is the way to go, as Niels suggested. Probably even have some that are dynamic and context-dependent too. The human mind definitely has some level of control over at least one of them.
Regarding the Habitat “wisdom tooth extraction”, well you couldn’t have known about the 10x slowdown without trying! That’s what science is for. Have you guys made more progress since then? I do happen to have experience with interprocess communication, perhaps I could take a crack at it ![]()
Are these the repos in question?
Thanks for the kind words @AgentRev
I think all the projects were really cool and had impressive results for just a week’s work! In the end, it was a tie between Scott and Hojae’s saliency project and Will & Tristan’s simulator extraction (I had to order some more trophies; the store is now out of SPAM cans
)
There is a new repo for the interactive visualizations here: GitHub - thousandbrainsproject/tbp.plot: Tooling for plotting tbp.monty visualizations @rmounir put a lot of work into making them easy to use and assemble custom versions of them (a video of him walking through how to use them coming out soon).
After the compositional testbed is integrated into Monty (PR here feat: Add compositional experiments & metrics by vkakerbeck · Pull Request #467 · thousandbrainsproject/tbp.monty · GitHub) we plan to test all our other research prototypes in the pipeline on this benchmark, including the bio saliency ![]()
@tslominski is probably the best to answer on possible ways to contribute to the simulator extraction. For now, we are focusing on integrating MuJoCo as a second simulator and we are not currently working on implementing the separate simulator prototype ourselves (not because we won’t ever want to, just because of limited resources).
Hi @AgentRev,
Yes, those are the two repositories that we used for the demo.
As @vclay mentioned, we haven’t updated Monty with anything from the prototypes yet.
My recommendation would be to first integrate the changes that reduce the Simulator protocol to the bare minimum. Those changs are all contained in GitHub - thousandbrainsproject/prototype.simulator: Monty prototype using a simulator via a socket. While the separation made it very clear what is the minimum required, reducing the protocol surface is a good thing even prior to/without the separation. There’s less to implement in any simulator, including MuJoCo.
With the minimal protocol, I assume it should be easier to try out different serialization/communication approaches.
@jshoemaker will likely take a look at reducing the Simulator protocol, but I don’t know when that will be. Both him and I are currently integrating the latest research into Monty. I’m integrating Scott’s work and Jeremy’s integrating compositional work. So, we aren’t working on the simulator seperation (nor the Simulator protocol simplification) aspect of things yet.
Sure, I can take a look at that. I already see there are merge conflicts to solve due to the DataLoader refactor.
Or, if you’d instead prefer help with other things right now, just designate a target.
Simplifying the Simulator would be helpful.
I think it is worth noting that prototype.simulator is prototype code, and I recommend using it as a reference for an implementation rather than attempting to merge it as is or with modifications.
Additionally, some of the prototype.simulator commits are handoffs from pair programming sessions and correspond to partial work in progress.
@brainwaves Haha! There it is. Everyone rightfully earned their potted meat, indeed. ![]()
@tslominski Yes I figured as much, that as-is merge attempt was just to inspect the diff. I opened an issue to continue the discussion: Simulator protocol should be reduced to the bare minimum · Issue #506 · thousandbrainsproject/tbp.monty · GitHub