Comments (9)
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.
Related Issues (20)
- Please tag the 1.9.1 release HOT 2
- Minimum required python version currently 3.10 HOT 2
- Agent vector cells HOT 1
- New Actions HOT 3
- AgentVectorCells and FieldOfViewAVCs HOT 3
- Version mismatch in 1.11.0 metadata HOT 1
- Open discussion: Object disappear after Agent passes by HOT 3
- Name swap...
- Speed and place cells HOT 13
- "I" not updated in FeedForward Neurons HOT 6
- Small bug relating to PR #101 HOT 1
- history not loaded when importing trajectory HOT 3
- New python version bug HOT 2
- Modules of grid cells with uniform offsets HOT 1
- add error checking to parameter settings HOT 2
- Firingrate norm for BVCs should be unscaled HOT 2
- Confused about setting multiple spatial goals in the A2C demo HOT 4
- straight trajectory with fixed speed mean, but Ag.history['vel'] is not constant HOT 5
- Can't get firingrate when using import_trajectory with interpolate=False HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ratinabox.