Posted on 11/15/2005 8:25:44 AM PST by balrog666
'Perception' gene tracked humanity's evolution, scientists say
A gene thought to influence perception and susceptibility to drug dependence is expressed more readily in human beings than in other primates, and this difference coincides with the evolution of our species, say scientists at Indiana University Bloomington and three other academic institutions. Their report appears in the December issue of Public Library of Science Biology.
The gene encodes prodynorphin, an opium-like protein implicated in the anticipation and experience of pain, social attachment and bonding, as well as learning and memory.
"Humans have the ability to turn on this gene more easily and more intensely than other primates," said IU Bloomington computational biologist Matthew Hahn, who did the brunt of the population genetics work for the paper. "Given its function, we believe regulation of this gene was likely important in the evolution of modern humans' mental capacity."
Prodynorphin is a precursor molecule of the neurotransmitters alpha-endorphin, dynorphin A, and dynorphin B, collectively called opioids because their action is similar to stimulatory effects caused by the drug opium.
The notion that humans are more perceptive than other primates would hardly be news. But the list of genes known to have tracked or guided humanity's separation from the other apes is a short one. Genes controlling the development of the brain almost always turn out to be identical or nearly so in chimpanzees and human beings. And as it turns out, the protein prodynorphin is identical in humans and chimps.
It's the prodynorphin gene's promoter sequence -- upstream DNA that controls how much of the protein is expressed -- where the big differences are. "Only about 1 to 1.5 percent of our DNA differs from chimpanzees," Hahn said. "We found that in a stretch of DNA about 68 base pairs in length upstream of prodynorphin, 10 percent of the sequence was different between us and chimps."
Hahn said this "evolutionary burst" is responsible for differences in gene expression rates. When induced, the human prodynorphin gene was 20 percent more active than the chimpanzee prodynorphin gene. Past research has also observed variation in expression levels within humans.
This report supports a growing consensus among evolutionary anthropologists that hominid divergence from the other great apes was fueled not by the origin of new genes, but by the quickening (or slowing) of the expression of existing genes.
Hahn and his colleagues at Duke University, University College London and Medical University of Vienna first became interested in primate prodynorphin after noticing an unusual amount of variation in the human version's promoter. The scientists decided to examine the prodynorphin gene in human beings around the world and in non-human primates to see whether such variation was commonplace and whether that variation affected gene expression.
The group found a surprisingly large amount of genetic variation among humans within the prodynorphin gene's promoter. They examined prodynorphin genes from Chinese, Papua New Guineans, (Asian) Indians, Ethiopians, Cameroonians, Austrians and Italians.
The group also sequenced and cloned prodynorphin genes from chimpanzees, gorillas, orangutans, rhesus macaques, pigtail macaques and guinea baboons. The researchers found that high genetic variation in the prodynorphin promoter was unique to humans. Other primates' promoters were far more homogeneous.
Exactly how prodynorphin influences human perception is unknown. Evidence for its various effects comes entirely from clinical studies of people who have mutations in the gene. Past clinical studies have also indicated a positive correlation between lower prodynorphin levels in the brain and susceptibility to cocaine dependence.
Matthew Rockman, David Goldstein and Gregory Wray (Duke University); Nicole Soranzo (University College London); and Fritz Zimprich (Medical University of Vienna) also contributed to the research. It was funded by grants from the National Science Foundation, NASA, the Royal Society, and the Leverhulme Trust (U.K.).
###
I did the same on a Radio Shack Model I using Microsoft Basic.
At the letter "A".
Stack oriented - very useful. Same with Postscript.
Ah, the Trash-80, Level II Basic. Heaven. I still have two of them stashed away.
C is the only thing in the computer world that I truly loved without reservation.
Me too.
I've never understood why "goto" is not preferred to getting out of deeply nested 'if thens' and 'do loops' over repeating and executing a lot of really unnecessary code.
You programmed Postscript? I wrote a form generator that output PCL (HP) but never did Postscript.
Obviously switch statements couldn't always follow this rule, but I loathed deeply nested conditionals.
Switch statements are 'gotos' in disguise.
After a couple of years with the Trash-80 we discovered a clone! Called the LNW-80. We ended up with a word processor with lower case, proportional script, and all the goodies--back about 1981. We had one feature not found, that I know of, in most word processors today--a word swap feature. Put the cursor on a word and you could swap with the following word. Very handy when your committee chairman had a thing about "were also" vs. "also were." Stayed with that until we could jump to a real computer (Macintosh, of course).
I never did deeply nested conditionals. When they got three deep I did function calls. If I couldn't see the structure clearly on the screen it was too complex to follow and debug. I really hated having other people find bugs in my code.
On the other hand, I eventually had to find other work, because I was slow. Some project managers would rather count lines of code than have things work the first time.
In the 10 years I did C programming I was hung out naked. When the customers had a problem the phone rang at my desk.
I had a wordprocessor that I used with my Apple II that had features I've never seen anywhere else. I particularly remember -- and still miss -- using variables that could be filled in at print time. If you put the right code into a document you planned to use as a form, whenever you printed it the code would halt the printout, ring the bell, and put your prompt on the screen. Something like "What interest rate?" You'd key it in, hit return, and the document would resume printing. But the ol' daisy wheel printer sounded like a battlefield.
It's been ten years since I coded in C, but I think that is not entirely true. The default after executing a statement is to return and examine the next switch. I'm having a senior moment here, so I might be wrong.
Not if you want to keep your job.
I've used "goto" in C/C++ quite a few times, and I still have a job. ;-)
Actually, while it's a good rule of thumb to avoid "goto" whenever reasonably possible (and most times it *is* reasonably possible) there are always a few times when avoiding one just for the sake of obsessive-compulsion can make the code a lot uglier than it would be otherwise.
Some of the more obvious examples are error-handling (like you're 12 levels deep in control structures and it's time to bail the hell out because of a major failure), or similar special-case scenarios.
In many of those situations, all the goto-less alternatives are even uglier than the more simple and obvious "goto CLEANUP_AND_RETURN;" option.
Oh, yeah it was very useful for high precisions graphics, fixing driver screwups, and direct access to the printer. It was always nice to control your own grey scale levels and screening. It still is useful on (very) rare occasion.
On the side I wrote a Fortran program that would generate Postscript code to annotate chess games, switching fonts and sizes and slapping in the occasional board position with my own board and chess font. It was pretty neat until you ran out of stack space.
I never did deeply nested conditionals. When they got three deep I did function calls.
Likewise. However conditionals within called functions are just more deeply nested conditionals, etc.
In the 10 years I did C programming I was hung out naked. When the customers had a problem the phone rang at my desk.
Actually, I think that's life when getting stuck in maintenance mode. I've seen C++ and Java programmers in the same situation complaining about the same unexpected consequences because of objects, code, functions, etc. that did unintended and unexpected things. Some things never change.
BTW, compilers often compile your functions as in-line code and use the equivalent of 'gotos' at the assembler/machine code level.
The TRS-80 Model I was shipped with seven bits of video memory -- not enough to display lowercase. I modified two of them by adding an eighth memory chip in a humping cockroach configuration. The PC cost me $800 dollars (used), and this mod involved soldering several pins of the chips together, plus a couple of wires directly to the motherboard.
That was scary.
Actually, while it's a good rule of thumb to avoid "goto" whenever reasonably possible
I agree wholeheartedly. Use of 'goto' should never be 'taken lightly' and should be avoided, except when it's absurd no to use it.t
As long as we are into stories about having to walk 20 miles to school -- uphill in both directions -- I wrote a form generator for a mortgage company that printed from their mainframe with some of the data filled in, but the form had to be designed so you could put it in a typewriter and fill in stuff not in the computer. The form had to go into a Selectric and line up without any manual adjustment. Every box had to line up perfectly.
I did that about 15 years ago as a one shot deal. I met someone a few years ago who worked at the company, and they were still using it.
I seen the assembly language code from decompiled C. I don't even want to think about it. It's not your child at all. It's a cowbird.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.