I posted on this subject earlier, but I thought I would clarify some things, since what I provided was not sufficient for doing correct gamma correction on antialiasing. The basic issue is that a gray scale that appears to be linear to the human eye (perceptual brightness) is in fact not linear in how much light is produced for each brightness level (luminocity).
To summarize the issue that needs to be corrected for, consider a thin white antialiased line on a black background. At some point along the line, you will encounter two adjacent pixels which are each 50% brightness, because the line covers each pixel by 50%. It is not sufficient to plot two pixels next to each other which you perceive to be 50% brightness, since what you perceive to be 50% brightness is really 18% as much light as a 100% bright pixel. Therefore, when you put two 50% pixels together, you get 36% as much light as a single 100% bright pixel, making the line appear to get dark and light along its length.
To correct for this, the pixels to be plotted must be gamma corrected so that two 50% pixels together add up to 100%. To do this, set the pixel brightness (as a value from 0 to 1) to the power of 0.4, so to get two pixels to add up to 100%, you each pixel needs to be 76% (perceptually).
Unfortunately, what I have described only works for a black background. Even if you are not actually doing alpha blending, antialiasing must be done in such a way that what you are drawing appears to blend properly into its background. So if you assume a blue background and want to draw a red line, then you can compute a color scale which progresses from red to blue depending on how much of the line covers a pixel.
Since we are generally talking about drawing black text onto a white background, then the math changes. Simply setting the brightness you want to the power of 0.4 assumes a black background.
The solution is to convert the color spaces of both the foreground and background colors into luminance space, blend them, and then convert back to perceptually linear color space.
With antialiased lines, we can start with an assumption that each point that is plotted is a representation of how much of the foreground color we want to blend in. That is, rather than thinking of gray pixels in the antialiased text as gray pixels, consider the pixel value to represent how much black must be blended with white. This makes a subtle difference.
So we come to the full formula for blending foreground and background colors. In this formula:
B is the background color (perceptually linear). F is the foreground color (for antialiased text, this is full black for ALL pixels to be plotted). P is the percentage of the foreground to blend (you can compute this by taking a pixel from an antialiased glyph as you would have drawn it before (black fg, white bg) and subtracting it from 1.0). V is the value of the pixel to actually plot to the screen.
V = pow(pow(F, 2.5)*P + pow(B, 2.5)*(1-P), 0.4) In other words, convert F and B to luminance space, weight them by the blend factor, add them together, then convert the result back to perceptual space.
For white text on a black background, this reduces to [pow(P, 0.4)], which I had described earlier. For black text on a white background, this reduces to [pow(1-P, 0.4)] (where P here is how much black, not how much white).
People in the XFree project may already be considering this, but antialiased objects look much better when you take into consideration that a gray ramp that is perceptually linear is not optically (luminously?) linear.
To be specific, imagine you're drawing an antialiased line, and you have come to a point where the line covers 50% of two adjacent pixels, so you decided to paint them both with 0x7f. The problem there is that a pixel that looks like 50% gray is actually emitting 18% as much light as a full-on pixel, so when you put the two 18% pixels together, they add up to 36% instead of 100%. The result is that a thin antialiased line will appear to get darker and lighter along its length. If you were to take this into account, it might improve antialiased text further.
The function to apply to all pixels is this, where x is a number from 0 to 255 representing the brightness you WANT to get, and y is what you have to plot:
y = (int)(255.0 * pow(x/255.0, 1/2.5) + 0.5)
The +0.5 rounding factor in there may not affect much.
I believe it was a Dr. Poynton who talked at length about this in the 1998 Siggraph.
You are using a faulty definition of "fittest". You think "fittest" means "strongest" or "healthiest". This is incorrect. "Fittest" means "that which survives better". As such, the weak who don't die are more "fit" than the strong who do. To be "fit" means only that you have a chance to breed.
Well, perhaps "natural" culling has ceased, but culling in general hasn't. It's just changed.
Here's one way to look at it: Since medicine is allowing certain diseases to flourish, we are evolving into a less healthy and robust population.
Nevertheless, we are still evolving.
Any change in a population's genetics is evolution. Since we are allowing certain negative things to enter into our general population, we are evolving into a species which more generally has those problems.
There are a few facts about evolution that simply don't change, no matter how we try to affect the system.
The first fact is that the rate of gene mutation is a constant. Sexual reproduction makes the effects of the mutations less prominent over a given period of time, but there is intermixing which leads to the second concept.
Genetic diversity is very important for a stable population. When environments change which cause members of a population to die off, this is natural selection. When mutations occur which do not fit the environment, members die off, which is also natural selection.
Because of our stable and safe environments, we are seeing more of the effect of evolution which is to increase genetic diversity. People can live now which could not live in the recent past because they could not function in the environment.
Despite having an environment which supports greater diversity, we are always under the influence of natural selection. Although environmental constraints are relaxed, constraints still exist and genetic possibilities are being culled all the time.
Greater genetic diversity allows for greater deviation from our ancestry, which leads to new forms of humans. But evolution in general is a very slow and subtle process. People aren't going to grow extra heads (except as conjoined twins), and they aren't going to be able to breathe under water any time soon, but every change in our environment has a long-term effect on human evolution.
The technology that we use today and will continue to use in the future changes the way our environment favors different genetic possibilities and thus culls our genetic diversity. People who cannot function will suffer and their presence in the population will dwindle.
The big idea that people seem to often miss about evolution is that it is not a forward process with any specific goals. Evolution is a RESULT of our environment. Random genetic mutation is just that... random. It is not directed in any way. It doesn't play favorites. It happens at a constant rate, and there's nothing we can do about it. Natural selection does play favorites and eliminates those who don't fit. But it has no goals either; what is left is not necessarily superior, just more adapted. The environment is constantly changing, and thus, we are constantly being affected by it.
Humans are evolving no less than we or any other species have in the past.
Well... it took some work to get it to meet timing which required a few of the oldest modules to be rewritten. I now look at the architecture of some of my earlier work and cringe at how sloppy it is, but it works.
I spent a lot of time doing synthesis and re-synthesis of modules and rewriting critical paths to meet constraints. Apparently, that's par for the course.
Before going to fabrication, we did extensive testing in simulation, and worked out almost all of the bugs then. When we got the first real chips, we ran through more testing and found three bugs, all of which we have software or hardware work-arounds for.
If you're still quibbling about which HDL language to use, you need a few more years of experience learning how to design chips. The language is 1% of what you have to learn.
Two years ago, I, a software engineer, was asked to design a chip for my employer, not because I knew anything about chip design, but because I was the only one who knew what was needed in the design. You should see some of the crap I wrote back when I first started. It's taken me two years to unlearn programming and learn chip design. They're nothing alike. I know Verilog syntax and semantics better than the senior ASIC designer we hired a year ago. His code is messier than mine, and he avoids certain features of the language, but his code synthesizes more easily to meet constraints. He's a better designer.
Many programmers love abstraction. I do. Design a C++ class that performs some library of tasks and then forget about the internals of the class and just use it at a higher level in a bigger system. LISP is a WONDERFUL language for writing code at a very high level. Depending on your needs and your personality, there is a plethora of programming languages that provide different levels of abstractibility (is that a word?) and power.
You must forget about all of that in chip design. If you try to abstract yourself too far from the hardware, the synthesizer is going to give you garbage. Some tools like Synopsys Module Compiler do a lot of the work for you and you don't know EXACTLY how it's going to pipeline your design, but you know, for the most part, what kind of hardware you're going to get. If you don't, then you're in trouble.
When I was in highschool and was learning C, one thing I did was compile lots of little things to assembler and look at the results. I wanted to know what I was getting from my code. Given what I learned, I was able to optimize my C code much better. Likewise, when I started learning Verilog, I synthesized lots of small designs and looked at the gate-level results to see what I was getting. There were a number of things I tried to synthesize that I knew the synthesizer would choke on (because I knew that the design was counter-intuitive from a hardware perspective), and I got lousy results, as expected.
One interesting rule of thumb in software development is that smaller code is faster. Although it's not true all of the time, statistically, if I write a function to perform a task and my code is significantly smaller than my co-worker's verion, my code will run faster. Exactly the opposite is true with chip design. The more explicit you are about the hardware you want, the better the synthesizer will understand what you want and be able to give you a good result. Remember that you are smarter than the synthesizer. Of course, telling the synthesizer that you want an adder is a bit of an abstraction over telling what gates you want for an adder, but nevertheless, when you say "a
I'm sure some more experienced chip designers will see inexperience in what I'm saying, but from some of the other comments I have read, I think many generally agree with me. The bottom line is that although some languages may be better for chip design than others, good chip design comes from a chip-design way of thinking, which is completely unlike software engineering.
One tip comes to mine, BTW. Many chips are embedded in systems with a CPU that will be controlling it. Don't try to put too much into the hardware. A little software can save a lot of hardware without any loss of performance or functionality.
Number crunching and productivity apps are in two different worlds. The latter benefits greatly from OO because OO encourages consistent interfaces and code-reuse. The former often has no use for it. In some cases, where you are using things like matrix algebra libraries or any number of other tools, it may be of great benefit to use an OO language, just because the tool set benefits from being written in an OO language. But when you want to throw together a one-time use program which does a bunch of number crunching and where you're pretty much writing all of the code yourself, then it's better to use a procedural language which cuts away all of the OO wrappings and lets you get down to business. Furthermore, FORTRAN has been around SO LONG that it's hard to find a C compiler which can optimize as well. FORTRAN has always been used for heavy number-crunching, and as a result, its compilers have been optimized almost exclusively for that purpose.
IBM's response to their dismal failure with the 75GXP is the 60GXP which has an incredibly LOW failure rate. It's also a wonderfully fast drive and very much on par with the Maxtor equivalents.
Ever try to do multi-headed X on AIX? You can't, because their stupid operating system won't let you map more than 4 regions of memory-mapped I/O into a process address space. Not only that, but the OS takes steps to prevent you from working around that!
Ok, so people don't use AIX for CAD, but my company has huge demand for multi-headed X on PPC platforms, and it's nothing but sheer stupidity on the part of IBM that gets in our way.
It depends a bit on your hardware. I found Mandrake to be easy to install and had lots of options in install that I liked. Unfortunately, the machine would hang whenever I would try to read a CD which had been created from a Windows-based CD burner. I also had some other hardware-related problems. I dumped Mandrake and installed Red Hat. Although the installation wasn't perfect (it didn't set up networking correctly), it seems more stable in general.
Last I heard, Compaq still hasn't fixed the fact that it can't register both buttons being pressed at once. In fact, one of my friends was blacklisted by them just because he asked about it.
I'd like to offer an alternative viewpoint with regard to CFS. I have had it for 8 years. It's very debilitating. The inability to think clearly and the physical weakness are real symptoms that I cannot make go away even though I know that they are "all in my head".
Although I suspect there are many different things that might case one to be chronically fatigued, my best theory so far for what is causing MY fatigue is that I went far too many years not properly caring for my body and brain, and one day, things just fell apart. I didn't have problems until I got Mono, but that was probably just the straw that broke the camel's back.
I have come to realize is that my sleep patterns have always been poor. I get to bed late, and I don't sleep soundly. I have also eaten a relatively poor diet. And I have led a sedentary life in front of a TV and a computer keyboard.
Changing my habits has had a profound effect on my health and energy levels. Exercising before bed helps me get to sleep easier, in addition to improving my general cardiovascular efficiency. Eating a proper diet and cutting out certain foods that seem to cause me trouble (soy gives me headaches) have also yielded significant improvements.
I would honestly like to forget that CFS exists. I hold a good job and make a salary higher than most of the best paid/. readers. I don't want or need excuses. I want to function well so I can perform as a contributing member of society and follow my ambitions.
So, even if there is some mysterious pathogen or systemic failure which is causing me problems, optimizing my health to its maximum will get me at least near normal levels, and with my immune system improved, any other causes will surely go away in time themselves.
I know full well what it's like to want to go out an have fun but be entirely unable because you're just too tired. And I know full well that CFS is not depression. Recovery is a long, difficult process, but there is no magic cure. You just have to treat your body right and fix it yourself, because whining about it isn't going to make other people want to help, understand, or care. They can't.
This article looks like the output of a Markov chain generator. Anyone want to see my algorithm? I've gotten MUCH clearer results than this out of my own implementation.
It's a well-observed phenomenon that people who are better at learning abstract ideas are poorer at remembering discrete details. Einstein had trouble remembering his own street address and phone number. I suspect that the majority of people who own PDAs have the more abstract kind of memory and therefore use the PDA to suppliment their weaker concrete memory.
Maybe this is silly/impossible/ignorant (I've never looked at the APIs of Gnome or KDE), but has anyone considered writing emulation layers that let people run apps designed for one on the other's platform?
It's cool that there are competing desktops for Linux. But it's not cool that it divides the application base. We need something to bridge that gap.
Someone here doesn't seem to understand the different between intinsic rest mass and effective mass. A photon has no rest mass, but it does not ever rest, so we are better off considering how its mass appears to be, based on its interactions with other matter. The momentum of a photon is the ratio of Planck's constant to its wavelength or (p = h / lambda), which can also be expressed as the Planck's constant times the frequency divided by the speed of light (p = hf/c). We also know that the momentum of an object with mass is its mass times its velocity or (p = mv). For a photon in a vacuum, v=c, so doing some simple algebra, we can solve for the inertial or gravitational mass of a photon as being the frequency times planck's constant divided by the speed of light squared (m = h * f / (c^2)). I didn't read the web site in question very carefully because its fundamental assumption that photons have no gravitational mass is completely wrong which blows the theory out of the water before it's out of the starting gate.
For further consideration, consider that an object which is moving at a constant non-zero velocity compared to you has an effective mass which is greater than its (intrinsic) rest mass. Simple Relativity.
Slashdot Mirror
I posted on this subject earlier, but I thought I would clarify some things, since what I provided was not sufficient for doing correct gamma correction on antialiasing. The basic issue is that a gray scale that appears to be linear to the human eye (perceptual brightness) is in fact not linear in how much light is produced for each brightness level (luminocity).
To summarize the issue that needs to be corrected for, consider a thin white antialiased line on a black background. At some point along the line, you will encounter two adjacent pixels which are each 50% brightness, because the line covers each pixel by 50%. It is not sufficient to plot two pixels next to each other which you perceive to be 50% brightness, since what you perceive to be 50% brightness is really 18% as much light as a 100% bright pixel. Therefore, when you put two 50% pixels together, you get 36% as much light as a single 100% bright pixel, making the line appear to get dark and light along its length.
To correct for this, the pixels to be plotted must be gamma corrected so that two 50% pixels together add up to 100%. To do this, set the pixel brightness (as a value from 0 to 1) to the power of 0.4, so to get two pixels to add up to 100%, you each pixel needs to be 76% (perceptually).
Unfortunately, what I have described only works for a black background. Even if you are not actually doing alpha blending, antialiasing must be done in such a way that what you are drawing appears to blend properly into its background. So if you assume a blue background and want to draw a red line, then you can compute a color scale which progresses from red to blue depending on how much of the line covers a pixel.
Since we are generally talking about drawing black text onto a white background, then the math changes. Simply setting the brightness you want to the power of 0.4 assumes a black background.
The solution is to convert the color spaces of both the foreground and background colors into luminance space, blend them, and then convert back to perceptually linear color space.
With antialiased lines, we can start with an assumption that each point that is plotted is a representation of how much of the foreground color we want to blend in. That is, rather than thinking of gray pixels in the antialiased text as gray pixels, consider the pixel value to represent how much black must be blended with white. This makes a subtle difference.
So we come to the full formula for blending foreground and background colors. In this formula:
B is the background color (perceptually linear).
F is the foreground color (for antialiased text, this is full black for ALL pixels to be plotted).
P is the percentage of the foreground to blend (you can compute this by taking a pixel from an antialiased glyph as you would have drawn it before (black fg, white bg) and subtracting it from 1.0).
V is the value of the pixel to actually plot to the screen.
V = pow(pow(F, 2.5)*P + pow(B, 2.5)*(1-P), 0.4)
In other words, convert F and B to luminance space, weight them by the blend factor, add them together, then convert the result back to perceptual space.
For white text on a black background, this reduces to [pow(P, 0.4)], which I had described earlier. For black text on a white background, this reduces to [pow(1-P, 0.4)] (where P here is how much black, not how much white).
People in the XFree project may already be considering this, but antialiased objects look much better when you take into consideration that a gray ramp that is perceptually linear is not optically (luminously?) linear.
To be specific, imagine you're drawing an antialiased line, and you have come to a point where the line covers 50% of two adjacent pixels, so you decided to paint them both with 0x7f. The problem there is that a pixel that looks like 50% gray is actually emitting 18% as much light as a full-on pixel, so when you put the two 18% pixels together, they add up to 36% instead of 100%. The result is that a thin antialiased line will appear to get darker and lighter along its length. If you were to take this into account, it might improve antialiased text further.
The function to apply to all pixels is this, where x is a number from 0 to 255 representing the brightness you WANT to get, and y is what you have to plot:
y = (int)(255.0 * pow(x/255.0, 1/2.5) + 0.5)
The +0.5 rounding factor in there may not affect much.
I believe it was a Dr. Poynton who talked at length about this in the 1998 Siggraph.
Thanks.
You are using a faulty definition of "fittest". You think "fittest" means "strongest" or "healthiest". This is incorrect. "Fittest" means "that which survives better". As such, the weak who don't die are more "fit" than the strong who do. To be "fit" means only that you have a chance to breed.
Here's one way to look at it: Since medicine is allowing certain diseases to flourish, we are evolving into a less healthy and robust population.
Nevertheless, we are still evolving.
Any change in a population's genetics is evolution. Since we are allowing certain negative things to enter into our general population, we are evolving into a species which more generally has those problems.
The first fact is that the rate of gene mutation is a constant. Sexual reproduction makes the effects of the mutations less prominent over a given period of time, but there is intermixing which leads to the second concept.
Genetic diversity is very important for a stable population. When environments change which cause members of a population to die off, this is natural selection. When mutations occur which do not fit the environment, members die off, which is also natural selection.
Because of our stable and safe environments, we are seeing more of the effect of evolution which is to increase genetic diversity. People can live now which could not live in the recent past because they could not function in the environment.
Despite having an environment which supports greater diversity, we are always under the influence of natural selection. Although environmental constraints are relaxed, constraints still exist and genetic possibilities are being culled all the time.
Greater genetic diversity allows for greater deviation from our ancestry, which leads to new forms of humans. But evolution in general is a very slow and subtle process. People aren't going to grow extra heads (except as conjoined twins), and they aren't going to be able to breathe under water any time soon, but every change in our environment has a long-term effect on human evolution.
The technology that we use today and will continue to use in the future changes the way our environment favors different genetic possibilities and thus culls our genetic diversity. People who cannot function will suffer and their presence in the population will dwindle.
The big idea that people seem to often miss about evolution is that it is not a forward process with any specific goals. Evolution is a RESULT of our environment. Random genetic mutation is just that... random. It is not directed in any way. It doesn't play favorites. It happens at a constant rate, and there's nothing we can do about it. Natural selection does play favorites and eliminates those who don't fit. But it has no goals either; what is left is not necessarily superior, just more adapted. The environment is constantly changing, and thus, we are constantly being affected by it.
Humans are evolving no less than we or any other species have in the past.
I spent a lot of time doing synthesis and re-synthesis of modules and rewriting critical paths to meet constraints. Apparently, that's par for the course.
Before going to fabrication, we did extensive testing in simulation, and worked out almost all of the bugs then. When we got the first real chips, we ran through more testing and found three bugs, all of which we have software or hardware work-arounds for.
People are happy.
If you're still quibbling about which HDL language to use, you need a few more years of experience learning how to design chips. The language is 1% of what you have to learn. Two years ago, I, a software engineer, was asked to design a chip for my employer, not because I knew anything about chip design, but because I was the only one who knew what was needed in the design. You should see some of the crap I wrote back when I first started. It's taken me two years to unlearn programming and learn chip design. They're nothing alike. I know Verilog syntax and semantics better than the senior ASIC designer we hired a year ago. His code is messier than mine, and he avoids certain features of the language, but his code synthesizes more easily to meet constraints. He's a better designer. Many programmers love abstraction. I do. Design a C++ class that performs some library of tasks and then forget about the internals of the class and just use it at a higher level in a bigger system. LISP is a WONDERFUL language for writing code at a very high level. Depending on your needs and your personality, there is a plethora of programming languages that provide different levels of abstractibility (is that a word?) and power. You must forget about all of that in chip design. If you try to abstract yourself too far from the hardware, the synthesizer is going to give you garbage. Some tools like Synopsys Module Compiler do a lot of the work for you and you don't know EXACTLY how it's going to pipeline your design, but you know, for the most part, what kind of hardware you're going to get. If you don't, then you're in trouble. When I was in highschool and was learning C, one thing I did was compile lots of little things to assembler and look at the results. I wanted to know what I was getting from my code. Given what I learned, I was able to optimize my C code much better. Likewise, when I started learning Verilog, I synthesized lots of small designs and looked at the gate-level results to see what I was getting. There were a number of things I tried to synthesize that I knew the synthesizer would choke on (because I knew that the design was counter-intuitive from a hardware perspective), and I got lousy results, as expected. One interesting rule of thumb in software development is that smaller code is faster. Although it's not true all of the time, statistically, if I write a function to perform a task and my code is significantly smaller than my co-worker's verion, my code will run faster. Exactly the opposite is true with chip design. The more explicit you are about the hardware you want, the better the synthesizer will understand what you want and be able to give you a good result. Remember that you are smarter than the synthesizer. Of course, telling the synthesizer that you want an adder is a bit of an abstraction over telling what gates you want for an adder, but nevertheless, when you say "a I'm sure some more experienced chip designers will see inexperience in what I'm saying, but from some of the other comments I have read, I think many generally agree with me. The bottom line is that although some languages may be better for chip design than others, good chip design comes from a chip-design way of thinking, which is completely unlike software engineering. One tip comes to mine, BTW. Many chips are embedded in systems with a CPU that will be controlling it. Don't try to put too much into the hardware. A little software can save a lot of hardware without any loss of performance or functionality.
Number crunching and productivity apps are in two different worlds. The latter benefits greatly from OO because OO encourages consistent interfaces and code-reuse. The former often has no use for it. In some cases, where you are using things like matrix algebra libraries or any number of other tools, it may be of great benefit to use an OO language, just because the tool set benefits from being written in an OO language. But when you want to throw together a one-time use program which does a bunch of number crunching and where you're pretty much writing all of the code yourself, then it's better to use a procedural language which cuts away all of the OO wrappings and lets you get down to business. Furthermore, FORTRAN has been around SO LONG that it's hard to find a C compiler which can optimize as well. FORTRAN has always been used for heavy number-crunching, and as a result, its compilers have been optimized almost exclusively for that purpose.
IBM's response to their dismal failure with the 75GXP is the 60GXP which has an incredibly LOW failure rate. It's also a wonderfully fast drive and very much on par with the Maxtor equivalents.
I find it easiest to just go to groups.yahoo.com and set up a mailing list on their servers.
Ever try to do multi-headed X on AIX? You can't, because their stupid operating system won't let you map more than 4 regions of memory-mapped I/O into a process address space. Not only that, but the OS takes steps to prevent you from working around that!
Ok, so people don't use AIX for CAD, but my company has huge demand for multi-headed X on PPC platforms, and it's nothing but sheer stupidity on the part of IBM that gets in our way.
Down with AIX. Hurray for Linux!
It depends a bit on your hardware. I found Mandrake to be easy to install and had lots of options in install that I liked. Unfortunately, the machine would hang whenever I would try to read a CD which had been created from a Windows-based CD burner. I also had some other hardware-related problems. I dumped Mandrake and installed Red Hat. Although the installation wasn't perfect (it didn't set up networking correctly), it seems more stable in general.
Last I heard, Compaq still hasn't fixed the fact that it can't register both buttons being pressed at once. In fact, one of my friends was blacklisted by them just because he asked about it.
I'd like to offer an alternative viewpoint with regard to CFS. I have had it for 8 years. It's very debilitating. The inability to think clearly and the physical weakness are real symptoms that I cannot make go away even though I know that they are "all in my head".
/. readers. I don't want or need excuses. I want to function well so I can perform as a contributing member of society and follow my ambitions.
Although I suspect there are many different things that might case one to be chronically fatigued, my best theory so far for what is causing MY fatigue is that I went far too many years not properly caring for my body and brain, and one day, things just fell apart. I didn't have problems until I got Mono, but that was probably just the straw that broke the camel's back.
I have come to realize is that my sleep patterns have always been poor. I get to bed late, and I don't sleep soundly. I have also eaten a relatively poor diet. And I have led a sedentary life in front of a TV and a computer keyboard.
Changing my habits has had a profound effect on my health and energy levels. Exercising before bed helps me get to sleep easier, in addition to improving my general cardiovascular efficiency. Eating a proper diet and cutting out certain foods that seem to cause me trouble (soy gives me headaches) have also yielded significant improvements.
I would honestly like to forget that CFS exists. I hold a good job and make a salary higher than most of the best paid
So, even if there is some mysterious pathogen or systemic failure which is causing me problems, optimizing my health to its maximum will get me at least near normal levels, and with my immune system improved, any other causes will surely go away in time themselves.
I know full well what it's like to want to go out an have fun but be entirely unable because you're just too tired. And I know full well that CFS is not depression. Recovery is a long, difficult process, but there is no magic cure. You just have to treat your body right and fix it yourself, because whining about it isn't going to make other people want to help, understand, or care. They can't.
This article looks like the output of a Markov chain generator. Anyone want to see my algorithm? I've gotten MUCH clearer results than this out of my own implementation.
It's a well-observed phenomenon that people who are better at learning abstract ideas are poorer at remembering discrete details. Einstein had trouble remembering his own street address and phone number. I suspect that the majority of people who own PDAs have the more abstract kind of memory and therefore use the PDA to suppliment their weaker concrete memory.
Well, I THINK the link is broken. It doesn't work, and it hasn't since the article appeared on slashdot. Anyone got an alternate or something?
Hey, I came up with an idea very much like this when I was in highschool.
Maybe this is silly/impossible/ignorant (I've never looked at the APIs of Gnome or KDE), but has anyone considered writing emulation layers that let people run apps designed for one on the other's platform? It's cool that there are competing desktops for Linux. But it's not cool that it divides the application base. We need something to bridge that gap.
Someone here doesn't seem to understand the different between intinsic rest mass and effective mass. A photon has no rest mass, but it does not ever rest, so we are better off considering how its mass appears to be, based on its interactions with other matter. The momentum of a photon is the ratio of Planck's constant to its wavelength or (p = h / lambda), which can also be expressed as the Planck's constant times the frequency divided by the speed of light (p = hf/c). We also know that the momentum of an object with mass is its mass times its velocity or (p = mv). For a photon in a vacuum, v=c, so doing some simple algebra, we can solve for the inertial or gravitational mass of a photon as being the frequency times planck's constant divided by the speed of light squared (m = h * f / (c^2)). I didn't read the web site in question very carefully because its fundamental assumption that photons have no gravitational mass is completely wrong which blows the theory out of the water before it's out of the starting gate.
For further consideration, consider that an object which is moving at a constant non-zero velocity compared to you has an effective mass which is greater than its (intrinsic) rest mass. Simple Relativity.