Spin Path Generator

Page 1 of 2 1, 2  Next

View previous topic View next topic Go down

Spin Path Generator

Post by Nevyn on Mon Nov 27, 2017 8:50 pm

I have created a new application that allows the path of a stacked spin particle to be generated without the need to watch it as the BPhoton moves through that path. While it is still a 3D application and you can rotate the camera around the particle and zoom in/out, what you see is static. The path is generated as a series of points when you press the generate button and does not change until you generate again.

You can have from 2 to 40 spin levels. That is a lot of spins and way above what we need but they are there to play with.

You can enable and disable higher axial spins. The first axial spin is about the Y axis (because the next X spin will translate the BPhoton in the Y dimension) but all higher axial spins are about the Z axis. After some deliberation, I chose the Z axis because that is the only dimension that the new spin axis can go through without touching the spin path of the particle which has a top level Z spin. Interestingly, this does not change the spin boundary all that much but it does change the spin path itself.

On the settings tab called Model, you can set the number of points to record, called Iterations. It defaults to a million points but you can go down to 100 and up to 10 million. It takes a really long time to generate 10 million points with 40 spin levels. Sleep

The other setting on the Model tab is called Unit Time and it allows you to set how much time passes between frames. This can be very useful for a large number of spin levels because the particle gets so big. You can increase the number of iterations but it is usually better to just decrease the resolution by making the unit time larger.

The third tab is called Graphics and this contains a single control that allows you to render the generated points as points or lines. If the resolution is high enough (small unit time) then points look the same as lines because they are so close together. With larger unit time settings, it can be helpful to see them as lines.

You can play with the Spin Path Generator at http://www.nevyns-lab.com/mathis/app/SpinPathGenerator

Enjoy! bounce
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by LongtimeAirman on Mon Nov 27, 2017 11:02 pm

.

Twin aliens ultrasound?

Great job Nevyn. Zooming and rotating about the particle spin level gives a view which exceeds Spin Simulator's. Of course, the two apps match perfectly, please consider including this app within Spin Simulator. It's strange how each spin level resembles the previous. Some kind of nested scaling. How about including an option of showing the superposition of the next lower level (a different color) so that we may see the relationship between consecutive spin levels.

When I returned to smaller levels I remembered to keep scaling - turning the mouse wheel -  until I found the lower lever. I appreciated the fact that the origin marker remained the same across the levels. The sliding bar is a might unwieldy and takes up a long line, typing a number might be easier. Apparent bug, particle spin levels 4 and 5 are the same.
.

LongtimeAirman
Admin

Posts : 633
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Mon Nov 27, 2017 11:30 pm

Spin levels 4 and 5 are the same, if you do not use higher axial spins.

There are 4 spin levels to a spin set: A, X, Y, Z. So spin level 5 is the axial spin of spin set 2. If you don't use higher axial spins then level 5 does nothing. It is a bit confusing but kind of necessary. It allows you to compare the same spin level with and without higher axial spins. I could do some math to figure out the right number of spin levels, but then that number means different things based on the higher axial spin control.

I've been thinking about providing some buttons to zoom to the current particle size because it is easy to get lost. The difference between the smallest and the largest particle is quite staggering. I did have a scale control but it was difficult to use so I removed it for release.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Thu Nov 30, 2017 8:11 pm

I've been thinking about those spin level numbers and how to show that they are different if you use higher axial spins or not.

I thought about showing both values where it currently shows the number of spin levels next to the slider but then it has to be explained and I have to squash that into the control framework I have developed because it is a special case. I am confident that I can make that happen in a generic manner, but it still feels a bit ham-handed at the moment.

I thought about changing the displayed value so that it does reflect whether higher axial spins are used or not but this causes the slider to behave strangely because the user can slide from 4 to 5 (8 to 9, 12 to 13, etc) but there will be no change in the value.

I am leaning towards the 2nd option but am open to any ideas.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by LongtimeAirman on Thu Nov 30, 2017 9:37 pm

What's wrong with using one or two drop-down lists instead. The lists could include comments.


Oh oh, a straight line artifact.

LongtimeAirman
Admin

Posts : 633
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Thu Nov 30, 2017 11:35 pm

The problem is that I need to use the same number for both as the internal math ignores the higher axial spins if told to do so. So the code expects a number, let's say it is 5, and it will always execute 5 operations but that 5th one will be ignored when not using higher axial spins. By ignored I mean that it will have no translation and no rotation applied, so it is silent to the math, as if it didn't exist at all. It ends up as an identity matrix so when it is multiplied with the matrix I am generating, it does nothing and just results in the existing matrix.

