New DeSTIN proposal vs. BECCA
Matt Chapman
Ben Goertzel just posted these wiki notes on a revised architecture
for DeSTIN designed to increase the system's pattern capacity and more
easily translate learned patterns into symbolic 'features.'
I'm wondering if you have any thoughts on this, specifically with
regard to how this architecture compares to BECCA's Grouper & Feature
creator.
All the Best,
Matt Chapman
---------- Forwarded message ----------
From: Ben Goertzel <b...@goertzel.org>
Date: 2012/3/30
Subject: "Uniform Destin" + OpenCog = intelligent computer vision?
To: des...@opencog.org, opencog <ope...@googlegroups.com>, Itamar
Arel <ita...@gmail.com>, 陈硕 <master...@163.com>, Shuo Chen
<shuo1984...@gmail.com>, 江敏 <mail.m...@gmail.com>, 温程璐
<cl...@xmu.edu.cn>, Mohamad Tarifi <mohamad...@gmail.com>
Hi all,
I had a slightly wacky idea tonight, about how to modify DeSTIN to
make it achieve more intelligence using the same resources, and also
to make it easier to make it work together with OpenCog. Actually
this idea resolves a problem I've had for years with DeSTIN, HTM and
all similar systems.
I'm leaving for a 10-day vacation tomorrow late morning, so I just
wrote up the idea in a fairly informal way on the OpenCog wiki site...
http://wiki.opencog.org/w/DestinOpenCog
But I'll be online everyday during the vacation (it's Japan, not rural
Mongolia this time ... Japan has more reliable Internet...) to read
your congratulations or jeers ;)
... ben
--
Ben Goertzel, PhD
http://goertzel.org
"My humanity is a constant self-overcoming" -- Friedrich Nietzsche
SeH
Ben Goertzel just posted these wiki notes on a revised architecture
for DeSTIN designed to increase the system's pattern capacity and more
easily translate learned patterns into symbolic 'features.'
I'm wondering if you have any thoughts on this, specifically with
regard to how this architecture compares to BECCA's Grouper & Feature
creator.
- Similarities, differences, and interoperabilities between DeSTIN and BECCA components, and anything offered by EnCog http://www.heatonresearch.com/encog (which has GPU kernels for various NN's)
- OpenCL vs. CUDA (which DeSTIN is currently implemented in) with regard to compatibility (OpenCL *should* be more compatible) and performance
- ROS (python) vs. Android (java)? How to most simply support sensors, robots, and mobile apps? Arduino and RaspberryPi?
SeH
Theano is a Python library that lets you to define, optimize, and evaluate mathematical expressions, especially ones with multi-dimensional arrays (numpy.ndarray). Using Theano it is possible to attain speeds rivaling hand-crafted C implementations for problems involving large amounts of data. It can also surpass C on a CPU by many orders of magnitude by taking advantage of recent GPUs.Theano combines aspects of a computer algebra system (CAS) with aspects of an optimizing compiler. It can also generate customized C code for many mathematical operations. This combination of CAS with optimizing compilation is particularly useful for tasks in which complicated mathematical expressions are evaluated repeatedly and evaluation speed is critical. For situations where many different expressions are each evaluated once Theano can minimize the amount of compilation/analysis overhead, but still provide symbolic features such as automatic differentiation.
Gnumpy is a simple Python module that interfaces in a way almost identical to numpy, but does its computations on your computer's GPU.
Brandon Rohrer
I enjoyed reading Ben's thoughts. DeSTIN is definitely trying to solve
the same problem as Becca's feature creator. I haven't been able to
find any detailed writeups on its operation or see any demonstrations
that would allow me to compare their performance, but if DeSTIN shows
itself to be the better performer (and meets the other requirements of
the Becca architecture, such as being incrementally updated and not
having a separate training phase) then I would readily substitute it
for Becca's feature creator. I've talked with Itamar Arel about it
(DeSTIN's creator) and we're both curious to see how the two tools
will mature.
As Ben says, you have to start with a fairly intimate knowledge of
DeSTIN to understand the technical details of his notes, which I don't
have. I enjoy talking with Ben about his software efforts and research
goals. What I take away from our discussions is that we think about
intelligence differently. I want to get machines to perform tasks that
they haven't been able to do yet--my research goals regarding
intelligence are defined by the problems that the machines must solve.
Ben's notion of intelligence captures something else that I haven't
yet been able to put into words for myself (although he does in a
couple of his books). For him solving problems isn't sufficient. As a
result of our slightly different goals, our research efforts can be
somewhat orthogonal. I'm not yet sure whether the modifications he
proposes to DeSTIN and its integration with OpenCOG further progress
toward Becca's technical goals or not. If anyone has insights into
this, I would be interested to hear them.
SeH, in your posts, you mention several libraries that offer high
performance substitutions for common tools and numerical packages. My
plan is to keep the Becca core as simple and transparent as possible.
This means consciously neglecting many tweaks and improvements that
could speed it up significantly. But I hope in the future that as
Becca stabilizes, people will extend the Becca core with improvements
like the tools you sugggest to optimize its performance in specialized
forks. While the current Python port is making use of numpy, for the
time being the limiting factor on Becca's performance is not its speed
of calculation. It's a little more fundamental--I have to get the
thing working again.
Brandon