Spin Path Generator

As a Spin Path Generator, isn't Nevyn just trying to show the spin paths?

I don't think of it as a BPhoton with 40 individual velocities. I think of it in layers, or levels. Each spin level has a tangential velocity. Each level is kind of an entity in its own right. It is based on mass distribution. A spin level distributes the mass that it is spinning into a larger volume of space. With a tangential velocity of c, it acts like an entity that inhabits that volume. That entity can now be given another end-over-end spin with a collision in the right place and direction because the volume of space is not a sphere but a torus-like object. This creates a difference in balance among the dimensions. The spin axis dimension reacts to force applied along it more easily than the other 2 dimensions. This is caused by those other 2 dimensions containing all of the motion, or potential force, of this spin level.

Airman wrote:
Ok, another question just hanging there in the breeze. We know that charged particles usually gain or lose outermost spin motions. How can the BPhoton shown in Spin Gen protect its innermost spins while sustaining rates of random collisions throughout its path? I already know the answer, it cannot;

A particle doesn't need to maintain that path while in collision. SpinGen only shows you what it would do without interference of any kind.

The outer spin is the most likely to take any force but I assume that it is possible for the right collision to affect spins just under the top one. What happens in this circumstance, I don't know. I suspect that all spins above it will soon collapse. It isn't a theory ender.

Airman wrote:Include photons!

SpinGen is designed to show you a photon, or electron or proton. It can't show a nectron or neutron yet. To be technical, it can't actually show you a photon because that would require a linear velocity. I'm still thinking about how to incorporate that into the mix.

I got a bit side-tracked on another project over the weekend, but I have now updated SpinGen to use higher axial spins on the Y axis and I have also updated the Iterations slider to use more friendly values.

I made a quick attempt at formatting the number of spin levels depending on whether the higher axial spin checkbox is selected or not and it didn't work. I'll have to think about it a bit more than the 10 minutes I gave it.

Have you shown this to Miles yet? Or were you refining it further? It seems like something he'd be pretty interested in, unless you forget to include the genealogy or something in your email.

I already know what Miles will say: "You need linear velocity to show photons.".

.
Jared wrote (speaking to Nevyn). I think your argument against higher axial spins is about as strong as it needs to get. I can't find or form a collision that might cause such a spin, in my collision sims.
Airman. We all agree, neither Nevyn’s Spin apps nor, apparently, Jared’s own collision sims, show how higher axial spins can form. Nevyn (please correct me if I’m wrong) is therefore convinced higher axial spins do not exist. Jared seems to agree.

I must disagree. Electrons and protons give all indications of being spherical. If Spin apps show that higher axial spin don’t exist, the problem may in fact lie with the Spin apps model. We should all recognize the fact that the Spin apps do not include charge. Given that omission, there is insufficient basis to claim the Spin apps shows higher spin level particles.

Jared wrote. As a Spin Path Generator, isn't Nevyn just trying to show the spin paths?
Airman. I haven't seen the program code, I’d say the spin path most closely resembles a set of outside radius positions, which show the tangential light speed charged particle surface boundary limits given the sampling of up to each of the other 40+ simultaneous end-over-end spin motion light speed radius doublings. Whatever it shows, whether it’s considered a complete and valid model or not, the spin path has been treated as a physical model, enough so that it is taken as proof of the non-existence of higher axial spins. After a great deal of time and effort spent considering this subject - as we all have - it no longer makes any sense to me to suggest that a single BPhoton can span all a particle’s spin levels or form a higher spin level charged particle’s surface.

Nevyn wrote. I don't think of it as a BPhoton with 40 individual velocities. I think of it in layers, or levels. Each spin level has a tangential velocity. Each level is kind of an entity in its own right. It is based on mass distribution. A spin level distributes the mass that it is spinning into a larger volume of space. With a tangential velocity of c, it acts like an entity that inhabits that volume. That entity can now be given another end-over-end spin with a collision in the right place and direction because the volume of space is not a sphere but a torus-like object. This creates a difference in balance among the dimensions. The spin axis dimension reacts to force applied along it more easily than the other 2 dimensions. This is caused by those other 2 dimensions containing all of the motion, or potential force, of this spin level.
Airman. It’s true, those motions exist. It is not true to describe those motions as a BPhoton. A BPhoton is present with the first end-over-end motion, each higher spin level created will be beyond the BPhoton’s influence. The BPhoton position may indeed trace out a path in time, but I don’t believe it would remain at the particle surface boundary as shown by SpinGen.

Discussion of mass distribution and balance cannot replace missing charge. How do photons move through the spins? What are the charge mechanics? I could easily believe the original BPhoton is the first photon recycled through the first end-over-end spin particle.
 