Maybe I can write it out to show it. This is an array of 8 spin levels with their spin axis as a value:


[A, X, Y, Z, A, X, Y, Z]


If we are using higher axial spins then that is the exact representation. However, when not using them, the 2nd A is ignored so we actually only have 7 spin levels, not 8, but the user has no way of knowing that. They will think that they are looking at 8 spin levels which should look like this:


[A, X, Y, Z, X, Y, Z, X]


Which is a completely different path to what it is actually generating.

The real problem is that I want to be able to compare using higher axial spins to not using them easily. I want to just check/uncheck the higher axial spins checkbox and regenerate. I don't want to have to adjust the number of spin levels as well. Basically, I want my cake and I want to eat it too. That's why I thought about changing the displayed value rather than the values the user is selecting.

The reason that I wanted to compare the higher axial spins was because I found some interesting results when I tested them. That turned out to be me rotating them about the wrong axis (Y, which is used for the first axial spin) but when I thought about it I changed the higher axial spins to use the Z axis. That still doesn't feel right, but it is the only dimension that allows the spin axis to go through all of the existing spins without touching the spin path. I don't actually think that the Z axis can be used because we are putting an axial spin on Z that already has a top level spin of Z. That would effectively increase the tangential velocity above [b]c/[b]. I just don't see how higher axial spins can be implemented.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Thu Nov 30, 2017 11:38 pm

A straight path? How could that happen? My first thought was that the browser is causing that when you switch away from the webpage tab or to another application. Chrome stops the rendering process when the page goes off screen. Firefox does not. I have seen SpinSim do this for this reason. However, Spin Path Generator (SpinGen?) should not do that because it calculates all of the points and then renders them. I haven't seen it do this myself but I will try to make it happen and see if I can figure out why.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Thu Nov 30, 2017 11:47 pm

Verified!

You have to turn on Line rendering rather than Points, which is the default.

I think what is happening is that the first and last points are being joined by a line. I regenerated, without moving the camera, using Point rendering and that line becomes a gap. I did not expect it to join the end points since I am rendering as a line and not a polygon (which must be closed). I'd say that is a bug in ThreeJS, but I will see if I am causing it (always a possibility).
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Thu Nov 30, 2017 11:54 pm

This is from a ThreeJS tutorial:

ThreeJS wrote:Note that lines are drawn between each consecutive pair of vertices, but not between the first and last (the line is not closed.)

So I consider it a ThreeJS bug at this point but I haven't been able to look over my code yet. However, I am using the same classes that the tutorial does and I am not doing anything fancy.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Fri Dec 01, 2017 12:00 am

I just tried a different number of spin levels and about 1,000,000 iterations and it does not connect those end points. Must be my fault.

I left the same number of spin levels but increased the iterations to 2.77m and it connected those end points again. Might be a problem in how the points array is being populated when there are a lot of points. I break it down into a number of sections to avoid having one big long calculation which would freeze up the page.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Cr6 on Sat Dec 02, 2017 2:11 am

Nicely done as always Nevyn.

Took a bit of time to render but it came through. I don't know if you could put together a little guide, but it may help a few people trying to set the settings. With Javascript iterations at this level, it is just going to take a bit of time

This was on Firefox Quantum 54 with a lame Laptop video card and 8 gigs of Ram.

Cr6
Admin

Posts : 712
Join date : 2014-08-09

View user profile http://milesmathis.the-talk.net

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Sat Dec 02, 2017 4:34 am

Yes, calculation time is a bit of an issue. It actually calculates faster if I don't do anything about it and just run the calculations straight through. However, the page freezes up until it finishes and that is unacceptable. I break it down into smaller sections (maybe 1,000,000 points per section but it lowers it depending on how many spin levels there are), but this actually makes it run slower. It does allow me to show a progress meter though, so that helps a bit.

Unfortunately, all calculations are run through the CPU, not the graphics card. If browsers supported the WebCL standard then I could but they don't, so I can't.

I'll have to look into some sort of guide. I was hoping it would be simple enough that anyone with knowledge of stacked spin could work with it. Probably too much to assume.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Mon Dec 04, 2017 6:52 pm

I have made an attempt at a description of the app and its settings. I would appreciate any feedback you want to give.

Spin Path Generator wrote:
Spin Path Generator

This application can be used to generate the spin path of a BPhoton with up to 40 stacked spins. While the Stacked Spin Motion Simulator allows you to watch the motion of the particle, this application will just generate the path that it covers, given the constraints placed upon it. It is much quicker to calculate the path than it is to watch the particle traverse it. There is much to be learnt by watching the motion as, ultimately, the motion is what matters more than the path it creates. However, sometimes we just want to analyse the paths of various particles to see how they compare with each other.

