I was there last Wednesday - the Differential Engine II is built according to the specs Babbage laid out but they were unable to build it in his time - the Science Museum commisioned it I believe.
Apart from the Babbage stuff, the computer department wasn't too impressive IMHO. I did like the real WW2 V2 rocket they have on display - I didn't realize it was so huge till I saw it! And the actual Apollo 8 capsule that went around the moon (test-driving for the Apollo 11) was also neat.
Their display of seventeenth/eighteenth century measurement equipment on the third floor is also rather impressive, if you like that kind of stuff. I've had the pleasure to do some work on remote sensing measurement equipment calibration in the last years, so I can appreciate the difficulties that these guys had to overcome back then. They came up with quite a lot of clever tricks!
One nice feature of the science museum is that it is free to enter (as in beer;-)).... You have to pay a couple of pounds though for the LoTR exhibit.
The amount of money they allocate for this is quite ludicrously small. 250 million dollar would just about cover the cost of
one or two instruments on an Earth-Observation satellite. They are talking about multiple missions here,
including interplanetary, and manned.
For this kind of money you could probably fund a few feasibiltiy studies, perhaps build & launch one piece of
(unmanned!) space hardware as a prototype. I would assume that they want to follow this up with more funding, but I don't see
any mention of that in the bill. To achieve the goals they lay out, you would probably need somewhere between 1,000--10,000 times
this amount of money.
Only a mentally disturbed person would write a Python program with anywhere near 100,000 modules. Even my 1000 modules example sounds farfetched.:)
Sure. Still I fail to see any good reason why tar.gz or tar.bz2 would be preferable over zip for this particular situation. In cases like this, I would always favor the approach yielding O(1) behavior over the approach yielding O(number_of_files) behavior, even if number_of_files were usually small. it's a matter of software engineering ethics I suppose.
Really, the tar approached yield performance linear to the offset in the compressed file (that is just loosely approximated by the total of number of files. Now suppose your desired module file sits right after a 100MB file containing generated data that's also contained in the module (this kind of applications do exist in my line of work at least) - with tar.bz2 you would be in deep shit.
Ah well let's just agree to disagree or something:-)
Sure it could be done. However I was answering your original question: "why not also support from other archives?"
For things like this (dynamic module loading) the obvious choice is simply to use a format that has a TOC. For this kind of application, that is
a far more important consideration than saving a few percents of compression. That's also why Java's Jar files are in Zip format. It's just the right solution for this kind of problem.
For 1000 files you may not get burnt but I just did a benchmark on extracting the middle file from a 100,000 file ZIP, TAR, TAR.GZ, and TAR.BZ2, each file holding 1000 random bytes, no special compression flags used (default compression levels etc):
zip: 0.11 sec/retrieval
tar: 0.65 sec/retrieval
tar.gz: 3.1 sec/retrieval
tar.bz2 48 (!!!) sec/retrieval
So this does really start to matter for large archives; ZIP is practically O(1) while TAR and variants are O(length of file), on average cases, since they have to read (decompress) the entire file up to the point where the compressed data resides. Note also that BZip2 is really really slow.
I didn't realize gzip could concatenate files. How does that work? Just cat the resulting files together?
The answer to your first question is easy; zip-files have a table-of-contents, making random access to a certain file contained in the file fast. Tar files don't have this, and bzipped/gzipped tar files are still more difficult to use for this kind of application.
By the way, a little known (and sometimes useful) property of gzip is that it is allowed to concatenate gzip-files, and the resulting file will gunzip to the concatenated originals. This is not just a quirk, it's by design, and works for bzip2 too. Not for tar though which is a bit of a pity.
Nobody is shedding tears for *other* classes of workers that don't get better deals than they asked for -- computer consultants or plumbers or proctologists aren't getting any love
... And the proctologists, obviously, get the shittiest deal of them all.
I wonder how the/. community would have reacted on a story saying "there's this company that
wants to make software that can be used to censor DVD content".
Or better yet- "M$ will put a feature in their next MediaPlayer release that will give
the ability to auto-detect certain DVD titles and skip certain scenes".
I just wonder how many of us would be on the side of Microsoft if it came to that...
Just because the Good Guys are pursuing this one, I feel that many here are swayed in favor.
I for one feel that censoring a (possibly artistic) work amounts to intellectual rape, in extreme
cases, which for me outweighs the right of a buyer to mutilate his property.
On the other hand I do applaud the EFF for taking this stand, regardless of the eyebrows it will raise.
They claim that "there was this crack" or "we confused metrics" but at the very core of the problem they didn't understood the problem and the tools to solve it.
However much you may disagree, simple Newtonian dynamics and is all it takes to get a space probe from A to B in the vast majority of cases. It's a well-understood problem domain.
Dragging in stuff like chaotic long-term behavior of n-body systems, while an interesting fact in itself and worthy of study, has very little to do with the engineering problem at hand. Ephemerides for all major bodies in the solar system for the coming hundreds of years are known up to uncanny accuracies (metres) and plotting the trajectory of a probe is simply a matter of numerical integration, to put it bluntly.
Now when someone mixes up metres and feet things go awry. But don't claim stuff like this could have been prevented by hiring more mathematicians. It's simply a case of human error, something that happens in the Real World.
Having a high IQ, my friend, is no excuse for making stupid claims about things you don't know anything about.
Well a large part of my job is space-related (I'm a software engineer) and from what I have seen the three most important things are:
* be good at your specialism
* the ability to communicate with people that have a different specialism
* the willingness to learn a bit of domain knowledge (e.g. physics)
The fun thing about the space industry is that most people are highly motivated, and good at what they do - you won't last otherwise. Also, you
cannot go far without at least an M.Sc. degree in this world.
Although the economy is struggling a bit right now, people with truly good computer skills are rare, even in the space sector. I was pleaseantly
surprised to find that I could really contribute something there. Despite its image, space is really a quite conservative business with regard
to new technologies; the "proven technology" doctrine is quite strong for obvious reasons. New developments come by way of evolution rather that revolution, and you have to be able to work like that.
The best way to get into space-related work is via the industry; many big companies have a space division where most of the actual work is done.
The role for ESA is mostly setup and monitoring of projects; the big bucks (and therefore the most jobs) are with the companies that get the contracts. I don't know if the prime contractor(s) for GALILEO have already been established but that is probably where you should look.
If you take this line of reasoning to it's logical conclusion I would expect you to sell your computer tomorrow and send a couple of bucks to the aid agency of your choice. Now *why* don't you do that? Think about it; then scale up 6 orders of magnitude - and there's your answer why we do things like this.
When still in college, I upgraded the lab course for assembly programming. The lab course used to be PDP-11 based,
and we used a semi-working MS-DOS based emululator. We upgraded to PowerPC assembly - x86 was rightly regarded as way
too complicated as a starting point.
Making the new assignments and getting everything to work on the local computer setup (this included writing an
eery program that used TCP/IP to communicate between the PowerPC emulator and a custom-built terminal-emulator) took
the better part of three months.
While the lab course got much better, we were still getting complaints about doing 'non-mainstream' assembly (some
students complained that we didn't do x86). But we went to the trouble of explaining them why, which helped. I am
sure we would've stuck to PDP-11 if it wasn't for the terrible software: the PDP-11 is ideal as a learning device. It
is arguably the best example of proper orthogonal design in a microprocessor; better than PowerPC, and incomparably
better than x86. The fact that PDP-11 immediate addressing mode is just post-increment indirect access on the
program counter still brings tears to my eyes;-)
First bottom line: learning proper principles is much more important than learning a bleeding-edge technology. These
are often cluttered with performance-enhancing details that students cannot grasp when first approaching a subject.
After leaving college, you should be intellectually equipped to read specs and manuals of current and future designs.
While I agree that it is a good idea to pay some attention to current technology (it helps to convey insight into the
limitations of older technology), current technology usually has too many quirks for teaching a subject.
Second bottom line: revising a class taking a tremendous amount of work. In practice, this is probably what keeps
most lecturers from doing so.
I would recommend Mathematica for any serious work. It has (is) a beatiful functional language that allows you to express problems very consisely. This contrast greatly to most other math programs I have used, where you can often still smell the Fortran-66 legacy, or have much less expressive power (i.e., Maple, which has an imperative Algol/Pascal-like core language).
On top of that, Mathematica has probably the best GUI I've ever seen in any program; with some practice and twiddling of settings you can produce high-quality mathematical documents that get close to (La)TeX typesetting. Furthermore, the amount of mathematical knowledge and algorithms that it contains is quite formidable (about on-par with Maple, I'd say).
One other language you might consider is IDL (http://www.rsinc.com). Just mentioning it, since I didn't see any posts (and I have been doing a lot of work-related programming for it lately). It's in the same class as Matlab/Octave/Scilab, i.e., it does numerical computations pretty well but cannot do symbolic computation. It's quite big in astronomy and earth observation, but I suspect that has more to do with community inertia than the product's merits.
Slashdot Mirror
Actually, the speed of light is 299792458 m/s by definition/p>
So, given the frequency of your microwave a priori, this is actually a rather elaborate way of determining the length of a met{re|er} :-)
A cunning plan, were it not for the fact that mouse A would actually be younger than you would naively expect.
I suggest this course of action only when there will be a contest for the highest-mass mouse :-)
I was there last Wednesday - the Differential Engine II is built according to the specs Babbage laid out but they were unable to build it in his time - the Science Museum commisioned it I believe.
Apart from the Babbage stuff, the computer department wasn't too impressive IMHO. I did like the real WW2 V2 rocket they have on display - I didn't realize it was so huge till I saw it! And the actual Apollo 8 capsule that went around the moon (test-driving for the Apollo 11) was also neat.
Their display of seventeenth/eighteenth century measurement equipment on the third floor is also rather impressive, if you like that kind of stuff. I've had the pleasure to do some work on remote sensing measurement equipment calibration in the last years, so I can appreciate the difficulties that these guys had to overcome back then. They came up with quite a lot of clever tricks!
One nice feature of the science museum is that it is free to enter (as in beer ;-)) .... You have to pay a couple of pounds though for the LoTR exhibit.
The amount of money they allocate for this is quite ludicrously small. 250 million dollar would just about cover the cost of one or two instruments on an Earth-Observation satellite. They are talking about multiple missions here, including interplanetary, and manned.
For this kind of money you could probably fund a few feasibiltiy studies, perhaps build & launch one piece of (unmanned!) space hardware as a prototype. I would assume that they want to follow this up with more funding, but I don't see any mention of that in the bill. To achieve the goals they lay out, you would probably need somewhere between 1,000--10,000 times this amount of money.
'A recent stable Debian release', uhm.... Continents have been known to drift several miles in between stable Debian releases.
I'm a big Debian fan though. Unstable and testing are really quite useable these days.
Sure. Still I fail to see any good reason why tar.gz or tar.bz2 would be preferable over zip for this particular situation. In cases like this, I would always favor the approach yielding O(1) behavior over the approach yielding O(number_of_files) behavior, even if number_of_files were usually small. it's a matter of software engineering ethics I suppose.
Really, the tar approached yield performance linear to the offset in the compressed file (that is just loosely approximated by the total of number of files. Now suppose your desired module file sits right after a 100MB file containing generated data that's also contained in the module (this kind of applications do exist in my line of work at least) - with tar.bz2 you would be in deep shit.
Ah well let's just agree to disagree or something :-)
Sure it could be done. However I was answering your original question: "why not also support from other archives?"
For things like this (dynamic module loading) the obvious choice is simply to use a format that has a TOC. For this kind of application, that is a far more important consideration than saving a few percents of compression. That's also why Java's Jar files are in Zip format. It's just the right solution for this kind of problem.
For 1000 files you may not get burnt but I just did a benchmark on extracting the middle file from a 100,000 file ZIP, TAR, TAR.GZ, and TAR.BZ2, each file holding 1000 random bytes, no special compression flags used (default compression levels etc):
So this does really start to matter for large archives; ZIP is practically O(1) while TAR and variants are O(length of file), on average cases, since they have to read (decompress) the entire file up to the point where the compressed data resides. Note also that BZip2 is really really slow.
I didn't realize gzip could concatenate files. How does that work? Just cat the resulting files together?Yes. Cool, eh? :-)
The answer to your first question is easy; zip-files have a table-of-contents, making random access to a certain file contained in the file fast. Tar files don't have this, and bzipped/gzipped tar files are still more difficult to use for this kind of application.
By the way, a little known (and sometimes useful) property of gzip is that it is allowed to concatenate gzip-files, and the resulting file will gunzip to the concatenated originals. This is not just a quirk, it's by design, and works for bzip2 too. Not for tar though which is a bit of a pity.
It's what Slashdot pundits have been saying all along
Dammit! Now they're infringing on our IP! Why are we applauding this while we should be claiming a cool billion dollars in damages!?
... And the proctologists, obviously, get the shittiest deal of them all.
I wonder how the /. community would have reacted on a story saying "there's this company that
wants to make software that can be used to censor DVD content".
Or better yet- "M$ will put a feature in their next MediaPlayer release that will give the ability to auto-detect certain DVD titles and skip certain scenes".
I just wonder how many of us would be on the side of Microsoft if it came to that...
Just because the Good Guys are pursuing this one, I feel that many here are swayed in favor. I for one feel that censoring a (possibly artistic) work amounts to intellectual rape, in extreme cases, which for me outweighs the right of a buyer to mutilate his property.
On the other hand I do applaud the EFF for taking this stand, regardless of the eyebrows it will raise.
However much you may disagree, simple Newtonian dynamics and is all it takes to get a space probe from A to B in the vast majority of cases. It's a well-understood problem domain.
Dragging in stuff like chaotic long-term behavior of n-body systems, while an interesting fact in itself and worthy of study, has very little to do with the engineering problem at hand. Ephemerides for all major bodies in the solar system for the coming hundreds of years are known up to uncanny accuracies (metres) and plotting the trajectory of a probe is simply a matter of numerical integration, to put it bluntly.
Now when someone mixes up metres and feet things go awry. But don't claim stuff like this could have been prevented by hiring more mathematicians. It's simply a case of human error, something that happens in the Real World.
Having a high IQ, my friend, is no excuse for making stupid claims about things you don't know anything about.
Well a large part of my job is space-related (I'm a software engineer) and from what I have seen the three most important things are: * be good at your specialism * the ability to communicate with people that have a different specialism * the willingness to learn a bit of domain knowledge (e.g. physics) The fun thing about the space industry is that most people are highly motivated, and good at what they do - you won't last otherwise. Also, you cannot go far without at least an M.Sc. degree in this world. Although the economy is struggling a bit right now, people with truly good computer skills are rare, even in the space sector. I was pleaseantly surprised to find that I could really contribute something there. Despite its image, space is really a quite conservative business with regard to new technologies; the "proven technology" doctrine is quite strong for obvious reasons. New developments come by way of evolution rather that revolution, and you have to be able to work like that. The best way to get into space-related work is via the industry; many big companies have a space division where most of the actual work is done. The role for ESA is mostly setup and monitoring of projects; the big bucks (and therefore the most jobs) are with the companies that get the contracts. I don't know if the prime contractor(s) for GALILEO have already been established but that is probably where you should look.
If you take this line of reasoning to it's logical conclusion I would expect you to sell your computer tomorrow and send a couple of bucks to the aid agency of your choice. Now *why* don't you do that? Think about it; then scale up 6 orders of magnitude - and there's your answer why we do things like this.
Rosetta is an ESA project - metric system all the way. That doesn't guarantee a succesful Ariane-5 launch, unfortunately :-)
When still in college, I upgraded the lab course for assembly programming. The lab course used to be PDP-11 based, and we used a semi-working MS-DOS based emululator. We upgraded to PowerPC assembly - x86 was rightly regarded as way too complicated as a starting point.
Making the new assignments and getting everything to work on the local computer setup (this included writing an eery program that used TCP/IP to communicate between the PowerPC emulator and a custom-built terminal-emulator) took the better part of three months.
While the lab course got much better, we were still getting complaints about doing 'non-mainstream' assembly (some students complained that we didn't do x86). But we went to the trouble of explaining them why, which helped. I am sure we would've stuck to PDP-11 if it wasn't for the terrible software: the PDP-11 is ideal as a learning device. It is arguably the best example of proper orthogonal design in a microprocessor; better than PowerPC, and incomparably better than x86. The fact that PDP-11 immediate addressing mode is just post-increment indirect access on the program counter still brings tears to my eyes ;-)
First bottom line: learning proper principles is much more important than learning a bleeding-edge technology. These are often cluttered with performance-enhancing details that students cannot grasp when first approaching a subject. After leaving college, you should be intellectually equipped to read specs and manuals of current and future designs. While I agree that it is a good idea to pay some attention to current technology (it helps to convey insight into the limitations of older technology), current technology usually has too many quirks for teaching a subject.
Second bottom line: revising a class taking a tremendous amount of work. In practice, this is probably what keeps most lecturers from doing so.
There is of course one problem: teaching this subject matter at the pre-university level will upset a lot of parents...
Kids will start to question (especially) religion and some people seem to think this is bad.
I would recommend Mathematica for any serious work. It has (is) a beatiful functional language that allows you to express problems very consisely. This contrast greatly to most other math programs I have used, where you can often still smell the Fortran-66 legacy, or have much less expressive power (i.e., Maple, which has an imperative Algol/Pascal-like core language).
On top of that, Mathematica has probably the best GUI I've ever seen in any program; with some practice and twiddling of settings you can produce high-quality mathematical documents that get close to (La)TeX typesetting. Furthermore, the amount of mathematical knowledge and algorithms that it contains is quite formidable (about on-par with Maple, I'd say).
One other language you might consider is IDL (http://www.rsinc.com). Just mentioning it, since I didn't see any posts (and I have been doing a lot of work-related programming for it lately). It's in the same class as Matlab/Octave/Scilab, i.e., it does numerical computations pretty well but cannot do symbolic computation. It's quite big in astronomy and earth observation, but I suspect that has more to do with community inertia than the product's merits.