Reality - Version 0.1

I am starting with a random distribution.

I am basing the random distribution on three basic principles.

The important of design can not be underestimated, for instance we need a random number generator that is actually random - randomness does involve clusters and sparsity as well as a continuum to place clusters and sparsity on - we use milliseconds to initiate the continuum because not one millisecond is ever the same id est milliseconds are forever - once the initiation is complete we get some sparse information and clustered information and if this is not apparent then our randomness is no good but if it is apparent then we are good to go.

There are no personal attacks here . . .

So guys I will finish with this for the time being - nothing I have written was intended as a personal attack. I still want the criticism, suggestions and ideas.

I still want a little debate too . . .

Back to the field emulation…

This freedom is what I want most of all - nobody has to be concerned that I would let the freedom go to my head.

I will say this . . .

I have to go with my gut to a certain extent because I have some ideas that I am certain will work.

I will respond as best I can and if I do not respond to one thing I will guarantee a response to another - at least every second post I will respond to.

Peace!

Lets go again . . .

So lets start another round . . .

:smiley:

Links

Collated Formation
Affectance Transition
Certainty
Regional Affectance Density
Metaspace Principles
Rendering by the Emulator
A new beginning . . .
You are here . . .

1 ► Increase the size of the Meta-Box.
2 ► Double the Afflates processed for the larger Meta-Box.
3 ► Make some color adjustments(same amount of distinct yellow as distinct blue, with a lot of green between).
4 ► Calculate the ambient density for each individual afflate.
5 ► Toy with Afflate Scatter.
6 ► Calculate the engagement speed for each Afflate.
7 ► Consider all rules of engagement.

Back to the field emulation…

I have put two sentences of my own in here as well as making four edits(for clarity), the rest is written by James . . .

PtA
PtA, Potential-to-Affect, refers to a physical situation, an arrangement of substance, not the substance itself. Space is similar in that regard. As PtA changes, it becomes the physical substance called “affectance”. And PtA is always undergoing changes, being affected as it affects. Affectance is the changing of the PtA situation. Affectance is the changing whereas PtA is the arrangement of the changing that is itself being changed. It is easiest to think of PtA as an electric field and affectance as a electromagnetic wave (EMR). An electric field is merely a situation, not a substance. And an electromagnetic wave is an electric field that is changing.

The physical affects the physical and the meta affects the meta. And at times, they are the same thing.

The PtA is the arrangement of affectance being emulated and Afflates are just a chosen portion of affectance to study during the emulation . . .

Ambient Density
The next concern is choosing how you are going to calculate the ambient density for each individual afflate. It might be interesting to display a point by point averaged affectance density so as to get a better feel for the actual field rather than watching racing afflates. The field, although still rustling about, will be smoother, more like a shifting cloud.

Again, this is a time when you have some freedom to pick and choose which way you would like to setup the field. You have specific afflate characteristics defined as if they were marbles (not yet “fuzzy”), yet the field has no such hard objects within. So if asked what the field density is as some point, {d,e,f}, precisely how are you going to use the local afflates to determine (to declare) the precise density … at any point chosen?

By “point”, I merely mean a chosen location within the space. And yes, choose a type of averaging that will yield the kind of field you are trying to form (smoother, choppier,…). And you will want to make that a “hook” so that you can play with it later.

A point can be chosen with any resolution I guess, obviously there is more than two “things” involved but points are infinitely small so I could base my average on a small or large selection.

You could, just for example, have a linear decrease in afflate characteristic with distance from surrounding afflates. Or it could be exponential, giving a more choppy effect. I would recommend a very limited local distance for the range of evaluation so as to not consume too much processor time. I had to think for a while to figure a way to quickly evaluate each afflate’s (or location point’s) immediate surrounding. Of course, you are free to choose your own method.

Realize that the afflates do not interact with each other directly. Each afflate interacts with it’s immediate ambient field, which is an indirect association with the combination of the other local afflates. Each afflate interacts with the averaged affect of all local afflates.

  • dx = difference in x values, “differential”.
  • Af1.x = x coordinate of Afflate1 (then Af21.x, Af53.x,…)
  • x = x coordinate of the point of interest.
  • d = distance between point of interest and a local afflate.

Actually, I guess that your notation will be more like, “Af.1.x” or some such.

One could do the simple yet smart thing and just search the entire list of afflates to see which ones are close enough to be concerned with. To save processor search time, I chose to divide the entire cubic space into many cubical regions, 40x40x40 regional cubes. Every time an afflate moved, I recorded which region it was in. Then each region had a list of the only afflates of concern. Then in order to save memory space (perhaps not relevant in your case), I created a set of dynamic link-list functions to prevent wasted space (AddToLinkList, DeleteFromLinkList,…). Each afflate remembers the region. Each region stores an entry point into the link-list for all afflates. The search time turned out to be very quick without wasting memory resource.