There are various parameters you can set that will dictate what kind of particle, and how much of it, you will see. These parameters are arranged into tabs. The first tab is called Particle and gives you the ability to set the number of spin levels and whether you want to use higher axial spins or not. The latter parameter requires a bit of understanding as I have a difference of opinion with Miles Mathis, the creator of the stacked spin model, with respect to axial spins. The very first spin must be axial, however, once we start stacking spin levels, I do not see how another axial spin can be formed given that the new spin axis can not go through any existing spins. Any axial spin must go through the center of that which is spinning, therefore, I find it difficult to see how any higher axial spin can exist. Further more, one must ask what axis should the higher axial spin use. Which dimension can be used to spin around that does not go through any existing spins?

I have chosen to use the Z axis for all higher axial spins since a top level spin creates a hole through its center on the axis that it is spinning around. We need to add an axial spin on top of a Z spin so I had to use the Z axis for the next spin level. It seemed the only logical choice, but even that has problems because we are effectively adding motion to the existing top level Z spin which is already spinning about the same axis. Not just the same dimension but the exact same axis. This is exactly the same as increasing the velocity of that Z spin and that is not allowed as it already has a tangential velocity of c.

Even though that is my position on the subject, I am modelling someone else's theory, so I have included the ability to turn them on and off so that I can model both ideas in the same application. You can use this application to get a closer look at stacked spins and determine for yourself if you believe in higher axial spins or not.

There is one caveat with providing this choice of higher axial spins. Whether you use them or not determines how the number of spin levels is used. This is an implementation issue, not an issue with the theory, as my algorithm assumes that the number of spin levels chosen includes higher axial spins and then ignores them if you have turned them off in the settings. This can be confusing as when you have higher axial spins turned off, the number of spin levels is deceiving. It may not actually be the number that you see on screen.

Let's take a conceptual look at stacked spins to get a better feel for why this happens. We start with an axial spin, then we add an X spin on top of that, then a Y spin and finally a Z spin. This gives us 4 spins in the order [A, X, Y, Z]. That is what I call a Spin Set. A collection of 4 Spin Levels in that order. It is important to realise that in reality, they do not need to be in that exact order. The axial spin will be first but the X, Y and Z could be in any order. However, for simplicity, I have mandated that they use that order. It makes it easier to comprehend and discuss, if nothing else.

Now that we have a complete Spin Set, we can continue to add stacked spins. According to Miles we now add another axial spin, then X, Y and Z spins. This gives us 2 Spin Sets: [A, X, Y, Z, A, X, Y, Z]. You can see that the second A spin is a higher axial spin because it is on top of another Spin Level. That is how the number of Spin Levels is interpreted. It will always set things up assuming the use of higher axial spins. To create that list, you need to set the number of spin levels to 8. If you turn on higher axial spins then you will actually get 8 spin levels. However, when you turn them off, you will only get 7 Spin Levels because the second A spin is ingored. The list [A, X, Y, Z, A, X, Y, Z] is created but since the higher axial spin will be ignored, we actually get [A, X, Y, Z, X, Y, Z], which is only 7 levels. I am working on an effective solutions to this.

The next set of options are in a tab called Model. These settings are related to the recording of the path and how it is generated. The first setting is called Iterations and it sets the number of points to be calculated. It defaults to 1,000,000 but it can be varied between 100 and 10,000,000. If you find that the path is too short, which happens we you use many spin levels, then you can increase the number of points to see more of it. However, there is a performance penalty for doing so. The more points you want the more calculations that have to be made and it takes some time for all of that to happen. Therefore, the second setting can be used to change it in a different way. This setting is called Unit Time and it sets the amount of time that passes between consecutive points that are calculated. Increasing this value will also cause a longer path to be generated given the same settings for all other parameters. What it is doing is creating more space between points. If you create a path using the default setting and then create another path with a Unit Time twice the previous, then you are only seeing every second point from that first path. You can think of this parameter as being the resolution of the model. If you go too far though, then the gaps between points become visible. This can be useful but if you want to see the path then you need to look at the next set of options.

In the final parameter set, called Graphics, we only have 1 setting and it is called Geometry. This can be used to set how the points are rendered. The default is to render them as points but you can also render them as lines. This allows you to see the actual path that the particle follows, even when using a low resolution. The default resolution creates points that are very close together and they actually appear as lines without rendering them as such.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by LongtimeAirman on Wed Dec 06, 2017 9:34 pm

