It's also not a good analysis. So, when you design one of these multiple choice tests you should have in mind what you're trying to test. You probably want a pass mark to be around 70/100. You can do scoring in three ways: one, just count the right answers, two, right answers minus wrong answers, three you can have a weighting (so there may be a best answer for +3, an OK answer for +1 and a bad answer for -5 or something).
You don't really care about ranking people, you just want a pass or fail (or maybe one or two more groupings, but not too many). So trying to see whether the guy who got 1/100 is really a lot worse than the guy who got 2 is not interesting, you don't want either guy.
If you want to test knowledge and a bit of (basic) problem solving, then you can just add up the right answers. If you know a lot, you'll know more answers and you'll know more wrong answers so you'll make better guesses for the questions you don't know. This isn't always appropriate, though. It's probably right for a law test, where you know that no lawyer will know all the law, but they might sometime be asked to give an answer now on some point they haven't learned - and they'll need to say something that at least doesn't make them look like an idiot in court. But if you are testing doctors, say, you probably do not want them to be making guesses about the right drug to put into someone, because the consequences of getting it wrong are bad. So it's probably a good idea to penalise for wrong answers here.
Of course, if you start weighting answers you can make the test do whatever you want, but then it's a real pain to design.
To those who have never worked in a maths journal: you don't have ads, you don't paste a PDF, instead you ask for the source LaTeX, you don't need to use linux to get LaTeX (I don't, I use Wordpad and miktex) and most maths journals simply say: first submission, PDF or maybe PS, on acceptance send the LaTeX and the figures, if you can't do that we will charge you retyping fees for any other format. There is a reason for this, and it is that anything other than LaTeX makes more work for the editors.
Most journals get round this by giving you a list of things that you may not do in the latex you send them (no hard breaks, no font changing beyond italics emphasis), or having a public house-style package (or both). Then it's pretty easy to house-style it.
I'm not quite sure what you mean here - OK, not appropriate if you want to produce an advert or something, but that's not what LaTeX is for.
Assuming the content is sensible, the styling you get will be readable (which is most of what's important for a paper in a journal) and the journal can (assuming the author hasn't done unpleasant things to get his own style in the document) simply tack their styling headers onto essentially the original LaTeX to get an output in the journal's style - that means that you can publish ten papers that look like they belong together (i.e. the styling doesn't change from one to the next) in an issue with not too much effort, rather than having to pay a staff to retype all the papers into a house style.
OK - probably they've updated equation editor since I last tried to use it five years ago.
As far as drawing objects go, Word occasionally screws up drawing positions whether or not they're equations. In any case, I can't send a word document to any journal I want to submit to (combinatorics) and therefore I don't want to use it.
It _can_ include jpeg, since I've tried - but agreed that it's not a clever thing to do. I suppose that if you want something that doesn't really go with vector graphics PNG would do.
I don't really see any conflicts here. If you submit to a journal, you don't send them source LaTeX initially, because then you have to send 15 eps graphics separately as well and then they have to muck about compiling it. It's easier (for both of you) to send them the compiled PDF or PS, which they can open, see it looks like mathematics, and bounce to an appropriate referee in a few minutes. Then after the referee reads it, the journal can come back and tell you to send along the LaTeX and graphics for publishing.
When you use LaTeX you get what you wanted fairly quickly, and it comes out the same on any computer anywhere, and you end up with PDFs that do the same, so you can take them to a conference. And journals accept it.
When you use MS word it takes forever to get anything like what you wanted (subscripts on superscripts, tower-type functions?), then when you change something elsewhere in the document or email it to a coauthor something breaks and the equations get changed. And you end up trying to use powerpoint to do presentations, which means you take it to a conference and what appears on the screen is a bunch of hearts and spades instead of the right symbols (seen this happen, just once). Which is why journals generally don't accept it.
LaTeX predates MS word, anyway. Before that, you sent a handwritten or typed paper to the journal, which again isn't going to get there and have all the equations different to how they looked when you wrote it.
That said, if I was trying to write a paper with lots of detailed diagrams I might not want to use LaTeX; it's fine for line and block diagrams (which is all I need for combinatorics papers) via xfig, but I wouldn't want to try to, say, draw some anatomical thing. And it doesn't really seem to handle jpeg inclusion very nicely.
I'd guess this is essentially where the law in question comes from. If you go around (in the UK) carrying that sort of thing, then you can be picked up and done for going equipped. Obviously a (proper) locksmith is allowed to, but they are also supposed to be registered.
I suspect the Germans have simply thought, well we already have a law against wandering around carrying a slimjim and a lockpick, why not extend it to computers. Unfortunately they haven't thought about the fact that making houses secure is pretty easy (good locks and a burglar alarm) and you don't really need to check it, while making a network secure is not so easy and it is a great help to be able to check by trying to hack in to your own network and stopping any holes you find that way.
The type of library that is a copyright library (i.e. receives a copy of every published book) rather than a public library (which is what you are thinking of). Think about e.g. university libraries, the British Library, the Library of Congress, that sort of thing. Obviously a public lending library isn't going to want one of these things, but then you don't go to a public library when you want to find a bit of obscure data.
A T1 doesn't really guarantee you bandwidth: it's pretty normal for an ISP to play the same game with T1s that they do for DSL and cable. Same way a plane ticket stating that you will go on this flight doesn't guarantee you a seat, companies often sell more than they can deliver and accept the occasional penalty when they are caught out because everyone who bought actually shows up.
The differences are, first you will not get a nasty letter from your ISP if you do use your T1 to its limit all day every day, second you can actually serve web pages at a decent rate, third your ISP will make a serious effort to fix problems and bandwidth issues fast and will (if grudgingly) compensate you for serious problems (whereas if you miss a straight week of DSL you might maybe get five quid off your next bill if you threaten court action).
No, but by designing your quantum computer in an appropriate way (i.e. it handles sufficiently large numbers of qubits as one operation) you can make the polynomial speed-up essentially as large as you like. For practical problems, you know how big your typical problems will be in advance, and so you can design your quantum computer to fit that size of problem.
Combinatorial optimisation, yes. When you have a nice clear objective function.
Software, no. Unless you can think of a way to write an objective function which will pick up the best possible (or for that matter any) word processing code (or whatever). This isn't even something people are very good at, if you're writing the code for a small project to someone else's specifications you will quickly find that a lot of the job consists of trying to work out what the guy who wrote the specs actually wanted, what he forgot to mention, and probably how to put something resembling a UI on it that someone other than just you and him will be able to use.
78kg. Crazy power is someone like Armstrong, who weighs a bit less than me and was able to put out about 450W up l'Alpe d'Huez at the end of a hard day in the middle of the Tour de France (although it's debatable whether that was a clean performance).
I didn't say 'humans don't use quantum computing'. Maybe we do, maybe not. I said that we are not able (at present) to write an AI whether we are trying to do so on a classical or quantum computer. Because you can simulate a quantum computer using a classical computer, but (unlike simulating one classical computer with another) the number of steps required to simulate one step of the quantum computer could be arbitrarily large.
Sony doesn't dictate; the site can do as it wishes. But you are missing:
0. For a long time Sony provides site with much free information which it is in no way obliged to do, because it is so nice (or more accurately because it thinks it's getting decent publicity out of it).
and you should be saying
5. Sony decides that if someone they trust to provide them with good publicity is doing things they don't like, then they won't trust them with any more free info. It didn't attempt to play legal games.
Why is it that people who should know better seem to treat quantum computing as some kind of miracle device which will Make Everything Good?
A working quantum computer would not be capable of computing anything a normal computer cannot. The only difference is that where a conventional computer would use parallel processing through many cores and then run out of cores and have to process serially, the quantum computer would not, so that for that sort of problem (any NP-complete problem, for starters) a quantum computer would always take polynomial (generally small polynomial or linear) time while a classical computer would (if P=/=NP) take much longer, probably exponential time. This means that for something like code breaking a quantum computer would be very fast: but it also means that if you can't see how to write an AI, even one which thinks very very slowly with a classical computer, you won't be able to write an AI on a quantum computer. Maybe we need more processing power to produce an AI which can actually think at a sensible rate, but we also need some fundamental software ideas to produce one at all.
I'm fairly physically fit - so I can generate 320W of mechanical energy for an hour on a bike. Which is about 1p worth of electricity; less than is used to provide light, music and a hot shower afterwards. And a typical (fat, unfit) person would not be able to generate half that. There are some practical ways to generate electricity that don't involve fossil fuels (nuclear, hydro, geothermal, wind in some places, solar in some places), but this is not one of them.
Which anyway doesn't work, because the pirate rips it, drops the quality down to DVD size and puts it online, the same way they used to rip DVDs down to CD size when broadband speeds were slower and DVD-R wasn't cheap.
Not really. You have four sorts of websites. You have the amateur sites, which probably are done by one person, don't involve making money (in any serious way). Some of these involve a CMS, some don't, and frankly no-one cares. You have the small-business sites, which exist to advertise a product and maybe sell it. Generally the small business doesn't employ anyone with the skills to make a good looking et cetera website, certainly it doesn't have the cash to have a full time webmaster who would most of the time sit on his arse anyway. So they pay a web design firm for a website and for the occasional update. Maybe there is a CMS system put in by the design firm so the small business's owner can change a few words himself, but that's about as far as it goes. Maybe these companies could do more with the internet than they do, but they don't have the money. You have the big business sites which do all kinds of things over the internet, and those guys don't have 'a webmaster' because there is far too much for one guy to do, instead they have the web section of the IT department, with several full time guys all doing bits of the company website (and intranet site). And somewhere in a tiny niche market you have a few companies which have decided they need to employ a full time webmaster specifically to run their website, they're big enough and internet-dependent enough to need it, but then they've stopped there. That means they need a guy who is making changes all the time, 40 hours a week, so there is likely to be a fair bit of ASP or PHP or whatever, some database stuff, but somehow the CEO and PR guys have decided that the current flashy stuff is enough and they don't need any more stuff that would require another website guy to be hired.
Yes - but that's still not an issue: if I send you an encrypted message using your public key, together with a signature (using a hash) to prove it's from me, then that's all fine. Now suppose that my enemy intercepts the message, and tries to find hash collisions to send you misinformation supposedly from me. Either the signature was encoded with the message (in which case it'll use a hash of the plain text) or it wasn't (in which case it generally uses a hash of the encrypted text). In the first place, my enemy is stuffed unless he can break your cipher, in which case the crypto system's fairly useless anyway. In the second place, my enemy can go looking for hash collisions. Let's assume a worst case: the hash is so badly broken that my enemy can quickly find a hash collision with a message that's almost entirely his choice: he can choose all but say 20 bytes of the message, maybe his algorithm is so good he can put the 20 bytes all over the message to look like spelling errors, and it still has the same hash as my encrypted message. Looks good for my enemy - except that his message will still _decrypt_ as garbage to you unless he can break your cipher, because although he can encrypt his message using your public key, when he is forced to change some bytes to make the hash work the decryption of the altered message will be very different, and he is still stuffed.
It would almost certainly be much harder, but it would mean your hash overheads would triple (bandwidth and processing), and that is very important for hash codes.
Hash insecurity is nothing like as much of an issue as cipher insecurity.
If I use a hash algorithm now, and I am confident that it's secure enough that no-one's going to find a useful collision within a month, then I can happily distribute my data for a couple of weeks, then I maybe need to find another hash algorithm, and the eventual recipients of my data can check their data against the hash I produce and be confident they got the right stuff; the possibility of an attacker coming along a few weeks later with some malware with an identical hash isn't an issue, because I'm no longer using the old hash as a certificate.
Whereas if I want to send secrets around, then I probably don't want anyone to be able to read them for a long time, so my cipher has to be much more secure against being broken.
Sure there must be collisions, but that's not the point.
The point is that you can verify that data is correct with a good amount of confidence, from a relatively small hash code. So I can download a lot of data through, say, bittorrent, and despite the fact that I don't necessarily trust the people I actually download from, I can verify that the hash is right and therefore I am confident that the data I receive is what the original seeder put out: no-one's decided to play games and (say) sneak their CC number grabber into the data.
So what you want is an algorithm which is reasonably easy to run, which SHA-1 is, but where it is not easy to find a collision. For example, if my hash code was simply to give the total byte sum modulo 1000, then while it would almost certainly catch accidental errors in data, it would be very easy for an attacker to stick in his CC number grabber to your data then fiddle the byte sum back to where it should be.
Your idea pretty clearly shows you have no idea of what hashes are used for: there is no point preserving the data structure, it takes a lot of extra space and gives virtually no security. For example, SHA-1 produces a 20 byte hash. I can put something that size up on my personal website without getting huge bandwidth charges even if millions of people want to download it - and then I can distribute my 1GB zipfile by way of people I don't necessarily trust (but who have more bandwidth than I) and still the eventual recipients can be confident that what they receive is what I sent out. If I include the virtual FAT table of this zipfile, my hash size goes up by about 500,000 percent (literally), and so do my bandwidth charges. And I get virtually no extra security, because all that an attacker has to do above finding an SHA-1 collision is ensure that the change doesn't affect the FAT table: i.e. he replaces some suitable virtual file of mine with one of his, keeps the name and size the same and he's done.
Good code is code where you can identify fairly quickly the part of the code you're interested in (what happens when I click this button?), and then you can get an idea of what's doing what within that code fast. So you follow some kind of indent convention, you put in some comments, you use sensible names. Bad code is either hard to understand or hard to change (or likely both); long blocks of solid code, misleading names, using global variables to pass data unnecessarily, playing with memory addresses unnecessarily. Bugs in code are different: if you're writing good code which has lots of bugs in then it should be pretty obvious that you're doing something stupid and you will probably catch most of those bugs when you read your code. If there are lots of bugs in your code and you don't see them when you read it, then you are writing bad code.
Slashdot Mirror
It's also not a good analysis. So, when you design one of these multiple choice tests you should have in mind what you're trying to test. You probably want a pass mark to be around 70/100. You can do scoring in three ways: one, just count the right answers, two, right answers minus wrong answers, three you can have a weighting (so there may be a best answer for +3, an OK answer for +1 and a bad answer for -5 or something).
You don't really care about ranking people, you just want a pass or fail (or maybe one or two more groupings, but not too many). So trying to see whether the guy who got 1/100 is really a lot worse than the guy who got 2 is not interesting, you don't want either guy.
If you want to test knowledge and a bit of (basic) problem solving, then you can just add up the right answers. If you know a lot, you'll know more answers and you'll know more wrong answers so you'll make better guesses for the questions you don't know. This isn't always appropriate, though. It's probably right for a law test, where you know that no lawyer will know all the law, but they might sometime be asked to give an answer now on some point they haven't learned - and they'll need to say something that at least doesn't make them look like an idiot in court. But if you are testing doctors, say, you probably do not want them to be making guesses about the right drug to put into someone, because the consequences of getting it wrong are bad. So it's probably a good idea to penalise for wrong answers here.
Of course, if you start weighting answers you can make the test do whatever you want, but then it's a real pain to design.
To those who have never worked in a maths journal: you don't have ads, you don't paste a PDF, instead you ask for the source LaTeX, you don't need to use linux to get LaTeX (I don't, I use Wordpad and miktex) and most maths journals simply say: first submission, PDF or maybe PS, on acceptance send the LaTeX and the figures, if you can't do that we will charge you retyping fees for any other format. There is a reason for this, and it is that anything other than LaTeX makes more work for the editors.
Most journals get round this by giving you a list of things that you may not do in the latex you send them (no hard breaks, no font changing beyond italics emphasis), or having a public house-style package (or both). Then it's pretty easy to house-style it.
I'm not quite sure what you mean here - OK, not appropriate if you want to produce an advert or something, but that's not what LaTeX is for.
Assuming the content is sensible, the styling you get will be readable (which is most of what's important for a paper in a journal) and the journal can (assuming the author hasn't done unpleasant things to get his own style in the document) simply tack their styling headers onto essentially the original LaTeX to get an output in the journal's style - that means that you can publish ten papers that look like they belong together (i.e. the styling doesn't change from one to the next) in an issue with not too much effort, rather than having to pay a staff to retype all the papers into a house style.
OK - probably they've updated equation editor since I last tried to use it five years ago.
As far as drawing objects go, Word occasionally screws up drawing positions whether or not they're equations. In any case, I can't send a word document to any journal I want to submit to (combinatorics) and therefore I don't want to use it.
It _can_ include jpeg, since I've tried - but agreed that it's not a clever thing to do. I suppose that if you want something that doesn't really go with vector graphics PNG would do.
I don't really see any conflicts here. If you submit to a journal, you don't send them source LaTeX initially, because then you have to send 15 eps graphics separately as well and then they have to muck about compiling it. It's easier (for both of you) to send them the compiled PDF or PS, which they can open, see it looks like mathematics, and bounce to an appropriate referee in a few minutes. Then after the referee reads it, the journal can come back and tell you to send along the LaTeX and graphics for publishing.
When you use LaTeX you get what you wanted fairly quickly, and it comes out the same on any computer anywhere, and you end up with PDFs that do the same, so you can take them to a conference. And journals accept it.
When you use MS word it takes forever to get anything like what you wanted (subscripts on superscripts, tower-type functions?), then when you change something elsewhere in the document or email it to a coauthor something breaks and the equations get changed. And you end up trying to use powerpoint to do presentations, which means you take it to a conference and what appears on the screen is a bunch of hearts and spades instead of the right symbols (seen this happen, just once). Which is why journals generally don't accept it.
LaTeX predates MS word, anyway. Before that, you sent a handwritten or typed paper to the journal, which again isn't going to get there and have all the equations different to how they looked when you wrote it.
That said, if I was trying to write a paper with lots of detailed diagrams I might not want to use LaTeX; it's fine for line and block diagrams (which is all I need for combinatorics papers) via xfig, but I wouldn't want to try to, say, draw some anatomical thing. And it doesn't really seem to handle jpeg inclusion very nicely.
I'd guess this is essentially where the law in question comes from. If you go around (in the UK) carrying that sort of thing, then you can be picked up and done for going equipped. Obviously a (proper) locksmith is allowed to, but they are also supposed to be registered.
I suspect the Germans have simply thought, well we already have a law against wandering around carrying a slimjim and a lockpick, why not extend it to computers. Unfortunately they haven't thought about the fact that making houses secure is pretty easy (good locks and a burglar alarm) and you don't really need to check it, while making a network secure is not so easy and it is a great help to be able to check by trying to hack in to your own network and stopping any holes you find that way.
The type of library that is a copyright library (i.e. receives a copy of every published book) rather than a public library (which is what you are thinking of). Think about e.g. university libraries, the British Library, the Library of Congress, that sort of thing. Obviously a public lending library isn't going to want one of these things, but then you don't go to a public library when you want to find a bit of obscure data.
A T1 doesn't really guarantee you bandwidth: it's pretty normal for an ISP to play the same game with T1s that they do for DSL and cable. Same way a plane ticket stating that you will go on this flight doesn't guarantee you a seat, companies often sell more than they can deliver and accept the occasional penalty when they are caught out because everyone who bought actually shows up.
The differences are, first you will not get a nasty letter from your ISP if you do use your T1 to its limit all day every day, second you can actually serve web pages at a decent rate, third your ISP will make a serious effort to fix problems and bandwidth issues fast and will (if grudgingly) compensate you for serious problems (whereas if you miss a straight week of DSL you might maybe get five quid off your next bill if you threaten court action).
No, but by designing your quantum computer in an appropriate way (i.e. it handles sufficiently large numbers of qubits as one operation) you can make the polynomial speed-up essentially as large as you like. For practical problems, you know how big your typical problems will be in advance, and so you can design your quantum computer to fit that size of problem.
Combinatorial optimisation, yes. When you have a nice clear objective function.
Software, no. Unless you can think of a way to write an objective function which will pick up the best possible (or for that matter any) word processing code (or whatever). This isn't even something people are very good at, if you're writing the code for a small project to someone else's specifications you will quickly find that a lot of the job consists of trying to work out what the guy who wrote the specs actually wanted, what he forgot to mention, and probably how to put something resembling a UI on it that someone other than just you and him will be able to use.
78kg. Crazy power is someone like Armstrong, who weighs a bit less than me and was able to put out about 450W up l'Alpe d'Huez at the end of a hard day in the middle of the Tour de France (although it's debatable whether that was a clean performance).
I didn't say 'humans don't use quantum computing'. Maybe we do, maybe not. I said that we are not able (at present) to write an AI whether we are trying to do so on a classical or quantum computer. Because you can simulate a quantum computer using a classical computer, but (unlike simulating one classical computer with another) the number of steps required to simulate one step of the quantum computer could be arbitrarily large.
Sony doesn't dictate; the site can do as it wishes. But you are missing:
0. For a long time Sony provides site with much free information which it is in no way obliged to do, because it is so nice (or more accurately because it thinks it's getting decent publicity out of it).
and you should be saying
5. Sony decides that if someone they trust to provide them with good publicity is doing things they don't like, then they won't trust them with any more free info. It didn't attempt to play legal games.
Why is it that people who should know better seem to treat quantum computing as some kind of miracle device which will Make Everything Good?
A working quantum computer would not be capable of computing anything a normal computer cannot. The only difference is that where a conventional computer would use parallel processing through many cores and then run out of cores and have to process serially, the quantum computer would not, so that for that sort of problem (any NP-complete problem, for starters) a quantum computer would always take polynomial (generally small polynomial or linear) time while a classical computer would (if P=/=NP) take much longer, probably exponential time. This means that for something like code breaking a quantum computer would be very fast: but it also means that if you can't see how to write an AI, even one which thinks very very slowly with a classical computer, you won't be able to write an AI on a quantum computer. Maybe we need more processing power to produce an AI which can actually think at a sensible rate, but we also need some fundamental software ideas to produce one at all.
I'm fairly physically fit - so I can generate 320W of mechanical energy for an hour on a bike. Which is about 1p worth of electricity; less than is used to provide light, music and a hot shower afterwards. And a typical (fat, unfit) person would not be able to generate half that. There are some practical ways to generate electricity that don't involve fossil fuels (nuclear, hydro, geothermal, wind in some places, solar in some places), but this is not one of them.
Which anyway doesn't work, because the pirate rips it, drops the quality down to DVD size and puts it online, the same way they used to rip DVDs down to CD size when broadband speeds were slower and DVD-R wasn't cheap.
Not really. You have four sorts of websites.
You have the amateur sites, which probably are done by one person, don't involve making money (in any serious way). Some of these involve a CMS, some don't, and frankly no-one cares.
You have the small-business sites, which exist to advertise a product and maybe sell it. Generally the small business doesn't employ anyone with the skills to make a good looking et cetera website, certainly it doesn't have the cash to have a full time webmaster who would most of the time sit on his arse anyway. So they pay a web design firm for a website and for the occasional update. Maybe there is a CMS system put in by the design firm so the small business's owner can change a few words himself, but that's about as far as it goes. Maybe these companies could do more with the internet than they do, but they don't have the money.
You have the big business sites which do all kinds of things over the internet, and those guys don't have 'a webmaster' because there is far too much for one guy to do, instead they have the web section of the IT department, with several full time guys all doing bits of the company website (and intranet site).
And somewhere in a tiny niche market you have a few companies which have decided they need to employ a full time webmaster specifically to run their website, they're big enough and internet-dependent enough to need it, but then they've stopped there. That means they need a guy who is making changes all the time, 40 hours a week, so there is likely to be a fair bit of ASP or PHP or whatever, some database stuff, but somehow the CEO and PR guys have decided that the current flashy stuff is enough and they don't need any more stuff that would require another website guy to be hired.
Yes - but that's still not an issue: if I send you an encrypted message using your public key, together with a signature (using a hash) to prove it's from me, then that's all fine. Now suppose that my enemy intercepts the message, and tries to find hash collisions to send you misinformation supposedly from me. Either the signature was encoded with the message (in which case it'll use a hash of the plain text) or it wasn't (in which case it generally uses a hash of the encrypted text).
In the first place, my enemy is stuffed unless he can break your cipher, in which case the crypto system's fairly useless anyway.
In the second place, my enemy can go looking for hash collisions. Let's assume a worst case: the hash is so badly broken that my enemy can quickly find a hash collision with a message that's almost entirely his choice: he can choose all but say 20 bytes of the message, maybe his algorithm is so good he can put the 20 bytes all over the message to look like spelling errors, and it still has the same hash as my encrypted message. Looks good for my enemy - except that his message will still _decrypt_ as garbage to you unless he can break your cipher, because although he can encrypt his message using your public key, when he is forced to change some bytes to make the hash work the decryption of the altered message will be very different, and he is still stuffed.
It would almost certainly be much harder, but it would mean your hash overheads would triple (bandwidth and processing), and that is very important for hash codes.
Hash insecurity is nothing like as much of an issue as cipher insecurity.
If I use a hash algorithm now, and I am confident that it's secure enough that no-one's going to find a useful collision within a month, then I can happily distribute my data for a couple of weeks, then I maybe need to find another hash algorithm, and the eventual recipients of my data can check their data against the hash I produce and be confident they got the right stuff; the possibility of an attacker coming along a few weeks later with some malware with an identical hash isn't an issue, because I'm no longer using the old hash as a certificate.
Whereas if I want to send secrets around, then I probably don't want anyone to be able to read them for a long time, so my cipher has to be much more secure against being broken.
Sure there must be collisions, but that's not the point.
The point is that you can verify that data is correct with a good amount of confidence, from a relatively small hash code. So I can download a lot of data through, say, bittorrent, and despite the fact that I don't necessarily trust the people I actually download from, I can verify that the hash is right and therefore I am confident that the data I receive is what the original seeder put out: no-one's decided to play games and (say) sneak their CC number grabber into the data.
So what you want is an algorithm which is reasonably easy to run, which SHA-1 is, but where it is not easy to find a collision. For example, if my hash code was simply to give the total byte sum modulo 1000, then while it would almost certainly catch accidental errors in data, it would be very easy for an attacker to stick in his CC number grabber to your data then fiddle the byte sum back to where it should be.
Your idea pretty clearly shows you have no idea of what hashes are used for: there is no point preserving the data structure, it takes a lot of extra space and gives virtually no security. For example, SHA-1 produces a 20 byte hash. I can put something that size up on my personal website without getting huge bandwidth charges even if millions of people want to download it - and then I can distribute my 1GB zipfile by way of people I don't necessarily trust (but who have more bandwidth than I) and still the eventual recipients can be confident that what they receive is what I sent out. If I include the virtual FAT table of this zipfile, my hash size goes up by about 500,000 percent (literally), and so do my bandwidth charges. And I get virtually no extra security, because all that an attacker has to do above finding an SHA-1 collision is ensure that the change doesn't affect the FAT table: i.e. he replaces some suitable virtual file of mine with one of his, keeps the name and size the same and he's done.
Good code is code where you can identify fairly quickly the part of the code you're interested in (what happens when I click this button?), and then you can get an idea of what's doing what within that code fast. So you follow some kind of indent convention, you put in some comments, you use sensible names. Bad code is either hard to understand or hard to change (or likely both); long blocks of solid code, misleading names, using global variables to pass data unnecessarily, playing with memory addresses unnecessarily.
Bugs in code are different: if you're writing good code which has lots of bugs in then it should be pretty obvious that you're doing something stupid and you will probably catch most of those bugs when you read your code. If there are lots of bugs in your code and you don't see them when you read it, then you are writing bad code.