Of course going down the link-list, each associated afflate had to be measured for closeness and varied trial formulas were used to decide how much affect each close afflate would have on the average at the point of interest (the afflate under calculation). The size of the afflates is very relevant at this point.

An additional issue is raised when you realize that one cannot merely examine a single region in order to average in all near afflates. Depending on how close the afflate is to a regional border, adjacent regions must also be included in the averaging. Unfortunately that requires the process to be considerably longer. I used a special table to provide quick region adjacency pointers, but the processor still had to go through each adjacent region’s link-list.

The examination of the local region to resolve the ambient affectance took most of the processor time. Once the ambience is resolved (still involving much more than currently discussed), how to move to afflate is very complex, involving the more sophisticated math (trig functions and such), but not terribly time consuming.

Light Photons
Light photons (light bundles of energy) are extremely large puffs of affectance (relative to afflate sizing) traveling in a single direction. Such large groups have to “swim” through the ambient affectance field and thus their speed is dependent upon the density of that field.

A field of absolute zero affectance is not physically possible, but the thought of it allows for a measuring point for “zero density” (absolute nothingness). IF such a zero-field existed, affectance would travel through that zero-field at a particular speed (infinite speed is impossible due to all affects requiring time). A puff of affectance with zero resistance must propagate as fast as any affect can possibly travel. That much is logically required.

A puff of light traveling through an “absolute vacuum” would be the same as an afflate traveling through absolute nothingness. And thus the propagation speed of both would be identical = “the speed of light in an absolute vacuum” = “c0”.

Real light photons can never actually do that and in fact, due to their size, there is always an afflate that is propagating faster than any light photon. But the difference between them is almost immeasurably small. So practically speaking, the speed of light in an absolute vacuum, the speed of an afflate in zero density ambient affectance, and the fastest propagation speed possible are all the same.

Gravitation
I am saying that what we call “gravity” is both physical in every location where it is operating and also “gravity” is a concept at all times. But as stated, there are no “forces”. Gravity is not a force, but rather a “gradient migration” (a migration due to an affectance density gradient).

Gravitating is what particles do when they are in an affectance density gradient (ie. denser gradually becoming less dense or vsvrsa). Particles migrate into the higher affectance density (assuming no polarity is involved).

Gravitation behaves such as to give the appearance of a pulling force. For all practical purposes, it might as well be a pulling force. But what is actually happening has nothing to do with forces pulling or pushing anything. The center point of each particle is merely getting reconstructed a little closer to the more dense affectance field - closer to the other mass.

Okay, obviously aimed at me.

I’m going to take the high road. I’m not going to get into oneupsmanship. I’m not going to claim that my experience and opinions of compiler history is the only way to think. Your experience has been duly noted.

You’re the one doing this project so obviously you can take any approach and use any tools that you want.

Since my presence seems to bother both of you, I’m going to piss off for a while. I will look in, maybe at Xmas, to see your results.

phyllo

I apologize man . . .

Sorry phyllo. Your presence most certainly does not bother me - it was not meant to come across that way - I just wanted the few things inside my head to be shared. This is not my typical way - usually I just back down. I am not trying to one up anyone. You seem to have experience too.

Please don’t piss off on my account man. I appreciate your hard ass attitude.

You have sharpened me up quite a bit.
I just wanted to push back a little.

I found your input to be constructive for me.
Just some things I do not want to get into yet.

I know, I know, I started it . . .

Again, my apologies for being an ass.
And thank you phyllo . . .

:handgestures-thumbupright:

[size=85]UNTAB for footnotes[/size]

Checked one time for errors . . .

Calculating vectors - pre-conceptual!

Afflate ≡ Portion of the affectance field : Let N ≡ Any particular afflate in the array.

With two arrays we are tracking many Afflates - there is a copy of each afflate in each array.

Structure ForBothArrays ; using double-precision(represented by the .d after each variable)* PtA(N).d x(N).d y(N).d z(N).d EndStructure
Speed is one clock cycle(theoretically equating to the speed of light in physical space) represented as a tic.
Angle is randomly preset at the first moment of populating the Afflate - and updated as the “difference” between n & dn where n can be x,y or z.
Currently void of the actual rules of engagement between Afflates.

Each tic, n is assigned the value of dn - during the process of switching the primary(active) array over.

<<<<< >>>>>

We are now ready to add Ambient Density to the array.

[tab]*We are using single-precision in the prototype.[/tab]

Task Completion as it stands today . . .

So I have not adhered completely to the To Do list but I have managed to get quite a bit done.
I have managed to knock three things off of the list and do a little extra.

1 ► Increase the size of the Meta-Box.
I certainly increased the size of the Meta-Box - I have increased it from 120 to 400 units.

