1 by default. 2 means add mutation on every second clone.

Add for loop. Loop d times starting from current line till cur + abs(a). I don't sure, that we have to implement this in first release.

Related to #16

Эта команда должна возвращать тип повержности на которой сейчас находится организм. По сути, она возвращает значение взятое из World._data[org.offset].

It should be replaced by FastArray2

jumpX should work with d register. abs(d) is amount of lines after jumpX, which it's block. This is opposite logic to current.

Related to #17, #16

Add config molDecayPeriod:number. It should get molecule age and decay it if needed into two parts. It there is no free space near molecule, then it should try few random free spaces and then skip the decay.

Main documentation related to "line" is here.

Related to #5, but separate commands:
nget - means neighbor code get b - direction, a = org.code[d]
nput - means neighbor code put, b - direction, org.code[d] = a

Будет затемнять мир. Влияет на работу команды see.

Это должна быть появляющаяся\исчезающая панелька, которая отображает информацию об организме, когда пользователь кликнул на него. Нужно учитывать смещение канваса и зум+прокрутку panzoom.
Должна содержать:

• item
• x, y
• isOrg
• color
• packet
• age
• probs
• period
• percent
• ax, bx, ret
• energy
• code
• mem
• function amount

Add speak related commands:
say a, d, where

• a - value
• d - direction

If organism is on that direction, then we have to put the value into it (to special register "s")
listen d - just reads value into d from "s" register

Should not create new typed array if destination size is equal or less then current

Зачем мы храним для каждой команды 32 бита?

• Нужно хранить по 6 бит на команду (максимум 64 команды). Мы значительно сэкономим занимаемое организмами и молекулами место.
• Нужно юзать Uint8Array.
• Для этого нужно использовать свой splice иpush.
• Все должно работать

Now, we loop through all molecules and organisms in main while(). We don't need to loop over molecules at all. We have to keep organisms at the beginning or at the end and molecules at the end or at the beginning. If we meet first molecule (org.isOrg === false), we have to break the loop (not continue). In case if some organism die and it's position inside the list (vm._orgs = [org1,org2,null,org4,molec1,molec2,...]) we have to take him and switch with last live organism in a list (org4).

update: i have to use separate class for organisms and molecules. Now, we use FastArray. It should be a class, which keeps organisms at the beginning and molecules at the end.

To have an ability to use VM for GA experiments it should be splitted into two classes:

• VM - core class with basic logic (from toggle till not, also find, move, find, len). Should contain main switch() operator and call super() for other operators. There should not be any biological logic and instances like world, orgsAndMols and so on.
• BioVM - extended logic for LGP and digital organisms (join, split,...). This class should obtain all related instances (world, db,...) as parameters and store them as properties. Should also contain switch() operator, which extends commandsv from VM class.
• класс VM не должен знать о молекулах
• не должен содержать логику для прокрутки (_onScroll)

Основная идея - сделать код luca короче. Если для этого нужно будет изменить команды - это окей. В этой статье описана архитектура языка системы Avida. Длина кода не должна превышать 64 команды.

• заменить кусок с цветом на цикл
• убрать включенность команды join

Связано с #47

Нужно использовать эту функцию для копирования части массива в себя же при скроле.

Если верить этой статье, то можно использовать типизированный массив из 32 битных чисел для хранения данных канваса. Здесь сравнение по скорости.

Эта ссылка описывает как можно сгенерировать различные поверхности с помощью всего одной функции Перлина. Нам нужно получить лед, горы, землю, море, радиационные области и вулканы. Возможно еще что-то. Основная идея здесь следующая - находясь на каком-то элементе, организм испытывает его влияние. Например, находясь на верхушке горы, во льду, его инструкции будут выполняться медленнее (за один проход их выполнится меньше), что увеличит его продолжительность жизни, но уменьшит ее скорость.
Вот какие параметры организма могут изменяться в зависимости от поверхности:

