Reality - Version 0.1

What are afflates? Leaves? OK
:evilfun:

I guess you could say they are leaves - leaves are made of the the same stuff we are studying - just that god has them pre-packaged for us already. Leaves decay to become part of the universe that we imagine they come from. In fact they never became separate from the universe - it is just an illusion.

James wrote: The field, although still rustling about, will be smoother, more like a shifting cloud.

I still do not quite understand what you are saying here.

I am going to average between afflates surrounding the point chosen for study.

:-k

The decrease could be determined through interpolating next points from two previous points and two previously averaged points.

4.25 - 4.24 will lead to 4.23

4.21 - 4.18 will lead to via the following

4.24 - 4.23 - 4.21 - 4.18 to 4.14 because the drop has been decreasing one at a time.

Then the same could be done from another point in the field that is approaching the point that we just studied.

We would need at least 6 points in 3 dimensions from guessing.

The method could be fixed around the vector of the afflate’s travel.

In case you were serious, an afflate is an “affectance oblate” representing a minuscule portion of space-stuff, “affectance”. With millions of random afflates zipping about, the effects of actual physical space, energy, and mass can be emulated.

I’m not sure that I am following you, so let me try to explain one way of doing this, from which you can deviate as you wish.

1. Always the first thing to do is to form a list of nearby afflates to the point-of-interest,
afNearList.n, where n has a value from 0 to 10000. At the center of a particle, n gets huge even though in free space, n might be merely 2 or 3.

2. Calculate the distance between the point of interest, Poi, and each afflate center in the afNearList as explained before;

3. Use the assigned radius of each afflate to allow for afflate size to affect afflate nearness;
afNearList.n.d -= afNearList.n.r

4. Fill in the effective afflate density values for each afNeaList.n assuming a linear gradient . This is the “fuzzy” part of each afflate. In more developed versions, this gradient should be assigned a random value for each afflate;
If afNearList.n.d =< 0;
[list]afNearList.n.e = afNeaList.n.density
If afNearList.n.d > 0;
afNearList.n.e = afNearList.n.density - afNearList.n.d
If afNearList.n.e =< 0;
afNearList.n.e = 0, having no affect upon the point of interest.[/list:u]

5. SUM the effective density values into the point-of-interest ambient total. As density has an upper limit of 1, a simple sum will not due. We are adding noise to noise;

6. Display all points of interest densities (the ambient field).

7. Increment each afflate in accord with its velocity (at the moment, always = 1);

8. Repeat 1-8

After that is working properly, we allow the ambient density to affect the velocity, size, and density of each afflate. At that point, if the average random density is set too high, clumps will begin to form as traffic jams emerge. But there are still other engagement rules required in order to have true particle formation.

James

So that looks like a proximity calculation to me for each afflate within range of the point of interest - I can see why you were not following me.

I was talking about splitting the calculation up by interpolating points around the point of interest - effectively performing a compression of sorts.

  1. Get every second point around the point of interest.
  2. Interpolate every other point around the point of interest.
  3. Calculate for density with interpolation.

Don’t be too concerned about what I am saying because I am following the mathematics you presented in your last post - I am only trying to save on cycle time so that we can study larger fields. You did recommend that we study smaller fields so I am going to stick with what you are saying for the time being.

Yes, “proximity” is the right word. The afflates have no association with each other except where they overlap. There should be no implied interpolation between them. They are each headed in their own direction. They each have their own affect upon what they run across. There is nothing between afflates other than more afflates each headed in its own direction. Ideally there are an infinity of singly directed, independent afflates at every point in space. Other than additive interference, they have nothing to do with each other.

The interpolation that I speak of is different to how you are perceiving what I am saying - we are getting side tracked here, however we can double the resolution for the same cost. Such proximity and density calculations are not entirely unknown to me James and some are very expensive to run in code, not that I am worried or in the least concerned about this. Let us remain on topic though. We want a field.

This way is a better way to put it that additive interference is what we are looking at - I knew a long time ago that this part of the project could be brought down to additions and subtractions - the beauty of simple mathematics - this is what reality is doing - simple mathematics - we are the ones who convolute the situation.

Affect upon affect . . . elegant!

James

It feels like there are a few first things to do now - for me the first thing to do is get organized as quickly as possible.

So if this is our primary target then in a nutshell I would say subatomic particles form through a gradient.

It is a lack of organization that is slowing us down - nothing else - aside from I have been busy.

Our documentation is at times sporadic - something I have been trying to solve - I believe I now have a sufficient solution.

The proof for that comes without trying or intention.

All you need to do next is create a routine to fill in afNearList.n for each cubic region Poi or you can skip that and just go ahead and use each afflate as the Poi between each tic.

Actually I think the proof for all of this follows the same line as in the quote.

Too simple - it is similar to what I have.

Actually, we could do both. And that way targeting could be switched around with ease too.

James, I believe the following is key to my understanding of what you mean by field in the first place.

When you say point by point, you are certainly talking about cutting the resolution of the analysis into a pre-chosen set of measurements, much the same as is done with afflates. I am thinking you are referring to visualizing a cubic lattice of a pre-determined unit size.

