Graviton?

I am a professional software developer, not a professional physicist; however, I have had a keen interest in physics since early childhood, and was seriously considering a career in the field upon entering college. I am open to constructive criticism from those in the field; please read the following post with the understanding that I am expressing my opinions and not putting forward a serious scientific paper. I do, however, feel I have a better understanding of physics than the average amateur physicist; but again, I would appreciate any qualified individual coming forward with perceived holes in my understanding.

Gauge bosons are the conveyers of the forces of nature. For example, a photon conveys the electro-magnetic force. The graviton is proposed to convey the force of gravity; however, although both particles are gauge bosons, there is a very big difference between a graviton and a photon. The key difference is that there is empirical evidence supporting the existence of photons. Even if one were for some reason mistrust the results of scientific experiments, the evidence for photons is all around us in everything we see. Our vision is the result of numerous photons colliding with the electrons in the photoreceptive cells of our retinas. However, despite the significant roll gravity plays in our universe, a graviton has yet to be detected in any way. Although, something not being detected at a certain point in time is not proof of non-existence; it is my personal position that gravitons have yet to be detected precisely because they do not exist.

Before I continue, I will mention that some might posit that the graviton is simply, “the quantity of which we measure the interaction of gravity with particles of mass.” It is hard to deny the existence of the graviton if it is given this definition; however, I feel like this is a semantic work around. The photon is said to be a particle because electro-magnetic radiation is observed to behave as a particle when coming into contact with an electron cloud. In addition, electro-magnetic energy has been observed to be quantized for a very long time; where is there is absolutely no evidence to support gravitational energy being quantized. That is to say, light only comes in discrete steps of energy. A light beam cannot be in whatever frequency one desires, but instead, its frequency is strictly limited to values allowed by the laws physics; hence, lending credence to calling the photon a particle.

I will admit a personal bias to not believing things that have yet to be proven both rationally and empirically; however, my disbelief in the graviton is not without rational basis. The hypothetical graviton appears to directly contradict the theory of relativity. Einstein’s relativity claims that gravity is the result of curved space-time, not some mystical gauge boson. Unlike the graviton, relativity has empirical evidence supporting it. Gravitational lensing, as well numerous other predictions of relativity, have been observed in the real world. It would be absurd to throw out a perfectly reasonable theory with evidence supporting it in favor of a theory with no evidence. However, I doubt many proponents of gravitons would favor throwing out relativity, but would probably prefer some strange work around akin to hammering a square peg into a round hole.

In order to reconcile relativity with the existence of gravitons we either have to demonstrate how gravitons can cause gravitational lensing, or assert prior observations of gravitational lensing were the result of some other natural phenomenon. In order to assert the graviton is the cause of gravitational lensing, a model of the interaction of the photon and the graviton must be proposed. Although, the results of my Google search for “graviton photon interaction” were a bit sparser than I would have liked, I came across an interesting article by Matthew R. Edwards. It was titled Photon-Graviton Recycling as Cause of Gravitation and was located in the third issue of volume 14 of the Apeiron publication. The publication date was July 2007 and the article can be found at the following URL, http://redshift.vif.com/JournalFiles/V14NO3PDF/V14N3EDW.pdf. According to this article, photons lose energy when traveling through space because of interactions with gravitons. I therefore deduce, perhaps wrongly, that in this model, gravitational lensing is caused by light refraction as the photon either slows down when entering an area of higher graviton concentration, or speeds up when entering an area of lower graviton concentration. If this is the case, my position has the potential to be falsified by comparing the speed of light at a point of high gravitation to the speed of light at a point of low gravitation. I am not sure how one would go about setting up this type of experiment, but if Edwards is correct, the speed of light after taking into account coronal gas density, should be slower near the sun than the speed of light at a point farther out in the solar system. I do, however, realize I may be straw-manning, as the Apeiron publication may not necessarily speak for the physics community at large.

Biologist Richard Dawkins has noted that humans have the tendency to make false positives in association recognition. That is to say, people will tend to see patterns where they do not exist. The desire of even extremely intelligent people to see patterns can be very strong; this tendency helped our ancestors survive in a vast and confusing world. I feel as if the graviton comes from the desire to fit gravity into the pattern of the other three known forces. It is reasonable to think that gravity might have a gauge boson because electro-magnetism does; however, there is no scientific reason why this must be the case.

I believe that attempts to combine gravity with the other three known forces have failed, and will continue to fail, because gravity is simply a very different “animal”. I also feel as if the tendency of some physicists to analyze the world in terms of symmetry is misguided and needs to be checked. The universe is not symmetrical and there absolutely no logical reason why it should be. Symmetry is like beauty, it is extremely subjective, and people tend to like it. In addition, the word “symmetrical” is ambiguous. When you say symmetrical, do you mean in terms of a vertical orientation? Or do you mean in terms of a horizontal one? Maybe, your perspective is not in terms of any spacial dimension at all?

