Wha? How about this: "STV is a voting system whereby voters rank candidates in order of preference. If their primary choice stands no chance of election their vote is transfered to their second choice. This is repeated until only one candidate remains."
Really though, how complicated is "Rank the candidates according to your preference."? Stupid people.
A byte *is* an 8-dimensional bit, at least in the mathematical vector sense. Not a particularly useful description of a byte though. And this use of '5 dimensional' is pure marketing bollocks.
Running mathematical algorithms is usually a very small part of what the average desktop program does. Java can be very fast at this since it essentially produces the same assembly as the equivalent C program. For example something like
for (int i = 0; i 1000; ++i) total += i;
is going to produce exactly the same machine code in Java or C. I think the difference comes when you start writing real-world desktop programs. These make use of things like vector's strings, function calls, etc. which seem to slow java programs down. I'd also argue that the java programming paradigm and API forces you to do 'slow things'. Consider the mess that is String/StringBuilder compared to std::string or QString.
As evidence I present the only non-trivial Java programs I've actually used:
Azereus: I think this one isn't actually too bad, but many people complain about its memory use/speed. Netbeans: Awesome program but very slow. Eclipse: Tried this once. It was excrutiatingly slow. Slow enough to be unusable.
Compare that to roughly equivalent C++ programs:
KTorrent/uTorrent: Admittedly not as large or advance but they are both much much faster and smaller. MS Visual Studio/KDevelop: Again, much much faster.
No doubt the Java fan-boys are going to say "It's all swing's fault!" or "That's not a very objective argument." to which I would say:
* Yes it probably is largely the fault of the Java API being really really annoying, but there's no way to avoid that is there? * It's also a very hard thing to test. The reason benchmarks are all the misleading mathematical algorithm type is because they are quick to write. No-one's going to rewrite eclipse in C++. We can only compare roughly equivalent large programs.
You jest, but this technique *has* been around for years. I remember when digital cameras first became available there was a product that could perform a 3D scan by projecting a pattern onto the object and using an offset picture. I think the pattern came on a slide - that's how long ago it was! Here's a whole wikipedia page about the scanning technique: http://en.wikipedia.org/wiki/Structured_Light_3D_Scanner
Anyway after reading the patent abstract, it isn't about the 3D scanning at all, it appears to be about an algorithm to find the fold once you've already got the point cloud. I would have thought that was fairly trivial. A possible approach would be to take the radon transform of the height map and find the smallest value that's roughly in the middle.
You're interpreting 'unsafe' to mean 'possible to exploit/crash'. I think the parent was taking it to mean 'likely to lead to exploitable/crashable code'. You can hardly argue about that. Just look at the number of sprintf/strcpy security vulnerabilities compared to std::string-caused vulnerabilities.
When writing modern C++ there are very few situations where you need to use memcpy. Still there are some, and I don't think they should get rid of it entirely.
You can use them for more than books. Think what kind of PDFs you might use - sheet music, manuals, business documents, API references, presentations, etc.
Actually current devices probably aren't that great for these purposes but the Plastic Logic reader and Kindle DX should be ideal.
"My argument rests on people preferring paper to e-books, and I think they do."
For now, but that's mainly due to the extreme slowness of e-ink. Imagine if colour video-speed e-ink. Many people would stop buying paper books even if the price doesn't come down at all.
As it is currently they are fairly benign. The vast majority of CCTV cameras are in places corner shops and supermarkets. These aren't really monitored and the video data isn't accessible from elsewhere. There's no real danger to privacy and certainly people on Slashdot care far more about Britain's CCTV cameras than the British!
However the danger comes when a large enough network of CCTV cameras (e.g. on the underground or in central london) is combined with sufficiently advanced computer vision software. This would allow the kind of data mining that people *should* be worried about.
This hardly ever works any more. As someone above said, it is evil and violates Google's policies but they definitely know about it and for some reason don't do anything to stop it.
Forget SSH, what about SSL? I fail to see how they will intercept facebook & gmail messages for example. The whole point of this system supposedly is to intercept email, and no-one ever mentions that in most cases it won't even work.
Yeah. There are lots of very easy-looking (to humans) scenes in the episode I watched where it detected a face (a fairly solved computer vision problem) but couldn't detect who it was.
This data set is also possibly the easiest one they could have chosen. All the shots are very simple - the camera never moves. There are a limited number of characters and most of their faces are pretty distinct (e.g. one black woman, one with crazy eyebrows, etc.)
Still, it's quite impressive that it works as well as it did.
Slashdot Mirror
"STV is too complex to describe briefly."
Wha? How about this: "STV is a voting system whereby voters rank candidates in order of preference. If their primary choice stands no chance of election their vote is transfered to their second choice. This is repeated until only one candidate remains."
Really though, how complicated is "Rank the candidates according to your preference."? Stupid people.
A byte *is* an 8-dimensional bit, at least in the mathematical vector sense. Not a particularly useful description of a byte though. And this use of '5 dimensional' is pure marketing bollocks.
Not pedestrianised unfortunately, but only buses, taxis and cyclists can go there.
Well I expect this will be most useful in the UK for streets where the google cars can't go, e.g. Oxford Street.
But those are all diesel cars. They always get better mileage than petrol cars.
Still if you look at this page:
http://en.wikipedia.org/wiki/List_of_May_2008_UK_fuel_economy_ratings
There are several petrol cars that get over 50 mpg.
You can't link to the daily mail and expect to be taken seriously.
Running mathematical algorithms is usually a very small part of what the average desktop program does. Java can be very fast at this since it essentially produces the same assembly as the equivalent C program. For example something like
for (int i = 0; i 1000; ++i) total += i;
is going to produce exactly the same machine code in Java or C. I think the difference comes when you start writing real-world desktop programs. These make use of things like vector's strings, function calls, etc. which seem to slow java programs down. I'd also argue that the java programming paradigm and API forces you to do 'slow things'. Consider the mess that is String/StringBuilder compared to std::string or QString.
As evidence I present the only non-trivial Java programs I've actually used:
Azereus: I think this one isn't actually too bad, but many people complain about its memory use/speed.
Netbeans: Awesome program but very slow.
Eclipse: Tried this once. It was excrutiatingly slow. Slow enough to be unusable.
Compare that to roughly equivalent C++ programs:
KTorrent/uTorrent: Admittedly not as large or advance but they are both much much faster and smaller.
MS Visual Studio/KDevelop: Again, much much faster.
No doubt the Java fan-boys are going to say "It's all swing's fault!" or "That's not a very objective argument." to which I would say:
* Yes it probably is largely the fault of the Java API being really really annoying, but there's no way to avoid that is there?
* It's also a very hard thing to test. The reason benchmarks are all the misleading mathematical algorithm type is because they are quick to write. No-one's going to rewrite eclipse in C++. We can only compare roughly equivalent large programs.
You jest, but this technique *has* been around for years. I remember when digital cameras first became available there was a product that could perform a 3D scan by projecting a pattern onto the object and using an offset picture. I think the pattern came on a slide - that's how long ago it was! Here's a whole wikipedia page about the scanning technique: http://en.wikipedia.org/wiki/Structured_Light_3D_Scanner
This picture is especially good: http://en.wikipedia.org/wiki/File:6-seat.jpg
Anyway after reading the patent abstract, it isn't about the 3D scanning at all, it appears to be about an algorithm to find the fold once you've already got the point cloud. I would have thought that was fairly trivial. A possible approach would be to take the radon transform of the height map and find the smallest value that's roughly in the middle.
You're interpreting 'unsafe' to mean 'possible to exploit/crash'. I think the parent was taking it to mean 'likely to lead to exploitable/crashable code'. You can hardly argue about that. Just look at the number of sprintf/strcpy security vulnerabilities compared to std::string-caused vulnerabilities.
When writing modern C++ there are very few situations where you need to use memcpy. Still there are some, and I don't think they should get rid of it entirely.
You get a pair for free with the BT Vision box I think. It costs £30.
That's the same. You just started n at a different value... :-)
You know you don't actually need to do that.
average = (new_value-average)/++n + average;
I think that should work.
You can use them for more than books. Think what kind of PDFs you might use - sheet music, manuals, business documents, API references, presentations, etc.
Actually current devices probably aren't that great for these purposes but the Plastic Logic reader and Kindle DX should be ideal.
You know you can use ebook readers for more than just books? At least you will be able to once the A4 size ones materialise.
Maybe not many people read books, but lots print PDFs.
"My argument rests on people preferring paper to e-books, and I think they do."
For now, but that's mainly due to the extreme slowness of e-ink. Imagine if colour video-speed e-ink. Many people would stop buying paper books even if the price doesn't come down at all.
"a bit slower since reading text on a monitor is still not quite as easy as a real book."
It amazes me how many people think ebook readers are just netbooks without keyboards. The screen looks like paper!
As it is currently they are fairly benign. The vast majority of CCTV cameras are in places corner shops and supermarkets. These aren't really monitored and the video data isn't accessible from elsewhere. There's no real danger to privacy and certainly people on Slashdot care far more about Britain's CCTV cameras than the British!
However the danger comes when a large enough network of CCTV cameras (e.g. on the underground or in central london) is combined with sufficiently advanced computer vision software. This would allow the kind of data mining that people *should* be worried about.
This hardly ever works any more. As someone above said, it is evil and violates Google's policies but they definitely know about it and for some reason don't do anything to stop it.
Forget SSH, what about SSL? I fail to see how they will intercept facebook & gmail messages for example. The whole point of this system supposedly is to intercept email, and no-one ever mentions that in most cases it won't even work.
Yeah. There are lots of very easy-looking (to humans) scenes in the episode I watched where it detected a face (a fairly solved computer vision problem) but couldn't detect who it was.
This data set is also possibly the easiest one they could have chosen. All the shots are very simple - the camera never moves. There are a limited number of characters and most of their faces are pretty distinct (e.g. one black woman, one with crazy eyebrows, etc.)
Still, it's quite impressive that it works as well as it did.
Doesn't look that interesting really...
"No, the project will probably pipe 9MW of heat from the server farm over to the housing complex."
No you're wrong. Heat is the energy transfered (measured in Joules). The 9MW is the heat transfer *rate* and it is indeed a power quantity.
Ask Wikipedia if you don't believe me: http://en.wikipedia.org/wiki/Heat#Notation
Yes you just described a thought experiment. But data visualisation is still unrelated. Einstein couldn't have done it (no computers).
I'm still not seeing how thought experiments (an imaginary experiment) and data visualisation (finding ways to display complex datasets) are related.
Thought experiments seem pretty different to data visualisation to me. In fact, how are they remotely related?