Anyhow, I will show you my example as soon as I get setup on this new computer system - a matter of installing a few packages.

Yes. Divide the whole metaspace cube into a (perhaps) 40x40x40 block of cubes, each of the 64,000 a “region”. Whenever you move an afflate, un-register it from whatever region that it was in and register it into the region it falls into. Then in order to display the entire field, merely add the afflates for each region together and display each region as a single object.

Afflates are added to a region by:
$$region.x.density = \frac{region.x.density+af.n.density}{1+region.x.density*af.n.density},\quad for;all;n$$
And regional charge polarity (the color):
$$ region.x.polarity = region.x.polarity ;;+;; af.n.polarity,\quad for;all;n$$

That will yield a “cubic display” (low resolution) of a wavering field. Such is not necessary, but will create an interesting visual.

After that, go back to attending to each afflate’s immediate surroundings in order to determine the ambient density for each afflate individually. For that process, a “afNearList.n” (or perhaps “afProximity.n”) must be filled in for each afflate. That process requires a little more finesse.

James

What you are suggesting seems easy enough to do . . .

. . . so what would be next on you list?

Next on the list is to display it.

An array of 100,000 afflates with attributes;
x_location
y_location
z_location
x_vector
y_vector
z_vector
density
polarity
compression
original_size
original_gradient
region

Original values:
x_position = rand() * spaceWidth
y_position = rand() * spaceHeight
z_position = rand() * spaceDepth
x_vector = rand() - 0.5
y_vector = rand() - 0.5
z_vector = sqrt(1 - x_vector^2 - y_vector^2)
density = rand() * intensity
polarity = rand() - 0.5
compression = 0
size = rand() * (spaceWidth/numberOfRegionsX) * 0.5
gradient = rand()
region = x_position + (y_position * numberOfRegionsX) + (z_position * numberOfRegionsX^2)

An array of 64000 regions;

density_accumulation
polarity_sum

Display each region by density_accumulation * polarity_sum on a range from -1, yellow to +1, blue.
For each Afflate;
Step each location by its vector
Compensate for borders
Update afflate region
For each region;
Accumulate densities
Sum polarities
Loop to Display

Adjust intensity for effective display.
Make video
Publish video

James

Between what you just posted and the metabox solution, you seem to have given me the complete solution.

Am I off the mark?

You still have to choose which NearList method you prefer. A link list is faster, but more complicated to organize. A simple search and contrast is easy, but much more CPU intensive.

After that cubic display, returning to calculating from each afflate rather than from each region, there is more to organizing and consider.

Once that is done, the “affects-upon-affects”, “afflate engagement” can begin wherein speed, size, trajectory, and “wind” come into play.

The issue of what I call “ambient wind” is a little interesting because it is opposite to intuitive macro-scale expectations (one of the reasons that Michelson-Morley was invalid). Afflates veer INTO a cross wind, they are not carried with it as a mass particle would be. But that is down the road a bit.

And then passed all of the gravitation, charged particle, and polyparticle demonstrations, there is the issue of flowing charged particles and magnetism, a very complex issue. Then atomic structure and valence bonding, recreating the periodic table from scratch.

All of that is merely the physics. How all of it relates to psychology, sociology, economics and other fields becomes more obvious from the demonstrations and a little explanation.

What follows should be the rationale behind building an emulator . . .
. . . and not just a reason given to begin with that motivates any given person to pursue a course . . .

. . . a course of study involving RM:AO . . .

RM, and more specifically AO, are aimed at gaining a full ontological understanding of “God, Man, Me, and Reality”, beyond Man’s current level. RM:AO is the coup de grâce of the struggle to finally put all of the pieces into a single understanding, to finally see very clearly how and why it ALL works as it does.

The need to see such is only driven by Man’s abuse of himself and all things as he lusts for an impossible and unneeded absolute control. RM:AO reveals what absolutely can and cannot be done, and in principle how to accomplish from the status quo to whatever the goal. Of course such would be very analytical and complex, although still much simpler than modern science would have it. RM:AO is for the very few serious thinkers not blinded by personal passions (pride, ego, fear, hatred,…).

Basically it is an extremely detailed map of principles concerning “how to get along with the universe” derived from “why the universe does what it does”. It reveals the highest level of priority from which grand decisions can be made without losing one’s way or getting lost in doubt or presumption within the maze of methods and moralities.

When fully grasped, it answers with certainty the age old question, “What should I/we do? And Why?” Thus ending unnecessary conflict, struggle, and suffering before it ever begins. Being so extremely comprehensive, RM:AO spews general principles and aphorisms concerning every topic. But unlike that great fiery ball in the sky, it is not merely an intensely bright light, but a floodlight of laser coherent illumination, lighting all terrains whether day or night.

As far as any one individual, each individual must step from where they are and thus have differing needs at different times even if intending the same goal.