.
The spin levels created by Spin Path Generator are fascinating objects; moving one about, zooming in or out, what exactly is it? One finds the answer most readily by viewing Spin Sim, it’s the BPhoton’s path. Any given spin level displays locations briefly occupied by light speed BPhotons, which determine the particle’s surface. I say surface because all particles displayed by the spin applications (aside from A1 in Spin Sim) show an end-over-end spin torus. The BPhoton is always somewhere defining that torus surface, and never within it. Photons pass through the surface unless they happen to collide with the BPhoton.

1. http://www.nevyns-lab.com/science/spin-apps.php On the Stacked Spin page the two applications shown side by side are very similar, but they are in slightly different. I suggest making their formats agree a little more closely by including or not including bullets in both of the two Spin application descriptions.
 
2. Maybe add viewing coordinates or particle rotation options? Mouse orbit controls is confusing and difficult at times – hence the home button. Being able to adjust the viewing angle by user input might be a welcome alternative to just the orbit controls. The graphics tab might include a rotate about axis option that would allow the user to capture motion with a gif application.

3. The moving slide bar doesn’t seem to work for iterations, you may have subdivided the number range properly, but the limited slide positions – not smooth at all - allows for many random appearing digits, no rounded numbers like you’ve provided in the “unit time” slide bar.
 
Reviewing: Spin Path Generator wrote:

* First paragraph, 3rd line, suggest changing “the path that it covers“, to “the particle’s surface created by the BPhoton’s motion”.

** First paragraph, last sentence, “to analyse the paths of various particles to see how they compare with each other”. The “path of the various particles” is confusing, the particles are spin levels, the only thing moving is the BPhoton. Consider changing to “analyze and compare the paths of various particle BPhoton motions”.

It’s my impression, using Spin Path Gen’s iteration number and sampling rate, one can create any number of BPhoton track patterns (displaying points or lines) revealing the particle’s surface. The apps show how a particle’s surface complexity increases as the spin levels increase. One can vary the sampling number and rate, (or rely on the default, thank you), giving the particle surface anything from a rough outline, contour or veil-like appearances, to far denser patterns as one views the particle. Some selections are prettier than others. Those patterns strike me as an artifact of sampling and do not represent any particle variation whatsoever. I’m not sure the pattern would necessarily point to where we may most likely find the BPhoton.

*** Second paragraph, 3rd line. I like the tabs. They may be a bit too close to the “Run”, “Stop”, and “Home” buttons. I expect additional information on the controls, yes that higher axis A spin checkbox; instead, the description veers into the justification of the Spin apps. The theoretical basis of Spin Stacking, including your simulation’s description and explanation should be front and center, not here.

**** Second paragraph, last line. “Which dimension can be used to spin around that does not go through any existing spins? “. I agree that when I apply a vertical tangential collision to a horizontally oriented z-spin, the new axis of rotation goes through the same center of rotation as the z-axis. The two spin axii are orthogonal, and the BPhoton is never at the center point of the two spin axii. The only problem I see is that there’s no radius doubling.

Your argument “given that the new spin axis can not go through any existing spins“ may be the correct and winning physics argument, is it a violation of precession? I don’t know, I’ll take it for consideration, but I’m not convinced higher A spins don’t exist. My main complaint with the two, no higher A-spin spin apps, is the idea that a BPhoton can move simultaneously in up to 40 different motions, up to ten each parallel, scaled, or sign changed X,Y and Z spin motions. In my opinion a far greater problem than the Z and A spins sharing a common center. Lately I’ve begun to assert that one cannot properly model particles without including recycling photons which may cycle through all the end-over-end sub-spins.

The additional information you provide is welcome. As far as choosing higher axial spins – where my review broke down - there’s a check box. Selecting it will not get you higher axial spins. Since you don't agree they exist, you don't model them. You indicate that you're “working on an effective solution to this”, I can’t wait. Why not might include higher axial spins with the caveat, “higher A spins have not been shown to exist”, we understand, this is your simulation dadgumit, and a dang good one at that. Still, if there were higher A spins the particle surface complexity repeats but doesn’t grow, making each X, Y or Z more self-similar, simplifying the larger particle’s appearance.

Please consider presenting Spin Gen to Miles for his input.
.

LongtimeAirman
Admin

Posts : 633
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Thu Dec 07, 2017 12:18 am

LongtimeAirman wrote:
1. http://www.nevyns-lab.com/science/spin-apps.php On the Stacked Spin page the two applications shown side by side are very similar, but they are in slightly different. I suggest making their formats agree a little more closely by including or not including bullets in both of the two Spin application descriptions.