• количество затрачиваемой энергии
• скорость старения
• скорость движения
• скорость мутаций
• количество выполняемых инструкций за итерацию
• количество помех в команде see (вплоть до полного ее отказа. тогда она всегда возвращает 0)
• что еще?

Вот список поверхностей и их действий на организм

• лед - количество выполняемых за одну итерацию команд должно соответствовать высоте. Оно должно быть ниже, чем в горах. Скорость старения должна быть тоже замедлена. Движение должно быть тоже замедленно.
• горы - так же, как лед, но чуть меньше.
• земля - самая благоприятная. высокая скорость, минимальная трата энергии, жизни и старения. минимальная скорость мутаций.
• вода - минимальная скорость движения, трата энергии повышена, скорость мутаций обычная, повышенные помехи в команде see.
• вулкан - максимум забирания энергии, замедленное движение
• радиация - увеличенное количество мутаций

Все перечисленные выше поверхности должны быть динамическими.

Сейчас при создании инстанса организма создаются такие поля:

• loops
• funcs

Их размер всегда равен максимальному размеру кода Config.orgMaxCodeSize, а это очень много. По сути, у нас всегда висит память, которая не используется. Нужно использовать объекты для хранения смещений. Это уменьшит использование памяти.

We have to support more then 100 000 agents in parallel. inps should be more then 50 for 100 000 orgs.

Связан с #47, #46, #43, #42, #40
upd: А это сейчас не так?

Добавить логику отходов (вывода ненужных молекул). Работать это должно точно так же как клонирование: команду food нужно выставить на главный код, а бежать по остальному коду (ниже). Если команда (а позже молекула) не найдена в главном коде, то ее нужно вывести. Выполнение этой задачи имеет смысл только после того, как мы реализуем хранение структуры молекулы в организме.

#
# This is optimized version of luca 
#
# color+step+eat
nop
11
loop
    lshift
    step
end
color
join

# wastes logic
# TODO

После смерти организм разлогается на несколько молекул. Но свойства присущие только организму остаются у этой молекулы (которая недавно еще была организмом). Например: ax, bx, freq, generation и т.д. Нужно просто создавать новую молекулу с кодом организма, а его убивать.

Идея этого мейлстоуна в введении более реалистичной циркуляции энергии в системе. Энергия будет браться из соединений атомов в молекулах, которые поглощают организмы. Расщепление молекул (катаболизм) используется для получения организмом энергии и для получения простых молекул, которые могут использоваться для построения своих копий. Соединение атомов или молекул вместе (анаболизм) влечет за собой потерю энергии организмом, но получение новой молекулы. Эти операции должны осуществляться внутри организма. Соответственно, нужно убрать команду nsplit и добавить две новые: catab (катаболизм) и anab (анаболизм). Полученные молекулы должны использоваться для построения собственной копии (клона). Лишние или неподходящие молекулы, должны выводиться наружу. Пополнение (соединение атомов и молекул обратно) энергии будет осуществляться плагином Decay. В данном случае он будет выполнять функцию "дающего энергию" объекта (как солнце).

Изменения:

