That's interesting... we are looking to interface with FPGA hardware too for some things, so a heterogeneous implementation would be great. I'll keep checking in on OpenCL as time goes on. Thanks!
Yeah, I wouldn't call our Java implementation "naive" per se, but we are definitely looking into implementing other simulation back-ends and decoupling the Nengo GUI from the simulation core. I'll look more seriously into C and OpenCL -- does it run on both ATI and NVidia cards? We have mostly NVidia cards here.
Hmm... that's an excellent point! We have a few of hot loops that run over and over and over again. But, because of that we know what needs to be optimized and we've tried to do so. It's true though that some optimizations we've tried haven't worked out well, so the JVM's JIT compiler might be what's saving us most of the time. Personally I'd like to write it all in RPython and have it make a JIT for us;)
Because Python's such a nice glue language, it can talk to super fast Fortran and C libraries to be at at least comparable speed with Java. See NumPy. This is kind of stuff scientists use for number crunching.
Hey, we're definitely thinking about this! In fact, the Java version can run on a GPU. And we're in the process of making a fast Python version based on theano. Unfortunately, even with all of these speedups, we're still talking about lots of neurons and lots of computation.
However, there are plenty of smaller scale models that you can run in Nengo to get a sense of what's going on in the larger Spaun model! The tutorials are a good place to start.
I mean, we would be ecstatic to have people contribute in any way! That could even just mean learning the framework and the software and using it in your own research. We have lots of tutorials, and we'd be happy to help if you want to make your own models. The software itself is pretty good, but it's academic software, and certainly we'd welcome anyone's contributions to the software! We're pretty responsive, either at any of our emails, or by making a github issue if you need any assistance.
Unfortunately, I don't know if we have a lot of "low hanging fruit", things that we need done but are just too lazy to do so. Though I'm sure we could come up with some of those tasks if desired, as we're certainly lazy.
This model is already open source! I have been very adamant about keeping this the case in the Eliasmith lab. The model is here, and the software running it is here (and on github).
This is an interesting study, but the conclusion it appears to draw is erroneous at best.
Take this quote, from one of the study's investigators: "During sleep, our neurons are busy doing very complicated processing, including, this study shows, generating sleep spindles to protect us from being awoken from noises in the environment."
EEG is such a broad average that it tells us very little about what the brain is doing, just like looking at the NASDAQ doesn't tell you very much about how one company or a group of companies are doing. To suggest that our brain is "generating sleep spindles" is myopic; sleep spindles are a symptom of what the brain is doing during sleep: replaying memories temporarily held in the hippocampus and consolidating then into cortex.
The correlation between producing lots of "sleep spindles" and having relatively good memory makes sense in this light, as does being hard to wake up during sleep, as a brain that's attending to memory consolidation won't be as sensitive to external stimuli (just like when you're concentrating while conscious). But to suggest that sleep spindles function to protect us from noises in the environment makes no sense at all. Evolutionarily, it's more advantageous to wake up when you are being attacked, or are otherwise in peril. If anything, this research would suggest some kind of limiting factor to the overall intelligence of a society that deals with the environment in that way.
I'm in the same boat as iOdin. A lot of the work my lab produces is based on a certain framework we've developed. To make any sense out of our publications, we have to give a cursory description of the framework, even though we will obviously cite a suitable source as well. Even in a short paper this amounts to a few paragraphs; rewording them for each paper is no fun.
If a proposal like this is to succeed -- and I hope so hard that it does -- we need a central repository to store code and meaningfully link it to the papers that use it.
This repository should have the same amount of peer review and, therefore, authority that scientific journals have now. Maybe that can happen by existing journals adding the ability to link code to a paper (and enforce that any code used to generate results is included), maybe a new organization has to rise up to the challenge (I would love to see a code.arxiv.org).
Already I can hear the outcry of scientists claiming that their code is "sloppy" and "not ready to be released," but those concerns are simply irrelevant: all that matters is that the code produces the output cited in the paper given the input cited in the paper. That's it. If another researcher finds your result interesting, then let it be up to them to parse out your code -- it's probably still way better than trying to reproduce your result based on the prose that describes your algorithm.
By your logic, no one should have access to a programming language because what if that language is wrong. A ton of scientific research is done in Matlab, yet you don't hear anyone complaining that code produced in Matlab may not be correct because you aren't looking at each individual bit of information as it is processed.
The idea of providing your code, in fact, solves the exact problem that you're describing. The point of research is not to reproduce results -- certainly, that's a first step in many lines of research, but it by itself is not a result. However, if you find that the code used to produce some results is incorrect, then you do have a result, and this furthers that field of research immensely, because no longer are a string of papers going to build on an incorrect result. Everyone can be confident in a result and move on from that point.
Your line of reasoning may make sense when you talk about "equipment" in terms of sensors and proprietary hardware, but when we're talking about software that runs the same on whatever hardware you're using, being able to reproduce a result is only a first step. Shortening that step and allowing everyone to scrutinize how you did it only catalyzes further research.
Bits is not bits in the brain. We don't have a bunch of neurons representing ones and zeros.
A neuron is either spiking or not spiking, but everything is very temporal; with some stimulus (a particular input current) a neuron might spike at a rate of 100 Hz, with another input, at 20 Hz. How do we translate these spikes into information we can use? Well, we're trying to figure that out.
In addition, in the brain, we do not have the cleanness of digital processing. There is lots of noise from a variety of sources, so a lot of effort is taken to be resistant to noise.
Does it matter if things are carbon or silicon? No, but there's a huge difference between the transistors of today and the biological neuron. The "wet computer" as described is probably not exactly like a biological neuron, but I can assure you it is not like a modern transistor, and that in itself makes this an interesting project.
Re:Do we finally have unicode support?
on
Cygwin 1.7 Released
·
· Score: 0, Redundant
I haven't done enough research on Alzheimer's to support the link between the two, but the destruction of dopamine-producing cells in Parkinson's surely has an effect on long-term memory.
A lack of dopamine affects other cognitive functions, so I can imagine seeing similar behavioural effects as one sees in Alzheimer's, but I'm not aware of Alzheimer's characteristic loss of neurons and synapses in Parkinson's disease. So the link between them seems a bit shady to me.
I guess not all DVRs are created equally then, because when I was at my parents' house I was constantly frustrated by how difficult it is to fast forward through commercials on their Shaw-supplied DVR. The first level of fast-forward, which should double the speed the video playback, almost appears to slow it down, then jumping to the second level makes it skip fast enough that you're likely to have next week's Lost spoiled for you. A few years ago there was a button to skip exactly 15 seconds, which made it very easy to skip commercials, but they essentially disabled that button quite a while ago, and since then the fast-forward / rewind capabilities have gotten gradually worse. I'm not sure how many people use DVRs supplied by their cable company, but the ability for the company to push updates to essentially cripple your machine is something that needs to stop.
Me, I'll stick to downloading everything with the commercials already stripped out.
I saw District 9 last night and I have to say I was incredibly disappointed. After reading the good reviews, I was expecting to feel something during the movie, but instead it was just another action movie. Nice special effects, but the plot and characters were just awful. The main character has absolutely no personality; he changes his behaviour from scene to scene I guess to fit what the writers thought would be best for the action.
Slashdot Mirror
Whoa, I had no idea rootbeer existed! That sounds quite useful, thanks for the link!
We're doing this very explicitly, by writing CUDA code in C and interacting with it in our Java program with JNI.
That's interesting... we are looking to interface with FPGA hardware too for some things, so a heterogeneous implementation would be great. I'll keep checking in on OpenCL as time goes on. Thanks!
Yeah, I wouldn't call our Java implementation "naive" per se, but we are definitely looking into implementing other simulation back-ends and decoupling the Nengo GUI from the simulation core. I'll look more seriously into C and OpenCL -- does it run on both ATI and NVidia cards? We have mostly NVidia cards here.
Hmm... that's an excellent point! We have a few of hot loops that run over and over and over again. But, because of that we know what needs to be optimized and we've tried to do so. It's true though that some optimizations we've tried haven't worked out well, so the JVM's JIT compiler might be what's saving us most of the time. Personally I'd like to write it all in RPython and have it make a JIT for us ;)
We're using CUDA, so you'll need a recent NVidia card to run models on the GPU.
Because Python's such a nice glue language, it can talk to super fast Fortran and C libraries to be at at least comparable speed with Java. See NumPy. This is kind of stuff scientists use for number crunching.
Hey, we're definitely thinking about this! In fact, the Java version can run on a GPU. And we're in the process of making a fast Python version based on theano. Unfortunately, even with all of these speedups, we're still talking about lots of neurons and lots of computation.
However, there are plenty of smaller scale models that you can run in Nengo to get a sense of what's going on in the larger Spaun model! The tutorials are a good place to start.
I mean, we would be ecstatic to have people contribute in any way! That could even just mean learning the framework and the software and using it in your own research. We have lots of tutorials, and we'd be happy to help if you want to make your own models. The software itself is pretty good, but it's academic software, and certainly we'd welcome anyone's contributions to the software! We're pretty responsive, either at any of our emails, or by making a github issue if you need any assistance.
Unfortunately, I don't know if we have a lot of "low hanging fruit", things that we need done but are just too lazy to do so. Though I'm sure we could come up with some of those tasks if desired, as we're certainly lazy.
This model is already open source! I have been very adamant about keeping this the case in the Eliasmith lab. The model is here, and the software running it is here (and on github).
We'd be happy with faster than real-time too! Baby steps.
Hey, I'm still figuring out the copyright rules as to what I can post, but there are plenty of things already available:
This paper on Spaun specifically
Some background on how Spaun is built
Some background (with code) on the theoretical framework used
The actual code for Spaun
I'll let you know if a pre-print goes up!
We do use Python scripting to interface with our simulator, Nengo. See the last link for the actual script we use for Spaun.
This is an interesting study, but the conclusion it appears to draw is erroneous at best.
Take this quote, from one of the study's investigators: "During sleep, our neurons are busy doing very complicated processing, including, this study shows, generating sleep spindles to protect us from being awoken from noises in the environment."
EEG is such a broad average that it tells us very little about what the brain is doing, just like looking at the NASDAQ doesn't tell you very much about how one company or a group of companies are doing. To suggest that our brain is "generating sleep spindles" is myopic; sleep spindles are a symptom of what the brain is doing during sleep: replaying memories temporarily held in the hippocampus and consolidating then into cortex.
The correlation between producing lots of "sleep spindles" and having relatively good memory makes sense in this light, as does being hard to wake up during sleep, as a brain that's attending to memory consolidation won't be as sensitive to external stimuli (just like when you're concentrating while conscious). But to suggest that sleep spindles function to protect us from noises in the environment makes no sense at all. Evolutionarily, it's more advantageous to wake up when you are being attacked, or are otherwise in peril. If anything, this research would suggest some kind of limiting factor to the overall intelligence of a society that deals with the environment in that way.
I'm in the same boat as iOdin. A lot of the work my lab produces is based on a certain framework we've developed. To make any sense out of our publications, we have to give a cursory description of the framework, even though we will obviously cite a suitable source as well. Even in a short paper this amounts to a few paragraphs; rewording them for each paper is no fun.
If a proposal like this is to succeed -- and I hope so hard that it does -- we need a central repository to store code and meaningfully link it to the papers that use it.
This repository should have the same amount of peer review and, therefore, authority that scientific journals have now. Maybe that can happen by existing journals adding the ability to link code to a paper (and enforce that any code used to generate results is included), maybe a new organization has to rise up to the challenge (I would love to see a code.arxiv.org).
Already I can hear the outcry of scientists claiming that their code is "sloppy" and "not ready to be released," but those concerns are simply irrelevant: all that matters is that the code produces the output cited in the paper given the input cited in the paper. That's it. If another researcher finds your result interesting, then let it be up to them to parse out your code -- it's probably still way better than trying to reproduce your result based on the prose that describes your algorithm.
By your logic, no one should have access to a programming language because what if that language is wrong. A ton of scientific research is done in Matlab, yet you don't hear anyone complaining that code produced in Matlab may not be correct because you aren't looking at each individual bit of information as it is processed.
The idea of providing your code, in fact, solves the exact problem that you're describing. The point of research is not to reproduce results -- certainly, that's a first step in many lines of research, but it by itself is not a result. However, if you find that the code used to produce some results is incorrect, then you do have a result, and this furthers that field of research immensely, because no longer are a string of papers going to build on an incorrect result. Everyone can be confident in a result and move on from that point.
Your line of reasoning may make sense when you talk about "equipment" in terms of sensors and proprietary hardware, but when we're talking about software that runs the same on whatever hardware you're using, being able to reproduce a result is only a first step. Shortening that step and allowing everyone to scrutinize how you did it only catalyzes further research.
I just wrote that to a random contact on my Gmail Chat list. I'm sure they'll get it.
Bits is not bits in the brain. We don't have a bunch of neurons representing ones and zeros.
A neuron is either spiking or not spiking, but everything is very temporal; with some stimulus (a particular input current) a neuron might spike at a rate of 100 Hz, with another input, at 20 Hz. How do we translate these spikes into information we can use? Well, we're trying to figure that out.
In addition, in the brain, we do not have the cleanness of digital processing. There is lots of noise from a variety of sources, so a lot of effort is taken to be resistant to noise.
Does it matter if things are carbon or silicon? No, but there's a huge difference between the transistors of today and the biological neuron. The "wet computer" as described is probably not exactly like a biological neuron, but I can assure you it is not like a modern transistor, and that in itself makes this an interesting project.
From the 1.7 release announcement:
- Default character set is now UTF-8, but other character sets are supported via an improved internationalization support.
Full of what's new / changed.
I haven't done enough research on Alzheimer's to support the link between the two, but the destruction of dopamine-producing cells in Parkinson's surely has an effect on long-term memory.
http://www.sciencemag.org/cgi/content/abstract/325/5943/1017
A lack of dopamine affects other cognitive functions, so I can imagine seeing similar behavioural effects as one sees in Alzheimer's, but I'm not aware of Alzheimer's characteristic loss of neurons and synapses in Parkinson's disease. So the link between them seems a bit shady to me.
Artificial intelligence, simply put, is just applied computer science. The name is just intriguing enough that it gets (got?) decent funding.
I guess not all DVRs are created equally then, because when I was at my parents' house I was constantly frustrated by how difficult it is to fast forward through commercials on their Shaw-supplied DVR. The first level of fast-forward, which should double the speed the video playback, almost appears to slow it down, then jumping to the second level makes it skip fast enough that you're likely to have next week's Lost spoiled for you. A few years ago there was a button to skip exactly 15 seconds, which made it very easy to skip commercials, but they essentially disabled that button quite a while ago, and since then the fast-forward / rewind capabilities have gotten gradually worse. I'm not sure how many people use DVRs supplied by their cable company, but the ability for the company to push updates to essentially cripple your machine is something that needs to stop.
Me, I'll stick to downloading everything with the commercials already stripped out.
It's common practice for a journalist to strip those nonsense syllables from an audio interview transcribed to text. Just sayin'.
I saw District 9 last night and I have to say I was incredibly disappointed. After reading the good reviews, I was expecting to feel something during the movie, but instead it was just another action movie. Nice special effects, but the plot and characters were just awful. The main character has absolutely no personality; he changes his behaviour from scene to scene I guess to fit what the writers thought would be best for the action.
The phrase is "case in point".
Can you just imagine what Japan would be like if marijuana were legal there?
Awesome