matplotlib already does this in conjunction with Numpy and Scipy - its plotting quality and flexibility compares favourably to Matlab.
Its biggest drawback is that it is pretty glacial even by Matlab's standards when rendering large datasets (think millions of points). I'm not sure whether matplotlib or the interactive backend is at fault, but anything DARPA can do to improve the situation would be welcome.
Read the original SETI report (NASA SP-419) - from its inception, SETI didn't expect to overhear information-bearing signals. Instead, it was looking for deliberately generated 'beacons' - high-powered, spectrally dense transmissions. These should be detectable over distances of the order of several thousand light-years.
I seem to remember Autocad doing something like this. They used the dongle to decrypt a look-up table used in geometric transforms. If the LUT wasn't decrypted, subtle and cumulative errors would be introduced into the design which would only become noticeable after a week or two of use.
If used correctly, dongles are pretty damn hard to defeat. Ideally you use them to decrypt hunks of both your data and executable, then hide the significant decryption data amongst a blizzard of dummy calls to the dongle.
I'd have to agree - compared to proper packages like OriginPro (or even Matlab) Excel produces the most amateurish and ugly looking graphs. Simple tasks (like adding error bars) are made much harder than they should be. Data analysis options are non-existent, and forget about being able to export to EPS.
Hmm? Hypercubes are generally constructed using point-to-point links, not buses. Unless by bus you mean bidirectional links, but toroids often use bidirectional links as well.
But you're right, toroids constitute the most popular k-ary n-cube architecture today. Folded 3D toroids (eg. by Avici) are especially sweet (uniform, short interconnects, low diameter, huge path diversity).
While a few early parallel computers used hypercube based interconnects (eg, CM-1), there hasn't been a lot of interest in hypercubes since then. The advantage of hypercubes is that their diameter only increases logarithmically with the number of nodes in the network. Their disadvantage is that the node degree increases with the dimension, meaning that each node must be configured with sufficient ports to support the maximum dimensionality of the network -- making hypercube-based networks either expensive or non growable. (This can be solved to an extent by using cube-connected cycles.)
I concur, a router based on a standard PC architecture simply doesn't scale. For this reason, most high-end routers push as much of the work as possible out to the line cards, which are interconnected with a dedicated high speed backplane (often based upon a crossbar or 3D-torus).
Also, as the parent noted, doing longest prefix matching in anything other than hardware is a nightmare (and it's going to get worse with IPv6). Still, it seems that Vyatta is aiming more for the low/medium end of the router market so they may be able to avoid these problems.
It's not just the quality of the AI, it is how effectively it is put to use.
For example, the AI in Thief/Thief2 wasn't particularly advanced, even by the standards of the day - simple pathfinding and patrol paths, with AI behaviour linked to the alert status of that entity. However, unlike other games where the AI appears to be an afterthought, LGS made the AI in the Thief series integral to their level design and game-play philosophy. By making the AI react to player sounds and environmental cues such as blood stains/bodies/missing items they were made to appear much more intelligent than they actually were. The range of dialogue uttered by the AI made them appear more real than they would have been without it.
Yeah, this gives me the shits as well. Many people here seem have gotten into their little heads that FPGAs == programmable hardware == open source goodness. They do this with little understanding of FPGA technology and its limitations.
FPGAs (especially the big/high speed grade devices) are *very* expensive, and while impressive gate density is being achieved, their performance is constrained by their internal interconnect topology and technology. Consequently, FPGAs are good for glue logic, specialised functions (e.g., bit-serial designs, network processors) but bad at most others (e.g., general purpose processors, signal processing, performing vector operations). More often than not a cheaper and faster solution is to just use a uC.
Depends. From what I can gather, the author is trying to send an array of integers to the serial port. To do this, the uC forms a character string from the array of integers using sprintf() then sends the string. This is a pretty inefficient way of doing things (particularly given the bloat in avr-libc's string handling).
A much better idea would be to set the USART to use 8 data bits and then send the array 1 byte at a time - trivial if you are using 8-bit integers, but requires a 16-bit integer to be sent as two bytes - and stitching the data back together at the host PC end. PC resources are cheap, uC resources are scarce.
I couldn't find any reference to what type of Atmel microcontroller this project uses - I guess it must be one of the smaller ones considering the amount of flash is an issue. But yeah, the Atmel series of microcontrollers is great to play around with, particularly the ATMEGA128.
Slashdot Mirror
matplotlib already does this in conjunction with Numpy and Scipy - its plotting quality and flexibility compares favourably to Matlab.
Its biggest drawback is that it is pretty glacial even by Matlab's standards when rendering large datasets (think millions of points). I'm not sure whether matplotlib or the interactive backend is at fault, but anything DARPA can do to improve the situation would be welcome.
Read the original SETI report (NASA SP-419) - from its inception, SETI didn't expect to overhear information-bearing signals. Instead, it was looking for deliberately generated 'beacons' - high-powered, spectrally dense transmissions. These should be detectable over distances of the order of several thousand light-years.
I seem to remember Autocad doing something like this. They used the dongle to decrypt a look-up table used in geometric transforms. If the LUT wasn't decrypted, subtle and cumulative errors would be introduced into the design which would only become noticeable after a week or two of use.
If used correctly, dongles are pretty damn hard to defeat. Ideally you use them to decrypt hunks of both your data and executable, then hide the significant decryption data amongst a blizzard of dummy calls to the dongle.
Put simply, the problem set that vector processors are geared towards (those involving large matrix ops) are the type clusters perform horribly at.
I'd have to agree - compared to proper packages like OriginPro (or even Matlab) Excel produces the most amateurish and ugly looking graphs. Simple tasks (like adding error bars) are made much harder than they should be. Data analysis options are non-existent, and forget about being able to export to EPS.
Hmm? Hypercubes are generally constructed using point-to-point links, not buses. Unless by bus you mean bidirectional links, but toroids often use bidirectional links as well.
But you're right, toroids constitute the most popular k-ary n-cube architecture today. Folded 3D toroids (eg. by Avici) are especially sweet (uniform, short interconnects, low diameter, huge path diversity).
While a few early parallel computers used hypercube based interconnects (eg, CM-1), there hasn't been a lot of interest in hypercubes since then. The advantage of hypercubes is that their diameter only increases logarithmically with the number of nodes in the network. Their disadvantage is that the node degree increases with the dimension, meaning that each node must be configured with sufficient ports to support the maximum dimensionality of the network -- making hypercube-based networks either expensive or non growable. (This can be solved to an extent by using cube-connected cycles.)
I concur, a router based on a standard PC architecture simply doesn't scale. For this reason, most high-end routers push as much of the work as possible out to the line cards, which are interconnected with a dedicated high speed backplane (often based upon a crossbar or 3D-torus).
Also, as the parent noted, doing longest prefix matching in anything other than hardware is a nightmare (and it's going to get worse with IPv6). Still, it seems that Vyatta is aiming more for the low/medium end of the router market so they may be able to avoid these problems.
It's not just the quality of the AI, it is how effectively it is put to use.
For example, the AI in Thief/Thief2 wasn't particularly advanced, even by the standards of the day - simple pathfinding and patrol paths, with AI behaviour linked to the alert status of that entity. However, unlike other games where the AI appears to be an afterthought, LGS made the AI in the Thief series integral to their level design and game-play philosophy. By making the AI react to player sounds and environmental cues such as blood stains/bodies/missing items they were made to appear much more intelligent than they actually were. The range of dialogue uttered by the AI made them appear more real than they would have been without it.
Yeah, this gives me the shits as well. Many people here seem have gotten into their little heads that FPGAs == programmable hardware == open source goodness. They do this with little understanding of FPGA technology and its limitations.
FPGAs (especially the big/high speed grade devices) are *very* expensive, and while impressive gate density is being achieved, their performance is constrained by their internal interconnect topology and technology. Consequently, FPGAs are good for glue logic, specialised functions (e.g., bit-serial designs, network processors) but bad at most others (e.g., general purpose processors, signal processing, performing vector operations). More often than not a cheaper and faster solution is to just use a uC.
Depends. From what I can gather, the author is trying to send an array of integers to the serial port. To do this, the uC forms a character string from the array of integers using sprintf() then sends the string. This is a pretty inefficient way of doing things (particularly given the bloat in avr-libc's string handling).
A much better idea would be to set the USART to use 8 data bits and then send the array 1 byte at a time - trivial if you are using 8-bit integers, but requires a 16-bit integer to be sent as two bytes - and stitching the data back together at the host PC end. PC resources are cheap, uC resources are scarce.
I couldn't find any reference to what type of Atmel microcontroller this project uses - I guess it must be one of the smaller ones considering the amount of flash is an issue. But yeah, the Atmel series of microcontrollers is great to play around with, particularly the ATMEGA128.