BVC firingrates go over max_fr about ratinabox HOT 9 CLOSED

Here's another run

from ratinabox.

It an interesting point. I agree there's no neat solution because there isn't a theoretical/analytic answer to whats the maximum firing rate of a BVC. It depends on the exact environment.

I'm kind of happy with your solution. It depends how much you really mind that the max_fr overshoots the user desired value. I see a few options.

Option 1: Do nothing and just tell in a comments that this is only an estimate.
Option 1.1: Your solution, add slightly jittered test points. Simple and easy but doesn't really fix it.

Option 2: Redefine. If you really minded a better way might be to keep it as it is and add a hard threshold. Some kind of tanh or threshold-linear function on the output of each neuron that just clips any overshoot back to max_fr (this works nicely because we can be sure its always an overshoot, not an undershoot. I don't particularly like this because the clipping could be quite bad for ego-BVCs (explained below).

Option 3: We could redefine what max_fr means so that it can be calculated analytically. For example we could change it to mean "if the environment consisted of a single infinite straight wall what would the max firing rate of the cell be in this environment?". This could probably be computed analytically then used instead of the empirical estimate. Or what about this, if a cell had preferred distance range of X cm then wouldn't it necessarily fire maximally in a the centre of a circular environment of radius X cm? This could be calculated and used as the scaling. Guaranteeably the cell must fire less or equal to this in its actual environment so it is a form of upper bound. As long as we tell the user this is what max_fr means they will get what they want.

Note that it's going to be much worse for ego-centric BVCs where the (true) max_fr requires a grid search over positions and head-directions which I think we're not currently implementing so the overshoot could be quite severe for ego-BVCs if II had to guess. Because of this, whatever we choose I'd advocate better explaining in the comments what max_fr means in the case of each vector cell as it's not such a trivial notion.

Fwiw I think I'd lean option 1 or 1.1.

from ratinabox.

Thank you for the detailed response. I'm not sure what the best option is, but I realize that you are quite right! The head direction issue is probably contributing perhaps more than the sampling. This makes a lot of sense. I'm going to give this more thought to think of whether I can make a different small improvement that could substantially improve the estimate!

from ratinabox.

Yeah but the head direction thing actually would only be an issue if you're using egocentric BVCs (params = {'reference_frame':'egocentric'} or you're using FieldOfViewBVCs etc.). Also I just test it and the overshoot isn't noticeably worse for ego-BVCs.

from ratinabox.

Ah, that makes sense, as that's where my student and I discovered the largest overshoot (FieldOfViewBVCs). Values up to 1.6 with max_fr=1.0.

from ratinabox.

Ah ok, in which case your proposed fix wouldn't really solve their problem, we'll have to think of another way...

from ratinabox.

Hi Colleen, where did we leave. What's the current workaround your student is using and do you think we should push ahead and implement something more proper?

from ratinabox.

Hey Tom, we are just setting a max on the firingrates for the particular downstream calculation we were performing. Sorry, haven't had time to look into this further, though it is on the to do list.

from ratinabox.

Closing for now as current situation doesn't constitute a "bug" per se, but will happily reopen whenever needed...

from ratinabox.