Hopefully the activation of the Large Hadron Collider will help settle this issue. Perhaps the graviton will be found to be real and my position will be found to be incorrect. If that is the case, I will gladly change my mind in the spirit of truth finding and intellectual honesty. However, more than the graviton, the goal of this posting is to warn against the dangers of unscientific thinking disguised as rational means to obtaining knowledge. Symmetry is beautiful, and often part of our universe, but it is not a valid scientific approach.

Maybe I was Wrong

Curses of James Gosling’s name were common utterances from my mouth back when I was in school and was forced to use Java. No pointers? No private inheritance? No passing by reference? I detected the evolution of programming was watering it down for the lowest common denominator, and it made me livid.

My attitude was, and to a certain extent, still is, leave the dangerous language features in and if people are stupid enough to use them that is their problem. Most everybody agrees that multiple inheritance can lead to some major problems; however, it is immature to assume that it is always bad just because you have yet to find a good use for it. A do-while loop appears to be a useless feature at first sight, but once a programmer encounters a situation where he always needs to do something at least once his tune may change. Thinking in terms of absolutes is dogmatic and ineffectual. My ego is not small, however, even I am not arrogant enough to think that I have iterated through every possible situation to be encountered when creating an application. I am very much against passing by reference; however, when a developer needs to switch object references inside a function and cannot; it is frustrating to say the least.

I always welcome new features to a language that have the potential to make my life easier. I welcomed the implicit typing feature (var) to C# 3 because I assumed that developers would know not to use it as shorthand (as opposed for runtime created objects) in production code; I assumed wrongly. It was easy to sit back and criticize Gosling when I was sitting alone in my basement writing code for my own amusement; however, cursing him is becoming more difficult with each passing day.

A Change of Heart?

As I have left school and started working I have learned one very important lesson; if a language feature exists, programmers will use it. This is because it is always easier to use a feature to work around a mistake than to reengineer the entire program. It is not hard imagine some programmer 15 years back forgetting to implement a feature in a base object and then using multiple inheritance as a workaround; next the other members of his team inheriting from his work are greeted with diamonds. Additionally, most programmers are big on conventions. This sometimes means a programmer will knowingly repeat a mistake, or reuse a language feature that was only appropriate in a particular instance. The sometimes irrational tendency of programmers to stick to conventions at all costs can exacerbate use of bad language feature; even spreading it across a team like a retrovirus.

My frustration at the removal of “dangerous” language features has not subsided; however, I now understand why it has been done. My realization of some of the more ineffectual habits that programmers can exhibit has perhaps changed my mind on the validity of removing features, but it does not make me like it any more.

More than you ever wanted to know about void pointers

Void pointers in C and C++ are one of the most misconstrued features in programming. Although, there are many pages on the web which explain the basics of void pointers; most are brief and a subcomponent of more general tutorial. In this post, I hope to give a more in-depth explanation; however, I may lack some of the necessary experience with this “mature” language feature, so if any of the more experienced programmers would like to add some caveats or something else I forgot, please feel welcomed to leave your input on the matter.

Long before I knew I wanted to program professionally, I was learning the ropes with some good old Basic. How I yearned for a “variable holder”; this was my term for the feature that would have greatly simplified my life at a time when I knew nothing of OO and functions were still fairly fuzzy. When I found out that “real programmers” don’t use VB I decided to take up teaching myself C# and C++ simultaneously. When I discovered pointers, the C implementation of my “variable holders”, it was love at first sight. They were even better than I had imagined; you could do pointer arithmetic! Not only were they incredibly useful, but they were generally considered dangerous by the general coding community. This danger gave “pointing” a sex appeal I just could not resist; after all, it is not acceptable to point in polite society. Now that you know more than you care to about why I at least imagine myself to be qualified to discuss void pointers, we can move on to the actual void pointing.

The Basics:
A void pointer is a “wildcard” or “rainbow” pointer. More precisely, its value is a memory location whose type is not explicitly known at that point of execution. More concisely, it is a raw memory address. More basically, it points to a location but you don’t know what’s in there. Along with, integers, and floats, void pointers could be considered one of the few basic data types which modern processors recognize.



Explanation:
When many programmers are first introduced to the void pointer they are abhorred by the concept… it seems just a bit too wild. This misconception may stem from people like me who referred to them as “wildcards” in an attempt to convey the concept. Really, this interpretation is inaccurate because in reality they are not wild cards, but rather unknowns. There is a subtle, but very important distinction here because wildcard implies that you can mix and match which is certainly not the case.

