I guess I'm glad to say that someone else has had the same experience with Sun that I have. I really wish their hardware were more impressive, but sadly, it just doesn't seem to be the case. We have *much* few boxes--several Netras, an E4500, 3 E420Rs, and an E220R, but everything but the Netras has had a problem. The 4500 has had *two* CPU replacements in one year, one of the 420s had a motherboard replacement, another had a power supply fail, the other needed a CPU replacement. I think the 220 hasn't had any problems. Sun has always fixed things for us without trouble, but there have been absolutely no failures on any of our Intel servers, and there's only been two or three minor problems with our Dell workstations (bad serial port from static on a Palm Pilot, bad case fan, can't remember any others).
Right now we're benchmarking dual Athlon MP's and they're absolutely slaughtering the 420s in performance. I don't think we'll be buying any more hardware from Sun.
No, he's right. Everyone who went to Caltech (including myself) hates to see it spelled CalTech. I was about to post the exact same thing, but I decided I'd best search to see if someone beat me to it, which they did.
The Emacs JDEE does most of this (I'm not sure about about importing--you can ask it to import the class that the cursor (point) is currently over, and you can sort the import list at any time. It also generates getters and setters. I've never look for an automatic try/catch wrapping function. It may or may not have it. It would be a good thing to add to it!
I guess this is sort of a moot point. If I'm try to show that IDE's don't have too many advantages, I'm not really succeeding--it would be pretty safe to call Emacs and IDE IMHO.
Apparently you're not a coder. There's always a breakdown in communication somewhere. Sometimes it just happens to be small enough that the project can actually be successful.
This is just silly. If a coder is hired to implement something complicated, he should be able to implement something simple. Maybe you don't recall the algorithm off-hand for linked lists, but if you can't figure it out with a few minutes thought, you're not going to be able to solve complicated problems in a reasonable amount of time. You're right that you shouldn't *have* to implement linked lists, but it's a good test of simple problem solving skills.
I'm not sure how you code linked lists, but the easiest way I know to do it only has a special case for empty lists. One item lists are like any other list.
Needing root privilege to bind ports under 1024 is still a problem. It's fine for simple protocols like HTTP, but for brain-dead protocols like FTP, it's nearly impossible to write a server which can complete drop root privilege, because you need to bind the ftp-data port when making data connections to the client. The only server I know of that solves this problem is PureFTPd, and it uses Linux capabilities to remove the restriction that only root can bind ports under 1024.
You should read his book "On Lisp" next. "ANSI Common Lisp" doesn't cover macros in much detail. "On Lisp" spends the majority of its time on them. Unfortunately, it has gone out of print, but Graham has made it downloadable from his site.
Try connecting to a port that you know doesn't have a listener on it sometime. There is no timeout. An RST is sent in response to your SYN, giving an immediate "connection refused" error message:
[phiggins@court ~]$ telnet localhost 1 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused
Ummm...jars are the files that go into said CLASSPATH variable. Sure you can use the jre/lib/ext directory, but that presents a whole host of weird problems if you overdo it. The CLASSPATH situation is a friggin' nightmare, especially when you end up with customized classloaders like EJB 2.0 requires.
When I read his post I was expecting everyone to tell him this. I can't believe there's only one little post pointing it out. This guy really needs to do the OpenBSD thing and adapt the FreeBSD system rather than write his own. I doubt he will, though. It seems that everyone who thinks they've come up with a novel idea (whether it truly is or not is another story) has to get half-way through an implementation before giving up...
Hold on there, chief. You don't need to load the entire document into memory to validate it. There are many validating SAX parsers out there that work incrementally. SOAP doesn't require validation, either. Certain pieces are required, but IIRC there isn't a DTD or schema for SOAP--it is the job of the SOAP implementation to validate the (relatively small) required sections. I wrote a simple SOAP implementation before the final spec was released and it's very highly efficient. It's also kind of a pain in the ass to use, but it has to handle streaming because I'm shuffling around documents that are tens of megabytes and won't fit into the memory of the small devices my company uses.
SOAP can be pretty lightweight, as long as you consider (basic, non-validating) XML parsing lightweight...
Oh no! More confusion! Proving that P = NP would not necessarily mean that NP-hard problems could be solved in polynomial time. Every problem in NP can be reduced polynomially to an NP-hard problem, but the converse is not true. Not every NP-hard problem is in NP.
Mod this up! Finally, someone who understands. For those not too slick with sets, the definition of NP-complete as the intersection of NP and NP-hard means that NP-complete is a subset of NP. It is also a subset of NP-hard. There are many mistakes being made about this point!
I'm sorry, but you've got your definition a bit screwed up. I'll clarify:
A problem B is NP-complete if it satifies two conditions:
B is in NP
Every A in NP is polynomial time reducible to B
An NP hard problem is one for which the second condition holds. The first does *not* need to hold. The difference between this and your definition is that the reduction goes in the other direction. You don't reduce the problem to NP-complete problems, but rather reduce NP-complete problems to the problem in question. There are NP-hard problems which are not in NP, and thus cannot be reduced to them in polynomial time.
Primality tests don't give you the factors. That would be a factorization algorithm. They just tell you whether or not the number is prime. If it's probablistic, it just tells you there's a good chance the number is prime.
Slashdot Mirror
Do the math for Christ's sake:
p(sex) * p(sexy) = 0.97 * 0.99 = 0.9603 != 0.9997
Paul Graham knows his shit.
I guess I'm glad to say that someone else has had the same experience with Sun that I have. I really wish their hardware were more impressive, but sadly, it just doesn't seem to be the case. We have *much* few boxes--several Netras, an E4500, 3 E420Rs, and an E220R, but everything but the Netras has had a problem. The 4500 has had *two* CPU replacements in one year, one of the 420s had a motherboard replacement, another had a power supply fail, the other needed a CPU replacement. I think the 220 hasn't had any problems. Sun has always fixed things for us without trouble, but there have been absolutely no failures on any of our Intel servers, and there's only been two or three minor problems with our Dell workstations (bad serial port from static on a Palm Pilot, bad case fan, can't remember any others).
Right now we're benchmarking dual Athlon MP's and they're absolutely slaughtering the 420s in performance. I don't think we'll be buying any more hardware from Sun.
Not quite as expensive as all the "V"s on every HOVSE, but since no one actually wants to fix those, it's a non-issue.
No, he's right. Everyone who went to Caltech (including myself) hates to see it spelled CalTech. I was about to post the exact same thing, but I decided I'd best search to see if someone beat me to it, which they did.
Your test cases fail the assumptions:
1. x/y must equal 1/4.
2. x must end with a 6
3. y must start with a 6 and end with a 4.
The base case is thus y = 64 as anything smaller violates (3).
Solving (1) gives an intial x of 16, which satisfies (2).
Iterate from there.
The cheapest tool is not the best tool, but it will probably sell like hotcakes.
The Emacs JDEE does most of this (I'm not sure about about importing--you can ask it to import the class that the cursor (point) is currently over, and you can sort the import list at any time. It also generates getters and setters. I've never look for an automatic try/catch wrapping function. It may or may not have it. It would be a good thing to add to it!
I guess this is sort of a moot point. If I'm try to show that IDE's don't have too many advantages, I'm not really succeeding--it would be pretty safe to call Emacs and IDE IMHO.
Apparently you're not a coder. There's always a breakdown in communication somewhere. Sometimes it just happens to be small enough that the project can actually be successful.
Too bad he's already given away at least his Slashdot username...it may not be enough to track him down, but it's an obvious place to start.
This is just silly. If a coder is hired to implement something complicated, he should be able to implement something simple. Maybe you don't recall the algorithm off-hand for linked lists, but if you can't figure it out with a few minutes thought, you're not going to be able to solve complicated problems in a reasonable amount of time. You're right that you shouldn't *have* to implement linked lists, but it's a good test of simple problem solving skills.
I'm not sure how you code linked lists, but the easiest way I know to do it only has a special case for empty lists. One item lists are like any other list.
Those jobs are easy to move in and out of. Programming projects take time to adjust to, so moving around isn't such a great idea if you're a coder.
Needing root privilege to bind ports under 1024 is still a problem. It's fine for simple protocols like HTTP, but for brain-dead protocols like FTP, it's nearly impossible to write a server which can complete drop root privilege, because you need to bind the ftp-data port when making data connections to the client. The only server I know of that solves this problem is PureFTPd, and it uses Linux capabilities to remove the restriction that only root can bind ports under 1024.
ls -l /bin/mount /bin/mount
-rwsr-xr-x 1 root root 70104 Jan 27 00:05
You should read his book "On Lisp" next. "ANSI Common Lisp" doesn't cover macros in much detail. "On Lisp" spends the majority of its time on them. Unfortunately, it has gone out of print, but Graham has made it downloadable from his site.
Try connecting to a port that you know doesn't have a listener on it sometime. There is no timeout. An RST is sent in response to your SYN, giving an immediate "connection refused" error message:
[phiggins@court ~]$ telnet localhost 1
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Ummm...jars are the files that go into said CLASSPATH variable. Sure you can use the jre/lib/ext directory, but that presents a whole host of weird problems if you overdo it. The CLASSPATH situation is a friggin' nightmare, especially when you end up with customized classloaders like EJB 2.0 requires.
I'm certainly no expert in fluid dynamics, but I find it hard to believe that the results for fluids also apply to gases.
When I read his post I was expecting everyone to tell him this. I can't believe there's only one little post pointing it out. This guy really needs to do the OpenBSD thing and adapt the FreeBSD system rather than write his own. I doubt he will, though. It seems that everyone who thinks they've come up with a novel idea (whether it truly is or not is another story) has to get half-way through an implementation before giving up...
SOAP can be pretty lightweight, as long as you consider (basic, non-validating) XML parsing lightweight...
Oh no! More confusion! Proving that P = NP would not necessarily mean that NP-hard problems could be solved in polynomial time. Every problem in NP can be reduced polynomially to an NP-hard problem, but the converse is not true. Not every NP-hard problem is in NP.
Mod this up! Finally, someone who understands. For those not too slick with sets, the definition of NP-complete as the intersection of NP and NP-hard means that NP-complete is a subset of NP. It is also a subset of NP-hard. There are many mistakes being made about this point!
NP-complete is a proper subset of NP-hard.
This of course means that NP-complete problems are not harder than NP-hard. In fact, the converse can be true (for NP-hard problems not in NP).
A problem B is NP-complete if it satifies two conditions:
An NP hard problem is one for which the second condition holds. The first does *not* need to hold. The difference between this and your definition is that the reduction goes in the other direction. You don't reduce the problem to NP-complete problems, but rather reduce NP-complete problems to the problem in question. There are NP-hard problems which are not in NP, and thus cannot be reduced to them in polynomial time.
Primality tests don't give you the factors. That would be a factorization algorithm. They just tell you whether or not the number is prime. If it's probablistic, it just tells you there's a good chance the number is prime.