They don't actually have to know the criteria to evade them. Did you read the paper a year or two back that showed that targetted searches were provably less secure than random? Basically, all they need to do is send potential agents on "innocent" flights that are not the part of any plot. By tracking who is searched how often, they can build a model of the odds that a particular agent is on a watch list. Then, they an select the least likely to be scrutinized and improve the odds of success. True random searches are the only way to avoid this because there is no strategy for the terrorists that can improve their success rate.
Yes, I know what writing off means, thank you. Do you?
In this case, it would allow the bank to offset part of its gross income and pay a smaller tax as a result. The impact would be to reduce its cost of eating the loss by the lost amount times its tax rate. That fraction is in essence picked up by the government and paid for by the tax payers as a group rather than the bank.
As I said, the bank is in the best position to be able to afford the loss due to the fraud. For the typical individual, a piece of real estate is far more valuable than the rest of his assets and the loss is catastrophic. This is not true for a typical bank. Perhaps more ideally would be an insurance company -- I'm not terribly familiar with insurance matters, but there probably are policies to deal with this sort of issue. If not, there certainly could be.
The likelihood of a two-man team perpetrating fraud like this is extremely small. A key element of a successful fraud is getting out of the area BEFORE anyone is even aware that something is wrong. That would be impossible for the party who received payment from the bank. You can expect that there would be intense scrutiny of that party as part of the investigation giving rise to the refund. The odds of getting busted would be very high.
There are four parties involved and under the current law, two victims. The legitimate owner and the would-be buyer both get screwed. The illegitimate seller and the bank both get off without injury (assuming the thief evades the authorities). This is a poor arrangement because the party most capable of managing the loss -- the bank -- has virtually no incentive to ensure that all its dealings are on the up-and-up.
Even the smallest mortgage bank is far wealthier than the usual homeowners involved. Plus, they may have insurance for their investments (don't know for sure whether such insurance exists, but it seems likely) and can certainly be compensated through writing off loss through fraud.
They are also in the best position to help ensure that everyone does their due diligence to prevent such fraud from occurring. If it costs the bank when they screw up, they'll take that a lot more seriously.
Clearly the fairest way to resolve the situation is to refund the buyer's purchase price and return the property to its original owner. Everyone still has injuries (except the asshat fraudster), but no one is out a life's savings.
Maybe once upon a time, but I've had a Windows XP (+ linux) laptop since January that I almost never reboot except when I want to switch between OSes. When it's plugged in, it stays on full all the time and when it's off the wall it stands by. I've never had any problem with it waking. I've never found any reason to shut it down as a precaution other than when I feel like saving power.
Actually, with the current Gentoo kernel, I'm having problems with it waking from standby, so I do shut it down when I'm on the Linux side. Still no need for Windows, though.
And, for the record, I'd be pissed as hell if my computer insisted on making any sound more protracted than a BIOS beep at boot. I might even be pissed about that, but mine doesn't make any sound at all, so I don't know. Frankly, even the Mac startup sound is obnoxious.
The only "true" boot sound is a 5-1/4 floppy drive seek followed by that good old beep. If that's the Vista boot sound, then I guess it's ok...
Ok, well, if you're talking about King's Quest, I hear you. I never got in to those. Space Quest and Leisure Suit Larry were great, but I always found King's Quest to be less than enthralling. Might just be that it was more serious (and less bawdy)...
That's no different than any other form of entertainment. If you don't like a book or movie, it's because you don't like what the author had the characters doing. The only difference is that in a game, you are in charge of figuring out what it is that the character is to do.
Personally, I love trying to figure out what the author had in mind. As long as there's some logic to it, I don't usually find it too frustrating. I can understand that not everyone would like this, though.
As the parent pointed out, some game authors are better at writing non-frustrating adventure games than others. The old Sierra games were very hard (but not as bad as some of the Infocom stuff). Monkey Island and its sequels were great in terms of not letting you shoot yourself in the foot. The later Sierra's were more like this as well. There is a certain charm to the really farking hard games -- it gives you a sense of triumph when you do figure it out in the end. However, it can be a painful road...
I actually do keep fingerprints on my thumb drive. RSA fingerprints for the servers I ssh to so I can verify them when I connect from a new ssh installation.
I don't think you give RMS credit. Sure, his public appearances and talks focus on evanglism. However, he and the organization he built do a lot more than cheerlead for free software projects. As others have pointed out, one person only has so much time available, and only a fraction of that in the public eye. Just because he focuses on one aspect doesn't mean he's not interested or not working on other fronts as well.
You have a good point and I, too, hope that (a) this experiment works and (b) it's well documented, whether it succeeds or fails. If it succeeds, obviously, it's great ammunition for future debates. If it fails, then it'll be an excellent opportunity to evaluate the shortcomings and try to address them rationally.
Just because the dictionary says something doesn't make it correct either.:-)
As I'm sure you know, words often have multiple definitions. Technical terms in particular are not well represented in dictionaries, so be careful when you try to apply what Webster's (or even the venerable OED) tells you is the meaning of a word being used by an engineer. For the standard English "optimize," you're absolutely correct. When a programmer "optimizes," however, he's making an enhancement that improves some aspect of the code other than its functional correctness. Usually, he's trying to speed it up or make it use less memory. Even if he stops short of the mathematically provable optimum, he has still done some optimization.
Even if you don't buy my argument that there's more than one word spelled "optimize," by the definition you cite, there are degrees of optimization. The very meaning of "as perfect [...] as possible" assumes some particular purpose for which the optimized construct is perfect. Thus, you can have a piece of code that is optimized for speed but lousy for code size, etc. It comes down to context.
Yep... that was the golden age for a lot of reasons. I still like writing software for embedded systems, not least because the microcontrollers you get to use are often at about the same complexity as a computer from the early 80s. Sure, they're faster and have more RAM, but you generally don't have complex memory controllers and other peripherals that get in the way. Plus, you can buy a PIC or other similar little jellybean micro for about a dollar and slap it on a $33 custom PCB (if you're a student you can buy just one and get a free pizza, otherwise you have to buy three and no pizza, but you still get the standard bag of microwave popcorn). If you can fit it on a two-layer board, for about $50 total you can put together your own custom embedded device and understand exactly what's going on.
Re:Blog First, Then Scientific Journals.
on
Dark Matter Exists
·
· Score: 1
Yeah, Sean Carroll knows what he's talking about. He wrote the book on General Relativity. Ok, well, maybe not THE book, but a very good book nonetheless.
I dunno, I don't think it's so bad. First of all, we don't really mean by "optimize" what you suggest. Rather, it now refers to a particular type of enhancement made to improve a piece of code in some way. Second, even this isn't so much at odds with the original meaning. If you distinguish between the global absolute "optimal" and local measures of optimality in a specific way (code size, data size, number of floating point operations, complexity, etc), it's easy to see that optimizing one axis disproportionately compared to others is possible. Since it's so rare to have a problem where "optimal" in the global sense can even be found, I don't think it's much of a stretch to use the word in a more useful way, even if it's a slight change from the original meaning.
Also, akin to my example of porting code, to a new architecture, changing the environment can change what is truly optimal. It's not hard to imagine taking a piece of code and truly, globally, perfectly optimizing it for a specific application on a processor. Then, someone gets the bright idea to reuse it for a slightly different application on a different processor. Odds are that a lot of those optimizations are going to be a handicap in the new circumstance. Sure, it was optimal to begin with, but it may have been less flexible. Unless we really NEEDED that last bit of performance/whatever in the original application, we've over-optimized and shot ourselves in the proverbial foot.
Now, you may say that this can't happen because clearly we didn't use the right meaning of optimality. Had we included the flexibility to port it around as part of the original definition of optimal, we'd not have run into this problem. It doesn't take much to see that this is not a helpful way to think about optimization, though. Nothing can be absolutely perfect because you don't know what problems the future will throw at you. Pursuit of anything more than "good enough" is often a mistake and can be considered over-optimization. To put it in a sound bite, "Optimal isn't."
Of course -- writing embedded software/firmware is often closer to hardware than software development. Still, you wouldn't normally worry much about architecture details of, say, the off-the-shelf microcontroller that you're using to talk to the framebuffer, unless you were really concerned about running it at 100% efficiency.
Makes sense -- you're probably ok if you just monitor what's happening on your own machine. At least, I'd hope so...
Even if you don't track the guy down, it'd be fun just to monitor the slimeball's activities. And if you get lucky, maybe he'll download some child pr0n. That'd get the authorities involved, I bet. Of course, then you'll never see your laptops again because they'll be "tainted" and subject to civil forfeiture. Aaiyee...
I can just imagine a countersuit against you for something (wiretapping, unauthorized use of his services, ??) for doing that. Sort of along the lines of the thief who injures himself while breaking in to a home suing the homeowner for negligence. Monitoring what he does on your machine is probably (?) fine, but I imagine you open yourself up for a whole lot of headaches as soon as you do anything with a sniffed password.
If you're doing this for a company, run it by legal first... breaking a law in the name of apprehending a criminal is a right generally reserved for sworn officers.
Re:For most problems...
on
Computer Voodoo?
·
· Score: 4, Insightful
I know where you're coming from, but I disagree somewhat. I don't think understanding the physics of the semiconductors is terribly important unless you are actively working on engineering better chips. It's intellectually interesting (to some), but it's really of very little value when it comes time to program.
Even understanding the architecture of your processor is only of value to some programmers. For most, it's better to understand the programming model for the particular language being used and tailor your program to that abstraction. Trying to apply knowledge of the low-level architecture in high-level programming is a recipe for over-optimization, especially if that code ever gets ported to another architecture.
Now, in the latter case, I will grant that it's indispensible to have learned the details at least one computation architecture through and through at some point. It almost doesn't matter what it is, since it's the process of stepping back and thinking about how to construct machines that compute that is the enlightening bit. It's really astonishing how "dumb" the logic behind a really "smart" processor can be. However, day-to-day, it's very rare to actually need to apply details for the specific machine you're using.
If you're writing DSP code or other real-time embedded stuff, this is obviously different, but that's a very small subset of all programmers.
Their examples may be wrong, but the basic point is still correct. Given a float representation, you cannot guarantee correct rounding, even in your very last step. You can do everything right, preserving all the digits you've got, all the way through. At the end, your approximation may end up slightly above or slightly below your precise threshold. If your application demands that you round correctly (in base 10) 100% of the time, your float implementation cannot guarantee that. Add as much precision as you like and there's still a risk that you end up on the wrong side of the fence.
In your example, this amounts to the admittedly unlikely case that you end up with a calculation that gives 1648.659999999999999999994 instead of 1648.66000000000000002. (I did not check that to be sure it's really a pair of base-2 fractions, but that's incidental) When you round that, getting the correct answer depends on guaranteeing you get the right one of those. This has nothing to do with throwing away precision.
There are many alternatives to floating point for this. They're not as fast on the binary hardware we've got, but basically you need to avoid working in a base other than the one you need accuracy in. If you do your math using a base-10 library, then rounding is easy and can be guaranteed. Likewise, if you need accurate rounding in base-2, then go ahead and use a float (as long as your value doesn't "overflow" past the precision of your mantissa).
Most of the time, the odds of an error like this are small enough that the occasional error is tolerable. But, when it's not tolerable, it's not tolerable...
Slashdot Mirror
Chakrabarti and Strauss's Term Paper on the subject.
They don't actually have to know the criteria to evade them. Did you read the paper a year or two back that showed that targetted searches were provably less secure than random? Basically, all they need to do is send potential agents on "innocent" flights that are not the part of any plot. By tracking who is searched how often, they can build a model of the odds that a particular agent is on a watch list. Then, they an select the least likely to be scrutinized and improve the odds of success. True random searches are the only way to avoid this because there is no strategy for the terrorists that can improve their success rate.
Yes, I know what writing off means, thank you. Do you?
In this case, it would allow the bank to offset part of its gross income and pay a smaller tax as a result. The impact would be to reduce its cost of eating the loss by the lost amount times its tax rate. That fraction is in essence picked up by the government and paid for by the tax payers as a group rather than the bank.
This is a commonly allowed type of deduction.
As I said, the bank is in the best position to be able to afford the loss due to the fraud. For the typical individual, a piece of real estate is far more valuable than the rest of his assets and the loss is catastrophic. This is not true for a typical bank. Perhaps more ideally would be an insurance company -- I'm not terribly familiar with insurance matters, but there probably are policies to deal with this sort of issue. If not, there certainly could be.
The likelihood of a two-man team perpetrating fraud like this is extremely small. A key element of a successful fraud is getting out of the area BEFORE anyone is even aware that something is wrong. That would be impossible for the party who received payment from the bank. You can expect that there would be intense scrutiny of that party as part of the investigation giving rise to the refund. The odds of getting busted would be very high.
There are four parties involved and under the current law, two victims. The legitimate owner and the would-be buyer both get screwed. The illegitimate seller and the bank both get off without injury (assuming the thief evades the authorities). This is a poor arrangement because the party most capable of managing the loss -- the bank -- has virtually no incentive to ensure that all its dealings are on the up-and-up.
Even the smallest mortgage bank is far wealthier than the usual homeowners involved. Plus, they may have insurance for their investments (don't know for sure whether such insurance exists, but it seems likely) and can certainly be compensated through writing off loss through fraud.
They are also in the best position to help ensure that everyone does their due diligence to prevent such fraud from occurring. If it costs the bank when they screw up, they'll take that a lot more seriously.
Clearly the fairest way to resolve the situation is to refund the buyer's purchase price and return the property to its original owner. Everyone still has injuries (except the asshat fraudster), but no one is out a life's savings.
Maybe once upon a time, but I've had a Windows XP (+ linux) laptop since January that I almost never reboot except when I want to switch between OSes. When it's plugged in, it stays on full all the time and when it's off the wall it stands by. I've never had any problem with it waking. I've never found any reason to shut it down as a precaution other than when I feel like saving power.
Actually, with the current Gentoo kernel, I'm having problems with it waking from standby, so I do shut it down when I'm on the Linux side. Still no need for Windows, though.
And, for the record, I'd be pissed as hell if my computer insisted on making any sound more protracted than a BIOS beep at boot. I might even be pissed about that, but mine doesn't make any sound at all, so I don't know. Frankly, even the Mac startup sound is obnoxious.
The only "true" boot sound is a 5-1/4 floppy drive seek followed by that good old beep. If that's the Vista boot sound, then I guess it's ok...
... and the LED lightbulb spectra will be even LESS comforting than the CFL's.
Ok, well, if you're talking about King's Quest, I hear you. I never got in to those. Space Quest and Leisure Suit Larry were great, but I always found King's Quest to be less than enthralling. Might just be that it was more serious (and less bawdy)...
That's no different than any other form of entertainment. If you don't like a book or movie, it's because you don't like what the author had the characters doing. The only difference is that in a game, you are in charge of figuring out what it is that the character is to do.
Personally, I love trying to figure out what the author had in mind. As long as there's some logic to it, I don't usually find it too frustrating. I can understand that not everyone would like this, though.
As the parent pointed out, some game authors are better at writing non-frustrating adventure games than others. The old Sierra games were very hard (but not as bad as some of the Infocom stuff). Monkey Island and its sequels were great in terms of not letting you shoot yourself in the foot. The later Sierra's were more like this as well. There is a certain charm to the really farking hard games -- it gives you a sense of triumph when you do figure it out in the end. However, it can be a painful road...
a real Jamaican access point?
No, but they put up with a hell of a lot more inconvenient and intrusive searches, interrogations, etc, when they fly.
I actually do keep fingerprints on my thumb drive. RSA fingerprints for the servers I ssh to so I can verify them when I connect from a new ssh installation.
I don't think you give RMS credit. Sure, his public appearances and talks focus on evanglism. However, he and the organization he built do a lot more than cheerlead for free software projects. As others have pointed out, one person only has so much time available, and only a fraction of that in the public eye. Just because he focuses on one aspect doesn't mean he's not interested or not working on other fronts as well.
You have a good point and I, too, hope that (a) this experiment works and (b) it's well documented, whether it succeeds or fails. If it succeeds, obviously, it's great ammunition for future debates. If it fails, then it'll be an excellent opportunity to evaluate the shortcomings and try to address them rationally.
No, no it doesn't.
Just because the dictionary says something doesn't make it correct either. :-)
As I'm sure you know, words often have multiple definitions. Technical terms in particular are not well represented in dictionaries, so be careful when you try to apply what Webster's (or even the venerable OED) tells you is the meaning of a word being used by an engineer. For the standard English "optimize," you're absolutely correct. When a programmer "optimizes," however, he's making an enhancement that improves some aspect of the code other than its functional correctness. Usually, he's trying to speed it up or make it use less memory. Even if he stops short of the mathematically provable optimum, he has still done some optimization.
Even if you don't buy my argument that there's more than one word spelled "optimize," by the definition you cite, there are degrees of optimization. The very meaning of "as perfect [...] as possible" assumes some particular purpose for which the optimized construct is perfect. Thus, you can have a piece of code that is optimized for speed but lousy for code size, etc. It comes down to context.
Yep... that was the golden age for a lot of reasons. I still like writing software for embedded systems, not least because the microcontrollers you get to use are often at about the same complexity as a computer from the early 80s. Sure, they're faster and have more RAM, but you generally don't have complex memory controllers and other peripherals that get in the way. Plus, you can buy a PIC or other similar little jellybean micro for about a dollar and slap it on a $33 custom PCB (if you're a student you can buy just one and get a free pizza, otherwise you have to buy three and no pizza, but you still get the standard bag of microwave popcorn). If you can fit it on a two-layer board, for about $50 total you can put together your own custom embedded device and understand exactly what's going on.
Yeah, Sean Carroll knows what he's talking about. He wrote the book on General Relativity. Ok, well, maybe not THE book, but a very good book nonetheless.
I dunno, I don't think it's so bad. First of all, we don't really mean by "optimize" what you suggest. Rather, it now refers to a particular type of enhancement made to improve a piece of code in some way. Second, even this isn't so much at odds with the original meaning. If you distinguish between the global absolute "optimal" and local measures of optimality in a specific way (code size, data size, number of floating point operations, complexity, etc), it's easy to see that optimizing one axis disproportionately compared to others is possible. Since it's so rare to have a problem where "optimal" in the global sense can even be found, I don't think it's much of a stretch to use the word in a more useful way, even if it's a slight change from the original meaning.
Also, akin to my example of porting code, to a new architecture, changing the environment can change what is truly optimal. It's not hard to imagine taking a piece of code and truly, globally, perfectly optimizing it for a specific application on a processor. Then, someone gets the bright idea to reuse it for a slightly different application on a different processor. Odds are that a lot of those optimizations are going to be a handicap in the new circumstance. Sure, it was optimal to begin with, but it may have been less flexible. Unless we really NEEDED that last bit of performance/whatever in the original application, we've over-optimized and shot ourselves in the proverbial foot.
Now, you may say that this can't happen because clearly we didn't use the right meaning of optimality. Had we included the flexibility to port it around as part of the original definition of optimal, we'd not have run into this problem. It doesn't take much to see that this is not a helpful way to think about optimization, though. Nothing can be absolutely perfect because you don't know what problems the future will throw at you. Pursuit of anything more than "good enough" is often a mistake and can be considered over-optimization. To put it in a sound bite, "Optimal isn't."
Of course -- writing embedded software/firmware is often closer to hardware than software development. Still, you wouldn't normally worry much about architecture details of, say, the off-the-shelf microcontroller that you're using to talk to the framebuffer, unless you were really concerned about running it at 100% efficiency.
Makes sense -- you're probably ok if you just monitor what's happening on your own machine. At least, I'd hope so...
Even if you don't track the guy down, it'd be fun just to monitor the slimeball's activities. And if you get lucky, maybe he'll download some child pr0n. That'd get the authorities involved, I bet. Of course, then you'll never see your laptops again because they'll be "tainted" and subject to civil forfeiture. Aaiyee...
I'm always naysaying, but...
I can just imagine a countersuit against you for something (wiretapping, unauthorized use of his services, ??) for doing that. Sort of along the lines of the thief who injures himself while breaking in to a home suing the homeowner for negligence. Monitoring what he does on your machine is probably (?) fine, but I imagine you open yourself up for a whole lot of headaches as soon as you do anything with a sniffed password.
If you're doing this for a company, run it by legal first... breaking a law in the name of apprehending a criminal is a right generally reserved for sworn officers.
Ok, sorry, misunderstood the point of your post.
I know where you're coming from, but I disagree somewhat. I don't think understanding the physics of the semiconductors is terribly important unless you are actively working on engineering better chips. It's intellectually interesting (to some), but it's really of very little value when it comes time to program.
Even understanding the architecture of your processor is only of value to some programmers. For most, it's better to understand the programming model for the particular language being used and tailor your program to that abstraction. Trying to apply knowledge of the low-level architecture in high-level programming is a recipe for over-optimization, especially if that code ever gets ported to another architecture.
Now, in the latter case, I will grant that it's indispensible to have learned the details at least one computation architecture through and through at some point. It almost doesn't matter what it is, since it's the process of stepping back and thinking about how to construct machines that compute that is the enlightening bit. It's really astonishing how "dumb" the logic behind a really "smart" processor can be. However, day-to-day, it's very rare to actually need to apply details for the specific machine you're using.
If you're writing DSP code or other real-time embedded stuff, this is obviously different, but that's a very small subset of all programmers.
Their examples may be wrong, but the basic point is still correct. Given a float representation, you cannot guarantee correct rounding, even in your very last step. You can do everything right, preserving all the digits you've got, all the way through. At the end, your approximation may end up slightly above or slightly below your precise threshold. If your application demands that you round correctly (in base 10) 100% of the time, your float implementation cannot guarantee that. Add as much precision as you like and there's still a risk that you end up on the wrong side of the fence.
In your example, this amounts to the admittedly unlikely case that you end up with a calculation that gives 1648.659999999999999999994 instead of 1648.66000000000000002. (I did not check that to be sure it's really a pair of base-2 fractions, but that's incidental) When you round that, getting the correct answer depends on guaranteeing you get the right one of those. This has nothing to do with throwing away precision.
There are many alternatives to floating point for this. They're not as fast on the binary hardware we've got, but basically you need to avoid working in a base other than the one you need accuracy in. If you do your math using a base-10 library, then rounding is easy and can be guaranteed. Likewise, if you need accurate rounding in base-2, then go ahead and use a float (as long as your value doesn't "overflow" past the precision of your mantissa).
Most of the time, the odds of an error like this are small enough that the occasional error is tolerable. But, when it's not tolerable, it's not tolerable...