Yeah, I rushed those changes in to get the app deployed and haven't gone back to tidy them up. Will look into it soon.

LongtimeAirman wrote:
2. Maybe add viewing coordinates or particle rotation options? Mouse orbit controls is confusing and difficult at times – hence the home button. Being able to adjust the viewing angle by user input might be a welcome alternative to just the orbit controls. The graphics tab might include a rotate about axis option that would allow the user to capture motion with a gif application.

Good ideas. Assigning rotations via controls can be a bit awkward, but I will see what I can do. Auto-rotation about an axis is something I had not thought of before. Really good idea.

LongtimeAirman wrote:
3. The moving slide bar doesn’t seem to work for iterations, you may have subdivided the number range properly, but the limited slide positions – not smooth at all - allows for many random appearing digits, no rounded numbers like you’ve provided in the “unit time” slide bar.

Yeah, they could use some tweaking, for sure. The iterations are probably stepping by 1, I can make that 100,000 or something large like that. I might need to increase the minimum value, which is 100 at the moment, as the min and the step should be somewhat aligned with each other. For example, for the Unit Time slider, the min and the step are the same value.

LongtimeAirman wrote:
* First paragraph, 3rd line, suggest changing “the path that it covers“, to “the particle’s surface created by the BPhoton’s motion”.

I don't want to use the term surface, but I'm sure I can come up with something better. Maybe boundary since that doesn't imply something that exists, it can just be a concept.

LongtimeAirman wrote:
** First paragraph, last sentence, “to analyse the paths of various particles to see how they compare with each other”. The “path of the various particles” is confusing, the particles are spin levels, the only thing moving is the BPhoton. Consider changing to “analyze and compare the paths of various particle BPhoton motions”.

I was using the term particle to refer to both a BPhoton and all of its spin levels. Not just a spin level itself. Note that we could have the same number of spin levels but change whether it uses higher axial spins and that would be 2 different particles. I'll see if I can find some better words to use and make it clearer.

LongtimeAirman wrote:
It’s my impression, using Spin Path Gen’s iteration number and sampling rate, one can create any number of BPhoton track patterns (displaying points or lines) revealing the particle’s surface. The apps show how a particle’s surface complexity increases as the spin levels increase. One can vary the sampling number and rate, (or rely on the default, thank you), giving the particle surface anything from a rough outline, contour or veil-like appearances, to far denser patterns as one views the particle. Some selections are prettier than others. Those patterns strike me as an artifact of sampling and do not represent any particle variation whatsoever. I’m not sure the pattern would necessarily point to where we may most likely find the BPhoton.

True and not quite true. These patterns are most definitely a result of sampling, but they can be used to see the density variations which tell us that the BPhoton spends more time in those dense areas.

LongtimeAirman wrote:
*** Second paragraph, 3rd line. I like the tabs. They may be a bit too close to the “Run”, “Stop”, and “Home” buttons. I expect additional information on the controls, yes that higher axis A spin checkbox; instead, the description veers into the justification of the Spin apps. The theoretical basis of Spin Stacking, including your simulation’s description and explanation should be front and center, not here.

I can increase the white space on the screen to allow more space between sections. while I was developing the app, it was taking up the whole page and I was trying to avoid having scroll bars on the page. Once I deployed it to my site, I found that it didn't take up anywhere near all of the page so I think my dev browser must have some zoom applied.

I can put some short description as a tooltip on the controls, but I can't give a lengthy description in those. Hence the wall of text above. I will put that larger description, or overview, onto another tab, it was not meant to just exist here on this site, I just wanted some feedback before I made changes to the app.

I'm never sure how much I have to describe stacked spins themselves. I was planning on putting a few links in there so the user could go to Miles site to get more info on them.

LongtimeAirman wrote:
**** Second paragraph, last line. “Which dimension can be used to spin around that does not go through any existing spins? “. I agree that when I apply a vertical tangential collision to a horizontally oriented z-spin, the new axis of rotation goes through the same center of rotation as the z-axis. The two spin axii are orthogonal, and the BPhoton is never at the center point of the two spin axii. The only problem I see is that there’s no radius doubling.

I'm not too concerned about the absence of a doubling radius on higher axial spins. Much more concerned about the axis of rotation and how that relates to the previous top level spin.

If we have a top level Z spin, and we insist on a higher axial spin with an orthogonal spin axis, then that axis must be the X or Y axis. It can not be the Z axis since if it was, then it wouldn't be orthogonal. However, the X and Y axis passes straight through all of the existing spin path (before we add the next axial spin). That is, it passes through that boundary that the motion has given us. That is explicitly dis-allowed by the rules of stacked spins (or gyroscopes, actually). So I put it on the Z axis but then it really isn't an axial spin, it is just adding to or removing from the existing top level Z spin. It has to because it is the exact same spin axis.