I feel as many coders have images of wild eyed, lazy, irresponsible amateurs gone geek for cash pop into their minds when void pointers are brought up; “I’m too lazy to declare a type; what’s the worst that could happen?” However, nothing is further from the truth. Using void pointers when they are appropriate is the responsible thing to do, while using a typed pointer when voids are called for is careless.

In programming, just as in life, one of the worst mistakes you can make is being ignorant while filling in the gaps with fairytales. When a person fills in gaps with make-believe they are not motivated to search for the true answers. In code when you do this you open yourself up for a whole mess of errors. Do you know what happens when you treat a float like an integer? I don’t off the top of my head and I don’t have a compiler handy at the moment; however, I can safely assume I don’t want find out in a production application. Even if your code works fine without void pointers; what about the person reading your code? What about you a month from now? Even though void pointers don’t actually solve any sort of problem at the machine level, they let us admit our ignorance. When we know that we don’t know, at least we can start looking for the answer. When we place an integer pointer where a void should be we are just telling ourselves dangerous fairytales.

Void Pointers in Use:
Here is a quick list of possible uses for void pointers; this list is by no means unabridged:

• Pointing to a space of memory whose type may be unknown
• A pointer whose location is known to purposefully go beyond the bounds of a specified array
• Pointing to uninitialized memory (malloc)
• A pointer whose location is going beyond the bounds of the program’s allotted memory space
• A pointer which is pointing to a memory space known to contain multiple types
• Implementation of generics
• And of course, pointing to void functions in the case of a void function pointer

There a plenty of situations where a void pointer is appropriate. For example, reading a raw stream from a network connection, file, or a peripheral device are good candidates for void pointer usage. Even if you know the structure of the stream, a pointer which is pointed to the whole file should not be typed. The best practice is to have a stream pointed to by a void pointer. Many good programmers prefer a byte pointer when dealing with streams as all data can be said to boil down to a byte; however, as bytes are treated as integers in C, this is not my preference.



Void Pointer Arithmetic:
Dereferencing a void pointer is not allowed. Also, void pointers cannot be operated upon directly with arithmetic like other pointer types. Although, this may seem surprising at first, it makes sense when you consider the nature of void pointers. When incrementing or decrementing a pointer the memory location of the pointer increases or decreases by the size of the pointer’s data type. If an integer is 32bits then an incremented integer pointer is will be increase by 4 memory locations; 32 ÷ 8 = 4. However, a void pointer does not have a type; therefore, there is no logical amount to increment it by. One could argue that it would logical to increment the void pointer by 8 bits, or one memory position; however, this is not anymore justified that moving the pointer by the word size of the system. There are several options around this, however, if a programmer should find the need to increment a void pointer. A more unusual method would be to cast to a double void pointer; this will be discussed later. Another option would be to cast to an integer. The most conventional method is to convert the void pointer to either a char pointer or a byte pointer. As a programmer would expect, any type of pointer can be converted implicitly to a void pointer; however, as it is not safe, converting from a void pointer to another type requires an explicit cast.



Conversion to a char pointer or a byte pointer for void pointer arithmetic is common because on most systems chars and pointers are 8bits; or one memory position. Although there is something to be said for convention and readability; it is worth noting that on some systems chars or bytes are not 8bits in size. Although, this is unlikely to be a concern, it is still a potential problem with the char and byte approach as type size is not guaranteed by C or C++. If it is essential that a program increments a void pointer by one memory position then integer casting may best method; though, it is at the expense of both convention and convenience.

Void Double Pointers:
Even scarier than void pointers can be double pointers of the void variety. A void double pointer is a pointer to a void pointer. Although, it may seem logical; it is not a pointer to an unknown pointer. Despite the potential unintuitiveness of this concept, a void double pointer is completely typed. A void pointer can point to an integer or void double pointer (it’s a type too), but a properly behaved void double pointer can only point to a void pointer. Because a void double pointer’s dereference is typed, pointer arithmetic can be performed on it just like any other pointer.



Like any other double (or higher) pointer, a void double pointer is incremented or decremented by the word size of the system. Technically, the prior statement is actually inaccurate; it will be incremented by the word size of the system targeted by the compiler. If a 64bit system is running a program generated by a 32bit compiler a double pointer will be decremented by 32bits. However, this caveat is scarcely worth mentioning because in most cases your program logic is only dependent on the target word size.



When a programmer sees some funny operation performed with a double void pointer, this may be a clue that the prior coder was attempting to obtain information about the compile target of a program which will be operating on different types of machines. An example of this would be finding the word size of the target system by taking the difference of two void double pointers after casting them to ints. The second double void pointer’s value is the increment of the first (prior to casting). This type of operation can be performed just as well with any type of double pointer; however, convention dictates it is done with double void pointers. The moral of the story is a funky operation with a void double pointer is one of many potential clues that a program will be targeting multiple platforms and thusly the programmer should be warned accordingly.