• команды split и join должны учитывать какого размеры отсоединяемые\присоединяемые куски. Если присоединяется большой блок, то должно тратиться столько энергии, сколько присоединяется. И наоборот, при отбрасывании большого куска нужно давать энергию организму пропорционально отделяемому куску. (подумать об этом. ведь мы не разъединяем и не соединяем молекулы. их структура остается такой же)
• максимальное количество молекул должно быть WORLD_WIDTH ×WORLD_HEIGHT - orgAmount, где размер молекулы 1 команда. Мы должны стартовать с молекул размера 3 команды. почему?
• энергия должна уменьшатся с каждой итерацией выполнения кода организмов
• должна уменьшаться при движении с учетом размера организма и собранных молекул
• скорее всего нужно будет убрать экстра затраты на остальные команды
• скорость ее уменьшения должна зависеть от общего размера организма (его код + собранные молекулы)
• энергия должна тратиться на анаболизм и пополняться при катаболизме
• значения траты и пополнения должны быть зеркальными, но с разными знаками. Нужно использовать правило экспоненты. 1 молекула с 3я команды = 2×2×2 энергии. Если разделить ее на 2 части: 2×2 и 2, то энергия разделяется соответственно.
• скорее всего нужно будет переписать LUCA c учетом катаболизма, анаболизма и структуры молекул.
• нужно будет убрать ограничение на минимальный размер молекулы. организм может выделять и потреблять даже один атом
• собранные молекулы нужно будет ложить как и раньше.
• должен измениться принцип хранения кода в организме. В Uint8Array должны храниться команды в 6 битах начиная со 2го. 1й бит должен быть 1, когда текущая команда последняя в текущей молекуле и 0 если первая или промежуточная. Так мы сэкономим куча памяти и сможем хранить структуру молекул в организме.
• добавить команды anab, catab

Add cool loader while big world loading...

В книге "The Nature of code" разбираются примеры виртуального 2D мира, где действуют силы гравитации и объекты не просто двигаются, а испытывают все эти силы. То есть, они двигаются более реалистично, чем это происходит сейчас. Нужно подумать, возможно это хорошая идея чтобы внести эти силы в мой симулятор. Это усложнит систему и даст организмам больше степеней свободы для передвижения по миру. Вполне возможно, что в этом случае нужно будет перейти на координаты с плавающей точкой. Не факт, что это будет просто, так как тогда не выйдет трекать коллизии. Как вариант, можно оставить целочисленные координаты, но внести силы и движение на несколько точек за один шаг.

• We have to use just two crossover points
• Crossover should cross functions. Think about how to do this

Related to #16

Add two commands:
cget - means code get, a = this.code[d]
cput - means code put, this.code[d] = a

I don't understand why population grows at the beginning and degrades later till the total death. Why good mutations are not fasten.

Есть две TODO в файле Config.js:

// TODO: rename all molecules related names to prefix "mol".
// TODO: do we really can change all non constants in real time? codeRegs, codeLuca, worldZoomSpeed,...

Нужно глянуть на остальные свойства и переделать из в константы, если они не могут меняться в процессе работы программы.

Сейчас размер мира ограничен размером канваса. Он в свою очередь имеет максимальный размер - 32767 точек. Но в реальности при работе с размером больше чем 1920x1080 невозможно, так как все слишком тормозит. Чтобы хранить все точки канваса, нужно создать массив WIDTH * HEIGHT * 4. А это значительный перерасход памяти, которой у нас мало. Моя идея состоит в том, чтобы размер канваса был относительно небольшим. К примеру 1024х768, а размер мира был уже очень большой. Я исследовал вопрос с WebGL. Выглядит так, что это возможно отрисовать очень много точек с высоким показателем производительности, но порог вхождения в это слишком сложен. Для данной задачи на много проще использовать пиксельный канвас с возможностью доступа к отдельным точкам и возможностью отрисовки отдельных его областей.
Вот что нужно сделать:

• Размер мира должен быть очень большим. Например 1920*16 x 1080*16. При этом размер канваса не больше 1920 x 1080. Он как бы будет окном в этот большой мир.
• Пользователь может приближать мир (за это сейчас отвечает panzoom библиотека). Отдаление мира происходит до определенного минимума (сейчас это 100% от размера канваса). Далее, пользователь может только скролить канвас во все 4 стороны.
• Шаг для скрола задается в конфиге Config.worldScrollValue.
• Было бы классно сделать чтобы при увеличении области видимости канваса (когда в канвас влазит больше мира) можно было докрутить до максимума, так, чтобы пользователь видел весь мир в канвасе (не страшно, что это будет с потерями)
• Можно подумать про маленькое превью справа-вверху с уменьшенной полной картой, как в играх.