Nevyn wrote. A particle doesn't need to maintain that path while in collision. SpinGen only shows you what it would do without interference of any kind.
Airman. The actual particle may experience a fairly constant interference while maintaining its integrity. Of course there is no interference in SpinGen because there isn’t any charge included. Instead of charge, the Spin apps add up to 40 separate motions. I do not believe those motions represent any possible single BPhoton, nor could a single BPhoton define all but the first end-over-end higher spin particle’s surface boundary. Photons entrained or recycling through the spin loops is what must form the particle’s surface. Recycling photons far outnumber the BPhoton, and are present in many more locations. Entrained or recycling charge must be part the largest part of what forms the particle’s “surface”.

Nevyn wrote. The outer spin is the most likely to take any force but I assume that it is possible for the right collision to affect spins just under the top one. What happens in this circumstance, I don't know. I suspect that all spins above it will soon collapse. It isn't a theory ender.

Airman wrote. Include photons!

Nevyn wrote. SpinGen is designed to show you a photon, or electron or proton. It can't show a nectron or neutron yet. To be technical, it can't actually show you a photon because that would require a linear velocity. I'm still thinking about how to incorporate that into the mix.
Airman. I don’t know what you mean by adding linear velocity. I would start by assuming the BPhoton (X1 spin) is acting like a spinner in a blender. Just add photons. In any case, I’ve always provided plenty of positive attention and feedback, happy to work at improving our collective understanding or efforts. With all due respect to your best design intentions, one cannot plausibly claim to model an electron or proton without including charge.  

My Boids app is a real attempt at forming an alternative model, with pool hall collisions between individual particles. If we each had our own set of spinning particles and spin loops to play with, a more complete model of the charged particle may be developed. By the way, it’s been about a month, you haven’t mentioned seeing it run yet. 
.

I do humbly apologize for not spending more time with Boids. You got me back into programming again and I keep getting side-tracked on other things. First SpinGen, since we were discussing similar things in another thread, and then I got excited about a little idea someone at work gave me. Although it only took me a day to solve their problem, it then gave me ideas on how to do something else, closely related.

I've spent the last 2 weeks working on it and have created a way to implement very complex problems into much simpler solutions. It's all based around multi-threaded programming and it is very powerful with very simple constructs since most of the code is generated at runtime. Hooking everything together is a problem in highly parallel systems and my framework takes care of that for you. Anyway, you're probably not interested in that, but I'm pretty excited about it.

SpinSim, SpinGen, AtomicViewer, Relativity and Expansion are my attempts to model Miles work in the way that I understand it. I build them to understand it. They may be wrong. They may be partially right. They may, however unlikely, be completely correct. I don't build them to be correct. I build them to reflect my understanding and to test ideas about it. I build them so that I can see how things move or interact or even just how they look.

SpinSim, and now SpinGen, implements a stacked spin model in the only way that I can see it working. I think it closely reflects what Miles has written about it. It certainly matches the animation he has supplied but since I go so much further than that animation, I don't have anything else to go on, other than the words themselves. I have extrapolated up from that in logical ways, so I am confident in that model.

Airman wrote:
I must disagree. Electrons and protons give all indications of being spherical. If Spin apps show that higher axial spin don’t exist, the problem may in fact lie with the Spin apps model. We should all recognize the fact that the Spin apps do not include charge. Given that omission, there is insufficient basis to claim the Spin apps shows higher spin level particles.

I have implemented higher axial spins and shown you images of it, and they are not spherical. Nothing above the BPhoton itself is going to be spherical in a stacked spin model. The rules don't allow it. But you have to ask how it is that we think that an electron is spherical. What tests have been done to determine this and how have they been interpreted? I must say that I don't know. I haven't put in the research to find out. It does have great significance though, for they could be rotating the electron around as they test from different directions because the electron re-aligns to the charge field that they are supplying.

There is no correlation between implementing charge emission and whether higher axial spins exist. Charge emission will happen with or without higher axial spins and we need higher axial spins way before we get to charge emission. That is, we need to think about higher axial spins with just 5 spin levels but we don't need to think about charge emission until above 14ish. There is also nothing about charge emission that requires a spherical source. In fact, I would say that it is much harder to explain equatorial emission with a spherical source. What makes it equatorial?

SpinSim/Gen is not trying to show charged particles. AtomicViewer does a better job of that. SpinGen is just showing stacked spin motion with no linear velocity. SpinSim can show the linear velocity as well. But that has no bearing on whether higher axial spins exist. The problem is how do you implement them and remain consistent with the rules of stacked spins? I have implemented them by attempting to break as few rules as possible. But it does still break them.

Airman wrote:
It’s true, those motions exist. It is not true to describe those motions as a BPhoton. A BPhoton is present with the first end-over-end motion, each higher spin level created will be beyond the BPhoton’s influence. The BPhoton position may indeed trace out a path in time, but I don’t believe it would remain at the particle surface boundary as shown by SpinGen.

I wouldn't describe those motions as a BPhoton, I would call it the motion of a BPhoton that defines a particle.

