The Universe Project
This post will only be relevant to those who wish to assist me in unraveling the secrets of the time-space continuum.
Right, I just woke up, code written in the middle of the night while being tired is very likely to be buggy.
I introduced CGluon to keep my CQuarks together, out of a whip really, but I'll need it. My CNeutron consists out of two CDownQuark's and one CUpQuark. After 900 seconds in their life, CDownQuarks become CUpQuarks together with some junk, introduced trough a virtual CBoson, capable of splitting into new free flying objects (of the CLepton class)
My problem is that once one CDownQuark in the CNeutron has turned into a CUpQuark, there is still one CDownQuark left in the now CProton (practical it's still a CNeutron disguised as a CProton but I think that will work). The CProton doesn't decay unless some 10^31 years have passed. I think it is incorrect to believe that a CNeutron transformed in a CProton creates a CProton with a full life span still ahead of it, but I'll worry about that later, right now I need to prevent the decay of CQuarks when they are held together by CGluons inside some CHadron like a CBaryon or a CMeson, however, I don't believe prevention is correct, seeing how the CProton will eventually decay, I think the CQuarks decay is only slowed down by the presence of other CQuarks and the CGluon's that bind them.
To be coded:
Whenever CGluons bind CQuarks together, the CQuarks will get a pointer to their accompanying CGluon, which is in turn aware of the other CQuarks it binds, currently unaware of the object they compose (CGluon doesn't know what it is holding together right now, although it could always be calculated from the objects it is holding together of course). Whenever CTime requests the life span of the CQuarks floating around in space, the CQuarks should detect the presence of CGluon's and pass the request trough to the CGluon, which should slow down or accelerate the decay (by either a multiplication or a division of the life span remaining). It should also increase or decrease the effects of the passing of CTime on the life span of the object using the same factor.
Two problems remain:
1. CNeutron was thought to decay into CProton by changing a CDownQuark into a CUpQuark, given the implementation above, CDownQuark will still decay by itself when it's CGluon detects the composition of a CNeutron, if one of the CDownQuarks is to decay by itself, there is no use for the CNeutron to try and decay on its own, it should in fact be triggered by the decay of one of the underlaying objects. (What will trigger this ? CQuark itself, or CGluon, given a pointer to it's composition ?)
2. I've been puzzled about this all along, there are two CDownQuark's in a CNeutron, only one is to decay, which one ? What happens to the life span of the other ? It is supposed to be zero too, so no matter how much I multiply it inside CGluon, it'll still want to decay. There is a theory that says objects will decay when half of their life span has passed, so perhaps not the life span itself should change, but the likeliness of decay (for example a CDownQuark inside a CNeutron will decay in one half life, where the CDownQuark in the CProton would need a full life or something)
The concept of CProton and CNeutron I think is fundamentally wrong, I think I will delete them they are CBaryons with a certain composition, and since the CQuarks they are made up of can decay by themselves and change types, the probability is extremely high that by decaying as nature intended, I will stumble upon CBaryons for which there is no name yet.
Then there is still the rotation problem inside CMeson's, A CMeson is made out of just two CQuarks, but a combination of the same two CQuarks can make up two different CMeson's, depending on the direction in which the CQuarks rotate (right now, nothing rotates).
To be coded:
Delete CProton and CNeutron, create a detection mechanism to generate a string consisting of the CQuark designations (they are 'U','D','S','C','B',T', see previous post about CQuark types), I know I miss AntiQuarks all together, I still need to look those up, but they can be represented with lowercase letters. I'll sort that string and run it trough a table. DDU is a Neutron, DUU is a Proton, I can build a CMapStringToString or a CDWordToString around this. This must be done on demand only, not to slow down the world too much.
Somewhere in all that I will need to stick lunch.
Right, I just woke up, code written in the middle of the night while being tired is very likely to be buggy.
I introduced CGluon to keep my CQuarks together, out of a whip really, but I'll need it. My CNeutron consists out of two CDownQuark's and one CUpQuark. After 900 seconds in their life, CDownQuarks become CUpQuarks together with some junk, introduced trough a virtual CBoson, capable of splitting into new free flying objects (of the CLepton class)
My problem is that once one CDownQuark in the CNeutron has turned into a CUpQuark, there is still one CDownQuark left in the now CProton (practical it's still a CNeutron disguised as a CProton but I think that will work). The CProton doesn't decay unless some 10^31 years have passed. I think it is incorrect to believe that a CNeutron transformed in a CProton creates a CProton with a full life span still ahead of it, but I'll worry about that later, right now I need to prevent the decay of CQuarks when they are held together by CGluons inside some CHadron like a CBaryon or a CMeson, however, I don't believe prevention is correct, seeing how the CProton will eventually decay, I think the CQuarks decay is only slowed down by the presence of other CQuarks and the CGluon's that bind them.
To be coded:
Whenever CGluons bind CQuarks together, the CQuarks will get a pointer to their accompanying CGluon, which is in turn aware of the other CQuarks it binds, currently unaware of the object they compose (CGluon doesn't know what it is holding together right now, although it could always be calculated from the objects it is holding together of course). Whenever CTime requests the life span of the CQuarks floating around in space, the CQuarks should detect the presence of CGluon's and pass the request trough to the CGluon, which should slow down or accelerate the decay (by either a multiplication or a division of the life span remaining). It should also increase or decrease the effects of the passing of CTime on the life span of the object using the same factor.
Two problems remain:
1. CNeutron was thought to decay into CProton by changing a CDownQuark into a CUpQuark, given the implementation above, CDownQuark will still decay by itself when it's CGluon detects the composition of a CNeutron, if one of the CDownQuarks is to decay by itself, there is no use for the CNeutron to try and decay on its own, it should in fact be triggered by the decay of one of the underlaying objects. (What will trigger this ? CQuark itself, or CGluon, given a pointer to it's composition ?)
2. I've been puzzled about this all along, there are two CDownQuark's in a CNeutron, only one is to decay, which one ? What happens to the life span of the other ? It is supposed to be zero too, so no matter how much I multiply it inside CGluon, it'll still want to decay. There is a theory that says objects will decay when half of their life span has passed, so perhaps not the life span itself should change, but the likeliness of decay (for example a CDownQuark inside a CNeutron will decay in one half life, where the CDownQuark in the CProton would need a full life or something)
The concept of CProton and CNeutron I think is fundamentally wrong, I think I will delete them they are CBaryons with a certain composition, and since the CQuarks they are made up of can decay by themselves and change types, the probability is extremely high that by decaying as nature intended, I will stumble upon CBaryons for which there is no name yet.
Then there is still the rotation problem inside CMeson's, A CMeson is made out of just two CQuarks, but a combination of the same two CQuarks can make up two different CMeson's, depending on the direction in which the CQuarks rotate (right now, nothing rotates).
To be coded:
Delete CProton and CNeutron, create a detection mechanism to generate a string consisting of the CQuark designations (they are 'U','D','S','C','B',T', see previous post about CQuark types), I know I miss AntiQuarks all together, I still need to look those up, but they can be represented with lowercase letters. I'll sort that string and run it trough a table. DDU is a Neutron, DUU is a Proton, I can build a CMapStringToString or a CDWordToString around this. This must be done on demand only, not to slow down the world too much.
Somewhere in all that I will need to stick lunch.