Commands:

• call - goes to function d % amountOfFunctions. Any d should call real function.
• func - function begin operator. All registers should be pushed into stack before it's call. Function name is an index/position of it in a code.
• ret - returns to the line after call. All registers should be popped from stack. d value should be set from the function.
• end - function finish operator. If there is no ret operator inside, then all registers should be popped back. In case of ret d register sets to returned value. If there is no fend operator, then end of script is the end.

This is gloal problem of such optimization methods like GA. in case of stuck in local minima we have to remove 30% of population and add randmly generated organisms.

Is it steel actual?

We have to use Typed array instead common Array() type. They are faster 10x times. Related to #1

Эта ссылка описывает как можно сгенерировать различные поверхности с помощью всего одной функции Перлина. Нам нужно получить лед, горы, землю, море, радиационные области и вулканы. Возможно еще что-то. Основная идея здесь следующая - находясь на каком-то элементе, организм испытывает его влияние. Например, находясь на верхушке горы, во льду, его инструкции будут выполняться медленнее (за один проход их выполнится меньше), что увеличит его продолжительность жизни, но уменьшит ее скорость.
Вот какие параметры организма могут изменяться в зависимости от поверхности:

• количество затрачиваемой энергии
• скорость старения
• скорость движения
• скорость мутаций
• количество выполняемых инструкций за итерацию
• количество помех в команде see (вплоть до полного ее отказа. тогда она всегда возвращает 0)
• что еще?

Вот список поверхностей и их действий на организм

• лед - количество выполняемых за одну итерацию команд должно соответствовать высоте. Оно должно быть ниже, чем в горах. Скорость старения должна быть тоже замедлена. Движение должно быть тоже замедленно.
• горы - так же, как лед, но чуть меньше.
• земля - самая благоприятная. высокая скорость, минимальная трата энергии, жизни и старения. минимальная скорость мутаций.
• вода - минимальная скорость движения, трата энергии повышена, скорость мутаций обычная, повышенные помехи в команде see.
• вулкан - максимум забирания энергии, замедленное движение
• радиация - увеличенное количество мутаций

Сейчас для одной точки в мире мы храним 32 битное число в массиве World._data. 23 бита было бы вполне достаточно для хранения 8388608 организмов и столько же для вспомогательной информации (например типа поверхности).

Use jasmine to cover classes:

• VM
• BioVM
• Mutations
• Organism
• Canvas
• World

At least we have to support:

• water
• lava
• sand
• holes
• energy
• stones
• poison

They should move to randomly slected points (many) in a world. If some percent of dots (block) are not moving then random point should be changed. Because it will have many points, we will have many areas with different surfaces.
Config for one surface:

• color (%16 should be index to surface)
• barrier (can go through or not)
• energy (decrease of energy if organism above this type of surface)
• step (percent of step 0...1 if organism above this type of surface)
• radiation (percent of radiation, which is applied to organism if it steps on this surface)
• delay (surface delay between steps)
• amount (amount of dots for this surface)
• dirs (amount of random directions for surface moving)
• scan (amount of pixel processes by one time of running Surface.move() method)
• dirUpdate (Amount of movements after which random direction will be changed)

Amount of all surfaces dots should not be greater then amount of dots in a world. Think about configs for mutations and age.

Here is a simple algorithm:
Just go through all dots in a world and move them to dirx, diry. This is how we remove all Surface arrays. Maybe merge Energy and Surface classes.

Добавить сохранение и загрузку состояния всех элементов мира в бэкап. Должны сохраняться: все точки мира, организмы, молекулы, конфиг,...

This is how agent may move objects

Перечитать всю документацию и обновить ее. Она устарела. Там нет новой архитектуры связанной с энергией, размером мира, количеством организмов, поверхностей и шума Перлина.

Добавить в этот плагин такие новшества:

• Добавить соединение молекул. Если они рядом, то могут скрепиться
• В зависимости от того в какой точке Перлина находится молекула нужно чтобы распад или соединение происходили быстрее или медленнее. Нужно чтобы было образное равновесие между 3 уровнями (лава, песок, земля) и другими тремя (море, лед, горы). В первой тройке молекулы разлогаются (лава - быстрее, земля - медленнее), во второй - объединяются (лед - медленнее, горы - быстрее).
• распад молекул должен держать их вместе (сейчас они рассасываются достаточно далеко). Нужно делать маленькие кучки.

Every organism birth/clone should be stored in indexedDB. This is how we may create phylogenetic tree of entire population. irma should only store these data (only write to DB). Reading and graph creation should be implemented in a separate app - irma-tree.

Нужно изменить дизайн языка. Сейчас, мы используем два регистра ax и bx. И с ними работают все операторы языка. Программировать на таком языке достаточно сложно по той причине, что в один момент мы можем оперировать только двумя переменными. Обычно, задачи требуют хранения на много большего количества переменных. В этом случае удобной будет идея языка, похожего на машину Тюринга. Похожая идея реализована в языке slash-a. То есть, у нас будет одномерный массив 32 битных чисел в памяти (свой для каждого организма) и указатель на одну ячейку. Регистры ax и bx как и раньше будут жить отдельно от памяти. Регистр ret как и дальше будет временным и хранится в org.ret. Размер памяти задается в Config.orgMaxMemSize. Память должна быть круговой. Добавятся два новых оператора save и load. Они будут сохранять ax в ячейку памяти, на которую указывает указатель в момент сохранения. Сохранение и запись в регистры никак не влияет на состояние памяти. Таким образом можно будет хранить много значений одновременно без перетирания регистров.
Изменения:

• регистры ax и bx остаются, как и раньше отдельно от памяти
• регистр ret остается как и раньше
• добавляются новые команды: left, right - для сдвига указателя памяти влево и вправо на 1 ячейку
• Логика связанная с org.regs должна исчезнуть, как и команда shift
• убрать команды pop и push
• добавить команды save и load для записи, загрузки значений из памяти в регистры и обратно
• покрыть это тестами

Эта ссылка описывает как можно сгенерировать различные поверхности с помощью всего одной функции Перлина. Нам нужно получить что-то похожее и тоже с формой архипелага. А именно: вода, суша, пустыня, горы, лед, вулканы. Основная идея здесь следующая - находясь на каком-то элементе, организм испытывает его влияние на каждой итерации. Например, находясь во льду, его инструкции будут выполняться медленнее (за один проход их выполнится меньше), что увеличит его продолжительность жизни, но уменьшит скорость ее течения. Должны быть области, где жить наиболее выгодно и те, где жить очень сложно. В конфигурации должен быть раздел surfaces с массивом поверхностей и значениями коэффициентов для траты энергии, скорости старения, скорости выполнения команд и т.д.

Список новшеств:

• Нужно чтобы мир рисовался слоями: сначала поверхность, потом организмы и молекулы
• Все поверхности должны быть динамическими (конфиг - со скоростью изменения). Это можно сделать введя параметр времени в функцию Перлина.
• Поверхности должны быть закешированы в одномерном массиве мира, состоящем из 6 битных (тип поверхности) + 26 битных значений (индекс организма/молекулы). Кеш обновляется тогда, когда изменяется параметр времени и пересчитывается весь кеш (должно быть редко). Сейчас это массив World._data.

Дополнительную информацию для размышления можно взять отсюда и отсюда.

Вот какие параметры организма могут изменяться в зависимости от поверхности:

• количество затрачиваемой энергии (равен коэффициенту из конфигурации). Энергия уменьшается каждую итерацию.
• скорость старения (подумать над этим)
• скорость движения (сколько выполнится операторов step перед тем, как произойдет сдвиг на 1 пиксель)
• количество мутаций
• количество выполняемых инструкций за итерацию (по сути - приоритет)
• количество помех в команде see (вплоть до полного ее отказа. тогда она всегда возвращает 0. Зависит от освещенности. связано с #33)
• количество помех в команде listen, вплоть до ее отказа
• скорость поедания (join). Сколько команд выполняется до фактического присоединения молекулы

Продумать этот список
Вот список поверхностей и их действий на организм

• вода - меньше скорость движения, трата энергии повышена, повышенные помехи в команде listen, замедленное выполнение инструкций
• земля - самая благоприятная. высокая скорость, минимальная трата энергии, жизни и старения. минимальная скорость мутаций.
• пустыня
• горы - так же, как лед, но чуть меньше.
• лед - замедленное выполнение инструкций должно соответствовать высоте. Оно должно быть ниже, чем в горах. Скорость старения должна быть тоже замедлена. Движение должно быть тоже замедленно.
• вулкан - максимум забирания энергии, замедленное движение. увеличенное количество мутаций

Реализация этого таска сложная. По этому, нужно разбить ее на этапы:

• сделать отрисовку поверхностей и занесение ее в массив мира с учётом битности
• последовательно реализововать трату энергии, замедление/ускорение выполнения кода, ухудшения видимости, слышимости и т.д. Каждый из этих пунктов влечёт за собой изменение одной или нескольких команд. Они и могут быть отдельными тасками.

var inc = 0;
var simplex = new SimplexNoise(() => inc+=0.12357241),
    canvas = document.getElementById('c'),
    ctx = canvas.getContext('2d'),
    imgdata = ctx.getImageData(0, 0, canvas.width, canvas.height),
    data = imgdata.data,
    t = 0;

var scale    = 160;
var speed    = 1000;
var height   = .8;
var shift    = .3;
var SEA      = [65,105,225];
var GROUND   = [238,214,175];
var FOREST   = [34,139,34];
var SNOW     = [255,250,250];
var ROCKS    = [139,137,137];
var width    = 1000;
var radius   = width / 2 - 10;
var r2       = radius**2;
var radius10 = radius + 10;
var radius90 = r2 * .5;

window.setInterval(() => {
    for (var x = 0; x < width; x++) {
        for (var y = 0; y < width; y++) {
            let red = 1;
            let green = 1;
            let blue = 1;
            let color = SEA;
            const xy2 = (x - radius10)**2 + (y - radius10)**2;
            if (xy2 <= r2) {
                let r = simplex.noise3D(x / scale, y / scale, t / speed) * height + shift;
                r = r * (xy2 > radius90 ? r2 / xy2 - 1 : 1);

                if (r < 0.2) {color = SEA; blue = 1 - r / .2}
                else if (r >= .2 && r < .4) {color = GROUND; red = green = (r / .4) / 4 + 0.75}
                else if (r >= .4 && r < .6) {color = FOREST}
                else if (r >= .6 && r < .8) {color = ROCKS}
                else if (r >= .8) {color = SNOW}
            }

            data[(x + y * width) * 4 + 0] = color[0] * red;
            data[(x + y * width) * 4 + 1] = color[1] * green;
            data[(x + y * width) * 4 + 2] = color[2] * blue;
            data[(x + y * width) * 4 + 3] = 255;
        }
    }
    t++;
    ctx.putImageData(imgdata, 0, 0);
}, 1000/60);

Связано с #28

Related to #2. Energy should be also a surface but during agents eat it, we have to add energy dots back to the world. Total amount of energy (agents + energy) should not be more then orgCloneEnergy.

Organisms should not omit them. They can't go through them. It will be new surface.

Сейчас, когда организм умирает, он просто раскладывается на молекулы. Они разбрасываются по какому-то странному алгоритму. Нужно сделать чтобы это было что-то похожее на "кучку" точек. За разложение отвечает VM._mixAtoms().