There are a lot of problems where it is much easier to verify an answer than it is to figure out what the answer should be. For instance if I ask you to factor 221, you may have some trouble. If I tell you that 13 is a factor of 221, it is easy for you to test that.
Well the basic idea of quantum computing applied to factoring would be to set up an experiment that is like trying to divide 221 by every possible number at once. But the trick is that instead of coming back with "yes/no" you would try to cause the no answers to cancel themselves out, so that what an experimenter would see would almost certainly be something that came back with a yes.
LISP is but one of a great number of languages that used byte-code compilation many years before Perl. (Trivia: The interpreter for LISP was accidentally written in LISP before LISP existed!*)
But I don't know of any widely known languages before Perl which were predominantly thought of as interpreted languages and were compiled. The overhead of compiling was just thought to be too large for an interactive program...
Cheers, Ben
* Piece of trivia I saw in the Dragon Book. The story is that LISP was used as an informal way to write down a program that you would then convert by hand into assembler. Well someone decided to demonstrate that LISP made a nice general purpose machine and wrote an "eval" function in LISP. Someone else saw that, realized that eval was *also* a LISP interpreter and converted it by hand into the first working LISP interpreter. I remember that this was in 1959, but I forget the names...
Perl compiles the instructions down to byte-code, and then runs an interpreter on the byte-code. Trust me, you really don't want it to interpret one line at a time. You really, really don't want that.
Also note that while Perl was the first well-known interpreted language to do this, it is an idea that is now considered the norm.
But to apply HP's ideas to Perl would be quite possible and probably beneficial. Today Perl has a lot of run-time lookups. For instance if I write a function foo, and I call it from a function bar, then (I believe) every time you run my function bar there is a run-time lookup while running bar to find foo because you might have changed it.
But foo almost never changes from call to call! Imagine instead the following. Each time you run bar, first check a flag for whether you have profiled it. If you have not then increment a counter for how many times it is accessed. If that counter is below some level, just execute. If it is above some target, then profile it and record information from which you can check whether it needs to be profiled. After profiling then execute the profiled version.
If your original check found that you profiled it, then quickly check that the profiled version has not been invalidated, and if all is fine then run the profiled version. If it has been invalidated then flip the profiled version, set the counter at 0, and run the safe version.
So...what does this complicated logic do? Why for a minor run-time penalty you manage to remove most of the repeated dynamic run-time lookups for which function to call, probably with significant speedups! (It could be an even bigger win if you did a similar trick on method-call lookups.)
The basic technique of taking out time to store a fast static lookup on data that is otherwise recalculated is called memoizing, and is good to know. (In Perl memoizing is almost always done by having a lexical hash (ie one defined with my) around the function with memoizing being done by sticking the answer in the hash. So the program becomes check the memoized hash and return that answer if you can. Otherwise calculate the answer, stick it in the hash, and return the answer.)
Covert communication channels are a security risk in a system that has restricted data which it is trying to limit access to. For instance this would be an issue if you have a multi-user system which contains classified information. This is the kind of thing that is covered in a B2 security clearance.
Covert channels are not a security risk if your question is keeping the wrong person from getting in control of your computer.
It is called "salting". A lot of people do it. They don't talk about it though because they don't want to tell clients that there are deliberate distortions in their numbers.
In the last couple of hundred years there has been a trend. Machines become capable of doing a new job. People are put out of work. Other jobs need to be done and people can be trained for them. People move into the new areas. Everyone is happy.
When true artificial intelligence comes about (sufficient computational power to simulate a human brain is due somewhere between 2020 and 2030) we have a different scenario. Machines become capable of putting a lot of people out of work. For anything those people can be trained to do, it is cheaper to use AI. People are put out of work and stay out of work.
You see we don't have a problem with quantity of wealth. We have enough food, people don't need to starve. We have problems with the *distribution* of wealth. Free markets solve that by saying that you get wealth based on your being able to do something for someone else. For most people it is your employer.
Once we have AI who would be stupid enough to hire a human?
What do we do with all of the unemployed humans who nobody wants to hire?
When the cost of AI is less than the cost of keeping a person alive, what then?
I know of NOTHING in the history of economics to make me optimistic about what comes next. What I know about computers and technology makes me believe that it will happen in my lifetime.
The first thought that I had when I heard that it was going to be a peer-to-peer network was that there was going to be a *lot* of polling going on transferring information about what was available, and checking what was still up.
Scalability, needless to say, was something that I was curious how they planned to address...:-)
I have heard that the Samba folks have found buffer overflows in every major TCP/IP stack but make a policy of trying to notify the vendors rather than publicizing them. (OK, you fix the Linux bugs.:-)
Given this, how do you respond to the argument that vendors only fix their problems when threatened with disclosure, and therefore when you find problems you should not merely notify, but also threaten to disclose the problem if it is not fixed?
At the LinuxWorld Expo in NYC at the start of Feb he said that from a technical perspective virtually everything about fragmentation is good. Unix gave it a bad name. But the problem lies in being different just to be different. However it is important to be able to create a version customized to your needs, one size does not fit all, yadda, yadda, yadda. Just so long as your changes are recirculated and you don't introduce gratuitous incompatibilities, fragmentation is simply not an issue!
In 3 lawsuits the existence of the Pohlig-Hellman algorithm was missed. To be sure, there is a good case against their patent. But the fact remains that the connection was not necessarily obvious.
In fact comments by the authors of the Pohlig-Hellman algorithm suggest that it was not. Go here and scroll down to "Martin Hellman". They were actively looking for a good public-key algorithm. They did not find it. They were experts who knew the field, clearly knew their own algorithm, were looking for something like RSA, but did not succeed in finding it. That alone qualifies as extremely good evidence that the idea was non-obvious at the time, no matter how obvious it appears in retrospect.
Simplicity of an idea has nothing to do with how patentable it is!
As for the fact that it is math, check the qualification I gave. If you consider anything in math or computers (by which I meant software) patentable, then RSA clearly should qualify. Whether or not an algorithm should be patentable is another - far more questionable - issue.
Cheers, Ben
PS There was one thing that I was wrong on. The first public key algorithm predated RSA. However RSA is the first publically available public key algorithm that still stands. Here are some details. But the spooks apparently had it well before that.
Which is basically a stripped down 4400. Here is a link to a detailed description.
However I would hardly call this a general purpose CPU. It is a stripped down relative of SGI's 4400. If you recall SGI was known for being a graphics powerhouse, and most of the changes they made to the chip were to make it inexpensive, and even more specialized for graphics. True, they didn't put the same level of energy that went into later generations of gaming consoles. But it had a lot of design decisions that would not make sense for a general purpose CPU!
Compare that to the early Pentiums selling at around the same time-frame which were a true general purpose CPU for a home machine, and the differences leap out at you. The Nintendo 64 ran circles around several generations of home PCs in its intended use. Had it been used for running software closer to Windows 95, it would have been limping pitifully instead...
How many bytes do you need to allocate for any of the above?
On 32-bit machines an int is a long will hold a pointer, and all take 4 bytes. On 64-bit machines that doesn't work any more. If code gets it wrong, then porting becomes a nasty process. (Usual solution. Offer a slow 32-bit compatibility mode...)
As for the wider data path, it usually helps a lot for graphics. What you use the data path for is to process multiple pixels at once. Sure, you need mutually exclusive access to lots of things between processes. But the majority of the work can be done several pixels at the time. Graphics is extremely parallelizable (which is why some of the graphics benchmarks have Linux machines at the top).
But in general, you are right that 64-bits is not always better than 32. It is better if you need to deal with numbers over 2-4 GB. Which is why with larger amounts of RAM it makes sense for computers to switch. It also makes sense for parallel calculations. But for general purpose computing it can mean that programs need to toss around larger chunks of data to do the same thing, so it can be slower. (Which is why general purpose computers are only now making the switch now that available memory and file-sizes are running into problems with 32-bit machines.)
Where I work company policy for desktops is to buy Dells (because they do a good job of tracking every part in every computer) and then modifying it by installing a Kingston drive bay. Does someone have a problem with their computer that will require trouble-shooting? Swap in a new drive, reboot, and debug the problem at leisure. Do you need to back up the computer? Pop the drive in a special machine with 2 bays, and ghost it in 15 minutes. (Drive to drive copying is a lot faster than anything you can do with a network.) Do you need to get back to an old configuration? Pop the drive in the same machine, run ghost, and wait 15 minutes. Keeping spare drives around is a lot cheaper than spare computers! (Easier to lug as well.)
If you want to maintain a standardized software set-up, Kingston drives are your friend!
Crusoe is intended for mobile applications. Like cell-phones, PDAs, and the like. But if you expect to plug it into the wall, then the Crusoe's power savings are unlikely to be a huge win.
In their market Transmeta is actually doing quite well. And long term Transmeta probably hopes to move into the mainstream market as well. After all one of the basic problems that chips face for getting faster is keeping from melting down. Low power implies low heat which implies a design that can scale.
Another win for Transmeta's design is that they can take advantage of future architectures much more easily than can a traditional chip design. The value of this freedom is immense, but again only in the long haul does it really pay back.
The Unix world is moving to 64-bits. Some vendors have moved. Some are moving there. Eventually that will filter down to PCs. In the meantime trying to port 32-bit applications to 64-bit systems is painful.
But for parallel calculations wider is better. Do you know what the 64 in Nintendo 64 stands for? Yup, the CPU is 64-bit! The Playstation 2 has a 128 bit emotion engine. Sega's Dreamcast is also at 128 bits. Nintendo is rumored to have a 256 bit CPU on their upcoming Dolphin.
Now any PC gaming fanatics know that a good video card really improves gaming. Do you know why? The reason is that the video card is a special-purpose CPU (typically 128 bits) that absolutely creams your general-purpose CPU on graphics calculations.
Therefore you have a choice. Compatible with existing 32-bit programs. Great as a dedicated gaming platform. And never the twain shall meet.
Perhaps 2 decades of available thought about encryption has warped your perspective, but the RSA algorithm was most certainly novel, not obvious, and represented a fundamental advance in thinking about encryption. In some sense it represents the start of thinking about encryption algorithms outside of secret organizations. It likely was the first secure public key algorithm, and the implications of that detail on the possibilities of encryption are hard to overstate.
So yes, if anything in math or computers should be patentable (a debatable question to be sure) the RSA algorithm should be.
Of course by the end of the lifetime of the patent, the ridiculousness of long patents in software is painfully obvious...:-(
With the probability reasoning it is trivial that there are (100% probability) only a finite number of exceptions. The odds of there being any after you have verified the first 100,000 cases is pretty small. But it gives you no idea how to prove it.
Likewise the probability result strongly suggests that the Riemann conjecture is true. But again, it gives no insight into the real problem.
However when you compute statistics, perfect match with the probability prediction.:-/
You are holding waaay too much in memory. If you have 7000 primes, and you consider all pair of them, that is 49,000,000 numbers. If you were slightly smart about it you could cut that in half.
As you noticed, this is pretty inefficient.
A much better way to slice this problem is to look at the numbers as an array of bits. For instance the first 800,000 numbers is a 100 K string. Start off with a block of 0's. Generate a vector of primes. Shift the vector by 2. OR it with your first vector. Shift by 1 more. OR it with your first vector. Shift it by 2 more. OR it again. Shift it by 2 again, then 4, then 2... (We are walking through cumulative shifts equivalent to the number of primes.)
You can make it faster still by having your bitmap being only the even numbers. You will have to do a bit of thinking. But you should find that this approach is significantly faster and cuts down tremendously on the memory. You will also find that after a few shifts you will have covered most of the territory. At some point it becomes more efficient to track down each one you have not tracked down and search for primes that add up to that one...
Cheers, Ben
Curious fact that I have noticed
on
Laptop Exams?
·
· Score: 3
I have consistently found that the people who I considered to have learned the best are almost all people who are willing to sit down with large bodies of information and master them.
Sure, "Learning to Learn" sounds great. But realistically the way you learn to learn is to develop enough knowledge that anything you go to learn fits in a context. The specific facts usually don't matter so much as the context - if one person hears 1812 and thinks to the US invasion of Canada, and another thinks of Napoleon, both will have a context and will have a far easier time fitting the fact into their brains than someone with no grasp of history. (The one who thinks Napoleon will have an easier time with remembering what the 1812 overture is about though!)
I will leave the specifics of your calculus class for another time. Suffice it to say that if you do not conceptually understand how the math works, you won't be able to comprehend a lot of things down the road. But hey, you can still get a job for big bucks in Silicon Valley or on Wall St, so why does it matter?:-(
Movie theaters used to use the same 4:3 ratio that TVs do. Then when TVs became popular the movie industry moved to a wider screen because it had more of an impact on audiences. Now TVs are moving to the wider screen also. What will movies do next I wonder?
You are right about what it is that I like doing. I like paging between different applications, and when I am in one (eg xterm) I would like it to be 80 columns wide and loooong since that describes what most code looks like.
I don't really want 2 monitors though - not enough desktop space for that.
Cheers, Ben
PS I remember hearing about some famous person back in the 70's twisting a monitor into doing something like this and then refusing to get a new monitor for many years because he liked the effect and couldn't get newer ones to do it. Don't remember the details though.
Is there a way to tell X that the window is about twice as high as it really is, and about half the width, then display on my monitor in 2-column format...? The problem with real estate is that I wind up with this big blank unused area called the right.
Slashdot Mirror
There are a lot of problems where it is much easier to verify an answer than it is to figure out what the answer should be. For instance if I ask you to factor 221, you may have some trouble. If I tell you that 13 is a factor of 221, it is easy for you to test that.
Well the basic idea of quantum computing applied to factoring would be to set up an experiment that is like trying to divide 221 by every possible number at once. But the trick is that instead of coming back with "yes/no" you would try to cause the no answers to cancel themselves out, so that what an experimenter would see would almost certainly be something that came back with a yes.
Of course this is easier said than done...
Cheers,
Ben
LISP is but one of a great number of languages that used byte-code compilation many years before Perl. (Trivia: The interpreter for LISP was accidentally written in LISP before LISP existed!*)
But I don't know of any widely known languages before Perl which were predominantly thought of as interpreted languages and were compiled. The overhead of compiling was just thought to be too large for an interactive program...
Cheers,
Ben
* Piece of trivia I saw in the Dragon Book. The story is that LISP was used as an informal way to write down a program that you would then convert by hand into assembler. Well someone decided to demonstrate that LISP made a nice general purpose machine and wrote an "eval" function in LISP. Someone else saw that, realized that eval was *also* a LISP interpreter and converted it by hand into the first working LISP interpreter. I remember that this was in 1959, but I forget the names...
Perl compiles the instructions down to byte-code, and then runs an interpreter on the byte-code. Trust me, you really don't want it to interpret one line at a time. You really, really don't want that.
Also note that while Perl was the first well-known interpreted language to do this, it is an idea that is now considered the norm.
But to apply HP's ideas to Perl would be quite possible and probably beneficial. Today Perl has a lot of run-time lookups. For instance if I write a function foo, and I call it from a function bar, then (I believe) every time you run my function bar there is a run-time lookup while running bar to find foo because you might have changed it.
But foo almost never changes from call to call! Imagine instead the following. Each time you run bar, first check a flag for whether you have profiled it. If you have not then increment a counter for how many times it is accessed. If that counter is below some level, just execute. If it is above some target, then profile it and record information from which you can check whether it needs to be profiled. After profiling then execute the profiled version.
If your original check found that you profiled it, then quickly check that the profiled version has not been invalidated, and if all is fine then run the profiled version. If it has been invalidated then flip the profiled version, set the counter at 0, and run the safe version.
So...what does this complicated logic do? Why for a minor run-time penalty you manage to remove most of the repeated dynamic run-time lookups for which function to call, probably with significant speedups! (It could be an even bigger win if you did a similar trick on method-call lookups.)
The basic technique of taking out time to store a fast static lookup on data that is otherwise recalculated is called memoizing, and is good to know. (In Perl memoizing is almost always done by having a lexical hash (ie one defined with my) around the function with memoizing being done by sticking the answer in the hash. So the program becomes check the memoized hash and return that answer if you can. Otherwise calculate the answer, stick it in the hash, and return the answer.)
Cheers,
Ben
Covert communication channels are a security risk in a system that has restricted data which it is trying to limit access to. For instance this would be an issue if you have a multi-user system which contains classified information. This is the kind of thing that is covered in a B2 security clearance.
Covert channels are not a security risk if your question is keeping the wrong person from getting in control of your computer.
Cheers,
Ben
It is called "salting". A lot of people do it. They don't talk about it though because they don't want to tell clients that there are deliberate distortions in their numbers.
Cheers,
Ben
In the last couple of hundred years there has been a trend. Machines become capable of doing a new job. People are put out of work. Other jobs need to be done and people can be trained for them. People move into the new areas. Everyone is happy.
When true artificial intelligence comes about (sufficient computational power to simulate a human brain is due somewhere between 2020 and 2030) we have a different scenario. Machines become capable of putting a lot of people out of work. For anything those people can be trained to do, it is cheaper to use AI. People are put out of work and stay out of work.
You see we don't have a problem with quantity of wealth. We have enough food, people don't need to starve. We have problems with the *distribution* of wealth. Free markets solve that by saying that you get wealth based on your being able to do something for someone else. For most people it is your employer.
Once we have AI who would be stupid enough to hire a human?
What do we do with all of the unemployed humans who nobody wants to hire?
When the cost of AI is less than the cost of keeping a person alive, what then?
I know of NOTHING in the history of economics to make me optimistic about what comes next. What I know about computers and technology makes me believe that it will happen in my lifetime.
Regards,
Ben
The first thought that I had when I heard that it was going to be a peer-to-peer network was that there was going to be a *lot* of polling going on transferring information about what was available, and checking what was still up.
:-)
Scalability, needless to say, was something that I was curious how they planned to address...
Cheers,
Ben
I have heard that the Samba folks have found buffer overflows in every major TCP/IP stack but make a policy of trying to notify the vendors rather than publicizing them. (OK, you fix the Linux bugs. :-)
Given this, how do you respond to the argument that vendors only fix their problems when threatened with disclosure, and therefore when you find problems you should not merely notify, but also threaten to disclose the problem if it is not fixed?
Thanks,
Ben
At the LinuxWorld Expo in NYC at the start of Feb he said that from a technical perspective virtually everything about fragmentation is good. Unix gave it a bad name. But the problem lies in being different just to be different. However it is important to be able to create a version customized to your needs, one size does not fit all, yadda, yadda, yadda. Just so long as your changes are recirculated and you don't introduce gratuitous incompatibilities, fragmentation is simply not an issue!
:-)
It was...a unique answer.
Cheers,
Ben
The upcoming 2.4 kernel will handle 64 GB of RAM.
But to do it right you do indeed need a 64-bit processor.
As for there being no memory limits with 64-bit processors, oh really? The people who put together data warehouses can put the lie to that one!
Cheers,
Ben
You are right.
:-)
And it isn't often you get to correct me on anything related to math. Enjoy it while it lasts.
Cheers,
Ben
In 3 lawsuits the existence of the Pohlig-Hellman algorithm was missed. To be sure, there is a good case against their patent. But the fact remains that the connection was not necessarily obvious.
In fact comments by the authors of the Pohlig-Hellman algorithm suggest that it was not. Go here and scroll down to "Martin Hellman". They were actively looking for a good public-key algorithm. They did not find it. They were experts who knew the field, clearly knew their own algorithm, were looking for something like RSA, but did not succeed in finding it. That alone qualifies as extremely good evidence that the idea was non-obvious at the time, no matter how obvious it appears in retrospect.
Simplicity of an idea has nothing to do with how patentable it is!
As for the fact that it is math, check the qualification I gave. If you consider anything in math or computers (by which I meant software) patentable, then RSA clearly should qualify. Whether or not an algorithm should be patentable is another - far more questionable - issue.
Cheers,
Ben
PS There was one thing that I was wrong on. The first public key algorithm predated RSA. However RSA is the first publically available public key algorithm that still stands. Here are some details. But the spooks apparently had it well before that.
Which is basically a stripped down 4400. Here is a link to a detailed description.
However I would hardly call this a general purpose CPU. It is a stripped down relative of SGI's 4400. If you recall SGI was known for being a graphics powerhouse, and most of the changes they made to the chip were to make it inexpensive, and even more specialized for graphics. True, they didn't put the same level of energy that went into later generations of gaming consoles. But it had a lot of design decisions that would not make sense for a general purpose CPU!
Compare that to the early Pentiums selling at around the same time-frame which were a true general purpose CPU for a home machine, and the differences leap out at you. The Nintendo 64 ran circles around several generations of home PCs in its intended use. Had it been used for running software closer to Windows 95, it would have been limping pitifully instead...
Cheers,
Ben
Quick, is an int a long?
What size is a pointer?
How many bytes do you need to allocate for any of the above?
On 32-bit machines an int is a long will hold a pointer, and all take 4 bytes. On 64-bit machines that doesn't work any more. If code gets it wrong, then porting becomes a nasty process. (Usual solution. Offer a slow 32-bit compatibility mode...)
As for the wider data path, it usually helps a lot for graphics. What you use the data path for is to process multiple pixels at once. Sure, you need mutually exclusive access to lots of things between processes. But the majority of the work can be done several pixels at the time. Graphics is extremely parallelizable (which is why some of the graphics benchmarks have Linux machines at the top).
But in general, you are right that 64-bits is not always better than 32. It is better if you need to deal with numbers over 2-4 GB. Which is why with larger amounts of RAM it makes sense for computers to switch. It also makes sense for parallel calculations. But for general purpose computing it can mean that programs need to toss around larger chunks of data to do the same thing, so it can be slower. (Which is why general purpose computers are only now making the switch now that available memory and file-sizes are running into problems with 32-bit machines.)
Cheers,
Ben
Take their removable drives for instance.
Where I work company policy for desktops is to buy Dells (because they do a good job of tracking every part in every computer) and then modifying it by installing a Kingston drive bay. Does someone have a problem with their computer that will require trouble-shooting? Swap in a new drive, reboot, and debug the problem at leisure. Do you need to back up the computer? Pop the drive in a special machine with 2 bays, and ghost it in 15 minutes. (Drive to drive copying is a lot faster than anything you can do with a network.) Do you need to get back to an old configuration? Pop the drive in the same machine, run ghost, and wait 15 minutes. Keeping spare drives around is a lot cheaper than spare computers! (Easier to lug as well.)
If you want to maintain a standardized software set-up, Kingston drives are your friend!
Cheers,
Ben
Crusoe is intended for mobile applications. Like cell-phones, PDAs, and the like. But if you expect to plug it into the wall, then the Crusoe's power savings are unlikely to be a huge win.
In their market Transmeta is actually doing quite well. And long term Transmeta probably hopes to move into the mainstream market as well. After all one of the basic problems that chips face for getting faster is keeping from melting down. Low power implies low heat which implies a design that can scale.
Another win for Transmeta's design is that they can take advantage of future architectures much more easily than can a traditional chip design. The value of this freedom is immense, but again only in the long haul does it really pay back.
Cheers,
Ben
A Pentium is a 32 bit machine.
The Unix world is moving to 64-bits. Some vendors have moved. Some are moving there. Eventually that will filter down to PCs. In the meantime trying to port 32-bit applications to 64-bit systems is painful.
But for parallel calculations wider is better. Do you know what the 64 in Nintendo 64 stands for? Yup, the CPU is 64-bit! The Playstation 2 has a 128 bit emotion engine. Sega's Dreamcast is also at 128 bits. Nintendo is rumored to have a 256 bit CPU on their upcoming Dolphin.
Now any PC gaming fanatics know that a good video card really improves gaming. Do you know why? The reason is that the video card is a special-purpose CPU (typically 128 bits) that absolutely creams your general-purpose CPU on graphics calculations.
Therefore you have a choice. Compatible with existing 32-bit programs. Great as a dedicated gaming platform. And never the twain shall meet.
Cheers,
Ben
Perhaps 2 decades of available thought about encryption has warped your perspective, but the RSA algorithm was most certainly novel, not obvious, and represented a fundamental advance in thinking about encryption. In some sense it represents the start of thinking about encryption algorithms outside of secret organizations. It likely was the first secure public key algorithm, and the implications of that detail on the possibilities of encryption are hard to overstate.
:-(
So yes, if anything in math or computers should be patentable (a debatable question to be sure) the RSA algorithm should be.
Of course by the end of the lifetime of the patent, the ridiculousness of long patents in software is painfully obvious...
Cheers,
Ben
With the probability reasoning it is trivial that there are (100% probability) only a finite number of exceptions. The odds of there being any after you have verified the first 100,000 cases is pretty small. But it gives you no idea how to prove it.
:-/
Likewise the probability result strongly suggests that the Riemann conjecture is true. But again, it gives no insight into the real problem.
However when you compute statistics, perfect match with the probability prediction.
Cheers,
Ben
You are holding waaay too much in memory. If you have 7000 primes, and you consider all pair of them, that is 49,000,000 numbers. If you were slightly smart about it you could cut that in half.
As you noticed, this is pretty inefficient.
A much better way to slice this problem is to look at the numbers as an array of bits. For instance the first 800,000 numbers is a 100 K string. Start off with a block of 0's. Generate a vector of primes. Shift the vector by 2. OR it with your first vector. Shift by 1 more. OR it with your first vector. Shift it by 2 more. OR it again. Shift it by 2 again, then 4, then 2... (We are walking through cumulative shifts equivalent to the number of primes.)
You can make it faster still by having your bitmap being only the even numbers. You will have to do a bit of thinking. But you should find that this approach is significantly faster and cuts down tremendously on the memory. You will also find that after a few shifts you will have covered most of the territory. At some point it becomes more efficient to track down each one you have not tracked down and search for primes that add up to that one...
Cheers,
Ben
I have consistently found that the people who I considered to have learned the best are almost all people who are willing to sit down with large bodies of information and master them.
:-(
Sure, "Learning to Learn" sounds great. But realistically the way you learn to learn is to develop enough knowledge that anything you go to learn fits in a context. The specific facts usually don't matter so much as the context - if one person hears 1812 and thinks to the US invasion of Canada, and another thinks of Napoleon, both will have a context and will have a far easier time fitting the fact into their brains than someone with no grasp of history. (The one who thinks Napoleon will have an easier time with remembering what the 1812 overture is about though!)
I will leave the specifics of your calculus class for another time. Suffice it to say that if you do not conceptually understand how the math works, you won't be able to comprehend a lot of things down the road. But hey, you can still get a job for big bucks in Silicon Valley or on Wall St, so why does it matter?
Cheers,
Ben
Hint: What is the length of the diagonal from one corner to the opposite corner?
Cheers,
Ben
Movie theaters used to use the same 4:3 ratio that TVs do. Then when TVs became popular the movie industry moved to a wider screen because it had more of an impact on audiences. Now TVs are moving to the wider screen also. What will movies do next I wonder?
Cheers,
Ben
You are right about what it is that I like doing. I like paging between different applications, and when I am in one (eg xterm) I would like it to be 80 columns wide and loooong since that describes what most code looks like.
I don't really want 2 monitors though - not enough desktop space for that.
Cheers,
Ben
PS I remember hearing about some famous person back in the 70's twisting a monitor into doing something like this and then refusing to get a new monitor for many years because he liked the effect and couldn't get newer ones to do it. Don't remember the details though.
Is there a way to tell X that the window is about twice as high as it really is, and about half the width, then display on my monitor in 2-column format...? The problem with real estate is that I wind up with this big blank unused area called the right.
Cheers,
Ben