LongtimeAirman wrote:
Your argument “given that the new spin axis can not go through any existing spins“ may be the correct and winning physics argument, is it a violation of precession? I don’t know, I’ll take it for consideration, but I’m not convinced higher A spins don’t exist. My main complaint with the two, no higher A-spin spin apps, is the idea that a BPhoton can move simultaneously in up to 40 different motions, up to ten each parallel, scaled, or sign changed X,Y and Z spin motions. In my opinion a far greater problem than the Z and A spins sharing a common center. Lately I’ve begun to assert that one cannot properly model particles without including recycling photons which may cycle through all the end-over-end sub-spins.

Yes, it is a violation of precession. It may be more accurate to say that it is a force that would cause precession. The existing motion of the gyroscope resists that force and precession is the result of, or is, that resistance.

I agree that giving the BPhoton so many different velocities is difficult to accept. It is fairly unheard of at our own scale. However, it is not completely alien. We can accept that something can have an axial spin while also having a linear velocity. Our planet does it constantly, although it may be a bit of a stretch to call that a linear velocity since it is actually a second rotation (without getting into gravity). On top of that, the Sun is rotating around the galaxy, so we live with this stuff but don't really take much notice of it.

The reason I think that higher axial spins are more important at the moment is because it is an implementation detail. Whether stacked spins are real or not is a conceptual detail. I am modelling them with the assumption that they may be real and to see how they work. I'm not trying to prove that they are real but I am trying to give a solid position for such arguments, which ever way they go.

Recycling is important, but not always necessary. They are only necessary for the charged particles. Photons don't need them at all. Of course, linear velocity is also necessary for a photon but I haven't modeled that in this app. I have thought about it though.

LongtimeAirman wrote:
The additional information you provide is welcome. As far as choosing higher axial spins – where my review broke down - there’s a check box. Selecting it will not get you higher axial spins. Since you don't agree they exist, you don't model them. You indicate that you're “working on an effective solution to this”, I can’t wait. Why not might include higher axial spins with the caveat, “higher A spins have not been shown to exist”, we understand, this is your simulation dadgumit, and a dang good one at that. Still, if there were higher A spins the particle surface complexity repeats but doesn’t grow, making each X, Y or Z more self-similar, simplifying the larger particle’s appearance.

Not sure what you mean here. I do model them, even though I don't agree with them. I just provide a way to disable them so that the user has the ability to generate what they want to see. It also allows us to compare spin paths with and without higher axial spins.

What I meant by "working on an effective solution" is just what we have been discussing in the above posts. An effective way to tell the user what is going on, which the overview will help with, but I also want the number of spin levels to show the actual number of levels that are going to be generated. I don't want to impose my beliefs onto the user if I can help it. I want to be able to generate paths that adhere to Miles ideas exactly while also allowing modifications where I think it is appropriate.

Thanks for the feedback. I will take it all into consideration and see what I can come up with to make this app better.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Jared Magneson on Thu Dec 07, 2017 11:38 pm

Very good stuff, Nevyn. I'm still learning how to script such things and it's inspiring to see you making some headway in your direction. And of course the conversation on higher axial spins is really important too.

It would be cool if you were able to implement GPU-acceleration too, but I'm sure that's more technical. It's really quick at lower levels/iterations, just when you drop a million in there the CPU has a lot more to chew on. It's much, MUCH faster on Firefox 57 than Chrome or Firefox <56.

@CR6 I believe FF 57 is the "Quantum" update, which allows multi-core saturation that as far as I know no other browsers are offering. It's MUCH faster than FF 56 or Palemoon, for a more direct comparison. It does suck that I lost a lot of cool add-ons but the benefits so far are great.

Jared Magneson

Posts : 251
Join date : 2016-10-11

View user profile

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Fri Dec 08, 2017 12:38 am

Yeah, the new Firefox is great, but it doesn't give the developer any way to use multi-threading. That is because the underlying language doesn't (thanks, Javascript). I'd love to work in OpenCL, which I could if any browsers supported the WebCL extension. They've all taken on WebGL for 3D graphics but left out the WebCL for computing. Maybe in time they will support it.

On a side note, I just implemented SSL support on my site so everything now runs through a secure connection.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by LongtimeAirman on Fri Dec 08, 2017 12:47 am

