John Nash received his Nobel Prize for work he did as as a graduate student and post-doc. There were a couple of results he found that comprised his PhD thesis and another paper. He didn't actually work in the finance industry -- they took his work and applied it for their own purposes. So using him as a example of research coming out of the sector is a non sequitur.
The tech's still a bit flaky on the reading side if you have more than just a couple of pieces of information, however. JWZ did some investigating into this late last year and came away disappointed. I'm sure it will slowly improve over time, but it's nowhere near Just Works yet: See his results for more details.
It also doesn't have plausible deniability any longer. A union leader or employer or gangster who has some hold over somebody can force them to prove their vote was cast in the pre-agreed fashion: the person has to show that their session id, name, result and what they claim is their key matches up with the hash. They can't fake the key, since creating a hash collision on demand for a pre-specified hash is still a hard mathematical problem. They have to know the session id, otherwise there's no verifiability even for the voter.
There have been schemes created that allow verifiability along with deniability , but they are complex and expensive (in physical equipment terms) and I don't think I can recall one that allows over-the-internet voting (i.e. not being present at a specially constructed voting machine).
The parent post was making lots of sense until I read this bit:
Since it does things like treat "=" as comparison in conditionals and assignment in statements, as well as the whole whitespace formatting thing, it totally spoils you for writing in things like C and Perl.
I'm sorry, but that is just not true. In Python, '=' is assignment and '==' is comparison, just like in C, C++, etc. What you cannot do is do an assignment and simultaneously treat the rvalue as a boolean in a conditional. In other words, if you mean to do this:
if a== 6:
print 'a was 6'
If you had you accidently typed this:
if a = 6:
print 'a was 6'
Python stops with a 'Syntax Error' exception. If you make the same mistake in C, if would happily overwrite the previous value of a and print a was 6. Lots of fun to debug.. not!
It is not the case that M (in the previous) post must be prime. It is possible for it to be divisible by some prime greater than pn.
The smallest such example is 2*3*5*7*11*13 + 1 which is 59*509 (both of which are primes).
Secondly, checking divisibility by primes is enough, because if some non prime N was a factor of M, then any prime that divided into N would also divide into M. So the only factors of N (and it must have non-unit factors, since it is not a prime) can be composites (non primes). Then apply the same process to them (i.e. they can only have composite factors) and so on. The problem is that your factors are always getting smaller and are always positive. Eventually you run out of positive integers, so the original assumption that N has only composite factors must be wrong.
(OK, that last paragraph was a little more complicated that I was intending it to be.)
A question for your question: Do "Slashdotters" all have the same opinion? Methinks the answer to that one is a loud NO.:-)
In past Slashdot articles about patents, some have come down in favour of them, others are against them all. However, I think your topic needs to be sub-divided a little more: a lot of people are against the concept of being able to essentially patent algorithms (rather than hardware, for example).
I honestly don't know where I stand on this. Many patents that are just glorified descriptions of algorithms seem stupid to me. However, in the current state of Computer Science, many businesses *are* putting in the hours of research and coming up with new inventions. Those inventions just happen to be algorithms. So maybe a patent is ok in some cases. On the other hand, my training is as a mathematician and I would be horrified if somebody patented an algorithm for factoring numbers, for example (in fact, the RSA patent is a bit galling for that reason).
Re:what "with" means, various comments
on
Under The Radar
·
· Score: 2
Jamie's post points out something I left out of the review (definitely under "The Bad"): there is a complete lack of references or further reading suggestions in the book. It is obvious from much of the writing that the authors cannot have been present at every event. In the acknowledgements page, a few people are thanked for granting interviews. However, many other *written* sources must have been consulted in the perparation of the text. Would it have been so hard to credit them as well (just a bibliography list in the back, for example)? If, as Jamie suggets, the Netscape chapters are just a rewrite of Frank Hecker's writings, then a credit is almost required. As I said in my review, I didn't know much about this before reading the book and it certainly comes across as being entirely Goldman Rohm's own writing and research.
As the guy who wrote the review, I'm probably qualified to comment on this.
Firstly, the 7/10 is very dodgy, but for those who think you can accurately sum up an entire book with one number between 0 and 10, I suggest you go and rent "Dead Poets Society" on video and look at the scene where Robin Williams first meets his new class. Initially, I wanted to give it a score of about 3/10 for technical accuracy, 5 or 6/10 for interest to technical types (some of the chapters *were* interesting, despite their lack of complete accuracy) and about 8/10 for those who are not heavily involved "into" Linux already. I decided on the final number by looking back at some past Slashdot reviews and comparing my opinions of those books (I have read most of them) with the numbers they got. The numbers are slightly high, in general, but if you going to buy/read a book based on the number, rather than the review, then you probably deserve to be punished.:-)
I believe I made my true feelings about the book and its shortcomings known in the body of the review. However, I was also interested in trying to view it from the point of view of somebody who may not (yet) be a Linux user.
As to the Felinoid's comment that the book would get a good review based on "open source is good"... um... nice try, but not even close! Since I consider open source (the software, the movement, the people, the whole box and dice) to be more important than proprietary software (to me, personally), I am probably more likely to hold it to a higher standard than a book about some closed, inward looking company.
I remember reading about Huffman encoding back in high school and it is probably largely responsible for me moving on from "computers as a game thingie" to "computers as something to program". The following is my recollection of how this term paper came about - although the details may be a little wrong, since the articles where I've read it are in boxes in the garage and I can't be bothered going down to hunt them out at the moment.:-)
Anyway, just thought I'd share my memories about them man.
Huffman and a few others were taking a graduate course from a professor who gave them a choice about how to be assessed. Either they could sit an end-of-term exam (there may have been some assignments involved throughout the semester as well), or they could write a term paper. Each student could make their own choice.
Most of the class members chose the end-of-term exam, but Huffman (he admitted later) was a slightly lazy student and so decided on the term paper, thinking he could knock it off in a couple of weeks and get an easy credit. Unfortunately (for him, luckily for computer science) he kept putting off the work and suddenly realised he was running out of time to write the paper and couldn't even think of a topic. To make matters worse, he had missed (or not concentrated in) so many of the lectures that the option of renegging and doing the exam was no longer really open to him.
In desperation, he asked the professor for a suggested topic. The professor (I wish I knew his name - he deserves a place in history as well!) posed a problem about compressing data. Huffman struggled with the topic for quite a while but eventually (quite close to the deadline, IIRC) came across a very elegant solution that worked beautifully. He was even able to prove that his solution was optimal, in the sense that no better byte-by-byte compression method was possible (this doesn't include things like LZW, etc, which use run-length compression techniques).
The rest, as they say, is history. As an aside, Huffman passed the course with top marks, since the professor had neglected to inform Huffman that he (the professor) and a colleague had already put extensive work into the problem and failed to solve it satisfactorily.
Just goes to show, sometimes the best work *is* done under pressure.:-)
(OK, let the error-pointer-outers go to work. Where did I mess up?)
Slashdot Mirror
John Nash received his Nobel Prize for work he did as as a graduate student and post-doc. There were a couple of results he found that comprised his PhD thesis and another paper. He didn't actually work in the finance industry -- they took his work and applied it for their own purposes. So using him as a example of research coming out of the sector is a non sequitur.
The tech's still a bit flaky on the reading side if you have more than just a couple of pieces of information, however. JWZ did some investigating into this late last year and came away disappointed. I'm sure it will slowly improve over time, but it's nowhere near Just Works yet: See his results for more details.
It also doesn't have plausible deniability any longer. A union leader or employer or gangster who has some hold over somebody can force them to prove their vote was cast in the pre-agreed fashion: the person has to show that their session id, name, result and what they claim is their key matches up with the hash. They can't fake the key, since creating a hash collision on demand for a pre-specified hash is still a hard mathematical problem. They have to know the session id, otherwise there's no verifiability even for the voter.
There have been schemes created that allow verifiability along with deniability , but they are complex and expensive (in physical equipment terms) and I don't think I can recall one that allows over-the-internet voting (i.e. not being present at a specially constructed voting machine).
That's because you called it t.c and used gcc to compile it, so it was compiled as a C program.
Instead, either call it t.cxx or use g++ to compile it. Treated as a C++ program, it compiles fine.
The parent post was making lots of sense until I read this bit:
Since it does things like treat "=" as comparison in conditionals and assignment in statements, as well as the whole whitespace formatting thing, it totally spoils you for writing in things like C and Perl.I'm sorry, but that is just not true. In Python, '=' is assignment and '==' is comparison, just like in C, C++, etc. What you cannot do is do an assignment and simultaneously treat the rvalue as a boolean in a conditional. In other words, if you mean to do this:
if a== 6:
print 'a was 6'
If you had you accidently typed this:
if a = 6:
print 'a was 6'
Python stops with a 'Syntax Error' exception. If you make the same mistake in C, if would happily overwrite the previous value of a and print a was 6. Lots of fun to debug .. not!
It is not the case that M (in the previous) post must be prime. It is possible for it to be divisible by some prime greater than pn.
The smallest such example is 2*3*5*7*11*13 + 1 which is 59*509 (both of which are primes).
Secondly, checking divisibility by primes is enough, because if some non prime N was a factor of M, then any prime that divided into N would also divide into M. So the only factors of N (and it must have non-unit factors, since it is not a prime) can be composites (non primes). Then apply the same process to them (i.e. they can only have composite factors) and so on. The problem is that your factors are always getting smaller and are always positive. Eventually you run out of positive integers, so the original assumption that N has only composite factors must be wrong.
(OK, that last paragraph was a little more complicated that I was intending it to be.)
Since I haven't seen any links posted to Hilbert's original list yet: a copy of his original paper is avaiable for those interested.
A question for your question: Do "Slashdotters" all have the same opinion? Methinks the answer to that one is a loud NO. :-)
In past Slashdot articles about patents, some have come down in favour of them, others are against them all. However, I think your topic needs to be sub-divided a little more: a lot of people are against the concept of being able to essentially patent algorithms (rather than hardware, for example).
I honestly don't know where I stand on this. Many patents that are just glorified descriptions of algorithms seem stupid to me. However, in the current state of Computer Science, many businesses *are* putting in the hours of research and coming up with new inventions. Those inventions just happen to be algorithms. So maybe a patent is ok in some cases. On the other hand, my training is as a mathematician and I would be horrified if somebody patented an algorithm for factoring numbers, for example (in fact, the RSA patent is a bit galling for that reason).
Jamie's post points out something I left out of the review (definitely under "The Bad"): there is a complete lack of references or further reading suggestions in the book. It is obvious from much of the writing that the authors cannot have been present at every event. In the acknowledgements page, a few people are thanked for granting interviews. However, many other *written* sources must have been consulted in the perparation of the text. Would it have been so hard to credit them as well (just a bibliography list in the back, for example)? If, as Jamie suggets, the Netscape chapters are just a rewrite of Frank Hecker's writings, then a credit is almost required. As I said in my review, I didn't know much about this before reading the book and it certainly comes across as being entirely Goldman Rohm's own writing and research.
As the guy who wrote the review, I'm probably qualified to comment on this.
:-)
... um ... nice try, but not even close! Since I consider open source (the software, the movement, the people, the whole box and dice) to be more important than proprietary software (to me, personally), I am probably more likely to hold it to a higher standard than a book about some closed, inward looking company.
Firstly, the 7/10 is very dodgy, but for those who think you can accurately sum up an entire book with one number between 0 and 10, I suggest you go and rent "Dead Poets Society" on video and look at the scene where Robin Williams first meets his new class. Initially, I wanted to give it a score of about 3/10 for technical accuracy, 5 or 6/10 for interest to technical types (some of the chapters *were* interesting, despite their lack of complete accuracy) and about 8/10 for those who are not heavily involved "into" Linux already. I decided on the final number by looking back at some past Slashdot reviews and comparing my opinions of those books (I have read most of them) with the numbers they got. The numbers are slightly high, in general, but if you going to buy/read a book based on the number, rather than the review, then you probably deserve to be punished.
I believe I made my true feelings about the book and its shortcomings known in the body of the review. However, I was also interested in trying to view it from the point of view of somebody who may not (yet) be a Linux user.
As to the Felinoid's comment that the book would get a good review based on "open source is good"
I remember reading about Huffman encoding back in high school and it is probably largely responsible for me moving on from "computers as a game thingie" to "computers as something to program". The following is my recollection of how this term paper came about - although the details may be a little wrong, since the articles where I've read it are in boxes in the garage and I can't be bothered going down to hunt them out at the moment. :-)
:-)
Anyway, just thought I'd share my memories about them man.
Huffman and a few others were taking a graduate course from a professor who gave them a choice about how to be assessed. Either they could sit an end-of-term exam (there may have been some assignments involved throughout the semester as well), or they could write a term paper. Each student could make their own choice.
Most of the class members chose the end-of-term exam, but Huffman (he admitted later) was a slightly lazy student and so decided on the term paper, thinking he could knock it off in a couple of weeks and get an easy credit. Unfortunately (for him, luckily for computer science) he kept putting off the work and suddenly realised he was running out of time to write the paper and couldn't even think of a topic. To make matters worse, he had missed (or not concentrated in) so many of the lectures that the option of renegging and doing the exam was no longer really open to him.
In desperation, he asked the professor for a suggested topic. The professor (I wish I knew his name - he deserves a place in history as well!) posed a problem about compressing data. Huffman struggled with the topic for quite a while but eventually (quite close to the deadline, IIRC) came across a very elegant solution that worked beautifully. He was even able to prove that his solution was optimal, in the sense that no better byte-by-byte compression method was possible (this doesn't include things like LZW, etc, which use run-length compression techniques).
The rest, as they say, is history. As an aside, Huffman passed the course with top marks, since the professor had neglected to inform Huffman that he (the professor) and a colleague had already put extensive work into the problem and failed to solve it satisfactorily.
Just goes to show, sometimes the best work *is* done under pressure.
(OK, let the error-pointer-outers go to work. Where did I mess up?)