You're right that the poster doesn't supply NEARLY enough information, but on the other hand, I think that 7 months is about right given the sketchy details provided.
No offense, but it could also be 7 weeks or 7 years. As others have pointed out (and you admit), there is not nearly enough information to make a reasonable estimate.
The only thing to do (as others also have pointed out) is to find an experienced developer who also has experience with requirements analysis, and let him/her analyze the requirements and come up with an estimate. And then you are probably still way off...
Also, consider if there are any security requirements. If so, this could easily double or triple the development time, since security is very hard to get right, and a system that is only partially secure typically fails the requirement.
Another tidbit: the industry average is about 10 lines of source code per person, per day. I know it seems ludicrously low, but it includes everything, soup to nuts. Of course, that now shifts the problem to estimating the number of source lines needed, which is hardly any easier than estimating anything else, so that does not help a lot...
I had a boss who used to say: "If I can't do my job in 40 hours a week, they'll need to hire more people".
Obviously, it doesn't hurt to be a little flexible when it's crunch time, but basically you're paid for 40 hours a week, so that should be your normal working hours. Working 12-16 hours a day may please some managers, but in the long run it's very counterproductive. You'll spend the first 4 hours of tomorrow fixing the mistakes you made in the last 4 hours of today. I read a study some years ago that showed that after 9 hours of work, productivity and accuracy decreased dramatically in most workers. And this was an assembly line in a car factory.
Another point: "leaving after 8 hours when there's lots of things to do". Unless your project deadline is tomorrow and you really are very nearly done, there's always lots more things to do on a software project, so that doesn't hold water.
As for advice: since it is a new job, you could try to work a little more in the beginning. Look at what other people are doing: are you the only one working after hours? Is everybody doing it? Are they doing it because they feel like part of a team and want to accomplish something? Or are they doing it because they are intimidated by management? If it's the latter, you probably should start looking for yet another job (I know, I know, it's hard these days).
. Quickly, what is a 36-60-90 triangle in radians?
A strange triangle, at least if you mean to indicate the values of the angles with "36-60-90". It adds up to 186 degrees, so you're living in a somewhat curved universe.
It may not be very useful for woodworking, but mathematically (and implied, in practical applications based on mathematics, such as communications technology), the radian is the only proper unit for angles. I'm sure degrees are very useful in woodworking. To claim that radians are "pretty darn worthless" is a bit shortsighted.
On a more important matter: what's "90-60-90" (cm) in inches? If you don't know what I'm referring to, ask a guy who is used to metric units...
Somebody just can't come along and change someone else's system, and say that there way is right.
Sure they can. They do it all the time. The speed of light in vacuum (c) is now defined as constant, but it hasn't always been like that (measurements of the speed of light are therefore irrelevant now, you'd be measuring a meter rather than c).
A foot used to be defined as 30.45 cm. In recent years, an inch has been defined as exactly 2.54 cm, and with 12 inches in a foot, that now makes a foot equal to 30.48 cm. Go figure.
Also: What happens when you can measure these values more accurately? Suddenly all your old measurements are wrong.
Absolutely correct, and as a matter of fact, this has happened!
Because the orbit of the earth around the sun is not perfectly circular, there should be a time dilution happening in certain seasons, since the gravity field on earth varies throughout the year. This is kind of hard to measure on earth, of course, since all clocks are affected equally. So, you would need an extraterrestial time reference that is extremely accurate. Enter millisecond pulsars. A few years ago, the effect of general relativity on atomic clocks was measured, assuming that the pulsars are correct. Interestingly enough, the experimental result matched the result predicted by GR to a very high degree. Prediction was that time runs slower or faster by something like 235 microseconds a year, or maybe it was 235 milliseconds a year, don't quote me on that...The point is that the time dilution due to the elliptical orbit could be measured.
Anyway, you could argue that you don't know for certain that the pulsars are correct, but the fact that the prediction and the measurement were very close do make it very plausible.
It doesn't matter for everyday purposes of course (everything on earth is affected equally), but it just goes to show that the precise standard (cesium based), is only valid in a certain reference frame.
Sure. First of all, most people couldn't even tell the number of feet in a mile in the first place. For the people who do know it, I'm sure they all routinely divide 5280 in their head by all those factors such as 22...
The Imperial system is plain idiotic. It is based on things such as a king's shoe size, arm length, etc. Either that, or invented by a bunch of aliens with three heads, twelve fingers, and sixteen toes.
Actually, NASA does get it. As far as I know, they have been doing things in the metric system for a long time. It was one of their subcontractors that thought it was way cooler to use pound-force rather than Newtons.
Err, so the concept of relativistic mass is wrong? I think particles that are accelerated to a velocity close to c, very much do exhibit a behavior that is consistent with a greatly increased mass, i.e., the closer the velocity to c, the more energy you need to accelerate the particle even more. This is one of the reasons why an object with a non-zero rest mass cannot reach light speed, the energy needed would be infinite.
And mass is always the same, no matter what acceleration due to gravity is.
Actually, that's not correct. I realize you're pointing out that mass and weight are two different things, but acceleration of any kind affects mass due to relativity.
Actually, I think it is correct, albeit a bit confusing. Relativistic mass depends on velocity, not acceleration. Of course, any object that is accelerated will have a non-zero velocity. But I think that's not what the parent was trying to point out. I think what meant is the following: the mass of an object does not depend on the gravitational field (as opposed to the weight of an object). "acceleration due to gravity" should be thought of as g. I guess in a sense, you are both right.
You guys do realize that all your arguing is done in base-10 arithmetic, right?
As much as computers may hate it, humans do arithmetic in the decimal system. Something to do with having ten fingers, I think. The metric system is (shudder, dare I say it?) "better", since it has fewer conversion constants that are not a power of 10.
Btw, one of the things I still find very confusing is the following: 12 inches in a foot, but if you measure fractions of inches, it's suddenly in multiples of 1/16th? Huh?
(Of course you could say 1 second is the time taken for light to travel 299 792 458 meters)
Hmm, no.
The second is defined as 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom.
Years ago, I worked on a big software project for the aerospace industry. This was in the early 90s, and I am proud to say we were a bit ahead of our time. Iterative design, unit tests automatically running overnight, peer reviews, refactoring (although we called it "rewriting"), collective code ownership, we did it all.
After extensive integration testing (and finding and fixing many bugs), we installed the system at the customer site. After running for two weeks continuously, the system froze. Fortunately, the operating system was kind enough to report that it had run out of memory.
The cause of the problem was obvious: we had a memory leak somewhere. We had never run our code through a memory leak detection tool. The reason for this was that management did not want to spend money on something like this (...). Fortunately, we happened to have an evaluation copy of such a tool when the problem was detected. Installing the tool took 20 minutes, finding the leak took 2 minutes. It also found a memory leak in on of the OS libraries, but that was a one time leak. Our problem leak was only 8 bytes in size, but since the leaking routine was called several times per second, the system ran out of memory eventually.
Anyway, the leak was all my fault, and fixing it took about 20 seconds. Rebuild, and everybody was happy again.
So, what did we do wrong?
1. We should have had better checks for memory leaks in the first place. So, blame management...
2. We should have tested for a longer period than we did. Our integration tests included stress tests, but we never ran tests for more than 24 hours or so without rebooting (rebooting obviously hid the memory problem). Running for two weeks would have revealed the problem, but that doesn't always cure everything (read on for part two...)
Two years later. I had moved to another country, and was doing consulting work at a customer site. I got a phone call. The system had frozen again, but this time not after 2 weeks, but after 6 months running continuously. I investigated the problem, and after lots of debugging I isolated the problem to a (vendor supplied) device driver. Code inspection revealed that this driver incremented an internal counter every time it was called. This counter was a signed 32-bit integer. So, after 6 months of calling it several times per second, the counter rolled over, and the driver stopped working. Of course, a reboot fixed it, and the system was good to go for another 6 months. I'm not sure if this driver was ever fixed. You could very well argue that it's not worth the effort: just reboot once every 6 months, and you're fine.
What is the point of all this? Well, a lengthy testing period would have revealed our first bug. However, to find the second one, we would have had to do a stress test for more than 6 months. No matter how enlightened management or your customer are, they'll never agree to something like that in real life. Besides, there is a known defect in this system that will manifest itself in 2036 or so... Also, where should you stop testing? We trusted the 3rd party driver to be coreect, and in this case we were wrong to do so. I see no practical solution for this, though.
Lesson: you can do (almost) everything right, use proper methodologies, test early and often, have a team of brilliant people, etc., and still you can have problems.
Ironically, the fact that we had stable software running on a robust operating system (UNIX), caused the bugs to manifest themselves. Had we been writing unstable software or running on Windows, reboots would have happened more than once every two weeks, and neither bug would have shown up...
I've always wondered, why not simply connect all those harddrives with gigabit ethernet?
Well, at least for IDE drives, the interface is not the bottleneck. The fastest drives out there can pump out something like 60 MB/s, when the heads are on the outside of the platter. It gradually degrades to 30 MB/s or so when the heads move to the inside of the platter. So, it does not reach the maximum speed of the ATA-100 interface. Gigabit ethernet would not help a bit here. Serial ATA (150 MB/s) also seems overkill until the drives can reach this transfer rate. SATA has more to offer than just increased maximum throughput, of course.
Read performance is excellent, and write performance the same as a single drive.
Correct me if I'm wrong, but I thought that read performance would be better and write performance would be worse than a single drive. Reasons: for read performance, you only have to wait for 1 of the two drives to retrieve the data, i.e. the drive that happens to get the data the fastest. For write performance, you have to wait for both drives to finish writing (otherwise the whole purpose of mirroring is defeated). You're right of course that most applications do more reading than writing, so on average a mirrored setup should be slightly faster than a single drive.
And if you really want to get ~15000RPM with IDE technology, just get an IDE RAID controller and use striping...using this method you can actually get to much higher theoretical speeds than a single 15000RPM drive. with 4 7200RPM drives you could get up to a theoretical speed of 28800RPM!!!
Actually, IIRC, it's more like a 100% speed increase with 4 drives in RAID 0. But you make a good point. Four 120GB (= 480GB) IDE drives in RAID 0 cost less than one 80GB 15K SCSI drive, and are probably faster. Most new mobo's have a RAID controller as well, nowadays.
And a silly little difference like a 5200 RPM drive being 25% slower than a 7200 RPM drive pales in comparison to the thousand or so times faster that your memory is.
Most of the time, you are absolutely right. However, there are applications where pure throughput (i.e. MB/s) is critical (e.g. analog video capture), and in that case the 7200 RPM drives actually do perform noticeably better.
No, I don't really care about this whole story either, but this guy has gone to the trouble of translating it for everyone, and it makes a hell of a lot more sense than the google translation someone else posted, so c'mon, spread the love (mod points) around, people.
Thank you. You're right, I was trying to be helpful given that not everyone reading/. can read German. The post did get modded up by the way. And you got modded down for your kind words...
Looks suspiciously like a babelfish translation...
Really? I just did a babelfish translation of the text. As laudable as the effort is, the machine translation is somewhat lacking. There are some remarkable similarities in the translations, but I don't know if that is a good thing for the machine translation, or a bad thing for mine...
German is my 3rd language, but here it goes anyway.
UNAUTHORIZED TRANSLATION ------------------------
NEW WORLD RECORD
In the FEC Hall in Leeuwarden the builders are celebrating their big success, the biggest chain reaction in the world has completed successfully. Up til the last second it remained suspenseful, the stones that had remained standing were officially counted by a notary.
With 3,847,295 fallen domino stones, the attempt at a new world record has succeeded. In some fields some stones remained standing, but the final field with 1 million stones cleared completely.
Goose bumps were felt already at the beginning of the spectacle: the 10 second countdown was performed loudly. "Backstreet Boy" Nick Carter set off the domino avalanche at exactly 9:00 PM: the 22-year old pop singer placed the final stone, and by doing so unbalanced the two meter high "Domino Scale" with its five meter span.
Now "Domino Man" Robin Weijers and his 89-person team can enjoy an additional entry into the Guinness Book of World Records. While preparing, it was forbidden to cough or sneeze inside the hall. Robin Weijers: "Because of the amount of stones, space has become limited inside the hall. One false move and the catastrophe is complete".
THE SCALE STARTED IT!
[picture] The approximately two meter high "Domino Scale", through which the world record attempt was started.
In the past year 3,540,562 domino stones fell over, and up to 13.72 million people watched the TV event of superlatives.
HISTORY OF RECORDS
On November 5. 1999, domino expert Robin Weijers and his team built up 2.5 million dominoes in the Prince Bernhard hall in Zuid-Laren. Up to 14.2 million viewers followed the event live on TV, when 2,472,480 stones fell over. Give or take a few, 3,112,000 stones were toppled on November 3. 2000, again in the Prince Bernhard hall. In front of up to 13.2 million viewers, 2,977,678 stones fell over in a live broadcast. Then last year. Linda de Mol and Robin Weijers' team placed 3.75 million domino stones in the "Mecc" hall in Maastricht. The 90 person international team had worked seven weeks on the 75 different projects. On November 16 everything was ready. The Australian superstar Kylie Minogue started the biggest chain reaction in the world with a flick of her fingers. And again up to 13.72 million viewers watched the spectacle with the stones weiging 8 grams.
A friend of mine was involved in this back in the '80s. They don't really count the dominos. They weigh them. Given a certain tolerance in the weight, you can calculate the uncertainty in the number of stones. The exact number is not all that important, it's more that you can establish that you beat the previous record.
Slashdot Mirror
You're right that the poster doesn't supply NEARLY enough information, but on the other hand, I think that 7 months is about right given the sketchy details provided.
No offense, but it could also be 7 weeks or 7 years. As others have pointed out (and you admit), there is not nearly enough information to make a reasonable estimate.
The only thing to do (as others also have pointed out) is to find an experienced developer who also has experience with requirements analysis, and let him/her analyze the requirements and come up with an estimate. And then you are probably still way off...
Also, consider if there are any security requirements. If so, this could easily double or triple the development time, since security is very hard to get right, and a system that is only partially secure typically fails the requirement.
Another tidbit: the industry average is about 10 lines of source code per person, per day. I know it seems ludicrously low, but it includes everything, soup to nuts. Of course, that now shifts the problem to estimating the number of source lines needed, which is hardly any easier than estimating anything else, so that does not help a lot...
I had a boss who used to say: "If I can't do my job in 40 hours a week, they'll need to hire more people".
Obviously, it doesn't hurt to be a little flexible when it's crunch time, but basically you're paid for 40 hours a week, so that should be your normal working hours. Working 12-16 hours a day may please some managers, but in the long run it's very counterproductive. You'll spend the first 4 hours of tomorrow fixing the mistakes you made in the last 4 hours of today.
I read a study some years ago that showed that after 9 hours of work, productivity and accuracy decreased dramatically in most workers. And this was an assembly line in a car factory.
Another point: "leaving after 8 hours when there's lots of things to do". Unless your project deadline is tomorrow and you really are very nearly done, there's always lots more things to do on a software project, so that doesn't hold water.
As for advice: since it is a new job, you could try to work a little more in the beginning. Look at what other people are doing: are you the only one working after hours? Is everybody doing it? Are they doing it because they feel like part of a team and want to accomplish something? Or are they doing it because they are intimidated by management? If it's the latter, you probably should start looking for yet another job (I know, I know, it's hard these days).
Just my 2 cents though...
. Quickly, what is a 36-60-90 triangle in radians?
A strange triangle, at least if you mean to indicate the values of the angles with "36-60-90". It adds up to 186 degrees, so you're living in a somewhat curved universe.
It may not be very useful for woodworking, but mathematically (and implied, in practical applications based on mathematics, such as communications technology), the radian is the only proper unit for angles.
I'm sure degrees are very useful in woodworking. To claim that radians are "pretty darn worthless" is a bit shortsighted.
On a more important matter: what's "90-60-90" (cm) in inches? If you don't know what I'm referring to, ask a guy who is used to metric units...
Somebody just can't come along and change someone else's system, and say that there way is right.
Sure they can. They do it all the time. The speed of light in vacuum (c) is now defined as constant, but it hasn't always been like that (measurements of the speed of light are therefore irrelevant now, you'd be measuring a meter rather than c).
A foot used to be defined as 30.45 cm. In recent years, an inch has been defined as exactly 2.54 cm, and with 12 inches in a foot, that now makes a foot equal to 30.48 cm. Go figure.
Also: What happens when you can measure these values more accurately? Suddenly all your old measurements are wrong.
Absolutely correct, and as a matter of fact, this has happened!
Because the orbit of the earth around the sun is not perfectly circular, there should be a time dilution happening in certain seasons, since the gravity field on earth varies throughout the year. This is kind of hard to measure on earth, of course, since all clocks are affected equally. So, you would need an extraterrestial time reference that is extremely accurate. Enter millisecond pulsars. A few years ago, the effect of general relativity on atomic clocks was measured, assuming that the pulsars are correct. Interestingly enough, the experimental result matched the result predicted by GR to a very high degree. Prediction was that time runs slower or faster by something like 235 microseconds a year, or maybe it was 235 milliseconds a year, don't quote me on that...The point is that the time dilution due to the elliptical orbit could be measured.
Anyway, you could argue that you don't know for certain that the pulsars are correct, but the fact that the prediction and the measurement were very close do make it very plausible.
It doesn't matter for everyday purposes of course (everything on earth is affected equally), but it just goes to show that the precise standard (cesium based), is only valid in a certain reference frame.
Aha! That's why all these carpenters and woodworkers like this 12 based system so much. Much easier to adjust your math if you saw off a finger.
Thus, I think it's better to only look at the hydrogen nucleus, one proton.
I think you run into the same problem there, albeit on a vastly different scale.
Sure. First of all, most people couldn't even tell the number of feet in a mile in the first place. For the people who do know it, I'm sure they all routinely divide 5280 in their head by all those factors such as 22...
The Imperial system is plain idiotic. It is based on things such as a king's shoe size, arm length, etc. Either that, or invented by a bunch of aliens with three heads, twelve fingers, and sixteen toes.
You'ld think at least NASA would get this.
Actually, NASA does get it. As far as I know, they have been doing things in the metric system for a long time. It was one of their subcontractors that thought it was way cooler to use pound-force rather than Newtons.
Err, so the concept of relativistic mass is wrong? I think particles that are accelerated to a velocity close to c, very much do exhibit a behavior that is consistent with a greatly increased mass, i.e., the closer the velocity to c, the more energy you need to accelerate the particle even more. This is one of the reasons why an object with a non-zero rest mass cannot reach light speed, the energy needed would be infinite.
And mass is always the same, no matter what acceleration due to gravity is.
Actually, that's not correct. I realize you're pointing out that mass and weight are two different things, but acceleration of any kind affects mass due to relativity.
Actually, I think it is correct, albeit a bit confusing. Relativistic mass depends on velocity, not acceleration. Of course, any object that is accelerated will have a non-zero velocity. But I think that's not what the parent was trying to point out. I think what meant is the following: the mass of an object does not depend on the gravitational field (as opposed to the weight of an object). "acceleration due to gravity" should be thought of as g. I guess in a sense, you are both right.
You guys do realize that all your arguing is done in base-10 arithmetic, right?
As much as computers may hate it, humans do arithmetic in the decimal system. Something to do with having ten fingers, I think. The metric system is (shudder, dare I say it?) "better", since it has fewer conversion constants that are not a power of 10.
Btw, one of the things I still find very confusing is the following: 12 inches in a foot, but if you measure fractions of inches, it's suddenly in multiples of 1/16th? Huh?
(Of course you could say 1 second is the time taken for light to travel 299 792 458 meters)
Hmm, no.
The second is defined as 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom.
Based on nature.
Ok, a true story.
Years ago, I worked on a big software project for the aerospace industry. This was in the early 90s, and I am proud to say we were a bit ahead of our time. Iterative design, unit tests automatically running overnight, peer reviews, refactoring (although we called it "rewriting"), collective code ownership, we did it all.
After extensive integration testing (and finding and fixing many bugs), we installed the system at the customer site. After running for two weeks continuously, the system froze. Fortunately, the operating system was kind enough to report that it had run out of memory.
The cause of the problem was obvious: we had a memory leak somewhere. We had never run our code through a memory leak detection tool. The reason for this was that management did not want to spend money on something like this (...). Fortunately, we happened to have an evaluation copy of such a tool when the problem was detected. Installing the tool took 20 minutes, finding the leak took 2 minutes. It also found a memory leak in on of the OS libraries, but that was a one time leak. Our problem leak was only 8 bytes in size, but since the leaking routine was called several times per second, the system ran out of memory eventually.
Anyway, the leak was all my fault, and fixing it took about 20 seconds. Rebuild, and everybody was happy again.
So, what did we do wrong?
1. We should have had better checks for memory leaks in the first place. So, blame management...
2. We should have tested for a longer period than we did. Our integration tests included stress tests, but we never ran tests for more than 24 hours or so without rebooting (rebooting obviously hid the memory problem). Running for two weeks would have revealed the problem, but that doesn't always cure everything (read on for part two...)
Two years later. I had moved to another country, and was doing consulting work at a customer site. I got a phone call. The system had frozen again, but this time not after 2 weeks, but after 6 months running continuously. I investigated the problem, and after lots of debugging I isolated the problem to a (vendor supplied) device driver. Code inspection revealed that this driver incremented an internal counter every time it was called. This counter was a signed 32-bit integer. So, after 6 months of calling it several times per second, the counter rolled over, and the driver stopped working. Of course, a reboot fixed it, and the system was good to go for another 6 months. I'm not sure if this driver was ever fixed. You could very well argue that it's not worth the effort: just reboot once every 6 months, and you're fine.
What is the point of all this? Well, a lengthy testing period would have revealed our first bug. However, to find the second one, we would have had to do a stress test for more than 6 months. No matter how enlightened management or your customer are, they'll never agree to something like that in real life. Besides, there is a known defect in this system that will manifest itself in 2036 or so...
Also, where should you stop testing? We trusted the 3rd party driver to be coreect, and in this case we were wrong to do so. I see no practical solution for this, though.
Lesson: you can do (almost) everything right, use proper methodologies, test early and often, have a team of brilliant people, etc., and still you can have problems.
Ironically, the fact that we had stable software running on a robust operating system (UNIX), caused the bugs to manifest themselves. Had we been writing unstable software or running on Windows, reboots would have happened more than once every two weeks, and neither bug would have shown up...
I've always wondered, why not simply connect all those harddrives with gigabit ethernet?
Well, at least for IDE drives, the interface is not the bottleneck. The fastest drives out there can pump out something like 60 MB/s, when the heads are on the outside of the platter. It gradually degrades to 30 MB/s or so when the heads move to the inside of the platter. So, it does not reach the maximum speed of the ATA-100 interface. Gigabit ethernet would not help a bit here. Serial ATA (150 MB/s) also seems overkill until the drives can reach this transfer rate. SATA has more to offer than just increased maximum throughput, of course.
Read performance is excellent, and write performance the same as a single drive.
Correct me if I'm wrong, but I thought that read performance would be better and write performance would be worse than a single drive.
Reasons: for read performance, you only have to wait for 1 of the two drives to retrieve the data, i.e. the drive that happens to get the data the fastest.
For write performance, you have to wait for both drives to finish writing (otherwise the whole purpose of mirroring is defeated).
You're right of course that most applications do more reading than writing, so on average a mirrored setup should be slightly faster than a single drive.
And if you really want to get ~15000RPM with IDE technology, just get an IDE RAID controller and use striping...using this method you can actually get to much higher theoretical speeds than a single 15000RPM drive. with 4 7200RPM drives you could get up to a theoretical speed of 28800RPM!!!
Actually, IIRC, it's more like a 100% speed increase with 4 drives in RAID 0. But you make a good point. Four 120GB (= 480GB) IDE drives in RAID 0 cost less than one 80GB 15K SCSI drive, and are probably faster. Most new mobo's have a RAID controller as well, nowadays.
And a silly little difference like a 5200 RPM drive being 25% slower than a 7200 RPM drive pales in comparison to the thousand or so times faster that your memory is.
Most of the time, you are absolutely right. However, there are applications where pure throughput (i.e. MB/s) is critical (e.g. analog video capture), and in that case the 7200 RPM drives actually do perform noticeably better.
Mod parent up as informative, please.
/. can read German. The post did get modded up by the way. And you got modded down for your kind words...
No, I don't really care about this whole story either, but this guy has gone to the trouble of translating it for everyone, and it makes a hell of a lot more sense than the google translation someone else posted, so c'mon, spread the love (mod points) around, people.
Thank you. You're right, I was trying to be helpful given that not everyone reading
Looks suspiciously like a babelfish translation...
Really? I just did a babelfish translation of the text. As laudable as the effort is, the machine translation is somewhat lacking. There are some remarkable similarities in the translations, but I don't know if that is a good thing for the machine translation, or a bad thing for mine...
German is my 3rd language, but here it goes anyway.
UNAUTHORIZED TRANSLATION
------------------------
NEW WORLD RECORD
In the FEC Hall in Leeuwarden the builders are celebrating their big success, the biggest chain reaction in the world has completed successfully. Up til the last second it remained suspenseful, the stones that had remained standing were officially counted by a notary.
With 3,847,295 fallen domino stones, the attempt at a new world record has succeeded. In some fields some stones remained standing, but the final field with 1 million stones cleared completely.
Goose bumps were felt already at the beginning of the spectacle: the 10 second countdown was performed loudly. "Backstreet Boy" Nick Carter set off the domino avalanche at exactly 9:00 PM: the 22-year old pop singer placed the final stone, and by doing so unbalanced the two meter high "Domino Scale" with its five meter span.
Now "Domino Man" Robin Weijers and his 89-person team can enjoy an additional entry into the Guinness Book of World Records. While preparing, it was forbidden to cough or sneeze inside the hall. Robin Weijers: "Because of the amount of stones, space has become limited inside the hall. One false move and the catastrophe is complete".
THE SCALE STARTED IT!
[picture] The approximately two meter high "Domino Scale", through which the world record attempt was started.
In the past year 3,540,562 domino stones fell over, and up to 13.72 million people watched the TV event of superlatives.
HISTORY OF RECORDS
On November 5. 1999, domino expert Robin Weijers and his team built up 2.5 million dominoes in the Prince Bernhard hall in Zuid-Laren. Up to 14.2 million viewers followed the event live on TV, when 2,472,480 stones fell over. Give or take a few, 3,112,000 stones were toppled on November 3. 2000, again in the Prince Bernhard hall. In front of up to 13.2 million viewers, 2,977,678 stones fell over in a live broadcast. Then last year. Linda de Mol and Robin Weijers' team placed 3.75 million domino stones in the "Mecc" hall in Maastricht. The 90 person international team had worked seven weeks on the 75 different projects. On November 16 everything was ready. The Australian superstar Kylie Minogue started the biggest chain reaction in the world with a flick of her fingers. And again up to 13.72 million viewers watched the spectacle with the stones weiging 8 grams.
...and HOW much counting to get to 4 million?
A friend of mine was involved in this back in the '80s. They don't really count the dominos. They weigh them. Given a certain tolerance in the weight, you can calculate the uncertainty in the number of stones. The exact number is not all that important, it's more that you can establish that you beat the previous record.
Java = Lucifer
There we go already... You used '=' where you should have used '=='. One of the many problems of C...
Ok, interesting. I guess time will tell.
Unless you know otherwise...?
No, that's why I was asking...
Oh. My mistake :-)