.
Hi Jared. Nevyn, that reminds me, my system is really loaded when I run Spin Path Generator. I’ve had to reboot a couple of times when dialing up high levels with additional programs (normally Word and one or two other browsers) running in the background. I must remember to shut everything down before running Spin Path Gen.
 
I made one suggestion I though was a good one that you didn’t reply to. Spin Path Generator creates a BPhoton spin level. Is it possible to create two or three consecutive spin levels and display them in the same image?

After checking the Higher Axial Spin checkbox I don’t see any A-spins.



Here are the fifth and ninth spin levels, with and without Axial Spins.



The difference between the two pairs of A-spin and Z-spins is 45 degrees about the Z axis, both the A and Z spin levels share the same axis.

I’ve always imagined the A-spin as spherical, not as an end-over-end spin. I described creating the A spin badly yesterday (and months ago as well) so I’ll try again. Start with a horizontally spinning Z spin level (the Z axis is vertical). Strike the BPhoton tangentially, in a vertical direction. The new A-spin axis could be at any X,Y angle, orthogonal to the Z-spin axis. I think of it as spinning a ring. The A-spin axis penetrates the Z-spin in two locations, the Z and A-spin centers are the same, the new A-spin axis doesn’t go through the BPhoton which was 90 degrees away from it at the time of the collision. I understand that the force applied orthogonally to the existing Z-spin causes precession in gyroscopes; that may indicate that the same force applied to the BPhoton spin level isn’t allowed. The only defense I can offer is - the Z-spin isn’t a structure, what precesses? The BPhoton angle?

Higher spin level self-similarity. It seems to me that spherical A-Spins allow higher spin level self-similarity. A spherical A-spin causes each consecutive X,Y and Z spin set to have the exact same boundary dimensions, differing in scale alone. A2 looks exactly the same as A3, or A4, … . Same with each X,Y and Z set.
.

LongtimeAirman
Admin

Posts : 633
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Fri Dec 08, 2017 2:14 am

Now I see the confusion. There are differences, but they are subtle. Here are 2 images showing the exact same perspective:

With Higher Axial Spin
A, X, Y, Z, A, X, Y, Z


Without
A, X, Y, Z, X, Y, Z


The top image, with higher axial spins, shows a wider mouth with smaller uvula. The outer surface is also 'dented' more than the other with the 2nd image looking smoother in general.

I've just realised that I have used 8 and 7 spin levels respectively, when I really wanted to use 5 and 4. You can still see the differences here, even though there are 3 more spin levels stacked over the top of the higher axial spin.

However, I generally agree with your assessment. The Z axis can not be used for higher axial spins. It should be X or Y (technically it should be Y because the next spin is going to be an X), but I can't see how that can be allowed. It blatantly breaks the first rule of stacked spins with no reason, explanation or evidence.

It is interesting though, when I was using the Y axis for higher axial spins, it gave some really strange results. I was very shocked and started questioning myself and the implementation I was developing to generate it. I even had half of an apology for you written in my head as I thought I had to rethink all of this higher axial spin stuff. That's when I realised it was spinning on the Y axis and changed it to Z.

I wasn't thinking about collisions to form spin levels and I thank you for prompting me to think of it in that way again. That rules out the Z axis, although there is no reason that the top Z spin can't be slowed down and sped back up again. It can't go faster than c, but it can go slower.

I did notice your request for a scale marker but I am very hesitant to add anything like what you describe. I don't want to render anything in the scene other than the BPhoton position markers. Anything else I put in there may be mistaken for the particle being generated. The axis markers are necessary and should be recognized for what they are. If there was a smaller particle inside of the real particle, it could confuse users who don't really understand what they are seeing.

I have not completely ruled it out though, I just need to think of a better way to do it. It would be good if I could hook it up to the scrolling (zooming in/out) so that it only shows while you are zooming. If I can make it obvious that it is not part of the generated particle then I will do so.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Fri Dec 08, 2017 2:21 am

I think I should clear up any confusion around this statement:

Nevyn wrote:I've just realised that I have used 8 and 7 spin levels respectively, when I really wanted to use 5 and 4. You can still see the differences here, even though there are 3 more spin levels stacked over the top of the higher axial spin.

To generate those images, I set the number of spin levels to 8 and just altered the higher axial spin checkbox. I did not move the spin level slider down to 7 at any point.

I should have used 5 so that it would show A, X, Y, Z, A with higher axial spins enabled and A, X, Y, Z with it disabled.

In some ways it is better that I did accidentally add more spin levels on top of the higher axial spin because it shows you how that difference expresses itself as it bubbles up though other spins. Interesting, at least.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Jared Magneson on Fri Dec 08, 2017 4:20 am

