If you call the poll answers 0 for "not online" and 1 for "online", standard error can be calculated easily. First, standard deviation = square root of [mean of squares - square of mean]; both 0 and 1 are identities under squaring, so the mean of the squares is the same as the mean. So, stddev = sqrt(0.67 - 0.67^2) = 0.470. Standard error is calculated by dividing this by the square root of the number of samples; 0.470/sqrt(6403) = 0.00588.
That's an error of +-0.59% for both percentages, making the difference between 66% and 68% even less significant. The fact that only two digits of them are presented adds another +-0.5% error for both values, in a flat distribution. I don't know how to calculate the resultant significance, but it's pretty damned negligible.
If you want to split hairs, NTSC actually has 485 lines, and the 485th line is only about 2/3 used. But nearly all SD TV is digital these days (even if you're getting analog reception, it's likely to come from a digital uplink at the base station) so most of the time only 480 lines will be used.
I do notably remember that ST:DS9 was 485 lines on my local UPN when I last checked.
If you synchronize the pixel clock with the color clock* (which is convenient for a composite signal), NTSC is roughly 740x485 (roughly, because various sources use slightly different portions of the horizontal space). Years ago I watched TV in a custom 768x485 video mode so there was utterly no resampling or cropping, using my ATI All-in-Wonder Pro and a custom-modified version of GATOS.
PAL would be about 768x576 with a synchronized pixel/color clock. But I've never had the opportunity to test that with a real PAL source. I don't know whether most real PAL sources use more than 768 or less than 768, nor how many extra rows there are, if any.
*The NTSC clock referred to is 14318181.8 MHz (910*525*30000/1001), four samples for each cycle of the color clock.
About 7 years ago, I was fantasizing about the Ultimate Camera, and realized that it would record simply the location and direction of every photon entering its sensor. I didn't know how such a thing could be accomplished, but I was sure technology would eventually reach that point.
So this is awesome! I imagined this idea becoming practical only in the far future. Now it looks like it merely needs more megapixels.
The way it worked was, the TI-92 let you send and receive a "backup" -- an image of its RAM starting from a certain address. I sent a super-large RAM image that wrapped around over the top of its memory and into the interrupt vector table, so that the first time an interrupt occurred it would execute my hook (which I put elsewhere in the image).
The downside of this method was that sending the huge backup took a lot of time, which was especially inconvenient for me because I had to resend it every time I changed the kernel. Later I found a more streamlined hacking method; I found a callback function pointer in the RAM image, and modified the RAM image to make it point to my hook.
I later used a buffer overflow in a certain online PC game for non-evil purposes. I released an unofficial patch that exploited this, to remotely disable a cheat for the game I had previous written which had been leaked and abused, and also to allow people to host games with more options using remotely-executed code (the same code would run locally so the options would be the same on all ends). My patch also fixed some bugs in the game, like incompatibility with Windows 2000/XP.
The company that made this game noticed my patch and offered me the job of working on an official patch. This surprised the heck out of me but of course I accepted! Since then, I plugged the security hole. But had I not been hired, I would've wrapped a security layer around it and used it to further open the game to customization. Having the source code is much better though.:-)
If the flash demonstration is representative of their experiment, it is just ridiculous.
I tried the tests. In test A, I vaguely noticed something that might be sideways, a tree or something, but I wasn't sure. In test B I didn't notice anything that I could be at all sure was sideways. In test C however the lighthouse jumped out at me like a sore thumb and was obviously sideways.
So, I decided to figure out what was going on. I took screenshots while running the tests repeatedly until I got lucky and got a screenshot of one sideways image from each test. Guess what. The target image is different in each test, even though the static picture below claims that it is a lighthouse in each test. How the heck are you supposed to compare the results then?
The test A, the sideways image is a tree in what looks like desert-like terrain, with roughly an irregularly shaped 30% of the frame filled by sky. It is rotated 90 degrees clockwise. In test B, the target image is a picture of a bunch of trees against a misty mountain, rotated 90 degrees counterclockwise. In test C, the target image is a lighthouse on flat ground, rotated 90 degrees clockwise. A sideways lighthouse is obviously going to be easier to pick out, being linear in form... whereas trees are more organic, lacking in orthogonal lines.
So either the whole study was unscientific and the results meaningless, or this is a flash demonstration SNAFU and unrepresentative of the study.
Thanks, it makes perfect sense now.:-) Even if a user had broadband, there'd still be #2. Though if I were using your software I'd request a "maximum fuzziness" toggle.;-)
Ok, let me be honest... I didn't truly suspect it to be a fake, but it really bothers me how poor the video transfer was. I wanted to bring attention to that.:-\ It seems like it was converted from PAL to NTSC and back to PAL before being digitized. Step through it frame by frame, and you'll see that many frames are doubled or tripled while others seem to have been removed.
This has nothing to do with the image quality, which was just fine. This happens even to HDTV: Meerkat Adventure on Discovery HD showed random jerkiness due to PAL->NTSC framerate conversion, but the image quality was great.
I can understand why broadcast material sometimes has to be converted between NTSC and PAL; TVs can usually handle only their native framerate. But why do that to something targeted towards PCs, which can handle arbitary framerates?
The robot itself is very impressive. The footage of it balancing on one foot looks very real indeed and eliminated any real doubt in me. But the combination of the framerate jerkiness and the strange way the robot walks (static equilibrium every step of the way, apparently) made that part look like stop-motion animation to me.
Is it just me or does this video look a lot like stop-motion animation? This robot's movement immediately reminded me of the Terminator in the first movie after it had lost all its skin.
It's either that, or somebody did a really poor job on the video transfer. The MPEG stream is tagged with a framerate of 25 fps, but many of the frames are doubled at irregular intervals, resulting in a jerky look. It looks like some frames were decimated and others doubled, which makes no sense at all... yet even in some nasty PAL->NTSC transfers I've seen, the motion has looked fairly natural.
Maybe it's a combination of the poorly handled frame rate conversion in the video, and the fact that I'm not used to seeing real robots move.
I'm remaining skeptical for now, because if this is real, what this robot could would be very impressive indeed! (My jaw dropped anyway while watching its imitation game...)
I didn't realize you'd be replying here yourself.:) Thanks. The ability to browse the data at two zooms simultaneously indeed looks useful. But that doesn't answer my question...
I don't understand why the top graph doesn't make full use of pixel resolution. In the 6 hour view, every 2 pixel interval could represent 1 minute. But instead, every 7.8 pixel interval represents 4 minutes. Wouldn't the medium-zoomed rendering still be acceptibly fast if done at maximum resolution?
This is pretty cool... it'd be interesting to have graphs like this for my own home, and might even encourage conservation if I could see how much each thing was using. Too bad it's only of achedemic interest (I'm not about to go and install this, but it's impressive what this guy has done).
One thing I'm kinda puzzled about is the resolution of the graphs. If the hardware has a 3 second resolution, why only take averages at 1 minute fixed intervals? A shifting average (like in this experiment of mine) would make for prettier graphs and I doubt it would take much computation power (and might even reveal details that would otherwise go unnoticed).
I noticed that the graphs shown in the article don't even have a 1 minute resolution; for some reason they are limited to a 4 minute resolution. Seems silly to have such fine measurement resolution and throw it away in the graphs.:-\
I'm with you there -- I find tanned skin unattractive. But it seems most people like the look of a tan, so I've wondered if it has to do with my colorblindness. I have protanomalous vision (the response of my "red" cones is shifted towards green) so for example, green looks almost exactly like yellow to me, and red is quite dark.
Do you, like me, have some form of color deficiency?
One the one hand, I like "if (!ptr)" because it's terse yet logically intuitive; "if (!ptr)" means "if the pointer does NOT point to anything".
One the other hand, I like "if (ptr==NULL)" because then I can do a search for "NULL" and find all instances of pointers being tested for pointiness.
As a result, I use a mixture of the two in my code. D'oh!
I find it very interesting that RootkitRevealer finds a rootkit by virtue of its very attempt to hide. To hide from RootkitRevealer, all one would have to do is NOT hide from it!
Slashdot Mirror
If you call the poll answers 0 for "not online" and 1 for "online", standard error can be calculated easily. First, standard deviation = square root of [mean of squares - square of mean]; both 0 and 1 are identities under squaring, so the mean of the squares is the same as the mean. So, stddev = sqrt(0.67 - 0.67^2) = 0.470. Standard error is calculated by dividing this by the square root of the number of samples; 0.470/sqrt(6403) = 0.00588.
That's an error of +-0.59% for both percentages, making the difference between 66% and 68% even less significant. The fact that only two digits of them are presented adds another +-0.5% error for both values, in a flat distribution. I don't know how to calculate the resultant significance, but it's pretty damned negligible.
If I've made an error, someone please correct me.
If you want to split hairs, NTSC actually has 485 lines, and the 485th line is only about 2/3 used. But nearly all SD TV is digital these days (even if you're getting analog reception, it's likely to come from a digital uplink at the base station) so most of the time only 480 lines will be used.
I do notably remember that ST:DS9 was 485 lines on my local UPN when I last checked.
If you synchronize the pixel clock with the color clock* (which is convenient for a composite signal), NTSC is roughly 740x485 (roughly, because various sources use slightly different portions of the horizontal space). Years ago I watched TV in a custom 768x485 video mode so there was utterly no resampling or cropping, using my ATI All-in-Wonder Pro and a custom-modified version of GATOS.
PAL would be about 768x576 with a synchronized pixel/color clock. But I've never had the opportunity to test that with a real PAL source. I don't know whether most real PAL sources use more than 768 or less than 768, nor how many extra rows there are, if any.
*The NTSC clock referred to is 14318181.8 MHz (910*525*30000/1001), four samples for each cycle of the color clock.
So this is awesome! I imagined this idea becoming practical only in the far future. Now it looks like it merely needs more megapixels.
10E6 bots? How puny. My botnet is amplified by one to the tenth power!
I was the one who did that hack. :)
The way it worked was, the TI-92 let you send and receive a "backup" -- an image of its RAM starting from a certain address. I sent a super-large RAM image that wrapped around over the top of its memory and into the interrupt vector table, so that the first time an interrupt occurred it would execute my hook (which I put elsewhere in the image).
The downside of this method was that sending the huge backup took a lot of time, which was especially inconvenient for me because I had to resend it every time I changed the kernel. Later I found a more streamlined hacking method; I found a callback function pointer in the RAM image, and modified the RAM image to make it point to my hook.
I later used a buffer overflow in a certain online PC game for non-evil purposes. I released an unofficial patch that exploited this, to remotely disable a cheat for the game I had previous written which had been leaked and abused, and also to allow people to host games with more options using remotely-executed code (the same code would run locally so the options would be the same on all ends). My patch also fixed some bugs in the game, like incompatibility with Windows 2000/XP.
The company that made this game noticed my patch and offered me the job of working on an official patch. This surprised the heck out of me but of course I accepted! :-)
Since then, I plugged the security hole. But had I not been hired, I would've wrapped a security layer around it and used it to further open the game to customization. Having the source code is much better though.
If the flash demonstration is representative of their experiment, it is just ridiculous.
I tried the tests. In test A, I vaguely noticed something that might be sideways, a tree or something, but I wasn't sure. In test B I didn't notice anything that I could be at all sure was sideways. In test C however the lighthouse jumped out at me like a sore thumb and was obviously sideways.
So, I decided to figure out what was going on. I took screenshots while running the tests repeatedly until I got lucky and got a screenshot of one sideways image from each test. Guess what. The target image is different in each test, even though the static picture below claims that it is a lighthouse in each test. How the heck are you supposed to compare the results then?
The test A, the sideways image is a tree in what looks like desert-like terrain, with roughly an irregularly shaped 30% of the frame filled by sky. It is rotated 90 degrees clockwise. In test B, the target image is a picture of a bunch of trees against a misty mountain, rotated 90 degrees counterclockwise. In test C, the target image is a lighthouse on flat ground, rotated 90 degrees clockwise. A sideways lighthouse is obviously going to be easier to pick out, being linear in form... whereas trees are more organic, lacking in orthogonal lines.
So either the whole study was unscientific and the results meaningless, or this is a flash demonstration SNAFU and unrepresentative of the study.
Thanks, it makes perfect sense now. :-) Even if a user had broadband, there'd still be #2. Though if I were using your software I'd request a "maximum fuzziness" toggle. ;-)
Ok, let me be honest... I didn't truly suspect it to be a fake, but it really bothers me how poor the video transfer was. I wanted to bring attention to that. :-\ It seems like it was converted from PAL to NTSC and back to PAL before being digitized. Step through it frame by frame, and you'll see that many frames are doubled or tripled while others seem to have been removed.
This has nothing to do with the image quality, which was just fine. This happens even to HDTV: Meerkat Adventure on Discovery HD showed random jerkiness due to PAL->NTSC framerate conversion, but the image quality was great.
I can understand why broadcast material sometimes has to be converted between NTSC and PAL; TVs can usually handle only their native framerate. But why do that to something targeted towards PCs, which can handle arbitary framerates?
The robot itself is very impressive. The footage of it balancing on one foot looks very real indeed and eliminated any real doubt in me. But the combination of the framerate jerkiness and the strange way the robot walks (static equilibrium every step of the way, apparently) made that part look like stop-motion animation to me.
Is it just me or does this video look a lot like stop-motion animation? This robot's movement immediately reminded me of the Terminator in the first movie after it had lost all its skin.
It's either that, or somebody did a really poor job on the video transfer. The MPEG stream is tagged with a framerate of 25 fps, but many of the frames are doubled at irregular intervals, resulting in a jerky look. It looks like some frames were decimated and others doubled, which makes no sense at all... yet even in some nasty PAL->NTSC transfers I've seen, the motion has looked fairly natural.
Maybe it's a combination of the poorly handled frame rate conversion in the video, and the fact that I'm not used to seeing real robots move.
I'm remaining skeptical for now, because if this is real, what this robot could would be very impressive indeed! (My jaw dropped anyway while watching its imitation game...)
I didn't realize you'd be replying here yourself. :) Thanks. The ability to browse the data at two zooms simultaneously indeed looks useful. But that doesn't answer my question...
I don't understand why the top graph doesn't make full use of pixel resolution. In the 6 hour view, every 2 pixel interval could represent 1 minute. But instead, every 7.8 pixel interval represents 4 minutes. Wouldn't the medium-zoomed rendering still be acceptibly fast if done at maximum resolution?
This is pretty cool... it'd be interesting to have graphs like this for my own home, and might even encourage conservation if I could see how much each thing was using. Too bad it's only of achedemic interest (I'm not about to go and install this, but it's impressive what this guy has done).
One thing I'm kinda puzzled about is the resolution of the graphs. If the hardware has a 3 second resolution, why only take averages at 1 minute fixed intervals? A shifting average (like in this experiment of mine) would make for prettier graphs and I doubt it would take much computation power (and might even reveal details that would otherwise go unnoticed).
I noticed that the graphs shown in the article don't even have a 1 minute resolution; for some reason they are limited to a 4 minute resolution. Seems silly to have such fine measurement resolution and throw it away in the graphs. :-\
I'm with you there -- I find tanned skin unattractive. But it seems most people like the look of a tan, so I've wondered if it has to do with my colorblindness. I have protanomalous vision (the response of my "red" cones is shifted towards green) so for example, green looks almost exactly like yellow to me, and red is quite dark. Do you, like me, have some form of color deficiency?
One the one hand, I like "if (!ptr)" because it's terse yet logically intuitive; "if (!ptr)" means "if the pointer does NOT point to anything". One the other hand, I like "if (ptr==NULL)" because then I can do a search for "NULL" and find all instances of pointers being tested for pointiness. As a result, I use a mixture of the two in my code. D'oh!
"if (!(x-NULL))" is not only foolproof, but much easier to understand!
I find it very interesting that RootkitRevealer finds a rootkit by virtue of its very attempt to hide. To hide from RootkitRevealer, all one would have to do is NOT hide from it!