Within the noise, there is logic and understanding, a “firmament within the clouds”. And with such understanding arises order and clarity, simplifying the burden upon the mind.

  • Let negative things be fleeting and small.
  • Expect and allow for positive things to accumulate more slowly through give and take within the noise.
  • Filter what comes to you by its relative value to what you are, not that for which you want.
  • Support that which supports you.
  • Match impedance with patience.

The list could go on and on.

There is no end to it. And there is no beginning . . .

The link-list is a much more complicated way to get a list of all afflates within a region, but it is much, much faster than a simple search and much more memory efficient than using discrete lists for region registration. If an extreme number of afflates and regions are to be used, a link-list is strongly advised, avoiding the need for possibly 64 gig of RAM and/or extreme memory and CPU cycle speeds.

If memory serves (might want to check it over), to prepare a link-list requires 4 arrays;

RegionBeginAddr - double-word, Max-region length
RegionEndAddr - double-word, Max-region length
LinkPrior - double-word, Max-afflate length
LinkNext - double-word, Max-afflate length

Each element in each array is initialized thusly:

RegionBeginAddr - null (or 0)
RegionEndAddr - null (or 0)
LinkPrior - BOF
LinkNext - EOF

The idea is to form short chains within the link lists that represent collections of all items (afflates in this case) that reside within each region. A chain is formed by keeping track of beginning, prior, next, and end chain-links as a short connected chain. Each link in each chain is both an afflate number and an array address. Due to the manner in which the chains are maintained, an almost instant access to a complete list of afflates for any chosen region is always available.

Creating Region Chains
During initialization, as each afflate is assigned a location, the xyx location coordinates identify a specific region and the afflate is recorded as a link in the chain associated with that region (note that the AddAfflate module listed below can be used for this purpose). If the region has had no prior assignments, the afflate number becomes the RegionBeginAddr and also the RegionEndAddr for the region’s chain simply by storing the afflate number in the respective arrays and leaving LinkPrior and LinkEnd arrays untouched.

But if there is already a beginning to the region’s chain (RegionBeginAddr is not null), the newly assigned afflate must be linked onto the end of the region’s chain. This is done by obtaining the region’s chain end address from the RegionEndAddr array, which is an afflate number and array address into the LinkNext and LinkPrior arrays, then simply placing the afflate number into the RegionEndAddr address of the LinkNext array (displacing the EOF marker). Then that same afflate number must be stored as the new end address in RegionEndAddr.

Also there will be need to be able to delete from the middle of a chain, so a prior-link afflate number/address must also be stored as each new link is assigned. So after the new afflate displaces the EOF marker in the LinkEnd array, that same array address must be stored into the new afflate number/address of the LinkPrior array. Each afflate number is also an array address which leads to both a prior and a next afflate, which in turn is an address which does the same until the end of the chain.

What this has accomplished so far is to have each afflate within a region provide the next afflate number that is within the region (via LinkNext) until all afflates within the region have been listed. To obtain a list of every afflate within a region, simply find the beginning of the chain and read an afflate number from the LinkNext array, then using it as an address into the same array, read the next afflate number. Continue that until an EOF marker is found as the next afflate number.

Relocating
Once all of the assignments have been made, the emulation clock can begin. For each tic of time passing, all afflates are relocated to the new locations, as dictated by their assigned vector. This requires that each afflate be removed from its prior region and added to its new region (even if it is the same region). To simplify the coding its best to have a “RemoveAff” module and an “AddAff” module, each specifying which afflate and region is involved.

RemoveAff
To remove an afflate from a region’s chain requires that the afflate number be used as an address into the LinkPrior and LinkNext arrays.

  • The afflate’s NextLink number (possibly and EOF) must be placed as the NextLink number at the afflate’s PriorLink address (obtained from the PriorLink array).
  • And the afflate’s PriorLink number (possibly a BOF) must be stored at the afflates NextLink address in the PriorLink array.
  • If the BOF or EOF markers have been moved, store them in their respective region arrays.
  • Decrement a region counter (for later use)

This causes the removed afflate to be skipped over by the links in the chain. The prior-link points to the next link after the removed afflate-link and the next-link points back to before the removed afflate-link. It might be difficult to keep that straight, but once coded, it is very fast and need not be remembered.

AddAfflate
Once each afflate is removed from its prior region’s chain, it must be added to the new region’s chains (perhaps the same region). To add an afflate is the same process as initially forming the chain, simply add the afflate to the end of the region’s chain as before.

  • Find the RegionEndAddr for the region, displace the EOF marker with the new afflate number.
  • Using that afflate as an address, place the new EOF marker into the NextLink array, terminating the chain.
  • Place the former RegionEndAddr into the LinkPrior array.
  • Then replace the RegionEndAddr with the new afflate number as the new end of the chain.
  • Increment a region counter for later use

Once this module is written, it can be used during the original creation of the chains.

As wordy and complex as all of that is, once coded it is extremely fast and efficient, providing for already prepared regional afflate lists for ambient affectance attribute calculations (density, polarity, wind, gradient) and display. With each tic, the ambient region of every afflate must be examined. That can lead to millions of list compilations and then calculations for each tic, especially when more than one region might have to be examined for each of millions of afflates.