Once we have the formula for prime numbers, doesn't that mean that all of our encryption methods are no longer "difficult" problems?
Are there encryption methods that are not based on the difficulty of factoring large prime numbers?
What's the deal with averaging 4 or 5 factors I absolutely don't care about into one meaningless number that somehow I am supposed to take seriously? Movies aren't reviewed this way.
Aeon Flux
Plot: 76 It kind of made sense if you saw the movie Graphics: 92 Charlize Theron looks great! Sound: 83 The soundtrack was okay. Some may like it. Value: 50 It was too short. I like 80 hour epics! Reviewer Bias: 95 I'm a big fan of Peter Chung Total: 79.2%
I have no idea how this is supposed tell me if I should see the movie or not, but it's how games are rated.
Say that 10 times fast... Rat brains fly planes
on
Rat Brains Fly Planes
·
· Score: 1
Rat brains fly planes... rat brains fly planes...
Now are you still sure you want meatwarez to fly your plane?
But in the case of programming bugs, I believe the cause is the programming language. Currently, too much information is required by the programmer in order to get a program to run properly.
If a program is the sum of all information required to get it to run as intended, one part of it is the computer part--- memory, source code, data assets, other deterministic inputs. But the other part is the programmer or group of programmers who have a collective knowledge that is required to get the program to run correctly.
For example, if I write an API that has three functions A(), B(), and C(), the computer has the same information as if I write an API that has the three functions A(), Init_A(), Cleanup_A(). But the programmer has *extra* information that the computer does not know, namely that there is a relationship and interdependency between the three functions.
Furthermore, as demonstrated above, this relationship is often conveyed by ad-hoc naming conventions that are hardly standardized between two programmers at the same company, much less at different companies.
There are thousands, possibly millions of pieces of implicit information like this in the meat-memory of programmers. We tend to call this "programming experience". That is, each new program learns through trial and error or by cut and paste that functions need to look like this:
Init_A(); A(); Cleanup_A();
Rather that this: A(); Cleanup_A(); Init_A();
But due to event-driven programming, we are sometimes uncertain what order each function will be called. So, we place ASSERTS and conditionals to handle the out-of-order cases.
What this all leads to is bugs because the memory state and mixed conventions of all of the various programmers is always in some uninitialized, unknown state. If a chain is only as strong as its weakest link, then a program is only as strong as one of its programmers on its worse day--- and we tend to stress our programmers a lot with long hours and tight schedules.
The undetermined state of the collective minds of all of the programmers also explains why there is a mythical man-month. If you regard the program as not just the source and its assets, but include its programmers as well, you can easily see where your systems will fail in how arbitrarily stringently you treat your source code, but how lax you treat documentation and programming conventions.
The solution, which is easier to say than to implement, is to take as much implicit information as possible away from the programmer and put it into the program. Certainly, as memory capacity grows, we shouldn't be using the same programming languages that we had when memory capacity was 1/1000th of what it is now.
Once this information is included in the program, Init_A(), A(), Cleanup_A() don't need to be named as such. Their relationship can be visualized by the programmer through a documentation tool that shows the relationship of each function to each other function that has a relationship to it (sort of like a LinkedIn network, but for functions).
I don't know if all of the implicit information in a programmer's head can be transcribed into explicit information for the computer to use. If, during the programming process, all of this information can be described efficiently and simply, then functions themselves may attempt to initialize themselves by searching their own relationships for other functions that satisfy their parameters.
Then, we can write something like "draw_pixel(10, 12, YELLOW);" and expect it to work properly as a stand alone line because the function itself can figure out how to call all of its preconditions.
This is perhaps something serious computer scientists can answer. I don't know how much implicit knowledge can be transferred from the programmer's brain and into an explicit structured code in the computer's memory and source. Certainly some, unlikely all, but perhaps most. The more the better.
At this point, if some advanced alien society were to look at the primitive state of our information age advances, they would laugh at us, ridicule us, and perhaps consider us "cute" in the same way as when we watch monkeys poking a stick into a hollow log for grubs.
Most people can perceive at faster than 60 fps. If you are one of these people, simply set your computer monitor to refresh at 60 hz and then look at it from the corner of your eye. See it flicker? You probably do. Now change it to 72 hz. See it flicker? Probably not.
The corners of your eye have fewer color sensors and more intensity sensors, which are more sensitive. More sensitive really doesn't accurately describe it, but less persistence (sort of like how fast phosphors darken on a monitor). This allows us to catch monsters and motion out of the corners of our eyes in low light conditions. Sometimes, when you see something out of the corner of your eye and then turn to look at it and it goes away, you really DID see it out of the corner of your eye!
Now, 120 fps is really excessive, but not useless. Many effects such as bloom and anti-aliasing require applying a post-render effect. At 120 fps, you can do your post-render effects and still run 60 fps. Other effects, such as true depth of field, requires rendering the same scene from several camera angles (let's say 8) and blur the samples.
Claiming that it's 50 times faster than some other software renderer is like claiming your racecar is 50 times faster than any other racecar that has no wheels.
Perhaps the British wanted their own special cultural name for "Astronaut" like Cosmonaut or Taikonaut. The ban was to give them enough time to come up with a term as stupid as the cosmos is infinite.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." - Albert Einstein
Considering NASA's safety records (http://www.airsafe.com/events/space/astrofat.htm) , maybe they should copy someone else's software. Then again, 26 people to the Chinese is like 1/100th of an American.
The architeture of Maya (a scripting language called MEL on top of a "kernel" of sorts) makes it quite portable I would think.
I would hardly call MEL an architecture. In fact, I would hardly call MEL a programming language either.
However, Alias/Maya used to run on Irix, an SGI Unix variant (maybe still does). So, I wouldn't be surprised if the codebase was easily portable to other -ix platforms.
Dreamcast failed for exactly one reason: How they previously treated developers in the Sega Genesis days.
Both Sega and Nintendo charged outrageous fees for cartridges. When PS1 came out with the CD as a format, Sony did not gouge developers, and thus all of the ill-will that the developers had pent up against Nintendo and Sega worked in Sony's favor.
Then, they burned developers with Sega 32x, then they burned them again with Sega Saturn. Any developers and publishers who supported those formats lost a small fortune. By the time Dreamcast devkits were being handed out, Sega still treated developers with the monopolistic arrogant attitude from the Genesis days, and the developers did not sign up for a third round of losses.
If Activision offers $200M for your company, and you reject it because you consider it too low of an offer, then buying out Adrian for $11M is clearly underpaying him for his shares if he has anything more than 5% of the shares.
If he's been receiving $3M+ in dividends, chances are he owns more than 5%.
Note: Just because the rest of the owners have 59% doesn't mean that Adrian has the remaining 41%. Many of the remaining shares can be owned by the company in order to give away as employee stock options, sell to investors, or various other situations.
If you're good, it won't matter what degree you have (or don't have). If you're good, and you happen to have a CS degree, that's a bonus.
What I'm saying is that the people who I've found to be good game programmers tend to come from engineering disciplines, and not CS. It probably has to do with them working on a lower level with simple microprocessors or other bare bones programmable machinery that do not have higher level compilers (C would be considered a luxury). Thus, they have a stronger understanding of what memory is, how it works, when it's fast, when it's slow, and have an actual picture in their heads of how things are wired up to talk from one bus to another.
For whatever reason, I've found that CS majors tend to like to abstract away the actual machine underneath, which may be fine if you're writing a database program on a Unix server. But it's absolutely horrible for writing a console game. Or they may overcomplicate things with situations that would never occur... such as writing semaphore blocking code in a simple system that doesn't even support threading.
They also like to try out various CS arcana that they fell in love with in college that is incomprehensible to everyone else... and ultimately incomprehensible to themselves by the end of the project. For people from other engineering disciplines, programming is a means to a particular practical end. For some CS majors, it's a playground for them to try something they learned from college.
If you're good, then it works out. But in my experience, the extra cleverness is both unnecessary and often has undesirable side effects.
This is a single opinion, by someone with an engineering degree. By no means change the direction of your major because of my biases. Also, I would never *reject* applicants because they have a CS degree. I merely noticed that the quality of applicants is lower than those with engineering degrees. The code snippet I presented was one extreme example, but there are many failure cases that are not as amusing.
I work in the games industry as a programmer, and am generally leery of people with CS degrees.
On our programming test, we have simple question: implement char *strcpy(char *dest, char *src). Physicists, electrical engineers, mechanical engineers, and various other engineering majors seem to have no problem with this... which leads to various followup questions about optimization, memory use, pointers, etc.
One applicant with a 4-year CS degree asked us if he could use C++. "Sure... I guess," I replied.
So, after considerable time, he proceeded to write: char *strcpy(char *dest, char *src) {
char *dest;
dest = new char[strlen(src)];
strcpy(dest, src);
return; }
When I asked him if he saw any mistakes that he would like to correct (as I do with all applicants regardless of errors), he added the following line at the top and then said "done".
#include "string.h"
He didn't win the job, but he did win the award for highest density of errors in 3 lines of code.
While there will be some CGI, the Doom monsters like the Baron, the Imp and the Pinky Demon will mostly be real monsters created by the Stan Winston Studios...
I had no idea that Stan Winston had gotten into genetic engineering and Frankensteinian experimentation.
Where do you think Ben Affleck and Al Gore came from?
If at any point Google announced to the world, "Hey look, we now have the largest collection of the most talented software engineers in the world. We have control over a very important and difficult to develop function that can be at the heart of every computer system in the future. By leveraging our presence across all OS platforms and across international borders, we believe that distributed computer and information access over the internet will render OSes into a low margin commodities market like hard drives and memory chips. Our plan of attack is to..."...then Microsoft will surely take notice and turn their entire battleship towards Google and crush them as they did Netscape.
If, instead, they periodically leak many potential products for users in a beta program, each of which has revolutionary and potentially devastating implications for Microsoft, then Microsoft cannot bring to bear all of its laser-like competitive powers against those betas as they could against a concrete, real product strategy.
If, instead, Google gathers user feedback from their betas, and quietly works on improving the successes, they can release a product that has features that are difficult for even Microsoft to copy and compete on quality, and has very high user satisfaction. Then they can leverage the networking effect of positive word of mouth from users in their beta program to establish a very loyal and large satisfied user base before Microsoft even gets an inkling of what they're up to.
Google, like Netscape before it, has the *potential* to change how we use computers in the future. This is contrary to Microsoft's best interests. However, because Google is not in direct competition with Microsoft, but rather can grow around, and eventually subsume desktop functions, it is very difficult for Microsoft to directly attack Google. If, on the other hand, Google has clearly laid plans of attack, and product and profit plans clearly marked, then Microsoft can herald considerable force in a short amount of time to directly compete against whatever business model they have laid out, whether it's profitable or not.
Think of Microsoft as the Redcoats in Redmond. They have a very good regular army and have won every war they have been in. If you announce that you have an army and assemble one as such, they will assemble a larger one and destroy it. If, however, you use guerilla tactics and maintain an information network that is more aware of their position and movements than they are of yours, then you can win the war with even an inferior force.
Not that Google has an inferior force, but even with its high valuation, they would be hard pressed to win any war where dollars were being attritioned.
Like I said, the technology and gameplay (Carmack + Romero) both have to be there. Daikatana was an obvious struggle with technology.
It's easy for people to see when the technology is excellent, but the gameplay is missing. It's much harder, even for people inside the industry, to see through to solid design past shoddy engineering work.
And you can blame Warren Specter for the Deus Ex series.
Slashdot Mirror
Currently the most powerful quantum computers in the world can factor numbers as large as 15.
15 = 3 * 5
I is smarter than the computar!
Once we have the formula for prime numbers, doesn't that mean that all of our encryption methods are no longer "difficult" problems? Are there encryption methods that are not based on the difficulty of factoring large prime numbers?
What's the deal with averaging 4 or 5 factors I absolutely don't care about into one meaningless number that somehow I am supposed to take seriously? Movies aren't reviewed this way.
Aeon Flux
Plot: 76 It kind of made sense if you saw the movie
Graphics: 92 Charlize Theron looks great!
Sound: 83 The soundtrack was okay. Some may like it.
Value: 50 It was too short. I like 80 hour epics!
Reviewer Bias: 95 I'm a big fan of Peter Chung
Total: 79.2%
I have no idea how this is supposed tell me if I should see the movie or not, but it's how games are rated.
Rat brains fly planes... rat brains fly planes...
Now are you still sure you want meatwarez to fly your plane?
But in the case of programming bugs, I believe the cause is the programming language. Currently, too much information is required by the programmer in order to get a program to run properly.
If a program is the sum of all information required to get it to run as intended, one part of it is the computer part--- memory, source code, data assets, other deterministic inputs. But the other part is the programmer or group of programmers who have a collective knowledge that is required to get the program to run correctly.
For example, if I write an API that has three functions A(), B(), and C(), the computer has the same information as if I write an API that has the three functions A(), Init_A(), Cleanup_A(). But the programmer has *extra* information that the computer does not know, namely that there is a relationship and interdependency between the three functions.
Furthermore, as demonstrated above, this relationship is often conveyed by ad-hoc naming conventions that are hardly standardized between two programmers at the same company, much less at different companies.
There are thousands, possibly millions of pieces of implicit information like this in the meat-memory of programmers. We tend to call this "programming experience". That is, each new program learns through trial and error or by cut and paste that functions need to look like this:
Init_A();
A();
Cleanup_A();
Rather that this:
A();
Cleanup_A();
Init_A();
But due to event-driven programming, we are sometimes uncertain what order each function will be called. So, we place ASSERTS and conditionals to handle the out-of-order cases.
What this all leads to is bugs because the memory state and mixed conventions of all of the various programmers is always in some uninitialized, unknown state. If a chain is only as strong as its weakest link, then a program is only as strong as one of its programmers on its worse day--- and we tend to stress our programmers a lot with long hours and tight schedules.
The undetermined state of the collective minds of all of the programmers also explains why there is a mythical man-month. If you regard the program as not just the source and its assets, but include its programmers as well, you can easily see where your systems will fail in how arbitrarily stringently you treat your source code, but how lax you treat documentation and programming conventions.
The solution, which is easier to say than to implement, is to take as much implicit information as possible away from the programmer and put it into the program. Certainly, as memory capacity grows, we shouldn't be using the same programming languages that we had when memory capacity was 1/1000th of what it is now.
Once this information is included in the program, Init_A(), A(), Cleanup_A() don't need to be named as such. Their relationship can be visualized by the programmer through a documentation tool that shows the relationship of each function to each other function that has a relationship to it (sort of like a LinkedIn network, but for functions).
I don't know if all of the implicit information in a programmer's head can be transcribed into explicit information for the computer to use. If, during the programming process, all of this information can be described efficiently and simply, then functions themselves may attempt to initialize themselves by searching their own relationships for other functions that satisfy their parameters.
Then, we can write something like "draw_pixel(10, 12, YELLOW);" and expect it to work properly as a stand alone line because the function itself can figure out how to call all of its preconditions.
This is perhaps something serious computer scientists can answer. I don't know how much implicit knowledge can be transferred from the programmer's brain and into an explicit structured code in the computer's memory and source. Certainly some, unlikely all, but perhaps most. The more the better.
At this point, if some advanced alien society were to look at the primitive state of our information age advances, they would laugh at us, ridicule us, and perhaps consider us "cute" in the same way as when we watch monkeys poking a stick into a hollow log for grubs.
Well I would hope not, he's fucking 8 years old.
No, it would be his girlfriend who would be fucking 8 year-olds.
Give a year, two max. He'll be a master StarCraft player, and all that physics education will go down the drain.
I didn't think that the hydrogen electron orbit looked like that.
Most people can perceive at faster than 60 fps. If you are one of these people, simply set your computer monitor to refresh at 60 hz and then look at it from the corner of your eye. See it flicker? You probably do. Now change it to 72 hz. See it flicker? Probably not. The corners of your eye have fewer color sensors and more intensity sensors, which are more sensitive. More sensitive really doesn't accurately describe it, but less persistence (sort of like how fast phosphors darken on a monitor). This allows us to catch monsters and motion out of the corners of our eyes in low light conditions. Sometimes, when you see something out of the corner of your eye and then turn to look at it and it goes away, you really DID see it out of the corner of your eye! Now, 120 fps is really excessive, but not useless. Many effects such as bloom and anti-aliasing require applying a post-render effect. At 120 fps, you can do your post-render effects and still run 60 fps. Other effects, such as true depth of field, requires rendering the same scene from several camera angles (let's say 8) and blur the samples.
Claiming that it's 50 times faster than some other software renderer is like claiming your racecar is 50 times faster than any other racecar that has no wheels.
What's the point?
Perhaps the British wanted their own special cultural name for "Astronaut" like Cosmonaut or Taikonaut. The ban was to give them enough time to come up with a term as stupid as the cosmos is infinite.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe." - Albert Einstein
Considering NASA's safety records (http://www.airsafe.com/events/space/astrofat.htm) , maybe they should copy someone else's software. Then again, 26 people to the Chinese is like 1/100th of an American.
-Ming
The architeture of Maya (a scripting language called MEL on top of a "kernel" of sorts) makes it quite portable I would think.
I would hardly call MEL an architecture. In fact, I would hardly call MEL a programming language either.
However, Alias/Maya used to run on Irix, an SGI Unix variant (maybe still does). So, I wouldn't be surprised if the codebase was easily portable to other -ix platforms.
The Roomba wasn't useful enough for me to purchase before. Now, I might reconsider.
God knows my living room is crawling with dustbunnies and snipers.
Will there be two buttons? One for sniper sweep and one for "classic sweep"?
Dreamcast failed for exactly one reason: How they previously treated developers in the Sega Genesis days.
Both Sega and Nintendo charged outrageous fees for cartridges. When PS1 came out with the CD as a format, Sony did not gouge developers, and thus all of the ill-will that the developers had pent up against Nintendo and Sega worked in Sony's favor.
Then, they burned developers with Sega 32x, then they burned them again with Sega Saturn. Any developers and publishers who supported those formats lost a small fortune. By the time Dreamcast devkits were being handed out, Sega still treated developers with the monopolistic arrogant attitude from the Genesis days, and the developers did not sign up for a third round of losses.
If Activision offers $200M for your company, and you reject it because you consider it too low of an offer, then buying out Adrian for $11M is clearly underpaying him for his shares if he has anything more than 5% of the shares. If he's been receiving $3M+ in dividends, chances are he owns more than 5%. Note: Just because the rest of the owners have 59% doesn't mean that Adrian has the remaining 41%. Many of the remaining shares can be owned by the company in order to give away as employee stock options, sell to investors, or various other situations.
Lets face it, I know a lot of Slashdotters worship the ground he walks on...
He walks on the ground? I was worshipping the water he walks on and getting my boots so very wet.
If you're good, it won't matter what degree you have (or don't have). If you're good, and you happen to have a CS degree, that's a bonus.
What I'm saying is that the people who I've found to be good game programmers tend to come from engineering disciplines, and not CS. It probably has to do with them working on a lower level with simple microprocessors or other bare bones programmable machinery that do not have higher level compilers (C would be considered a luxury). Thus, they have a stronger understanding of what memory is, how it works, when it's fast, when it's slow, and have an actual picture in their heads of how things are wired up to talk from one bus to another.
For whatever reason, I've found that CS majors tend to like to abstract away the actual machine underneath, which may be fine if you're writing a database program on a Unix server. But it's absolutely horrible for writing a console game. Or they may overcomplicate things with situations that would never occur... such as writing semaphore blocking code in a simple system that doesn't even support threading.
They also like to try out various CS arcana that they fell in love with in college that is incomprehensible to everyone else... and ultimately incomprehensible to themselves by the end of the project. For people from other engineering disciplines, programming is a means to a particular practical end. For some CS majors, it's a playground for them to try something they learned from college.
If you're good, then it works out. But in my experience, the extra cleverness is both unnecessary and often has undesirable side effects.
This is a single opinion, by someone with an engineering degree. By no means change the direction of your major because of my biases. Also, I would never *reject* applicants because they have a CS degree. I merely noticed that the quality of applicants is lower than those with engineering degrees. The code snippet I presented was one extreme example, but there are many failure cases that are not as amusing.
Funny, because strcpy is a C-library routine. I guess you'd refuse to implement anything using strcpy, too.
The right answer is not hiring you.
I'll ask what I always ask, "Are there any mistakes that you'd like to correct?"
I work in the games industry as a programmer, and am generally leery of people with CS degrees.
On our programming test, we have simple question: implement char *strcpy(char *dest, char *src). Physicists, electrical engineers, mechanical engineers, and various other engineering majors seem to have no problem with this... which leads to various followup questions about optimization, memory use, pointers, etc.
One applicant with a 4-year CS degree asked us if he could use C++. "Sure... I guess," I replied.
So, after considerable time, he proceeded to write:
char *strcpy(char *dest, char *src)
{
char *dest;
dest = new char[strlen(src)];
strcpy(dest, src);
return;
}
When I asked him if he saw any mistakes that he would like to correct (as I do with all applicants regardless of errors), he added the following line at the top and then said "done".
#include "string.h"
He didn't win the job, but he did win the award for highest density of errors in 3 lines of code.
I had no idea that Stan Winston had gotten into genetic engineering and Frankensteinian experimentation.
Where do you think Ben Affleck and Al Gore came from?
If at any point Google announced to the world, "Hey look, we now have the largest collection of the most talented software engineers in the world. We have control over a very important and difficult to develop function that can be at the heart of every computer system in the future. By leveraging our presence across all OS platforms and across international borders, we believe that distributed computer and information access over the internet will render OSes into a low margin commodities market like hard drives and memory chips. Our plan of attack is to..." ...then Microsoft will surely take notice and turn their entire battleship towards Google and crush them as they did Netscape.
If, instead, they periodically leak many potential products for users in a beta program, each of which has revolutionary and potentially devastating implications for Microsoft, then Microsoft cannot bring to bear all of its laser-like competitive powers against those betas as they could against a concrete, real product strategy.
If, instead, Google gathers user feedback from their betas, and quietly works on improving the successes, they can release a product that has features that are difficult for even Microsoft to copy and compete on quality, and has very high user satisfaction. Then they can leverage the networking effect of positive word of mouth from users in their beta program to establish a very loyal and large satisfied user base before Microsoft even gets an inkling of what they're up to.
Google, like Netscape before it, has the *potential* to change how we use computers in the future. This is contrary to Microsoft's best interests. However, because Google is not in direct competition with Microsoft, but rather can grow around, and eventually subsume desktop functions, it is very difficult for Microsoft to directly attack Google. If, on the other hand, Google has clearly laid plans of attack, and product and profit plans clearly marked, then Microsoft can herald considerable force in a short amount of time to directly compete against whatever business model they have laid out, whether it's profitable or not.
Think of Microsoft as the Redcoats in Redmond. They have a very good regular army and have won every war they have been in. If you announce that you have an army and assemble one as such, they will assemble a larger one and destroy it. If, however, you use guerilla tactics and maintain an information network that is more aware of their position and movements than they are of yours, then you can win the war with even an inferior force.
Not that Google has an inferior force, but even with its high valuation, they would be hard pressed to win any war where dollars were being attritioned.
One Third of All Slashdot Comments are Nonsense. This isn't one of them.
Like I said, the technology and gameplay (Carmack + Romero) both have to be there. Daikatana was an obvious struggle with technology.
It's easy for people to see when the technology is excellent, but the gameplay is missing. It's much harder, even for people inside the industry, to see through to solid design past shoddy engineering work.
And you can blame Warren Specter for the Deus Ex series.