You can call me crazy but sometimes I do have to argue the very things that I myself do.
I am basing the random distribution on three basic principles.
Calculations In The Code are made on interactions that happen after the initial state. Some thought, has to be put into the interactions that take place, to make sure they can be physically true. Interactions In The Code are self driven after the initial state - that is no further input is required by the initiator.
Analytically there will be numbers to look for and these numbers will result in more mathematics. Interpreting results will come down to looking for these numbers and using tools available to verify the numbers - the numbers are representative of the universe, if they are not then they are not good numbers. The numbers should at times have patterns associated with them or they are not representative of anything.
The more consistency found in the operation of the emulator and physical reality the more that the emulator can be applied to answering questions one might ask.
Static ambient density:
Where {a,b,c} is the center point of the cube. $$Ab = \frac{1 }{(1 + 4\pi((x-a)^2 + (y-b)^2 + (z-c)^2))}$$
I wonder whether this is the only way to achieve this - whatever way is used would still be representative of this.
Ambient density has come from the distribution of fuzzballs. Where else would it come from?
The ambient doesn’t “come from” the “fuzzballs”. The ambient IS the fuzzballs.
The only way to achieve what?
If the whole universe is made of affectance then the ambient density is also fuzz - different fuzzing leads to different affects.
Fuzzballs are conveniently chosen portions of affectance - Ambient density has become differential from the balls not come from the balls.
Ambient density is just an unwanted artifact that is necessary to make contrast.
I appreciate you questioning everything phyllo. I wish there was a thumbs up smiley.
The only way to achieve what?
Oh there is a thumbs up, cool. Achieve static ambient density given the emulator is fundamentally working off discrete principles. Surely there is a way to get closer to the machine is what I am wondering - the end result would be that math.
I’m still lost as to what you are thinking. That formula is for the light scatter simulation. The formula yields a static ambient field density representative of an amassed monoparticle in the center of the cube with no other affectance present. A group of afflates are then to be introduced propagating from one side. As each afflate traverses the mass field, it’s trajectory will be altered.
I knew you would be still lost after I made the post and read it - I am thinking on the fly to see how much of this is internalized hence why I was appreciative of phyllo’s questions. I understand what the formula is for - I was wondering how I could translate it beyond regular code, closer to the machine - assembly code mixed with binary operations.
You are saying to create an amassed monoparticle, in the center of the cube - I am saying the same except I will have other affectance present. Point the afflates at it, as they approach there is going to be “force” between them and the monoparticle, and each other - I imagine some repulsive force is present and momentum to give the slingshot.
Speed versus density? Perhaps.
The repulsion is an illusion.
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.