Ok so you can't fit the human hearing's 130 dB dynamic range into the 96 dB dynamic range offered by 16 bits. Now take a $1500 Emotiva XPR-1 Mono Block amplifier. It only amplifies a single channel for all that money. It's not necessarily the best amp out there, but it sure is a very nice one. At 1 W, its SNR is 93 dB. So you won't fit the 16-bit dynamic range into it. Of course the SNR gets better at higher volume, and eventually you'll be able to fit 96 dB. But with 24 bits... You'll have 30 dB of dynamic range buried in amp noise. Then consider the average consumer. My $400 AVR has a 81 dB SNR at 1W, and could barely fit the 96 dB at max volume. At max volume, I don't want to be in the same room. It would be waaay to loud anyway. Also consider than an average quiet room registers at about 30 dB SPL. If you want 96 dB of dynamic range over that noise level, that would bring the total to 126 dB SPL, which is around thunder clap levels.
Oh! You meant that it has 17,425,170 decimal digits. Booooooooring!
Well, the etymology for "digit" is "finger", so it's first and foremost used for base 10. Binary digits have a special name, that you may know, which is a portmanteau of "binary" and "digit": it's a "bit".
Tom Murphy from the superb blog Do The Math does indeed go through all of the problems with that statement and many others, carefully analyzing about all energy sources and energy storage scheme that comes to mind. A very recommended read.
I concur: the Python shell is a very very powerful calculator given that you can define functions in the interpreter. There are many graphics packages for Python; Matplotlib is perhaps the most complete albeit not the symplest. As suggested above, installing Python with the IPython shell, NumPy and SciPy, enables the "PyLab" IPython mode, which is similar to what Matlab would offer in terms of graphics and computation integration.
Simpler to install and learn is perhaps Octave (with plots using GnuPlot), which would behave similarly. Although for the long term, I'd say learning the Python shell is more useful than learning Octave.
They do it by spending millions on computers, programmers, interconnects, and physical proximity and connectivity to exchanges. This gives them a fundamental and practically (for a small time player) unbeatable advantage over other users of the system, which is utterly against the spirit of a free market.
That got me thinking. Would a turn-based exchange be feasible? You know, with transactions all executed at predefined intervals? I guess the problem would still be who called dibs first on some offer, so the low ping advantage would remain when the offers are published. Maybe there could be a way in which the offers are propagated randomly as to not give any timing advantage?
Same thing here. Home theater stuff can generally be found at half the price in the US vs Canada. Same thing with kitchen and bathroom hardware. Also bizarrely I found some stuff that is "designed in Canada" and is distributed in the US but not in Canada. Using www.kinek.com and other border mail services, Canadians can benefit from free shipping (e.g. from Amazon.com) up to the border. Buying cars (typically a few $k less after taxes and duty and import regulations are taken care of) and tires (easily half the price) in the US is also popular.
While 3dB represents a factor 3 in *power*, sound pressure level (which is felt by the air) is proportional to displacement, not power. Thus it takes 6dB to double SPL. As previously mentioned, the human ear is not linear and will instead notice 10dB as a factor 2 in loudness.
In REAMDE, one of Stephenson's character is a prolific writer who is constantly active. He litterally lives on a threadmill. Being rich, he works in a room equipped with an industrial robot that supports keyboard, displays, and a head-tracking camera so that the whole setup is bobbing exactly in synchronicity with his head and arms.
I guess it *is* a solution. I'm just not sure anybody tried it for real yet.
A top-end BFG card would cost as much as I spent recently on a PS3 + 3 games bundle; no wonder the market for expensive video cards tanks: the current-gen consoles are now half their initial prices and a lot of people want to experience gaming on their new HD television set, which also cost a fraction of what it did a few years ago.
Does this mean one less reason (scientific field) to use commercial Matlab and prefer free Sage/ActionPython/NumPy/SciPy/matplotlib?
I'm not sure about ActionPython -- why pay for a bundle of free components? But I for one am a long-time Matlab user, and I am slowly migrating towards Python (using numpy, scipy, matplotlib, ipython, etc.). Migration is slow mainly because I have to recode some of my own Matlab tools, but so far it's been succesful. Not painless mind you, as the differences in numpy and Matlab can cause really subtle bugs.
So while it's great that ActivePython now gets numpy and matplotlib, I wouldn't say there is one less reason to use Matlab since those components were already available anyway...
Well this D-Drive resembles the Thompson coupling in that they both seem new but they're really not. The Thomson coupling is a (admittedly nicely packaged) double cardan joint, while the D-Drive is a powered-planetary, already used in infinitely variable transmissions before. I'm not sure if that particular arrangement existed before, and it's nice to see that novelty is still possible in basic mechanics, but similar devices with powered neutral already exist (for example in tractors).
A few quick comments on this well-informed post...
Price: you're right here, Matlab is expensive and is locking you down, but at least you get very decent support from The MathWorks.
Graphics: Matlab has a huge library of very usable graphics functions. However it is nonetheless lacking in certain areas. GUIs is one of them (you can only embed Matlab graphics in a Matlab GUI, and the various methods to build a GUI in Matlab mostly sucks compared to what is possible outside of Matlab). Also, while Matlab figures exported to other format (PDF, EPS, bitmaps) are fine, on-screen Matlab figures are not anti-aliased and sometimes present quirks that are not really there. Matplotlib uses the Antigrain library for screen output, so the end result is much more pleasing to the eye.
Speed: Using numpy, you benefit from the binary linear algebra subroutine (BLAS) speed, much as Matlab. Generic loops tends to be slower than Matlab because of Matlab's Just-in-Time (JIT) optimizer.
Documentation: I'll give you this one hands-down: Matlab has *excellent* documentation, written by experts in the field. This is an often neglected area, but clean and profuse documentation and examples allows you to do more things, much quicker.
Dev environment: very good in Matlab, but using any Python syntax-aware text editor + the IPython shell, I don't miss much when developing Python. Python is generally more consistent (e.g. you can define a multi-statement function interactively in the Python shell), which speeds up development. Also, Matlab is beginning to feel a namespace crunch. All functions in all toolboxes are in the same namespace in Matlab, and it's beginning hard to find creative new names for my own function, all the most if they replicate some Matlab's built-in capability. Python's namespace / module imports solves this problem very nicely.
Speed in interpreted languages such as Python and Matlab depends strongly on what it is doing exactly, and how it is done. For example, both Matlab and the numpy Python module use external, pre-compiled, and highly optimized basic linear algebra subroutines (BLAS) for things like matrix multiplication. Matlab ships with several different BLAS, but it's even possible for Matlab to use the ATLAS BLAS which numpy uses.
So the speed would be the same in that case, assuming both your Matlab installation and numpy are configured to use the same number of processors (linear algebra is typically highly parallel, and in huge matrix operations, multi-thread overhead will be negligible).
If you code your own matrix multiplication naively in C, you may end up with a factor of 6 or 7 in speed *below* that of Matlab.
However if we're talking about generic loops for example, C is then much, much faster. Matlab has a Just-in-Time (JIT) optimizer which vectorizes straightforward loops; the same for Python is not ready yet (this would be the Unladen Swallow project from Google I think). Depending on the precise morphology of a loop, very different speeds would be obtained in Matlab, C or Python. The lesson here is to use numpy or scipy precompiled and pre-optimized code whenever this is possible. But when it's done right, there's generally much less difference between Matlab, Python and optimized C than many people think.
As for your download speed, I'm surprised and curious.
Bell's throttling is active between 4 PM and 2 AM everyday. Outside of this period the download speed will be limited by other things -- such as swarm health and connexion quality.
3.5mm stereo minijack or stereo RCA all the way. No encryption, no DRM, just analog goodness. Sure you need an additional wire for power, but that's rarely a problem.
I use my old gen-4 iPod in my car exclusively. The funny part is that nowadays, it does not act as a player at all, only as a USB hard drive. My radio is the player, has a USB port, and read off the iPod. It's digital, it recharges the device, and completely bypasses the iTuneDB.
Of course I might as well use a USB key (and that's what I'll do when the iPod stops working), and I'm aware of the fact that this works as long as I don't need the player itself. However this shows that there often are alternatives to using analog signals or proprietary connectors.
Maybe I'm wrong here but I was under the impression that reading/dev/urandom produces pseudorandom bytes but only up to exhaustion of the entropy pool. A machine which sits there doing nothing during the night may have a low entropy pool, and thus may not be the most reliable alarm clock. Maybe you should read/dev/random instead...
Slashdot Mirror
The bubbly Tachikomas from Ghost in the Shell comes to mind when talking about combining legs and wheels...
I guess Android Nerds was too obvious...
"If the brain was so simple that we could understand it, we would be so simple that we couldn't"
- Lyall Watson
Maybe it won't turn out to be true, but there's that whole Godel's incompleteness thing in play here it seems.
Ok so you can't fit the human hearing's 130 dB dynamic range into the 96 dB dynamic range offered by 16 bits. Now take a $1500 Emotiva XPR-1 Mono Block amplifier. It only amplifies a single channel for all that money. It's not necessarily the best amp out there, but it sure is a very nice one. At 1 W, its SNR is 93 dB. So you won't fit the 16-bit dynamic range into it. Of course the SNR gets better at higher volume, and eventually you'll be able to fit 96 dB. But with 24 bits... You'll have 30 dB of dynamic range buried in amp noise. Then consider the average consumer. My $400 AVR has a 81 dB SNR at 1W, and could barely fit the 96 dB at max volume. At max volume, I don't want to be in the same room. It would be waaay to loud anyway. Also consider than an average quiet room registers at about 30 dB SPL. If you want 96 dB of dynamic range over that noise level, that would bring the total to 126 dB SPL, which is around thunder clap levels.
I think you can safely add Ridley Scott / Prometheus to your list...
Oh! You meant that it has 17,425,170 decimal digits. Booooooooring!
Well, the etymology for "digit" is "finger", so it's first and foremost used for base 10. Binary digits have a special name, that you may know, which is a portmanteau of "binary" and "digit": it's a "bit".
Tom Murphy from the superb blog Do The Math does indeed go through all of the problems with that statement and many others, carefully analyzing about all energy sources and energy storage scheme that comes to mind. A very recommended read.
I concur: the Python shell is a very very powerful calculator given that you can define functions in the interpreter. There are many graphics packages for Python; Matplotlib is perhaps the most complete albeit not the symplest. As suggested above, installing Python with the IPython shell, NumPy and SciPy, enables the "PyLab" IPython mode, which is similar to what Matlab would offer in terms of graphics and computation integration.
Simpler to install and learn is perhaps Octave (with plots using GnuPlot), which would behave similarly. Although for the long term, I'd say learning the Python shell is more useful than learning Octave.
To quote the late great George Carlin:
Just think of how stupid the average person is, and realize half of them are stupider than that.
That would be the median person, of course.
They do it by spending millions on computers, programmers, interconnects, and physical proximity and connectivity to exchanges. This gives them a fundamental and practically (for a small time player) unbeatable advantage over other users of the system, which is utterly against the spirit of a free market.
That got me thinking. Would a turn-based exchange be feasible? You know, with transactions all executed at predefined intervals? I guess the problem would still be who called dibs first on some offer, so the low ping advantage would remain when the offers are published. Maybe there could be a way in which the offers are propagated randomly as to not give any timing advantage?
What about SCO? Strange it wasn't mentioned at all.
Same thing here. Home theater stuff can generally be found at half the price in the US vs Canada. Same thing with kitchen and bathroom hardware. Also bizarrely I found some stuff that is "designed in Canada" and is distributed in the US but not in Canada. Using www.kinek.com and other border mail services, Canadians can benefit from free shipping (e.g. from Amazon.com) up to the border. Buying cars (typically a few $k less after taxes and duty and import regulations are taken care of) and tires (easily half the price) in the US is also popular.
While 3dB represents a factor 3 in *power*, sound pressure level (which is felt by the air) is proportional to displacement, not power. Thus it takes 6dB to double SPL. As previously mentioned, the human ear is not linear and will instead notice 10dB as a factor 2 in loudness.
In REAMDE, one of Stephenson's character is a prolific writer who is constantly active. He litterally lives on a threadmill. Being rich, he works in a room equipped with an industrial robot that supports keyboard, displays, and a head-tracking camera so that the whole setup is bobbing exactly in synchronicity with his head and arms.
I guess it *is* a solution. I'm just not sure anybody tried it for real yet.
so they're really only Alcubierre drive-equipped ships slowing down in our direction.
Ctrl-Alt-Del's review is a graphical representation of Ars Technica's review.
A top-end BFG card would cost as much as I spent recently on a PS3 + 3 games bundle; no wonder the market for expensive video cards tanks: the current-gen consoles are now half their initial prices and a lot of people want to experience gaming on their new HD television set, which also cost a fraction of what it did a few years ago.
Does this mean one less reason (scientific field) to use commercial Matlab and prefer free Sage/ActionPython/NumPy/SciPy/matplotlib?
I'm not sure about ActionPython -- why pay for a bundle of free components? But I for one am a long-time Matlab user, and I am slowly migrating towards Python (using numpy, scipy, matplotlib, ipython, etc.). Migration is slow mainly because I have to recode some of my own Matlab tools, but so far it's been succesful. Not painless mind you, as the differences in numpy and Matlab can cause really subtle bugs.
So while it's great that ActivePython now gets numpy and matplotlib, I wouldn't say there is one less reason to use Matlab since those components were already available anyway...
Well this D-Drive resembles the Thompson coupling in that they both seem new but they're really not. The Thomson coupling is a (admittedly nicely packaged) double cardan joint, while the D-Drive is a powered-planetary, already used in infinitely variable transmissions before. I'm not sure if that particular arrangement existed before, and it's nice to see that novelty is still possible in basic mechanics, but similar devices with powered neutral already exist (for example in tractors).
A few quick comments on this well-informed post...
Price: you're right here, Matlab is expensive and is locking you down, but at least you get very decent support from The MathWorks.
Graphics: Matlab has a huge library of very usable graphics functions. However it is nonetheless lacking in certain areas. GUIs is one of them (you can only embed Matlab graphics in a Matlab GUI, and the various methods to build a GUI in Matlab mostly sucks compared to what is possible outside of Matlab). Also, while Matlab figures exported to other format (PDF, EPS, bitmaps) are fine, on-screen Matlab figures are not anti-aliased and sometimes present quirks that are not really there. Matplotlib uses the Antigrain library for screen output, so the end result is much more pleasing to the eye.
Speed: Using numpy, you benefit from the binary linear algebra subroutine (BLAS) speed, much as Matlab. Generic loops tends to be slower than Matlab because of Matlab's Just-in-Time (JIT) optimizer.
Documentation: I'll give you this one hands-down: Matlab has *excellent* documentation, written by experts in the field. This is an often neglected area, but clean and profuse documentation and examples allows you to do more things, much quicker.
Dev environment: very good in Matlab, but using any Python syntax-aware text editor + the IPython shell, I don't miss much when developing Python. Python is generally more consistent (e.g. you can define a multi-statement function interactively in the Python shell), which speeds up development. Also, Matlab is beginning to feel a namespace crunch. All functions in all toolboxes are in the same namespace in Matlab, and it's beginning hard to find creative new names for my own function, all the most if they replicate some Matlab's built-in capability. Python's namespace / module imports solves this problem very nicely.
Speed in interpreted languages such as Python and Matlab depends strongly on what it is doing exactly, and how it is done. For example, both Matlab and the numpy Python module use external, pre-compiled, and highly optimized basic linear algebra subroutines (BLAS) for things like matrix multiplication. Matlab ships with several different BLAS, but it's even possible for Matlab to use the ATLAS BLAS which numpy uses.
So the speed would be the same in that case, assuming both your Matlab installation and numpy are configured to use the same number of processors (linear algebra is typically highly parallel, and in huge matrix operations, multi-thread overhead will be negligible).
If you code your own matrix multiplication naively in C, you may end up with a factor of 6 or 7 in speed *below* that of Matlab.
However if we're talking about generic loops for example, C is then much, much faster. Matlab has a Just-in-Time (JIT) optimizer which vectorizes straightforward loops; the same for Python is not ready yet (this would be the Unladen Swallow project from Google I think). Depending on the precise morphology of a loop, very different speeds would be obtained in Matlab, C or Python. The lesson here is to use numpy or scipy precompiled and pre-optimized code whenever this is possible. But when it's done right, there's generally much less difference between Matlab, Python and optimized C than many people think.
Probably not; hopefully they would spell "Aperture" correctly.
As for your download speed, I'm surprised and curious.
Bell's throttling is active between 4 PM and 2 AM everyday. Outside of this period the download speed will be limited by other things -- such as swarm health and connexion quality.
3.5mm stereo minijack or stereo RCA all the way. No encryption, no DRM, just analog goodness. Sure you need an additional wire for power, but that's rarely a problem.
I use my old gen-4 iPod in my car exclusively. The funny part is that nowadays, it does not act as a player at all, only as a USB hard drive. My radio is the player, has a USB port, and read off the iPod. It's digital, it recharges the device, and completely bypasses the iTuneDB.
Of course I might as well use a USB key (and that's what I'll do when the iPod stops working), and I'm aware of the fact that this works as long as I don't need the player itself. However this shows that there often are alternatives to using analog signals or proprietary connectors.
Maybe I'm wrong here but I was under the impression that reading /dev/urandom produces pseudorandom bytes but only up to exhaustion of the entropy pool. A machine which sits there doing nothing during the night may have a low entropy pool, and thus may not be the most reliable alarm clock. Maybe you should read /dev/random instead...