On 11/15/2021 10:15 AM, EricP wrote:
> MitchAlsup wrote:
>> On Sunday, November 14, 2021 at 10:46:40 AM UTC-6, EricP wrote:
>>>
>>> Understanding the origin of the wiring of biological NN (BNN) is
>>> appropriate to discussion of NN Accelerators as we are endeavoring to
>>> improve such simulators.
>> <
>> It is pretty clear that NNs are "pattern matchers" where one does not
>> necessarily know the pattern a-priori.
>> <
>> The still open question is what kind of circuitry/algorithm is
>> appropriate to match the patterns one has never even dreamed up ??
>
> The artificial convolution NN are basically fancy curve fit algorithms
> that adjust a polynomial with tens or hundreds of thousands of terms
> to some number of inputs after millions of examples.
>
A lot of what people are doing with NNs could be done with
auto-correlation and FIR filters.
Though, in the overly loose definitions often used, one could also try
to classify auto-correlation and FIR filters as a type of NN.
> Biological NN perform associative learning after just a few examples
> with just a few neurons.
>
> Both are suitable for sorting fish but only one
> can fit inside and control a fruit fly.
>
There is one reason I like genetic algorithms and genetic programming
for some tasks:
While the training process is itself fairly slow, and the results are
(rarely) much better than something one could come up with themselves
(in usually a fraction the time and effort), one can at least use it to
generate results that are fairly cheap to run within the constraints of
the target machine (unlike CNN's or "Deep Learning" models).
So, one can in theory set up a GP evolver to be able to use a simple set
of vector-arithmetic operators and a simplified register machine
(generally simpler register models seem to work out better, and are
simpler to implement, than a GP evolver which works in terms of ASTs).
The weighting algorithm can also impose a penalty for the number of
(Non-NOP) operations used, favoring smaller and simpler solutions (and
causing non-effective operations to tend to mutate into NOPs; which can
be removed when generating the final output).
Say, for example, for each "program":
Has between 64 and 1024 instruction words to work with;
Usually this is a fixed parameter in the tests.
Has 32 or 64 bits per instruction word;
Has 16 or 32 registers;
May or may not have control-flow operations (depending on the task);
...
An example GP-ISA design might have:
64-bit instruction words;
16 or 32 registers, encoded in a padded form (ECC style, *);
Opcode bits may or may not also have a padded encoding;
Most invalid operations are treated as NOP;
There is a way to encode things like vector loads, ...;
Most operators are 3R form, eg: "OP Rs, Rt, Rd"
...
*: Multiple encodings may map to the same logical register, and using
ECC bits makes the register ID more resistant to random bit-flips
(caused by the mutator).
So, a register may be encoded as:
4 bits (abcd): Register Number, Gray-Coded
3 bits: Parity (a^b^c, b^c^d, c^d^a)
R0: 000-0000
R1: 011-0001
R2: 100-0011
R3: 111-0010
R4: 001-0110
...
Similarly, could do a 5 bit register in 8 bits, eg:
{ a^b^c, b^c^d, c^d^e, e, a, b, c, d }
The ECC (~ Hamming(7,4)) may try to "correct" the register on decode.
Opcode may encode an 8 or 10-bit opcode number in 16 bits.
Encodings which fall into the "unrecoverable" or "disallowed" parts of
the encoding space are interpreted as NOPs.
Vector immediate values may be encoded as 48-bits, such as four 12-bit
floating-point values (S.E5.M6), which may also be stored in gray-coded
form. There might also be 2x 24-bit bit (truncated gray-coded single),
or 1x 48-bit (truncated gray-coded double).
It may also make sense to have integer operators available (depends on
the task).
...
The GP evolver basically consists of:
Test data, which is fed into the program in some form;
Say, the test data is presented as input registers.
An interpreter, which runs each GP program;
Output is one or more registers.
A heuristic to rank its performance;
...
For breeding the top-performing programs:
Pick instruction words randomly from each parent;
Randomly flip bits in each child produced.
The initial state would fill the programs with "random garbage" though,
using NOP encodings for the operators.
If one allows for control-flow, the interpreter will automatically
terminate after a certain number of instructions, and impose a fairly
severe penalty value.
Result (after a certain number of runs) would be dumped out in an ASM
style notation ("disassembled" from the internal format).
Not really developed any of this into a cohesive library or tool, partly
as it tends to be fairly ad-hoc, and I am not sure if anyone besides
myself would find something like this all that useful. These sorts of
small-scale tests were usually done via "copy-pasting something together".
...
Actually, thinking of it, it isn't exactly that huge of a stretch that
someone could also run such a GP evolver on an FPGA (as opposed to
running it on the CPU on a PC). It is possible that an FPGA could be
significantly faster at this task (if one had a good way to move results
and data between the FPGA and a PC).
...