2 ► Double the Afflates processed for the larger Meta-Box.
If I remember correctly we were processing 5000 Afflates before and now we are processing over 16000 with the larger Meta-Box. I also increased the minimum and maximum sizes of each Afflate. I am about to post a video. So instead of doubling the afflates processed, I have more than tripled them.

3 ► Make some color adjustments(same amount of distinct yellow as distinct blue, with a lot of green between).
I spent quite a bit of time on color adjustments. I have not finished yet, like everything, it is likely to be a work in progress. I want the colors perfect.

I have also started a new version of the emulator called Prototype two - this is the version where I will be working with some rules of engagement and mapping.
You will notice that the interface has evolved a little ready for the future of analysis as well as other experiments.

Before I post a video I will post an image . . .

The image shows a little more detail, simply because it is larger than the video . . .

The gif video is a little slower to load because I wanted to take 10 seconds this time to show the depth. The afflate being tracked is good old 118 shown in red.
Apologies in advance for the loading speed.

I am going to leave the colors the way they are for the time being so that I can get through the rest of the To Do List.

1 ► Calculate the ambient density for each individual afflate.
2 ► Toy with Afflate Scatter.
3 ► Calculate the engagement speed for each Afflate.
4 ► Consider all rules of engagement.

[tab]Things I will be taking a little bit of spare time with: I have been experimenting with memory and processor routines and I will be continuing along these lines. I will be further experimenting with doubling the Afflates processed for the larger Meta-Box and I will perhaps make the Meta-Box even bigger. I will continue to make more color adjustments over time(with this as my standard: same amount of distinct yellow as distinct blue, with a lot of green between).[/tab]

This was done intentionally to highlight what we are actually looking at . . .

It looks warm in there - I think I need some water.

:laughing:

I think that coloring is fine. Although the afflates seem to be moving pretty slow.

Do realize that when you double the space dimensions, you require 8 times the afflates in order to maintain the same density.

As we proceed, the afflates will shrink in accord with their ambience. As a particle forms, they become less than pixel size near the center. So to maintain a visible field surrounding the particle, a great many afflates are needed. In my case and in order to prevent having to have too many afflates, once afflates near the center of a particle became extremely small and close together, I combined them into a single afflate with the properties of the combination. It was one of those “close enough” shortcuts so spare resources.

I would put next on your ToDo list, an animated visual of the field rather than the afflates. You can use the regions or center of subdivisions of the regions as the points of interest/measure, rather than afflates. The video should come out interesting.

1 ► Animated visual of the field.*
2 ► Calculate the ambient density for each individual afflate.
3 ► Toy with Afflate Scatter.
4 ► Calculate the engagement speed for each Afflate.
5 ► Consider all rules of engagement.

[tab]*Use the regions or center of subdivisions of the regions as the points of interest/measure, rather than afflates. The video will come out interesting.

Things I will be taking a little bit of spare time with: I have been experimenting with memory and processor routines and I will be continuing along these lines. I will be further experimenting with doubling the Afflates processed for the larger Meta-Box and I will perhaps make the Meta-Box even bigger. I will continue to make more color adjustments over time(with this as my standard: same amount of distinct yellow as distinct blue, with a lot of green between).[/tab]

And your (4) should come before your (3). The scatterer uses both speed and refraction concerns - separate issues.

.
Note the difference in afflate speed:

In that clip, average density for the afflates was set pretty low so that the much higher density of the forming particle could be seen more distinctly. Because the average was so low, each afflate was largely unimpeded. The speed of an unimpeded afflate is always 1 tic/toe, but on your screen, you get to choose by how many pixels a “toe” is represented. If the afflate moves too slowly across the screen, it might take a very long render and “sit-and-watch” time before anything interesting begins to happen.

1 ► Animated visual of the field.
2 ► Calculate the ambient density for each individual afflate.
3 ► Calculate the engagement speed for each Afflate.
4 ► Toy with Afflate Scatter.
5 ► Consider all rules of engagement.

An acknowledgement James

I am glad that you are happy with the coloring. The afflates are moving slow, this was mainly performed in order for you to recognize the depth of field Z.
I was going to be talking with you about speed.

Oh, I do realize that. I am glad you bring these things up however, it shows me that we are on the same page.

Right now I have the colors on a spectrum, as you have no doubt recognized - I also have the opacity changing ready for density calculations. I understand what you are saying about the afflates shrinking and we will have to discuss all of this further. We can make the afflates as small as you need them. A great many afflates is what we are going to have - right now we need to work with manageable numbers that can be repeated in larger sets. We can still take some short cuts as long as the emulator is reflective of reality - the numbers that is.

I really like this idea. You have been giving me a lot of useful material lately James, I appreciate it.

Keep it coming James.

:sunglasses: