Why not count the number of times he was right, divide that by the total number of articles? You could also multiply that by the fraction of text on the page that doesn't read like something from rense.com, and compare the resulting number to a similar calculation on other sites?
Using that view, I think I'll stick with AnandTech, who was saying Q1 and pointing out that it was late for this generation anyway.
It's more like the police putting up police tape all around your house and locking you out while they sort out what happened. I have little doubt the user will get he rest of his email back eventually.
You keep running it until one answer dominates in a statistical sense. With the amount of data they are getting, it wouldn't be hard to construct a pretty accurate probabilistic model. If you never get a satisfactory probability for the most frequent answer, you could flag it for a developer to look at.
So, a project is trying to digitize historical books, newspapers, and documents, preserving them in a form that would allow our history to be kept near-losslessly for the first time since humans started writing -- and you are trying to purposely pollute their data. Okay then...
Thanks. From now on, for any car I buy I'm going to calculate a constant times the storage space divided by the top speed. I mean, given our knowledge, how can you commit to a car without knowing its bandwidth?
How about converting from km/h to m/s in your head[1]? Even "SI" countries don't actually consistently stick to the fundamental units, and one ends up doing things like diving by 3.6. While that is better than 2.54, it still means you need to (a) label units and (b) make sure your calculations use and convert units correctly. Being off by a factor of 12 or 10 or 1000 is still wrong in every case[2], and while a human will catch 3 orders of magnitude in a hand calculation easily, a computer will diligently use whatever you give it no matter how wrong.
Also, if we wanted to make physical calculations work out, we'd also ditch degrees for radians, we'd specify right-handed rotations for SO3, and we'd all used ECEF for locations on the planet, rather than similar-but-mutually incompatible systems which call themselves lat/lon, but don't even use the same elliptic[3]. SI certainly helps, but it is not the "everything is perfect" end-goal that many seem to think.
[1] mph converts to m/s as ~1.974, so using a factor of 2 gets within 1.3%. I had to do this conversion all the time for laypeople when I was working in robotics (m/s) and they wanted to know what that meant for speeds. Multiplying by 2 during interviews was easier in interviews than 3.6, for sure.
[2] I once had to use a physical simulator coded in decimeters for numerical stability (mm were too small, and m were too large). I have never before or since seen as many unit conversion errors as with that system. Everything "seemed" SI, so users would let their guard down. My high school physics teacher was right: "List all units in calculations, no exceptions."
[3] Interestingly, the US has done the most in trying to get a common ellipsoid used. Admittedly this is primary due to the an overactive US military wanting to operate seamlessly around the globe, but common standards are still important.
There have been 400M downloads of Silverlight so far.
That's more than the total market share of Firefox + Safari + Chrome (+ Linux + Mac + iPhone + Android if you're thinking platforms). So Silverlight's already a bigger audience than every browser NOT IE running on Windows.
First, downloads != daily usage. Second, {browser,phone,operating system} != plugin. If you want to use such a wide definition of platform, we might as well include Facebook, since it has an app platform. Facebook has 100M users active daily; Compared to 400M users ever for Silverlight. It seems that Facebook is very likely to be a bigger "platform" than Silverlight.
As for flash, youtube has 100M videos watched per day, and 300M accounts. All of those presumably would have flash, yet that would only be a percentage of the total. It's safe to say flash is in more common usage than Silverlight -- Many people (such as myself) downloaded it for the Olympics and haven't used it since.
In the USA, the highest profile Silverlight projects have probably been Netflix and the Olympics (Beijing and soon Vancouver), with the Masters and NCAA March Madness as recent big ones.
IOW, Silverlight's success up to now stems from exclusive content deals Microsoft has managed to strike with content providers, by way of generous contracts. If Chrome were the only way to see the 2012 Olympics, I would expect a lot of downloads of Chrome, and likely a lawsuit from Microsoft. It's funny how the shoe feels on the other foot.
MS natural keyboards are excellent IMO, since they are a great balance of ergonomics versus price and a familiar enough layout. I wish they had put as much thought into their software. The only two things I have bought from MS (for my own use) in the past ten years are two keyboards; They've worked quite nicely with my various Linux machines.
Mini-box has an assortment of very small DC-DC ATX power supplies. Look for ones with "wide input" that can handle a range of voltages. I have used an older, slightly larger module on some battery powered robots to run a mini-ITX computer, and I've been quite happy with it.
Your proposal sounds no different from the Dataflow architecture that people have worked on for decades. While they are appealing for their elegance, the Wikipedia article sums up the problems succinctly:
The research, however, never overcame the problems related to:
efficiently broadcasting data tokens in a massively parallel system
efficiently dispatching instruction tokens in a massively parallel system
building content addressable memories large enough to hold all of the dependencies of a real program
Although you reference "data flow" in some of the the comments on your blog, you don't seem to be referring to "dataflow architectures" since they very much have "signal flow" as you call it, in addition to data. GPUs are not really dataflow at all, and are more correctly described as variants of streaming or vector processors.
By all means, continue with your work if you think it is promising, but you should reference prior work, and show how you can overcome the limitations that the prior work got hung up on. In dataflow, it wasn't the theoretical design that caused problems, but instead practical implementation of the chips. There are enough free resources out there for doing simulated chip design that you could design a simple prototype. Until then, don't be surprised if people are skeptical.
Humans don't scale, so you need automation to make anything like a general search engine. However, you have to verify the algorithms are doing the right thing, even though external factors are evolving. Human evaluators allow more stable experiments to be run that tell you how you are doing, and in turn help you improve your algorithms.
This really isn't that new, other than realizing clever ways to apply traditional manufacturing quality control to natural language / information retrieval algorithm development. At a factory I interned at long ago, they would have machines that tested the quality of the parts -- it would be far to expensive to have a human test each part. Occasionally they would yank a part out and have some technicians test it in a full lab -- thus telling you how your testing machines are doing and help indicate if the process needs refinement.
Now that I work in the tech industry, it's nice to see some of those good ideas getting adapted and applied where they can help.
Um, I did try using it widely in my inner loops[1], and as I stated above: I have never found "restrict" to help at all. Type aliasing was made out to be this huge issue when people talked about languages and compilers, but when C99 and GCC fixed that, it turned out not to be much of a practical issue at all[2].
So, AFAICT, C/C++ programmers should not bother with restrict except as performance experiments on very critical code, where it is worth trying lots of techniques in case they help. I'm glad we seem to agree on that:)
[1] There is no point to optimizing outside of core loops in most programs. The programmer should spend their optimization work where it matters most. [2] YMMV, as I'm just stating my experience. I also mentioned this in GP.
C must generate suboptimal code in certain cases because it cannot protect against edge cases like pointer aliasing.
Aliasing is no longer a good example. There has been a "restrict" keyword since C99 came out, and it is supported in any modern compiler. There is also the type based optimization "strict-aliasing" which is enabled at O2 and above. Well written programs rarely use aliasing outside of esoteric helper functions, so the two compiler features solve the vast majority of cases.
In my own programs, which manipulate arrays of similarly typed items in inner loops, "strict-aliasing" helps a bit, but I have never found "restrict" to help at all. While adding "restrict"s changed the generated assembly, performance effects were well within the noise of caching effects that one could evoke from just updating the program or changing link order.
YMMV, but I avoid aliasing just because it makes programs easier to understand, and if a profile ever tells me I really need to look at a function, I can experiment with various flags that might help the optimizer to take advantage of that. Worrying about aliasing optimizations any more than that (such as porting to a new language) is not likely to be worthwhile IMO.
So, let's assume that individual readings are the true value plus some zero-mean error (it's supposed to be calibrated, after all). Using the exponential average that was in the actual device's code, your error will never be better than 1/2 of an individual reading (the last one). To beat this with a array to implement a sliding-window average, you'd need only 5 entries to get a more accurate reading than their approach (error is proportional to sqrt(N) for an arithmetic mean). That's 10 bytes. How cheap of a processor do you expect them to be using, such that 10 bytes is unacceptable? With 16 bytes, you get twice the accuracy, as well as the ability to take the average by a bit shift (likely not worth bothering with since you would convert it to base-10 for display anyway).
Assuming the microcontroller has a 10-bit A/D converter to get the reading, I'm pretty sure such a chip could add 32 numbers together. With the speed of 8-bit microcontrollers these days exceeding 1MHz even at ~$1 price points, emulating 16 bit numbers to get your sum is not a problem. Take a power-of-two number of readings and your average can be a simple bit shift. It will take more horsepower to convert to base-10 on the display than to take the average.
This is not a cheap child's toy or a toaster, it's a law-enforcment grade breathalyzer going for above $100; there is no excuse for being so lazy. Code that runs on small systems should be *clean* because bugs are harder to find without easy I/O, and the efficiency of it needs to be obvious. Also, code that can put someone in jail should not be spaghetti, regardless of the scale of the system running it.
Slashdot Mirror
Why not count the number of times he was right, divide that by the total number of articles? You could also multiply that by the fraction of text on the page that doesn't read like something from rense.com, and compare the resulting number to a similar calculation on other sites?
Using that view, I think I'll stick with AnandTech, who was saying Q1 and pointing out that it was late for this generation anyway.
A judge can order your house searched and all computers seized. There is no safety from the law/courts, except taking the issue up in court with them.
Deactivated != Deleted
It's more like the police putting up police tape all around your house and locking you out while they sort out what happened. I have little doubt the user will get he rest of his email back eventually.
You keep running it until one answer dominates in a statistical sense. With the amount of data they are getting, it wouldn't be hard to construct a pretty accurate probabilistic model. If you never get a satisfactory probability for the most frequent answer, you could flag it for a developer to look at.
So, a project is trying to digitize historical books, newspapers, and documents, preserving them in a form that would allow our history to be kept near-losslessly for the first time since humans started writing -- and you are trying to purposely pollute their data. Okay then...
"If the website got a hit, you must acquit."
Yes.
Thanks. From now on, for any car I buy I'm going to calculate a constant times the storage space divided by the top speed. I mean, given our knowledge, how can you commit to a car without knowing its bandwidth?
How about converting from km/h to m/s in your head[1]? Even "SI" countries don't actually consistently stick to the fundamental units, and one ends up doing things like diving by 3.6. While that is better than 2.54, it still means you need to (a) label units and (b) make sure your calculations use and convert units correctly. Being off by a factor of 12 or 10 or 1000 is still wrong in every case[2], and while a human will catch 3 orders of magnitude in a hand calculation easily, a computer will diligently use whatever you give it no matter how wrong.
Also, if we wanted to make physical calculations work out, we'd also ditch degrees for radians, we'd specify right-handed rotations for SO3, and we'd all used ECEF for locations on the planet, rather than similar-but-mutually incompatible systems which call themselves lat/lon, but don't even use the same elliptic[3]. SI certainly helps, but it is not the "everything is perfect" end-goal that many seem to think.
[1] mph converts to m/s as ~1.974, so using a factor of 2 gets within 1.3%. I had to do this conversion all the time for laypeople when I was working in robotics (m/s) and they wanted to know what that meant for speeds. Multiplying by 2 during interviews was easier in interviews than 3.6, for sure.
[2] I once had to use a physical simulator coded in decimeters for numerical stability (mm were too small, and m were too large). I have never before or since seen as many unit conversion errors as with that system. Everything "seemed" SI, so users would let their guard down. My high school physics teacher was right: "List all units in calculations, no exceptions."
[3] Interestingly, the US has done the most in trying to get a common ellipsoid used. Admittedly this is primary due to the an overactive US military wanting to operate seamlessly around the globe, but common standards are still important.
There have been 400M downloads of Silverlight so far.
That's more than the total market share of Firefox + Safari + Chrome (+ Linux + Mac + iPhone + Android if you're thinking platforms). So Silverlight's already a bigger audience than every browser NOT IE running on Windows.
First, downloads != daily usage. Second, {browser,phone,operating system} != plugin. If you want to use such a wide definition of platform, we might as well include Facebook, since it has an app platform. Facebook has 100M users active daily; Compared to 400M users ever for Silverlight. It seems that Facebook is very likely to be a bigger "platform" than Silverlight.
As for flash, youtube has 100M videos watched per day, and 300M accounts. All of those presumably would have flash, yet that would only be a percentage of the total. It's safe to say flash is in more common usage than Silverlight -- Many people (such as myself) downloaded it for the Olympics and haven't used it since.
In the USA, the highest profile Silverlight projects have probably been Netflix and the Olympics (Beijing and soon Vancouver), with the Masters and NCAA March Madness as recent big ones.
IOW, Silverlight's success up to now stems from exclusive content deals Microsoft has managed to strike with content providers, by way of generous contracts. If Chrome were the only way to see the 2012 Olympics, I would expect a lot of downloads of Chrome, and likely a lawsuit from Microsoft. It's funny how the shoe feels on the other foot.
I do feel uneasy deep down inside when I think "Google", but when I think, "Bing", I feel a burning horror very close to the surface.
Sheesh, you may want to reconsider your search terms when doing video/image searches.
MS natural keyboards are excellent IMO, since they are a great balance of ergonomics versus price and a familiar enough layout. I wish they had put as much thought into their software. The only two things I have bought from MS (for my own use) in the past ten years are two keyboards; They've worked quite nicely with my various Linux machines.
The BBC is reporting that nine people were arrested. Six men and three women. And not ten like many other articles are reporting.
That's because Keyser Soze got away.
Mini-box has an assortment of very small DC-DC ATX power supplies. Look for ones with "wide input" that can handle a range of voltages. I have used an older, slightly larger module on some battery powered robots to run a mini-ITX computer, and I've been quite happy with it.
Your proposal sounds no different from the Dataflow architecture that people have worked on for decades. While they are appealing for their elegance, the Wikipedia article sums up the problems succinctly:
The research, however, never overcame the problems related to:
Although you reference "data flow" in some of the the comments on your blog, you don't seem to be referring to "dataflow architectures" since they very much have "signal flow" as you call it, in addition to data. GPUs are not really dataflow at all, and are more correctly described as variants of streaming or vector processors.
By all means, continue with your work if you think it is promising, but you should reference prior work, and show how you can overcome the limitations that the prior work got hung up on. In dataflow, it wasn't the theoretical design that caused problems, but instead practical implementation of the chips. There are enough free resources out there for doing simulated chip design that you could design a simple prototype. Until then, don't be surprised if people are skeptical.
Humans don't scale, so you need automation to make anything like a general search engine. However, you have to verify the algorithms are doing the right thing, even though external factors are evolving. Human evaluators allow more stable experiments to be run that tell you how you are doing, and in turn help you improve your algorithms.
This really isn't that new, other than realizing clever ways to apply traditional manufacturing quality control to natural language / information retrieval algorithm development. At a factory I interned at long ago, they would have machines that tested the quality of the parts -- it would be far to expensive to have a human test each part. Occasionally they would yank a part out and have some technicians test it in a full lab -- thus telling you how your testing machines are doing and help indicate if the process needs refinement.
Now that I work in the tech industry, it's nice to see some of those good ideas getting adapted and applied where they can help.
There appears to be four offices in India.
Um, I did try using it widely in my inner loops[1], and as I stated above: I have never found "restrict" to help at all. Type aliasing was made out to be this huge issue when people talked about languages and compilers, but when C99 and GCC fixed that, it turned out not to be much of a practical issue at all[2].
So, AFAICT, C/C++ programmers should not bother with restrict except as performance experiments on very critical code, where it is worth trying lots of techniques in case they help. I'm glad we seem to agree on that :)
[1] There is no point to optimizing outside of core loops in most programs. The programmer should spend their optimization work where it matters most.
[2] YMMV, as I'm just stating my experience. I also mentioned this in GP.
They should have called it B|ng.
C must generate suboptimal code in certain cases because it cannot protect against edge cases like pointer aliasing.
Aliasing is no longer a good example. There has been a "restrict" keyword since C99 came out, and it is supported in any modern compiler. There is also the type based optimization "strict-aliasing" which is enabled at O2 and above. Well written programs rarely use aliasing outside of esoteric helper functions, so the two compiler features solve the vast majority of cases.
In my own programs, which manipulate arrays of similarly typed items in inner loops, "strict-aliasing" helps a bit, but I have never found "restrict" to help at all. While adding "restrict"s changed the generated assembly, performance effects were well within the noise of caching effects that one could evoke from just updating the program or changing link order.
YMMV, but I avoid aliasing just because it makes programs easier to understand, and if a profile ever tells me I really need to look at a function, I can experiment with various flags that might help the optimizer to take advantage of that. Worrying about aliasing optimizations any more than that (such as porting to a new language) is not likely to be worthwhile IMO.
True, but I'd rather search Wikipedia on Google using site:wikipedia.org. Most built-in site searches suck, and that certainly includes Wikipedia's.
So, let's assume that individual readings are the true value plus some zero-mean error (it's supposed to be calibrated, after all). Using the exponential average that was in the actual device's code, your error will never be better than 1/2 of an individual reading (the last one). To beat this with a array to implement a sliding-window average, you'd need only 5 entries to get a more accurate reading than their approach (error is proportional to sqrt(N) for an arithmetic mean). That's 10 bytes. How cheap of a processor do you expect them to be using, such that 10 bytes is unacceptable? With 16 bytes, you get twice the accuracy, as well as the ability to take the average by a bit shift (likely not worth bothering with since you would convert it to base-10 for display anyway).
Assuming the microcontroller has a 10-bit A/D converter to get the reading, I'm pretty sure such a chip could add 32 numbers together. With the speed of 8-bit microcontrollers these days exceeding 1MHz even at ~$1 price points, emulating 16 bit numbers to get your sum is not a problem. Take a power-of-two number of readings and your average can be a simple bit shift. It will take more horsepower to convert to base-10 on the display than to take the average.
This is not a cheap child's toy or a toaster, it's a law-enforcment grade breathalyzer going for above $100; there is no excuse for being so lazy. Code that runs on small systems should be *clean* because bugs are harder to find without easy I/O, and the efficiency of it needs to be obvious. Also, code that can put someone in jail should not be spaghetti, regardless of the scale of the system running it.
Get real.
The slow grain pierces the shield wall.