The wonders of fractal compression are a "dirty lie" of compression techniques. It happens to work well for classes of images with natural (self-repeating) subjects. Furthermore, it takes forever to find the right algorithm, and sometimes, the parameters/algorithm description is very large. Of course, sometime, you can never find the right algorithm to produce what you want.
Well, it wasn't hydrogen that was the problem with the airship. The skin was painted with a highly flammable paint. I believe it was made of a magnesium (!) compound.
If manufacturers just push how non-polluting fuel cells are, they'll be able to guilt people into using them instead of those messy, yucky chemical batteries.
SMP does not require a special application to take advantage of, only the operating system needs to support it (Windows 2000, XP Professional and Linux all do this).
It is useful if you like to do more than one thing at once. If you are like me and open up multiple instances of Netscape or IE, Word, MP3 players, all while burning a CD and hosting a Quake3 server, you would immediately experience the benefit from SMP.
Any multithreaded app can gain the benefit of SMP (not to mention running many simultaneously)
at 12:01 in a theatre will some of your closest friends. The whole time we were leaning forward with our mouths slackjawed, trying not to blink too much lest we miss something.
The one thing that was disappointing was the previews. Every one of them was flipped between cuts so fast that after 5 minutes or so, you felt like you were on speed. Thankfully, the opening credits to LOTR were calm, and unoverwhelming.
It's cool, they transmit packets that contain not only internal error correction information, but information about packets before and after (in decreasing degrees per level of checkbits). By watching the stream for long enough, you can get enough extra information to correct any string of bits (at the expense of decoder memory). This is why they were talking about XOR in the article. There's a lot of stuff about sparse bipartite graphs and modeling the required corrrection code transmission rates with differntial equations in the Tornado codes paper, so this isn't Mickey Mouse technology.
>However, what makes a good DAC is seldomly >discussed.
1) Precision crystal oscillators (for clock)
2) Copious amounts of capictance (for filtering)
3) Onboard extrapolation DSP for an overclocked, supersampling DAC (running at perahps 4x the sample rate). We do this to minimize the number of passive components needed to achieve a near-perfect reproduction. Perhaps we add an equalizer at this stage.
Suddenly this is a whole new audio component... you could also use a high-end audio card (NOT A SOUNDBLASTER) with a break-out box.
The DACs (digital to analog converter) are not capable of (and are not designed to if the player is well manufactured) outputting a square wave at 22 KHz. In fact, they can not recreate a true square wave at any frequency (it will be missing the high frequencies)
If you were to observe the output with an oscilloscope, you would see no "blocky" edges to the output, but a filtered representation. If the DAC driver filters are well designed, the output can in fact be EXACTLY reconstructed to the power limited by the frequency response of the system (x-22 KHz) with only the data recorded on the CD.
However, while the THD and noise floor of a CD player are very low, the dynamic range of the players are lacking. What would make them sound better is a logarithmic code instead of PCM (or a few more bits, hence 24-bit DVD audio)
bzip and gzip give poor results when compressing PCM audio data. bzip and gzip do good work when compressing repetative, discrete, spatially-oriented codes (like text), not widely varying and perceptive data (like photographs, data measurements, and audio). This is because their algorithms involve pattern matching.
Shorten uses techniques from linear prediction and correction to encoded audio data precisely.
that was used to make that really neat christmas tree logo for the topic. Who's responsible for that one, it looks really nice!
I know it's offtopic, but it really threw me for a second, I thought maybe it was a new category (then I realized it's been 11 months since the category was last used.)
BTW, someone buy me a Soul AVC player. That thing rocks!
Written in the form 2^k - 1, where k is also a prime number. They don't know if you can keep making these. There's no proof that an infinite number (or any finite bounded number) exists. They just find them by testing.
IPC isn't a part of any threading model. It's a method of process syncronization and message passing in Unix. Critical sections are a feature of threads, which exist in both environments, but can ALSO be simulated using seperate processes in Unix with IPC.
Also, there are no in-proc threads in Linux, don't forget. There's a library that makes it look like in-proc threads, but they are actually seperate processes. It's a clever trick, and thankfully Linux's scheduler is quite light and letting the kernel handle things works just fine.
I think that game was a not-to-ambitious but very entertaining platform game.
A technology demo was Yoshi's Island... (when he got high on those spores and everything started freaking out on screen, I went nuts with laughter.... so cool looking, but not as much fun/engaging as mario world)
Dreamcasts are powered by Hitachi's SuperH 4 CPU. This is a plain, run-of-the-mill 32-bit processor. It's got a 32-bit address bus too, just like your PC. I don't know who started the rumor that it's a 128-bit system, but it seems to stick. Maybe because it was released after the N64, they assumed that the size of the words had double for the next generation? Or maybe because it has a "128-bit wide vector FPU" engine. If this is so, then your Pentium MMX is also 128-bit with it's MMX instruction support (can do among other things 128-bit quadword operations).
If you can think of a reason why a video game console would need a number greater than 4x1024^3 to represent some integer quantity, I'd like to hear it.
Check this out while you're at it: http://mason.gmu.edu/~ngoldber/chip_truth.html
Because coroutines are not native structures of any popular programming languages and are dangerous pieces of hackery not suited for mere mortals. Most of us would rather have multiple processes and critical sections. Moreover, coroutines are an exception to the stack-based nature of many programs, and ruin any chance of debugging code that calls them until those functions have cleared the stack (Knuth himself found himself using assembly to achieve his ends). Finally, it is difficult to make such functions reentrant without making them context based (no local variables if you can help it).
and so on and so on. They are occasionally useful, but when I need them I just end up creating internal states or using "work contexts".
Ahem... but most library calls themselves invoke system calls to get the job done. I doubt pthread semaphores and mutexes are implemented without some help from the system (access to shared memory, putting threads into wait queues, etc.)
Furthermore, any library function that does the same thing as a system function will undoubtedly call the system function (fopen calls open, fork calls clone, etc.).
Perhaps this just reflects that the implementation of IPC in Linux, while complete, is not as fast or optimized as it should be. This is probably because everyone uses sockets, mmaps and stuff to do the same things, all of which are already fast, so nobody bitches enough about it to prompt someone to rework it.
Note that I make this statement purely from an observational standpoint; most code to apps I see forgo IPC for other methods. Would somebody care to give an example of some common Linux app that uses IPC heavily?
I wonder what the results would have been if he used the non-portable (non-pthread) interfaces to the sync/threading primitives in linux... because Windows gets an extra boost not having to go through a compatibility API. Are there non-pthread abstractions for mutexes and such? I don't know much about low-level threading stuff in linux beyond clone.
It works in Linux because of cdparanoia; the code of which is very careful and will read a sector over and over until it gets it right, even if the ECC bits are mangled. Also, this means *BSD, Solaris, etc. are also unaffected. I don't know what the Mac software does, but it's probably a lot more robust than CD Jukebox or whatever Windows users use. So, my question is, does WinDAC work? As I recall, it has it's own code for doing CDDA reads from a variety of drives.
Slashdot Mirror
The wonders of fractal compression are a "dirty lie" of compression techniques. It happens to work well for classes of images with natural (self-repeating) subjects. Furthermore, it takes forever to find the right algorithm, and sometimes, the parameters/algorithm description is very large. Of course, sometime, you can never find the right algorithm to produce what you want.
Wasn't that what I just said? When did I say a single-threaded app could suddenly run x times faster with SMP?
Well, it wasn't hydrogen that was the problem with the airship. The skin was painted with a highly flammable paint. I believe it was made of a magnesium (!) compound.
If manufacturers just push how non-polluting fuel cells are, they'll be able to guilt people into using them instead of those messy, yucky chemical batteries.
SMP does not require a special application to take advantage of, only the operating system needs to support it (Windows 2000, XP Professional and Linux all do this).
It is useful if you like to do more than one thing at once. If you are like me and open up multiple instances of Netscape or IE, Word, MP3 players, all while burning a CD and hosting a Quake3 server, you would immediately experience the benefit from SMP.
Any multithreaded app can gain the benefit of SMP (not to mention running many simultaneously)
at 12:01 in a theatre will some of your closest friends. The whole time we were leaning forward with our mouths slackjawed, trying not to blink too much lest we miss something.
The one thing that was disappointing was the previews. Every one of them was flipped between cuts so fast that after 5 minutes or so, you felt like you were on speed. Thankfully, the opening credits to LOTR were calm, and unoverwhelming.
I know too much about linux.
It's cool, they transmit packets that contain not only internal error correction information, but information about packets before and after (in decreasing degrees per level of checkbits). By watching the stream for long enough, you can get enough extra information to correct any string of bits (at the expense of decoder memory). This is why they were talking about XOR in the article. There's a lot of stuff about sparse bipartite graphs and modeling the required corrrection code transmission rates with differntial equations in the Tornado codes paper, so this isn't Mickey Mouse technology.
I never thought about it that way... very interesting explanation.
>However, what makes a good DAC is seldomly >discussed.
1) Precision crystal oscillators (for clock)
2) Copious amounts of capictance (for filtering)
3) Onboard extrapolation DSP for an overclocked, supersampling DAC (running at perahps 4x the sample rate). We do this to minimize the number of passive components needed to achieve a near-perfect reproduction. Perhaps we add an equalizer at this stage.
Suddenly this is a whole new audio component... you could also use a high-end audio card (NOT A SOUNDBLASTER) with a break-out box.
They do not ouptut square waves.
The DACs (digital to analog converter) are not capable of (and are not designed to if the player is well manufactured) outputting a square wave at 22 KHz. In fact, they can not recreate a true square wave at any frequency (it will be missing the high frequencies)
If you were to observe the output with an oscilloscope, you would see no "blocky" edges to the output, but a filtered representation. If the DAC driver filters are well designed, the output can in fact be EXACTLY reconstructed to the power limited by the frequency response of the system (x-22 KHz) with only the data recorded on the CD.
However, while the THD and noise floor of a CD player are very low, the dynamic range of the players are lacking. What would make them sound better is a logarithmic code instead of PCM (or a few more bits, hence 24-bit DVD audio)
bzip and gzip give poor results when compressing PCM audio data. bzip and gzip do good work when compressing repetative, discrete, spatially-oriented codes (like text), not widely varying and perceptive data (like photographs, data measurements, and audio). This is because their algorithms involve pattern matching.
Shorten uses techniques from linear prediction and correction to encoded audio data precisely.
that was used to make that really neat christmas tree logo for the topic. Who's responsible for that one, it looks really nice!
I know it's offtopic, but it really threw me for a second, I thought maybe it was a new category (then I realized it's been 11 months since the category was last used.)
BTW, someone buy me a Soul AVC player. That thing rocks!
Overture.com search for bulk email vendors
Then start clicking on links. You can see how much they have to pay next to each link. Sucks to be them!
mod up... because I can't do it myself.
What he says is very true. In fact, why aren't there filters for Photoshop and GIMP that would do this sort of thing?
Written in the form 2^k - 1, where k is also a prime number. They don't know if you can keep making these. There's no proof that an infinite number (or any finite bounded number) exists. They just find them by testing.
This is what people forget...
IPC isn't a part of any threading model. It's a method of process syncronization and message passing in Unix. Critical sections are a feature of threads, which exist in both environments, but can ALSO be simulated using seperate processes in Unix with IPC.
Also, there are no in-proc threads in Linux, don't forget. There's a library that makes it look like in-proc threads, but they are actually seperate processes. It's a clever trick, and thankfully Linux's scheduler is quite light and letting the kernel handle things works just fine.
... will be available on all consoles and the PC, at least, this is the plan. It will online and massively multiplayer.
I think that game was a not-to-ambitious but very entertaining platform game.
A technology demo was Yoshi's Island... (when he got high on those spores and everything started freaking out on screen, I went nuts with laughter.... so cool looking, but not as much fun/engaging as mario world)
Dreamcasts are powered by Hitachi's SuperH 4 CPU. This is a plain, run-of-the-mill 32-bit processor. It's got a 32-bit address bus too, just like your PC. I don't know who started the rumor that it's a 128-bit system, but it seems to stick. Maybe because it was released after the N64, they assumed that the size of the words had double for the next generation? Or maybe because it has a "128-bit wide vector FPU" engine. If this is so, then your Pentium MMX is also 128-bit with it's MMX instruction support (can do among other things 128-bit quadword operations).
If you can think of a reason why a video game console would need a number greater than 4x1024^3 to represent some integer quantity, I'd like to hear it.
Check this out while you're at it:
http://mason.gmu.edu/~ngoldber/chip_truth.html
Because coroutines are not native structures of any popular programming languages and are dangerous pieces of hackery not suited for mere mortals. Most of us would rather have multiple processes and critical sections. Moreover, coroutines are an exception to the stack-based nature of many programs, and ruin any chance of debugging code that calls them until those functions have cleared the stack (Knuth himself found himself using assembly to achieve his ends). Finally, it is difficult to make such functions reentrant without making them context based (no local variables if you can help it).
and so on and so on. They are occasionally useful, but when I need them I just end up creating internal states or using "work contexts".
Ahem... but most library calls themselves invoke system calls to get the job done. I doubt pthread semaphores and mutexes are implemented without some help from the system (access to shared memory, putting threads into wait queues, etc.)
Furthermore, any library function that does the same thing as a system function will undoubtedly call the system function (fopen calls open, fork calls clone, etc.).
Perhaps this just reflects that the implementation of IPC in Linux, while complete, is not as fast or optimized as it should be. This is probably because everyone uses sockets, mmaps and stuff to do the same things, all of which are already fast, so nobody bitches enough about it to prompt someone to rework it.
Note that I make this statement purely from an observational standpoint; most code to apps I see forgo IPC for other methods. Would somebody care to give an example of some common Linux app that uses IPC heavily?
Obligatory link: http://www-106.ibm.com/developerworks/linux/librar y/l-rt5/?dwzone=linux
I wonder what the results would have been if he used the non-portable (non-pthread) interfaces to the sync/threading primitives in linux... because Windows gets an extra boost not having to go through a compatibility API. Are there non-pthread abstractions for mutexes and such? I don't know much about low-level threading stuff in linux beyond clone.
It works in Linux because of cdparanoia; the code of which is very careful and will read a sector over and over until it gets it right, even if the ECC bits are mangled. Also, this means *BSD, Solaris, etc. are also unaffected. I don't know what the Mac software does, but it's probably a lot more robust than CD Jukebox or whatever Windows users use. So, my question is, does WinDAC work? As I recall, it has it's own code for doing CDDA reads from a variety of drives.
I just set options maestro dsps_order=2 in my modules.conf and I can open and write to /dev/dsp 4 times, simultaneously, in stereo.