Building HTM Systems (WIP Document)

My team had similar slowness issues with input boxes. We wanted to run input box validation (phone number, email, etc) I had to go do special hacky optimizations just to get where you could type without it lagging.

You can try storing the value outside of the component state (in any regular variable, or on this) and then just manually update the D3 element onclick/ondrag instead of updating the state. It would defeat the entire purpose of React state, but it might get the correct behavior. To get the D3 element like you would with jquery though, you have to use a thing called React References.

You can also dive into the chrome performance tools (one of the tabs in the chrome debugge) and it’ll let you pick apart the code to see what is causing the slowdown.

Maybe tomorrow I’ll look at making a fork of the React version and port it to Vue and see if the slowness is still there. Vue will let you check on a sub-value in state, and put a custom handler on it. (e.g. state.counter.onUpdate() ) If it’s still slow then it’s pretty likely it is just a virtual Dom issue.

2 Likes

I am not sure I agree with react being in the way or hampering development there is a reason it is so popular and used in production as much as it is. I have been using it without issues for a very long time. You are not using jQuery and the components are view only basically requiring only state changes when you need to rebuild the component. The page should only rerender when you change state and that “rerender” may actually not do anything if the non d3 elements haven’t changed. I am also not sure using a new framework (Vue) is the answer as it is not that different then React under the covers and any issue you run into with React you will most likely run into with Vue. I will take a look at why your page is rerending now. btw React has been shown to be much more performant then using something like jQuery.

1 Like

So first thing i notice is you are changing state on the value on hover. Is that something you want? If it is you are rebuilding the d3 diagram every time you hover which is the wrong thing to do so you would just not re-build the grid on value changes. That is why your lag is happening. Also you don’t need a my = this, you can just use arrow functions which will bind this in scope on declaration.

Let me know if you have a branch that i can pull and i can lend a hand at next live stream. Have no fear :slight_smile: there is easy fix for your issue :slight_smile:

2 Likes

Just take a look at master. It has the latest React. One thing I noticed was that closing the debugging console prevented the lag I was seeing :man_shrugging:.

I will be working on this today (offline) and tomorrow (live streaming).

sounds good, let me know if you have issues with updating value in the state (i am not sure that is what you want and if it is there is different way to do it)

yeah so i see you have sliced up my code in the SimpleScalarEncoder component breaking the updating (i can explain why it breaks it tomorrow in live stream) but i went into my fork and switched the scrubber to just use a input element for now (with high/low etc) and it is very performant (notice below the Value input changing whiile hovering in d3 changes – d3<->react very fast)…

so the issue is with your code changes that i can point out. I think it makes sense to use the input element for now instead of the number scrubber

this is the Number scrubber i changed …

import React from 'react'
import PropTypes from 'prop-types'

const style =  { 
	border: 'solid gray 1px', 
	borderRadius: '4px', 
	fontWeight: 'bold',
	padding: '2px',
}

const Number = ({ high = 100, low = 0, onUpdate, precision = 0, value = 0}) =>  <input type="number" min={low} max={high} style={style} value={value} onChange={(e) => onUpdate(e.target.value)} step="1" />
  
Number.propTypes = {
	high: PropTypes.number,
	low: PropTypes.number,
	onUpdate: PropTypes.func.isRequired,
	precision: PropTypes.number,
	value: PropTypes.any,
}

export default Number
1 Like

Skipping ahead to the SP…

We’ve made it partially through encoders, but everyone would rather skip ahead to Spatial Pooling. So we are going to skip some encoders so we can prepare for Spatial Pooling visuals.

So next up is a streaming combined encoder:

17%20PM

We’ll be working on this Thursday 9am. See my events for details. Next week, if that goes well, we’ll start on the “potential pools” diagram:

05%20PM

But we need the combined encoding first, because it will be a part of the potential pools diagram.

I hope you will be able to join me on Twitch if interested!

2 Likes

I’ve abandoned Trello and moved all issues into Github Projects (which is very nice!). I will go over this tomorrow in the live-stream, but I’ve broken work out into 3 projects (so far).

I’ve created all the issues we need to get us to the point where we need to actually build out the spatial pooling algorithm. Before we get there, we have a couple encoding-related tasks we must work on to set up the “input space” for the SP.

32%20AM

2 Likes

Knocked out two tasks on the live stream today. See the latest build here.


Big thanks to @David_Duckworth for his help with React and JavaScript.

1 Like

Good progress today. See it live at https://building-htm-systems.herokuapp.com/spatial-pooling:

1 Like

I think it is time to create a Spatial Pooler.

3 Likes

Tomorrow we’ll create the minicolumn competition that simulates inhibition. Skipping local inhibition and topology at this point.

1 Like

Yesterday I had some trouble getting learning working, but I found the problem today and finished up.

On Monday, we’ll finish up the learning bit and start tracking active duty cycles. This will set the stage for implementing boosting.

AdobeStock_261379799

4 Likes

Next stream will be this afternoon on YouTube, where I’ll be writing prose describing Spatial Pooling.

2 Likes

I had to update the link, sorry. Technical difficulties.

1 Like

Check out the Spatial Pooler prose so far.

2 Likes

I’ll be continuing writing prose for the SP today about the minicolumn competition. Tune in at 1PM PDT.

Live-coding Active / Overlap Duty Cycles (again) in about 15 minutes.

I got duty cycles working properly on my fork (both active and overlap). I just ignored performance and cached 1000 time steps. After testing on the website, it did not slow anything down, so let’s roll with it. I’ll be explaining the code and merging / deploying today, then we’ll create the overlay duty cycle diagram.

Today we created stack-ranked minicolumn competition diagram.

See it live at https://building-htm-systems.herokuapp.com/spatial-pooling#stackRank

2 Likes