It's very interesting stuff! It seems to me that only very specific though not irrationally obscure collisions would or could stack a new spin. So what happens to our photon otherwise? Does it just keep all its spins and change vectors, or would an off-spin collision "slow down" its velocity in either way, tangential or directional?

Are most photons just that, an average of non-stacked spin collisions?

Jared Magneson

Posts : 251
Join date : 2016-10-11

View user profile

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Fri Dec 08, 2017 8:46 pm

I think that in order to be called a photon, it must have A and X spins. You need that first X spin to create the wave of the photon. Anything less than that I would call a BPhoton.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Nevyn on Fri Dec 08, 2017 9:35 pm

I have made some changes on my dev environment to show higher axial spins on the Y axis rather than the Z.

This first image is without any higher axial spin and it is included to show what we are giving an axial rotation to.

A, X, Y, Z


Now we take that and spin it in the Y dimension which is up and down in this view.

A, X, Y, Z, A


I have not changed the camera position between those two shots. It is not the best perspective to see the higher axial spins path and you really need to generate it and move around it in SpinGen to get a good feel for it. It is a strange path, to say the least.

Here is some different views of it.

A, X, Y, Z, A


From the top
A, X, Y, Z, A


For my argument, we don't even need to see the higher axial spins. I only need that first image which shows a single spin set, A, X, Y, Z. You can see that the Y dimension, the green line going from center to the top, goes straight through the spin path (which is also green, didn't think that one through very far, did I?). If you generate that and move around it, you will see that it is embedded into the boundary of the photon.

Looking at the higher axial spin path though, I think that it looks unnatural. All paths generated without higher axial spins still feel organic, in some strange way. Maybe a better word to use is complicated. It looks too complex while not using them still looks simple in comparison. This is not a strong argument, if it is one at all, but that is how I feel about it. It could just be my prejudices, I do admit. Thankfully, my real argument is just enforcing the rules of the game, so I don't need this one at all. Very Happy

I will update SpinGen with this Y spin adjustment as it is the only logical axis to use. I'm working on a few other things at the moment though, so it might be later today or tomorrow before you see it on the site.
avatar
Nevyn
Admin

Posts : 853
Join date : 2014-09-11

View user profile http://www.nevyns-lab.com

Back to top Go down

Re: Spin Path Generator

Post by Jared Magneson on Fri Dec 08, 2017 11:41 pm

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. With the other stacked spins, we have gyroscopy and precession as reasons/mechanisms for how they "spin up", but with those higher axial spins it just seems very contrived. I don't think the particle itself could "know" how to spin about that common center. And that common center is constantly changing, as the path advances through that particular stacked spin.

So let's say it takes a certain, particular angle/velocity to "stack" a new spin. To stack an axial spin, it would take a certain, particular angle/velocity and it would also have to hit at very specific times along the existing stacked path. It wouldn't have the degrees of freedom the others do. It seems like only one or two collisions could possibly cause a higher axial spin, where almost all other viable collisions could cause an orthogonal stacking given the right vector.


Also, totally with you on the non-axial spins seeming and feeling "organic".

Jared Magneson

Posts : 251
Join date : 2016-10-11

View user profile

Back to top Go down

Where Are The Photons?

Post by LongtimeAirman on Sat Dec 09, 2017 5:58 pm

.
Déjà vu! Well, not really, although we've all been here before, we now have great Spin Path Generator images.

The simulation shows the path created by a BPhoton with up to 40 simultaneous end-over-end, spin motion mass radius doublings. How can an object have 40 separate motions? Sure, the location of my old pocket watch’s second hand, given all the motions of me and the universe comes close, but that doesn't explain how a BPhoton could possibly drive 40 spin levels. 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; Spin Gen doesn’t include photons.

No charged particle model is compete without showing how the spin level channels photons. We've discussed this topic and the need for a collision based charged particle model elsewhere at the site. I would like to show that photons become en-trained in the various spin loops, augmenting and amplifying the charge recycling capacity of the charged particle. The particle’s innermost spin is protected by increasing volumes of en-trained and recycling photons at every spin level. While I may believe the original BPhoton can drive an entire X,Y,Z spin set, I assume all higher spin particles would require many recycling photons rather than BPhotons alone. Maybe higher A-spins are possible when there are enough photons to actually double the radius.

Include photons!
.

LongtimeAirman
Admin

Posts : 633
Join date : 2014-08-10

View user profile

Back to top Go down

Re: Spin Path Generator

Post by Sponsored content


Sponsored content


Back to top Go down

Page 1 of 2 1, 2  Next

View previous topic View next topic Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum