General restrictions being followed.
Note: There are 71 usable bits for element instance members, and 32 bits for quarks.
Currently, the event window look-ups are restricted to adjacent sites, sites 1 through 4 as a HW implementation feasibility measure.
The desired requirements for allocation, size management, systems are the following:
- Containing a space with a specified shape
- Able to specify a max allocation
- Separates between different allocation IDs and from unknown elements
- Growth of allocated space tries to fill available space
- Deal gracefully with inconsistencies in shape of available space
- Kill allocation process if unfeasible
Demos:
- [ULAM - Bubble Allocation Demo](https://www.youtube.com/watch?v=diiUx5CkXa4)
- Creates a circle of a max radius if given infinite room
- Allocates using a max radius from a center point
- Locates the centroid of a space if constrained
- Standard allocation on display in github repo.
The chosen bubble allocation process went through multiple development stages. The selection process involved multiple development groups, with Group 4 being chosen. More details in past commits.
Crystalline growth, limited by inconsistencies in available area Initial amorphous growth attempt, unstable Pulsing growth attempt, ran into growth instability, fuse problem Based on group 2, with a logic pass-over to improve stability- Use barriers between nuclei of same ID
- every nucleus/stem have a unique ID separate from type
- transparent barriers form between nuclei of the same type
- allocations will join up together upon death/finalization
- if two of same ID meet, they should merge
- emitters transmit through transparent barriers?
- [ ] Currently, Cytoplasm based distance measuring means internal non-Cytoplasm elements will alter the overall shape of the allocated space
- [ ] Nucleus auto-centering works with simple organizations, current issues:
- Edges of world are preferable to auto-center, going to expect edges to exist for now
The following elements make up the bubble allocation process.
- This element initiates site allocation, by creating Cytoplasm elements, and setting their dist data member.
- Has an ID, that is bestowed on Cytoplasm children.
- The ID is used to separate allocated sites by purpose.
- Two nuclei of differing ID will not merge, and will stay distinct.
- Two nuclei of the same ID will share allocated sites.
- A nucleus will die if it is surrounded by Membrane elements.
- Nuclei currently attempt to auto-center themselves within spaces, see Future Work for progress concerning this.
- Parameters:
- maxDist
- This parameter determines how much space is allocated.
- This element serves as the primary mechanism for size management.
- Keeps track of a distance value, that decrements going outwards from the nucleus, that is used to determine distance.
- The life-cycle of Cytoplasm is strongly connected to the Membrane life-cycle.
- This element represents the boundary of allocated space.
- This element forms as Cytoplasm elements contact unknown elements, Cytoplasm of a differing ID, or the max allocation range.
- Creates straight path of a given max width and length if given infinite room
- Goal is the allocation of a path of a minimum width
- Allocations from an edge outwards using a max width and max length
- Ideally, will bend to use up available space
Below are proposed development directions that this allocation can be accomplished by.
- Build layer by layer by active edge
- The edge being built changes from cycle to cycle based on open sites
- Using multiple bubble allocations
- The centers of each bubble allocation form the path
- Could have a distance restriction from previous bubble
- While trying to separate self from other bubbles
- Retracts if previous bubble moves too far away
- Use transparent barriers and exciters to track nuclei separation
- Variables
- N
- number of bubbles
- W
- Width of path
- Path length ~ W(N/4 + 1/2)
- Bubble radius ~ W/2
- Bubble separation ~ W/4
- Have forward edge handle collision and bending?
- A chain element goes out with a priority directions.
- There are ‘bristles’ on either side that detect the distance to an obstacle
- And it turns based on the distances measured on either side
- If the minimum distance is ever met, than the chain element will die
- Will marking its direction as bad in its parent chain
- If chain under min chain length, then it will retract and try again, making different direction choices
- In this way, the chain will crawl backwards when a link dies
- Hopefully finding a more optimal path
- Could optimize by increasing amount of info kept about bad paths
- Variables
- Priority Direction
- Min bristle distance
- Max bristle distance
- Max chain length
- Min chain length
- Bad Direction [4]
- Pointing Priority
- if d < Max
- Turn Away onto not bad non-priority direction
- elif d < Min
- Die and mark as bad
- else
- Keep Straight
- if d < Max
- Else
- if d < Max
- Go current direction
- elif d < Min
- Die and mark as bad
- else
- Return to priority direction
- if d < Max
Only detects adjacent sites to chain, will detect non-adjacent chains and obstacles
Modify detection to be half of width, using new bristle elements Base on bubble centering logic
Detect bristles from previous chains so the path will maximize turning radius and reduce bristle overlap
Add in logic and more data to allow for path assumptions to reduce dead-end path attempts
Not yet implemented
The following are the requirements for organization:
- Relative addressing levels
- Absolute addressing is not possible
- Perform some kind of life-cycle management
- Current Levels include:
- Organ Layer
- Lobe Layer
- Leaf Layer
This forms the general organization of an organ. A hierarchical loop, where a central loop has a controlled distribution of contents. This distribution is then propagated through adjoining loops, indirectly.
Higher throughput than a melange, more directed. Encapsulation of functionality. Protect information better?
- Bubble allocation
- Variables
- Max Radius
- Organ ID
- determine leave/stem IDs
- Path allocation
- Variables
- base width
- max length
- Path allocation
- Variables
- Base width
- max length
- Stem ID
- Determines filters
- Hierarchical loop top-level
- Primary address level
- Has an allocation bubble
- Basic I/O ports
- Central kernel/node
- Connects to lobes and I/O
- Lobes have width, determines leaf height
- Coil out into available space
- Fit as many as possible with given width
- Grow within lobe wall
- Circulated through system and embed where there is open space
- simple loop
- has base width
- stem forms center
- Filters grow from stars
- perform data processing
- Could be similar
- Has base width
- Pushes into growth medium
- Stem path is important part of lobe growth
- leaves can cross lobe boundaries
- both could embed and grow?
- Organ stem exists
- Performs bubble allocation
- stem -> kernel
- Grows I/O lines
- Kernel inserts lobe stems
- Kernel inserts leave stems
- Open for business
- Homeostasis
- Lobe stem exists
- embed self in kernel wall
- perform noodle allocation
- Homeostasis
- Leaf stem exists
- Embeds self in lobe wall
- Performs noodle allocation
- Grows filters
- Homeostasis
- Die if allocation issues found
- Stem cells in permanent allocation, constant circulation
- Promotes regrowth of failed leaves and lobes
- If leave type missing or in short supply, cull population and replace
- Determine percentage of each
- Dynamically handle % based on input
- starving leaves w/constant stem circulation?
- Dynamic regulation of stems in kernel
- Kernel has a circular flow
- I/O have straight flow
Gates change addressing levels? Could leaf data only be valid within organs? Needing a special conversion to be viable on the organ addressing level?
- Organ ID based
- Organ Gate
- White-list data
- Kernel Gate
- White list data
- Organ Gate
- Leaf ID Based
- Leaf Gate
- White-list data
- Leaf Gate
- Dynamic
- Lobe Gate
- Dynamically white-list based on contained leaf IDs
- Lobe Gate
- Input data
- Output data
- Leaf ID distribution
- Allocation size
- Lobe width and length
- Input data
- Filters -> Output Data
- Width and Length
Organs contain a mixture of operator elements. Much simpler structure than Hierarchical loop organization. Operator elements organize themselves into stratification, move around depending upon if they have available input elements.
Routing would be to an organ ID first than an operator.
Simple
Should only move when seeing data? Try to organize based on certain ideas?
A collection of miscellaneous unorganized notes.
- Need multiple observes of input
- Able to recover and not spoil whole calculation process by a single bad calculation
- Single missing data element should not be an issue
- Like human
- T-cells
- Macro-phages
- Like Ecosystem
- Rot and decay
- Multiple levels of decay, chewing and then breakdown
- Each processor is a pointer to the law if physics
- Law of physics will need to be distributed in some fashion, maybe N processors per program memory
- Law of physics are compiled code and each processors element is decided by what line (program counter) the element has
Organs regenerate insides If organ dies, takes too much damage to regenerate , it’s not rebuilt and organism will die
- Shoot ?Egg? Into system, spawns organs which lead to organism
- Entered from edge of tile
- could fail, in that case shoot another egg in
Have some way of telling if tile organism has died or failed to gestate? Maybe a poison to clean up tile of partially developed organisms Or so simply power cycle tile
Organ
- Think standard library
- queue, stack, sort, I/O interface
Organism
- Appliance (Toaster, Soda Machine)
- control system
- when to know to heal??
- error produce hormone, that at certain density leads to death?
- Could use medium distance field to guide a growing tendril
- Goal would be to connect to a specific organ
- Once connected, could be used for high throughput routing of info to that organ
- if cut, could regrow
Think about spatial travel
- Train for long range
- trucks mid range
- walk short range (walking and diffusion)
Data storage
- Could have special data storage elements
- think barrels that you can load up on trains or trucks
What makes a destination unique? Why travel ?
- Certain spatial locations are required for I/O and devices in general
- need to make it to edges for I/O
- what about processing ?
- Perhaps major pathways exist and forks have road-signs saying what is which direction, and distance
- Road-signs update periodically when they see still-alive signals?
- Road signs communicate with one another about what they say
How to add/remove data within reason if stuff can go wrong?