How could the path not remain at the so-called surface? The path defines the surface. The path tells us where we can find the actual BPhoton and any collision with that BPhoton must be on that path. The surface is defined by collisions with the BPhoton so the path and the surface are one and the same. Of course, it is not really a surface but it is the only places that a collision can occur.

I assume that you are a bit shocked by the hollowness of the spin paths. They make a lot more sense when you watch the spin path being generated, like in SpinSim. The motions of the BPhoton are quite natural looking (not suggesting that their motions are natural) and the surface is generated by taking the same general motions with slight differences over time. SpinGen shows that given enough time (or iterations) it will cover enough positions to look like a real surface. That was actually the purpose of building SpinGen. It took way too long to do that in SpinSim and it couldn't really get to the same number of points recorded.

Airman wrote:
Discussion of mass distribution and balance cannot replace missing charge. How do photons move through the spins? What are the charge mechanics? I could easily believe the original BPhoton is the first photon recycled through the first end-over-end spin particle.

Discussing mass distribution is a way of thinking about how these motions could occur, which was in response to your statements about that in the previous post. They are not about charge emission, although they do become entangled with each other soon enough. Discussing how these motions could actually work is critical to building the stacked spin collision math that is required for a charge emission model that could answer your questions.

Airman wrote:
With all due respect to your best design intentions, one cannot plausibly claim to model an electron or proton without including charge.

Well that depends on how you define an electron or proton. I would say that you can not claim to model a charged particle without including charge. However, is the charge actually part of a proton or electron? Is the charge what makes it what it is? It is what makes a charged particle for we are thinking more about the effects of that charge than the particle it is coming from. An electron or proton will continue to have the same number of spin levels with or without charge around.

So in a definitive sense, I would say that SpinSim/Gen are modelling the motion of a BPhoton that can create various particles. Some of those are the same motions that make an electron or proton.

Airman wrote:Jared wrote. As a Spin Path Generator, isn't Nevyn just trying to show the spin paths?
Airman. I haven't seen the program code, I’d say the spin path most closely resembles a set of outside radius positions, which show the tangential light speed charged particle surface boundary limits given the sampling of up to each of the other 40+ simultaneous end-over-end spin motion light speed radius doublings. Whatever it shows, whether it’s considered a complete and valid model or not, the spin path has been treated as a physical model, enough so that it is taken as proof of the non-existence of higher axial spins. After a great deal of time and effort spent considering this subject - as we all have - it no longer makes any sense to me to suggest that a single BPhoton can span all a particle’s spin levels or form a higher spin level charged particle’s surface.

I think you're kinda losing me here - not in general, but in specific. This is likely just due to the intimacy Nevyn and I have with the spin path topic since we've both been knee-deep in it in our different ways for so long.

That is to say, I agree with Nevyn's responses because they match mine. The spin path shows where the Bphoton would be, where any and all collisions could take place. I know what you meant by saying "we need to include charge", but I disagree - because the spin path is showing the path of charge already. Any incoming photons will (more than likely, as charge averages at the infrared, not the lone, un-spinning Bphoton itself) also have a complex but calculable spin path, you see.

Maybe think of it this way: Imagine a 4-spin photon (infrared) meeting another 4-spin photon. Both will have similar "paths", stretched linearly of course by the linear velocity (which is absent in these diagrams, as we're studying the tangential velocities instead here). So both particles will have these "spin paths" as nonexistent visual "trails" for us to track their potential collision. They don't have to collide, and there is a very low chance that they will, but given enough charge density some collisions may occur.



Now if we let these two photons move towards each other, its not their spin paths that would collide if a collision occurs, but rather their present, current location at the head of that path. They most likely would miss. Timing would have to be quite exact for any collision tracked this way, and timing an exchange of energy that would cause a new stacked spin even more precise. We're not tracking the subspins here but rather the absolute path, if that makes sense. The subspins define that path, but the path isn't real. It's just a tool to visualize the motions, and hopefully find any issues or problems.

In some of my vids I used motion trails to show this path, some from the outer surface of the Bphoton and some from the inside center point. Again, they're just a tool to help us visualize these motions. Ideally my stacked spin motions would be identical to Nevyn's, assuming of course we're both on the right track. I tend to think he is much more than I am, which is why it's so helpful for his critiques in my previous simulations (and Miles' input as well). I got a lot of things wrong and still am, it's a struggle.

I have made an update to Spin Path Generator that allows you to export all of the coordinates generated from the motions of a BPhoton with various levels of spin. It will create a CSV (Comma Separated Value) file containing 1 point per line. Any spreadsheet application should be able to load a CSV file, but it is just a text file so any text editor can as well.

The generated files can get quite large. With the basic settings, using 1,000,000 iterations, it will create a file that is about 55MB is size.

You can set the name of the file to be generated and also if you want to scale up the values to match those used on screen. This roughly scales the points as if the BPhoton had a radius of 1.



Notice the new Save button that will start the export process. You do not need to have a model generated. It has to regenerate the points for the export anyway.