I am further stating to create an affectance field, such that it is static with more mass in the center.
“Unwanted artifact”?
The density will produce the specific pattern of motion that you see in the cube. Without it, the motion would be random.
Why on earth would you write assembly code unless you need it to speed up calculations?
There are no forces. Yes, “speed vs Density”, but then also angular trajectory vs gradient.
But one step at a time.
The Ab is the point-by-point ambient density as a result of an amassed affectance. So the speed of each afflate is determined by it relative position to that mass and the combination of its own density and that of the ambient at each point it traverses.
Bad choice of words on my part regarding artifact. You are correct in that a specific pattern of motion is dependent on a specific density.
Of course the density has to evolve into that specific density configuration first.
That is fair James.
Back to the field emulation…
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?
I appreciate the freedom.
Point? That would require some sort of averaging. The word point is throwing me a little.
There are many legit reasons. But yes to avoid the overhead of abstract functions and bad optimization on the part of the compiler writer. Binary operations like adding and subtracting I imagine would be good for building massive fields of affectance.
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.
Seems like the least of your worries.
I doubt it. You’re going to have a lot of calculations involving 1/x, 1/x^2 or 1/x^3 which will take up more of the processing.
I like the way you put that all of that.
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.
Why do you say that?
You are not looking at it the way I am.
You are going to be needing a lot of:
$$dx = Af1.x - x$$ $$dy = Af1.y - y$$ $$dz = Af1.z - z$$
$$d = \sqrt{dx^2 + dy^2 + dz^2}$$
Cause compilers are pretty good and flexible these days. Even the old school coders are abandoning assembler because they don’t get a significant payback any more.
Your big problem is figuring out the fuzzball interactions.
Yeah, obviously. I personally would get a handle on the interaction of a couple (or handful) of fuzzballs before I worried about 200,000 fuzzballs.
Fair enough.
I do have an idea but for the life of me I can not seem to get it into words at the moment - my head is in the coding. I will code some interactions up then explain them. I have to go with my gut I think - if I get into trouble perhaps you can point out why.
Plus you put me off phyllo 
just messin with ya.
What does this notation mean?