And yet, after a lifetime of using this account, you would still have stolen less money from me than my bank already did. So tell you what, give me a good interest rate and I may just take you up on it...
LOL - nice one. Thanks for the reply.
Maybe that is the intention? Just because Schneier *thinks* it is an average, doesn't make it so. Maybe the device becomes more accurate as more samples are taken, and therefore gives more weight to the last (not the first!) sample.
Suppose the machine does become more accurate as more samples are taken (like maybe it needs to warm up first or something?), I find it unrealistic that it would become more accurate at the same rate as the ratio implied by the calculations performed in the code. Further, wouldn't it make sense to drop the initial readings anyway until the machine had reached it's 'harmony' with the rest of the universe and was able to measure accurately?
Who cares if there is loss of precision? In the end, it spits out a value that is essentially binary: drunk or not. You are not less drunk if it says so with 9 extra bits of precision, and in fact the extra accuracy could itself be considered an error as it shows a certainty about the result that may not be warranted by the design of the machine.
As mentioned elsewhere, the important fact is that the loss of precision is done prior to making the final determination. I have a deal for you: I will start a bank that will ignore all fractions of a dollar for all of your deposits. You deposit $12.45 but your bank account only gets the $12. I will keep the $0.45. Sound good? It doesn't matter right? I will provide it as a free service to you.
If the code is tested properly, there is no need to keep the first two interrupts going. As for the "software interrupt", it may sound ominous that it is disabled, but there is absolutely no way to tell if and why it should be enabled, and in fact disabling it is probably correct. There is absolutely nothing in software engineering that says you should always enable all interrupts because otherwise your code would be less reliable.
Besides, a typical result of executing illegal instructions is that the device hangs or reboots. Since alcohol testing devices don't do that (to the best of my knowledge), it appears that disabling those interrupts does not cause any harm.
There IS something in software engineering that says you should take every precaution to avoid introducing errors into your code and that you should validate all inputs into your process. A computer (device) rebooting due to illegal instructions is really some low level validation code that forces a shutdown to avoid nasty things like corrupting your data or reformatting your hard drive. What these people have done is to remove this level of validation. If they left this error-checking in place, the unit would probably 'reboot' every five minutes and they would never gotten through the marketing demo.
That conclusion is entirely unwarranted. It appears to be designed to provide a weighted average, not show undue accuracy, and is sufficiently well-tested that it does not need emergency measures like the illegal instruction interrupt. In other words, even though the software may look messy it is working fine.
The interrupts are not emergency measures. If anything, they are safety measures. They were probably taken so that the device would appear to pass any 'testing' that had been performed. I have another deal for you. It's called a sub-prime mortgage
How can you work when the system's so crowded?