Blogs = shorthand for weblogs = people's journals online. Either their own sites, or a communal system like LiveJournal that allows people to collate the most recent entries by their friends into a single site and link together webs/communities of people by interest.
"An Introduction to Quantum Computing Algorithms" by Arthur Pittenger, published by Birkhauser. 1999 text - I'm actually taking a class on QC at the moment. Starts out with a review of quantum statics (you will need a good grounding in Heisenberg's interpretation of QM and linear algebra, make no mistake) and then dives into the basics of quantum computing, covers the major algorithms of the last few years (Deutsch-Jozsa, Simon, Grover, Shor, and finite Fourier transforms), and error correction.
More than a few hundred qubits will be needed, also. Shor's algorithm requires two registers of length N. Most Diffie-Hellman keys these days are 1024 bits, with some larger. I don't expect to see it in my lifetime, honestly. But when it does, there will be a shitstorm to beat all shitstorms. Some folks need to get cracking on an encryption process that doesn't rely on the intractability of factoring... they've got maybe 50 years to do it.
Try to learn at least one of the theories of quantum mechanics before you start throwing around principles, okay?
For one thing, QCs do exist - in fact, they demonstrated Peter Shor's 1994 factoring algorithm on a recently built 7-qubit box, factoring 15 into 3 and 7. You may say big deal, but it can factor ANY such integer in polynomial time. Usually the NSA is about 10 years ahead of the private sector, so I figure they've got at least 10 qubits by now. You should be worried - most public-key encryption methods rely on the intractibility of factoring.
Secondly, the Heisenberg uncertainty principle only states that you can't predict with 100% accuracy which eigenstate a qubit will collapse into upon measurement. You can, however, compute a probability amplitude (which ends up being a complex number) that it'll be a 0 and another probability that it will be a 1. And it is possible to perform operations upon one or more qubits without measuring it - the idea of creating an operation that doesn't collapse the state is the crux of Quantum Computing.
Unlike macroscopic physics, we don't know WHY things work on the quantum level the way they do. We've gotten relatively decent at predicting the end results though. So, we're just as confused as before... but we're capable of doing useful stuff with it. Don't knock it.
Umm... boolean gates were created a long, long time ago in QC. Hell, I have a textbook that lists the matrices for them.
(For those uninitiated, under the Heisenberg interpretation of Quantum Mechanics, you can view any quantum computer's state as a vector space, in which operations are unitary matrices, and making an observation collapses the Schrodinger wave into an eigenvalue.)
For that matter, the same textbook stops using Dirac notation in the latter three quarters of the book, and uses the quantum equivalent of NOTs and XORs as a sort of wiring guide, denoting entanglement and superposition as necessary, to construct a ripple carry adder. This is shortly before it starts diving into Grover's and Shor's algorithms, among others.
Lambda lists are part of functional languages, which often feature what's called higher order functions. This means that functions are a data type in and of themselves, and you can write functions that take functions as arguments, modify them, and output new functions as results.
Here's a quick example from Haskell:
addxy:: Int -> Int -> Int
addxy a b = a + b
map addxy [1 2 3...]
map will take the function addxy, apply it to each of the elements in the array (which is infinite) and return an array of results. However, the array only supplies one argument, so what you get back is an array of addxy functions with one argument hardcoded. add 1, add 2, add 3, etc. This is actually a type of lambda lists called curried functions, but you get the idea.
Haskell's a killer language - you should check it out. Any language that allows implementing a polymorphic quicksort in three lines turns me on:)
Ever heard of a diskless terminal? That's essentially what you're talking about - a Tektronix X term. Holds a small CPU, NIC, two SIMMs, and keyb/mouse/video. The problem with it is latency.
Although you are getting your wish as far as ribbon connectors - many companies are moving to Serial ATA. However, I think you would run into massive latency issues if you kept the cables so long as to reach another room. Transmission isn't instantaneous - whether you're transmitting over copper or fiber - and clock skew is a bitch.
I also find it relevant to point out that the x86 is not a readily virtualizable chip. VMWare has to make BIOS modifications to pull it off. And as for pure software emulation... look at the Bochs project, which is quite well regarded and supported, and is only up to the original Pentium. The x86 is notorious for having lots of little sideeffects and tricks/traps that make it a pain in the ass to duplicate. And, if you really want to make emulating the xbox interesting, the P6 family of processors is based on a microcode architecture... upload some new microcode, and whee, the behavior of the chip just changed until the power is reset!
The magical part of the xbox is the memory architecture. It may use standard SDRAM, but it uses a unified memory addressing scheme, which no existing PC uses - and in order to redirect it you'd have to trap every memory access made by the CPU, but this is AFTER you've reverse-engineered the northbridge to figure out what addresses map to actual chips, which addresses map to the sound card, to the video card, etc.
Not to mention that the HD has an IDE password chip, and in order to even dump the disc you have to first unlock it on a running xbox and then mux the IDE bus back into a PC. It's been done, but now they have raw bits. And believe me, MSFT is not going to be so silly as to make the HDD a standard FAT32 or NTFS drive. For that matter, I highly doubt the DVDs are in UFS format either.
The fact that the graphics hardware is made by NVidia and based on a GF3 core doesn't mean the full chip is a GF3, or that it uses the same pinout, or even the same surrounding support logic as an AGP card.
Tis better to shut thy mouth and be thought a fool, than to open it and remove all doubt.
Here's the curriculum as I've taken it at University of Portland - I slept through all the classes until my junior year:
First year of CS:
* Introduction to basic programming theory using Java
* Basic foundations of coding: loops, arrays, etc
* Fairly heavy exposure to GUIs, TCP/IP through Java classes
* Mostly individual work, some group projects
As a good example, the group project used for the end of the second semester was to implement a Battleship game in Java, including rules management, GUI/player interface, at least two different computer players, and the ability to pit two bots together. Connecting two clients via TCP/IP was extra credit.
Second year of CS is taught almost entirely in C++ - more OO programming, pointers, and a solid year of datastructures. I think the most complex structures our class got to were AVL binary trees and B-trees. They also take the opportunity to teach you x86 assembly, since you're likely to be doing your second semester of Physics and digital logic design at the same time.
Third year is mostly applied stuff and theory - I did general study of GUIs and human-computer interaction, Theory of Computation (DFA/NFA/Turing machines), (R)DBMS theory and practice, Operating Systems theory, computer organization from an EE perspective, and some of the more esoteric language styles - Haskell, LISP, and other functional languages, Fortran, Smalltalk, etc.
First semester of my senior year - this fall - was artifical intelligence (Search and A*, intelligent agents, neural networks, genetic algorithms/particle swarms, brief overview of hillclimbing and simulated annealing, philosophical approaches to AI), advanced computer architecture/parallel computing theory and practice (study of SMP snooping bus architectures, memory and cache based directory architectures, CC-NUMA, and the PCI bus), and this spring I'm taking Analysis of Algorithms, Computer Graphics at the graduate level, and a senior seminar class on genetic algorithms.
What POS uni did you go to? Remind me not to hire anyone from there. No offense.
Although it's a painfully obvious troll, this one line just truly made me belly-laugh for the first time in 2002:
"real professional formats like MP3"
MP3, quite probably the most famous high-range-butchering format in existence, the whole design revolving around stripping out all but the very roughest shape of the sound... called a real professional format?
A truely masterful troll would have pointed out that real professionals work in uncompressed 44.1 (or 48 or 96) kHz PCM, occasionally with some extra tracking/synching information - and not only would you have gotten a few bites about the file size differences from the non-audiophiles, you might have even gotten an Insightful mod at the same time for pointing it out;)
One thing people should consider is that while Genetic Algorithms are neat, they are limited.
Here's the fundamental decoder-based GA:
* Take an array of N identically long bits.
* Write a function, called the fitness function, that considers a single element in the array as a solution to your problem, and rates how good that solution is as a floating point number. Rate every bit string in the population of N.
* Take the M strings with the highest ratings. Create N-M new strings by randomly picking two or more parent strings, randmoly picking a spot or two in them, and combining the two parts of them.
* Rinse and repeat until the entire population is identical.
Their main limitation is that they take a lot of memory. Take the number of bits in a genome, multiply by population size, and your processing time grows exponentially with both population size and parent genome grouping. The other problem is that they require that the problem have a quantifiable form of measurement - how do you rate an AI as a single number?
The other problem is commonly called the "superman" problem - what happens if you get a gene by chance very early in your generations that rates very very high, but isn't perfect. Imagine a human walking out of apes, albeit with only one arm. It'll dominate the population. GAs do not guarantee an optimal solution. For some problems, this isn't a problem, or it can be avoided, or reduced to a very small probability. For others, this is unacceptable.
That said, you can do some neat shit with them. This screenshot is from a project I did during undergraduate studies at UP, geared towards an RTS style of game, automatically generating waypoints between a start and end position. I'll probably clean it up sometime, add a little guy actually walking around the landscape, stick it in my portfolio. Yay, OpenGL eye candy.
BeOS was/is a commercial OS, based on a microkernel, and POSIX-compliant enough that you could compile and run more than a few UNIX console apps on it. It was one of the first OSes to use a journaling filesystem as the default FS, but could read a pretty wide variety of other filesystems, including FAT/NTFS, ext2fs iirc, Mac drives, and a few others. It was marketed as a multimedia-oriented OS, and that was certainly true: it was rock stable, booted fast, had a solid integrated video system and OpenGL support built into the OS, had good filesystem performance and decent network drivers.
It also was available in a cut-down form for free on the web, but they've now removed that. (I luckily burnt it on one of my backup CDs a year ago.) The main limitation was that it had one 512MB partition that was created as a file on an existing FAT or NTFS fs, but once it was running, you could copy it over to a spacier install.
However, there weren't nearly enough drivers, and not enough freeware developer support, so it stayed a niche operating system until the end. Although I know some composers (live AND tracker) that still do their editing work with a Be-based PC on one side and a Mac on the other.
Ethernet over TP implements a link integrity signal. AUI does not. That's the main barrier to using this particular rig - you'd have to come up with an emulator for that signal, or the cards would refuse to transmit.
(And FYI, you're partly right. Ethernet over TP uses Manchester encoding, which means that it watches for changes in logic rather than states - i.e. transitioning from ground to 5V is a 0, and 5V to ground is a 1. Hard drives actually also use this method.)
Has anyone else bothered to read this enough to notice that it will not work with twisted pair Ethernet? It requires an AUI connection. They even say in the FAQ, redesigning it to work with TP would be a pain in the arse.
In order to use the circuit, you have to either buy an AUI->TP transciever, or set up a bridging machine.
Just saving a bit of time for some people who are no doubt running out to Ripoff Shack grabbing l33t bl00 leds.
I would disagree. Computer science is about application of principles, but programming tends to not be. CS tells us what P and NP and P-space and the rest of the goddamned classes in the pyramid are, it lets us quantify how long a quicksort runs on average, why trees are handy and why they work at all, what we can and can't compute (Turing's Halting Problem) and what qualifies intelligence (the Chinese Room problem in AI research). CS takes the theories and concepts that underlie implementation, and can be broken down into its fundamental laws.
Programming, on the other hand, at least as I see it, has a lot to do with technical anecdotes. For example, in C, typedef'ing a struct with the tag underscored, so that you can type just "link" instead of "struct _link" every time you touch a node in a linked list. Or, writing a fuzzy routine that decides whether to inline or outline the clause of an if function in a compiler, or knowing that NVidia cards have funky OpenGL fog processing under certain driver versions, and that under Windows you have to manually notify child windows of font changes. Computer Science is a pure science - Programming is more akin to engineering and applications of pure science in the real world. x86 is an application of a Von Neumann architecture, the Haskell language is an application of higher-order functions.
Good computer scientists can be good programmers, but aren't necessarily. I number many CS degree holders among my colleagues and friends who can't hack their way out of a paper bag. At the same time, I know many who can.
Maybe it's fun to write something for the HELL of it, and not worry about it being useful. I'm sure whoever came up with linked lists back in the 60s was confronted by someone saying "they're so much slower than arrays - what's the point?"
Who gives a rat's ass if it's not useful to you? It's useful to the author, because he's learned a lot doing it, and he doesn't owe you shit. He probably doesn't give a fuck what you think about it, either.
Well, they don't evolve by themselves. However, they can be programmed to:-) Evolutionary computation has been SOTA in computer science for the last twenty years, and is slowly moving into mainstream.
You might find it worthwhile to do some research on the primary three EP techniques at the moment:
- genetic algorithms (create a function to translate a string of bits into a possible "answer" and grade it on a 0.0-1.0 scale, then splice the best-ranking strings together to make new ones, i.e. survival of the fittest)
- particle swarms (create a bunch of particles in 3d space that can suggest to other particles around them to move in a certain direction, like ants with pheromones, and the particles converge on one or more points in space)
- simulated annealing (I don't understand this well enough to give a good explanation:-( )
GAs in particular have proven to be useful, since they can converge on a good (altho possibly nonoptimal) solution VERY quickly. In a recent experiment, an engineer implemented a GA in a prosthetic arm to act on nerve impulses. The traditional "clamper" arm takes about six months of training for a person to control it well. The GA chip adapted fully to the person in fifteen minutes.
ZeRo4 uses a M$FT ball mouse (which is pretty unusual, most gamers are using either a Logitech Wingman Gamer, an optical, or a Boomslang a la Fatality), the keyboard doesn't really matter. The monitor, machine, etc are provided by the tournament to ensure everyone has the same equipment.
To everyone wondering about the power sources on the HotSync cradles, one thing to keep in mind is that serial ports are built to take much higher AND lower voltages than the palm cradle. Those run off 5V IIRC...
Serial ports are built to the EIA-RS232 spec, which requires it to handle at least -10V to 10V to barely come within spec. Recommended tolerance for EIA-RS232 is an even larger swing.
About the only thing I can see is that there was a short, and it toasted the UART. Since many systems are integrating the UART onto the southbridge, this could be a possibility. However, I doubt this will ever make it to class action status. Palm will pay for the mobos and fix the cradle's design, and that will be that.
The Patriot system actually couldn't track Scuds for more than a few seconds - want to know why? They didn't use enough bits for the numbers in the internal calculations, and they didn't check for overflows, which means that on every confirmation-of-missile pass the view window was 60 or so feet closer to ground than where it should have been, and the Patriot wouldn't launch, beliving it to be a false alarm.
Paraphrased from a recent college text on number representation in binary and computer arithmetic.
Slashdot Mirror
Blogs = shorthand for weblogs = people's journals online. Either their own sites, or a communal system like LiveJournal that allows people to collate the most recent entries by their friends into a single site and link together webs/communities of people by interest.
"An Introduction to Quantum Computing Algorithms" by Arthur Pittenger, published by Birkhauser. 1999 text - I'm actually taking a class on QC at the moment. Starts out with a review of quantum statics (you will need a good grounding in Heisenberg's interpretation of QM and linear algebra, make no mistake) and then dives into the basics of quantum computing, covers the major algorithms of the last few years (Deutsch-Jozsa, Simon, Grover, Shor, and finite Fourier transforms), and error correction.
Shor's algorithm was 1994.
More than a few hundred qubits will be needed, also. Shor's algorithm requires two registers of length N. Most Diffie-Hellman keys these days are 1024 bits, with some larger. I don't expect to see it in my lifetime, honestly. But when it does, there will be a shitstorm to beat all shitstorms. Some folks need to get cracking on an encryption process that doesn't rely on the intractability of factoring... they've got maybe 50 years to do it.
Try to learn at least one of the theories of quantum mechanics before you start throwing around principles, okay?
For one thing, QCs do exist - in fact, they demonstrated Peter Shor's 1994 factoring algorithm on a recently built 7-qubit box, factoring 15 into 3 and 7. You may say big deal, but it can factor ANY such integer in polynomial time. Usually the NSA is about 10 years ahead of the private sector, so I figure they've got at least 10 qubits by now. You should be worried - most public-key encryption methods rely on the intractibility of factoring.
Secondly, the Heisenberg uncertainty principle only states that you can't predict with 100% accuracy which eigenstate a qubit will collapse into upon measurement. You can, however, compute a probability amplitude (which ends up being a complex number) that it'll be a 0 and another probability that it will be a 1. And it is possible to perform operations upon one or more qubits without measuring it - the idea of creating an operation that doesn't collapse the state is the crux of Quantum Computing.
Unlike macroscopic physics, we don't know WHY things work on the quantum level the way they do. We've gotten relatively decent at predicting the end results though. So, we're just as confused as before... but we're capable of doing useful stuff with it. Don't knock it.
Umm... boolean gates were created a long, long time ago in QC. Hell, I have a textbook that lists the matrices for them.
(For those uninitiated, under the Heisenberg interpretation of Quantum Mechanics, you can view any quantum computer's state as a vector space, in which operations are unitary matrices, and making an observation collapses the Schrodinger wave into an eigenvalue.)
For that matter, the same textbook stops using Dirac notation in the latter three quarters of the book, and uses the quantum equivalent of NOTs and XORs as a sort of wiring guide, denoting entanglement and superposition as necessary, to construct a ripple carry adder. This is shortly before it starts diving into Grover's and Shor's algorithms, among others.
A recent 2.4 kernel release corrupted ext2 and ext3 filesystems.
Lambda lists are part of functional languages, which often feature what's called higher order functions. This means that functions are a data type in and of themselves, and you can write functions that take functions as arguments, modify them, and output new functions as results.
:: Int -> Int -> Int
...]
:)
Here's a quick example from Haskell:
addxy
addxy a b = a + b
map addxy [1 2 3
map will take the function addxy, apply it to each of the elements in the array (which is infinite) and return an array of results. However, the array only supplies one argument, so what you get back is an array of addxy functions with one argument hardcoded. add 1, add 2, add 3, etc. This is actually a type of lambda lists called curried functions, but you get the idea.
Haskell's a killer language - you should check it out. Any language that allows implementing a polymorphic quicksort in three lines turns me on
AC = Asheron's Call - run by Turbine and Microsoft.
Ever heard of a diskless terminal? That's essentially what you're talking about - a Tektronix X term. Holds a small CPU, NIC, two SIMMs, and keyb/mouse/video. The problem with it is latency.
Although you are getting your wish as far as ribbon connectors - many companies are moving to Serial ATA. However, I think you would run into massive latency issues if you kept the cables so long as to reach another room. Transmission isn't instantaneous - whether you're transmitting over copper or fiber - and clock skew is a bitch.
I also find it relevant to point out that the x86 is not a readily virtualizable chip. VMWare has to make BIOS modifications to pull it off. And as for pure software emulation... look at the Bochs project, which is quite well regarded and supported, and is only up to the original Pentium. The x86 is notorious for having lots of little sideeffects and tricks/traps that make it a pain in the ass to duplicate. And, if you really want to make emulating the xbox interesting, the P6 family of processors is based on a microcode architecture... upload some new microcode, and whee, the behavior of the chip just changed until the power is reset!
The magical part of the xbox is the memory architecture. It may use standard SDRAM, but it uses a unified memory addressing scheme, which no existing PC uses - and in order to redirect it you'd have to trap every memory access made by the CPU, but this is AFTER you've reverse-engineered the northbridge to figure out what addresses map to actual chips, which addresses map to the sound card, to the video card, etc.
Not to mention that the HD has an IDE password chip, and in order to even dump the disc you have to first unlock it on a running xbox and then mux the IDE bus back into a PC. It's been done, but now they have raw bits. And believe me, MSFT is not going to be so silly as to make the HDD a standard FAT32 or NTFS drive. For that matter, I highly doubt the DVDs are in UFS format either.
The fact that the graphics hardware is made by NVidia and based on a GF3 core doesn't mean the full chip is a GF3, or that it uses the same pinout, or even the same surrounding support logic as an AGP card.
Tis better to shut thy mouth and be thought a fool, than to open it and remove all doubt.
Indeed - from a company that overcharges for its OS products and has its fingers in Office, games, etc. to back itself up.
Money makes the world go round...
Holy shit dude.
Here's the curriculum as I've taken it at University of Portland - I slept through all the classes until my junior year:
First year of CS:
* Introduction to basic programming theory using Java
* Basic foundations of coding: loops, arrays, etc
* Fairly heavy exposure to GUIs, TCP/IP through Java classes
* Mostly individual work, some group projects
As a good example, the group project used for the end of the second semester was to implement a Battleship game in Java, including rules management, GUI/player interface, at least two different computer players, and the ability to pit two bots together. Connecting two clients via TCP/IP was extra credit.
Second year of CS is taught almost entirely in C++ - more OO programming, pointers, and a solid year of datastructures. I think the most complex structures our class got to were AVL binary trees and B-trees. They also take the opportunity to teach you x86 assembly, since you're likely to be doing your second semester of Physics and digital logic design at the same time.
Third year is mostly applied stuff and theory - I did general study of GUIs and human-computer interaction, Theory of Computation (DFA/NFA/Turing machines), (R)DBMS theory and practice, Operating Systems theory, computer organization from an EE perspective, and some of the more esoteric language styles - Haskell, LISP, and other functional languages, Fortran, Smalltalk, etc.
First semester of my senior year - this fall - was artifical intelligence (Search and A*, intelligent agents, neural networks, genetic algorithms/particle swarms, brief overview of hillclimbing and simulated annealing, philosophical approaches to AI), advanced computer architecture/parallel computing theory and practice (study of SMP snooping bus architectures, memory and cache based directory architectures, CC-NUMA, and the PCI bus), and this spring I'm taking Analysis of Algorithms, Computer Graphics at the graduate level, and a senior seminar class on genetic algorithms.
What POS uni did you go to? Remind me not to hire anyone from there. No offense.
Although it's a painfully obvious troll, this one line just truly made me belly-laugh for the first time in 2002:
;)
"real professional formats like MP3"
MP3, quite probably the most famous high-range-butchering format in existence, the whole design revolving around stripping out all but the very roughest shape of the sound... called a real professional format?
A truely masterful troll would have pointed out that real professionals work in uncompressed 44.1 (or 48 or 96) kHz PCM, occasionally with some extra tracking/synching information - and not only would you have gotten a few bites about the file size differences from the non-audiophiles, you might have even gotten an Insightful mod at the same time for pointing it out
One thing people should consider is that while Genetic Algorithms are neat, they are limited.
Here's the fundamental decoder-based GA:
* Take an array of N identically long bits.
* Write a function, called the fitness function, that considers a single element in the array as a solution to your problem, and rates how good that solution is as a floating point number. Rate every bit string in the population of N.
* Take the M strings with the highest ratings. Create N-M new strings by randomly picking two or more parent strings, randmoly picking a spot or two in them, and combining the two parts of them.
* Rinse and repeat until the entire population is identical.
Their main limitation is that they take a lot of memory. Take the number of bits in a genome, multiply by population size, and your processing time grows exponentially with both population size and parent genome grouping. The other problem is that they require that the problem have a quantifiable form of measurement - how do you rate an AI as a single number?
The other problem is commonly called the "superman" problem - what happens if you get a gene by chance very early in your generations that rates very very high, but isn't perfect. Imagine a human walking out of apes, albeit with only one arm. It'll dominate the population. GAs do not guarantee an optimal solution. For some problems, this isn't a problem, or it can be avoided, or reduced to a very small probability. For others, this is unacceptable.
That said, you can do some neat shit with them. This screenshot is from a project I did during undergraduate studies at UP, geared towards an RTS style of game, automatically generating waypoints between a start and end position. I'll probably clean it up sometime, add a little guy actually walking around the landscape, stick it in my portfolio. Yay, OpenGL eye candy.
BeOS was/is a commercial OS, based on a microkernel, and POSIX-compliant enough that you could compile and run more than a few UNIX console apps on it. It was one of the first OSes to use a journaling filesystem as the default FS, but could read a pretty wide variety of other filesystems, including FAT/NTFS, ext2fs iirc, Mac drives, and a few others. It was marketed as a multimedia-oriented OS, and that was certainly true: it was rock stable, booted fast, had a solid integrated video system and OpenGL support built into the OS, had good filesystem performance and decent network drivers.
It also was available in a cut-down form for free on the web, but they've now removed that. (I luckily burnt it on one of my backup CDs a year ago.) The main limitation was that it had one 512MB partition that was created as a file on an existing FAT or NTFS fs, but once it was running, you could copy it over to a spacier install.
However, there weren't nearly enough drivers, and not enough freeware developer support, so it stayed a niche operating system until the end. Although I know some composers (live AND tracker) that still do their editing work with a Be-based PC on one side and a Mac on the other.
Ethernet over TP implements a link integrity signal. AUI does not. That's the main barrier to using this particular rig - you'd have to come up with an emulator for that signal, or the cards would refuse to transmit.
(And FYI, you're partly right. Ethernet over TP uses Manchester encoding, which means that it watches for changes in logic rather than states - i.e. transitioning from ground to 5V is a 0, and 5V to ground is a 1. Hard drives actually also use this method.)
Has anyone else bothered to read this enough to notice that it will not work with twisted pair Ethernet? It requires an AUI connection. They even say in the FAQ, redesigning it to work with TP would be a pain in the arse.
In order to use the circuit, you have to either buy an AUI->TP transciever, or set up a bridging machine.
Just saving a bit of time for some people who are no doubt running out to Ripoff Shack grabbing l33t bl00 leds.
I would disagree. Computer science is about application of principles, but programming tends to not be. CS tells us what P and NP and P-space and the rest of the goddamned classes in the pyramid are, it lets us quantify how long a quicksort runs on average, why trees are handy and why they work at all, what we can and can't compute (Turing's Halting Problem) and what qualifies intelligence (the Chinese Room problem in AI research). CS takes the theories and concepts that underlie implementation, and can be broken down into its fundamental laws.
Programming, on the other hand, at least as I see it, has a lot to do with technical anecdotes. For example, in C, typedef'ing a struct with the tag underscored, so that you can type just "link" instead of "struct _link" every time you touch a node in a linked list. Or, writing a fuzzy routine that decides whether to inline or outline the clause of an if function in a compiler, or knowing that NVidia cards have funky OpenGL fog processing under certain driver versions, and that under Windows you have to manually notify child windows of font changes. Computer Science is a pure science - Programming is more akin to engineering and applications of pure science in the real world. x86 is an application of a Von Neumann architecture, the Haskell language is an application of higher-order functions.
Good computer scientists can be good programmers, but aren't necessarily. I number many CS degree holders among my colleagues and friends who can't hack their way out of a paper bag. At the same time, I know many who can.
Maybe it's fun to write something for the HELL of it, and not worry about it being useful. I'm sure whoever came up with linked lists back in the 60s was confronted by someone saying "they're so much slower than arrays - what's the point?"
Who gives a rat's ass if it's not useful to you? It's useful to the author, because he's learned a lot doing it, and he doesn't owe you shit. He probably doesn't give a fuck what you think about it, either.
Well, they don't evolve by themselves. However, they can be programmed to :-) Evolutionary computation has been SOTA in computer science for the last twenty years, and is slowly moving into mainstream.
:-( )
You might find it worthwhile to do some research on the primary three EP techniques at the moment:
- genetic algorithms (create a function to translate a string of bits into a possible "answer" and grade it on a 0.0-1.0 scale, then splice the best-ranking strings together to make new ones, i.e. survival of the fittest)
- particle swarms (create a bunch of particles in 3d space that can suggest to other particles around them to move in a certain direction, like ants with pheromones, and the particles converge on one or more points in space)
- simulated annealing (I don't understand this well enough to give a good explanation
GAs in particular have proven to be useful, since they can converge on a good (altho possibly nonoptimal) solution VERY quickly. In a recent experiment, an engineer implemented a GA in a prosthetic arm to act on nerve impulses. The traditional "clamper" arm takes about six months of training for a person to control it well. The GA chip adapted fully to the person in fifteen minutes.
ZeRo4 uses a M$FT ball mouse (which is pretty unusual, most gamers are using either a Logitech Wingman Gamer, an optical, or a Boomslang a la Fatality), the keyboard doesn't really matter. The monitor, machine, etc are provided by the tournament to ensure everyone has the same equipment.
To everyone wondering about the power sources on the HotSync cradles, one thing to keep in mind is that serial ports are built to take much higher AND lower voltages than the palm cradle. Those run off 5V IIRC...
Serial ports are built to the EIA-RS232 spec, which requires it to handle at least -10V to 10V to barely come within spec. Recommended tolerance for EIA-RS232 is an even larger swing.
About the only thing I can see is that there was a short, and it toasted the UART. Since many systems are integrating the UART onto the southbridge, this could be a possibility. However, I doubt this will ever make it to class action status. Palm will pay for the mobos and fix the cradle's design, and that will be that.
Turning the web server off is not enough - it will still crash it. Your only course of action is to either:
1) Contact your ISP, have your connection changed to a static IP if it isn't already, and use RFC1483 bridging.
2) Upgrade to version 2.4.2 of the CBOS firmware.
The Patriot system actually couldn't track Scuds for more than a few seconds - want to know why? They didn't use enough bits for the numbers in the internal calculations, and they didn't check for overflows, which means that on every confirmation-of-missile pass the view window was 60 or so feet closer to ground than where it should have been, and the Patriot wouldn't launch, beliving it to be a false alarm.
Paraphrased from a recent college text on number representation in binary and computer arithmetic.