"If the heated plate is radiating 100 Joules then you insert the passive plate and once it reaches equilibrium it is radiating 10 Joules back toward the heated plate. What happens to that 10 Joules being radiated back?"
You tell me. But since it is radiating back at a cooler thermodynamic temperature, it won't be absorbed by the source. At equilibrium, if it is any distance at all from the (only) heat source, it does not absorb all the radiation from the source so it will not be as hot as that source. (And if there is no distance from the passive plate to the source, it is no longer a separate body... it become part of the source mass, which is an entirely different scenario.)
Since the passive plate MUST BE cooler than the source, there will be no net heat transfer from the plate to the source. Even if the plate were as warm as the source, there would still be no net transfer because T - T0 = 0.
Q.E.D.
I am aware that seems counter-intuitive to many people. But that's what the math says.
No "whoosh" involved. It's GP who doesn't understand the point.
A picture frame is a picture frame. A phone is a phone.
If I make a phone in a diamond shape (just pulling something something out of the air that is easy to describe), and then YOU make a phone that is a diamond shape, then you might have violated my patent, even if you had previously manufactured can openers in a diamond shape.
They're different kinds of devices. Further, they are different kinds of devices that are not very likely to be confused with one another.
"Aye, very much, but the point was the LOOK of the device, that as said, was the basis for their own later products."
That might have been GP's point but if so I don't think it's a valid point.
If I make a TV that resembles a toaster, I haven't infringed on any toaster patents. (Including, probably, any design patents because they are completely different kinds of devices.)
"When I wanted a phone "killed" I'd just call up the CEO of that phone company and have him have his people disable the phone plan for "non-payment" or whatever."
You've missed the point.
It's not about having "a phone" killed. It's about the ability to have phoneS killed. Plural.
But understand: If the program halts, the problem does get resolved, one way or the other. It won't halt again on the same kind of problem in the subsequent runs.
"ICANN isn't independent of the US government because they will be arrested and detained (even if it requies extrajudician extraction) to face criminal charges. "
Do you listen to YOURSELF?
Arrested and detained FOR WHAT?
Yes, I agree that they reside in the United States, but the kind of situation you describe has never happened.
The UN building is in the U.S. Do you see U.N. officials getting arrested on a regular basis? The UN doesn't exactly always act in U.S. interest.
"Sorry, but you're still making too much work for yourself by letting one faulty page halt the entire job."
NO, I definitely am not.
If the program goes through 1,000 chunks of text successfully, then chokes on # 1001, what is the likelihood that I will run into the same kind of issue when it parses 200,000 of them?
Answer, to be quite honest: unknown.
Therefore, the program halts, with a meaningful error message. That way, I can look at the problem and refine the code, so it WON'T halt again on the next trial run.
Understand that my goal is to minimize the amount of human intervention (parsing) necessary, while maximizing the total amount of successful parsing.
Yes, I have to make a judgment call on many of them. I must say to myself: "Does this look like something that is likely to occur again in hundreds of thousands of data points?" If the answer is yes, it is likely to occur often, then I must refine my code to handle that situation. If the answer is no, I can change the code to record this instance as something a human needs to look at, and resume its parsing.
"Same thing happened to Samsung. Here's a digital picture frame they made in 2005 and sold in 2006."
Get real. People were buying digital picture frames for their keychains before the iPhone came out. It was hardly a Samsung invention. Patent for digital picture frames was applied for clear back in 1996, and it wasn't Samsung.
If you are talking about the idea of the digital tablet, you have to go clear back to the Newspad from the film "2001: A Space Odyssey" which aired in 1968.
Not really, you spend all your time working on a project that's doomed to failure because the client wont listen. When it does fall through you cop the blame and the idiot client tells everyone at the golf club how useless you are. This is what I mean by "in the long term", what you're proposing is short term gain with no consideration of long term effects.
But that's why, as TFA says, you always "Document The Troubles".
This is a lesson I learned the hard way. Keep every piece of paper, memo, email, etc. Skype text chat? Archive it.
I had one client try to weasel out of paying me for something, saying I hadn't done the work. I showed him the entire record of when I did it, as he was chatting with me about it on Skype the whole time, which was a matter of some hours.
I got paid. But getting paid for a few hours is not the main thing. If somebody tries to really screw you, as in the situation you folks are discussing, documentation can make ALL the difference.
I don't believe in broadcasting ill will toward clients publicly. But if you ever run into a situation like "Oh, yeah. Well, we considered hiring you but then we heard about what happened with Project X", you can pull out your documentation and show them that it was actually Sam who f*ed it up, not you. Fuck the golf course.
Of if you have an asshole associate who tries to take all your credit. Voila. Records that show otherwise. (No, you probably don't want to shoot down co-workers, but if they try to shoot you down first, let 'em fry.)
"Not sure if this is a rehash of the same fusion discussion here a few weeks/months ago..."
In part.
The NIF did manage to spark a fusion reaction that actually output more energy than was input to the fuel pellet.
However, it is important to note that it was not more energy than the total input to the system. The energy used to power the lasers was still more than the energy of the fusion reaction. So it wasn't "break even".
There was some misunderstanding over my use of the word "crash". My program doesn't crash. But when it hits a serious unanticipated problem, it does halt.
And that's a GOOD thing. Because if it didn't halt when it came across something anticipated, I wouldn't have a chance to change the code to anticipate it again later. So the first 10,000 might work fine, but all the next 100,000 could have errors and I wouldn't catch them until the damage was done
.
As I replied to the other person above: I didn't mean "crash" literally. I have errors sufficiently trapped that it doesn't actually crash. It just stops running. So it isn't an actual crash, but it IS a pain in the ass.
Apologies for any confusion. I have anticipated problems with errors in the text; those are handled automatically. UNanticipated errors cause the program to halt with an error message.
I agree that it shouldn't "crash", and it doesn't. Just an unfortunate choice of words.
" Each individual task should be isolated by an exception handler so that the failure of one job in a batch doesn't cause the failure of the whole batch."
Yes, but now you're getting into the area of "should be" versus "can be". Or perhaps more accurately, "practically can be".
As I was saying earlier: without trying to build a full-blown Watson-like text parsing engine (which is WAY beyond the scope of this project), it simply isn't possible to anticipate all the possible errors. This is TEXT, remember. And people can fuck up text in horrifically unpredictable ways.
Regardless of whether it is a "first rule of programming" or not, it is only possible to account for the errors you can anticipate. Certainly, there are times when you probably should have anticipated something you did not. But some things are not anticipated.
Having said that: I DO trap errors. When I said the program "crashed", I just meant it stopped running and, spewed out a runtime-error message. Anticipated errors are all logged. Only unanticipated errors cause the program to halt. And even those are trapped and give me valuable debug information.
Next run, that error will be anticipated and (we hope) dealt with in the code so it doesn't happen again. But that doesn't preclude another unanticipated error from happening after another 10,000 or so documents.
Just look up the Stefan-Boltzmann law. Wikipedia has a pretty good explanation.
Regardless of whether a hotter radiator actually absorbs and re-emits, or reflects, or transfers, incoming cooler radiation, the NET effect is the same: it isn't retained by the hotter body.
When one body is hotter than another, NET heat flow is always in one direction.
"The standards are open for anyone to make their own [nation]net. With that in mind, it sure looks like everyone is leeching off the US-net and then whining that it isn't being twisted to their favored totalitarianisms and oppressions.
We have a special salute prepared for this kind of demand, and 90% of our citizens practice it regularly."
Precisely. There is nothing -- absolutely and literally nothing -- preventing any country from operating its own "intranet" and connecting or not connecting to the one operated by ICANN or not, as they please. Like China, for instance.
In fact, I am in favor of this approach. Set up one, big, international, NEUTRAL hub. (Which is basically what ICANN is, but whatever. Some people don't like the arrangment.) It should NOT be government-controlled, in any sense, by anybody. The UN is definitely out. To be perfectly honest, I would be happy if the UN would leave U.S. soil completely. But that's another story.
So anyway... set up your big hub and let countries connect or not, as they please. They can control the traffic to/from their country if they want. I don't give a damn.
The BIG problem with this scenario all around is government control. Frankly, I have grown to distrust the U.S. government almost as much as I distrust China's.
I simply don't trust surveys that don't publish the exact questions they used.
The wording, and how the questions are presented, are extremely important to the results. Most surveys are woefully unreliable anyway. But when you throw in the fact that you don't even know the actual questions asked, you might as well throw it away.
I don't give a damn if it was the National Science Foundation that conducted the survey, or the National Creationism Organization. List your questions when reporting your results, or don't bother me at all.
Since we're talking rules of thumb here: in North America, all native berries with a blue or purple color are edible. (But not necessarily ornamental or garden plants; you don't know where they're from.)
Red berries: some are edible, some are not. Be familiar with those that are.
White berries: pretty much inedible. Many are poisonous, none are very nutritious. There are stories of people surviving for a time on snowberries, but... they're stories.
"That comes down to definition of a "bug". What is the intended operation? Is that 100% defined? No? It isn't defined what to do with sufficiently inappropriate errors in the input? Not handling a case that wasn't intended to be handled isn't a "bug"."
But now you're getting into the area of: what one person calls a bug, another might not.
It was certainly the customer's "intention" that 100% of the text be parsed 100% reliably. It did not take long for him to be disabused of this notion, but in the beginning, if I had told him that 0.5% of the pages would require human intervention, he might not have hired me. (I did not know that at the time, myself. "Random" sampling of the tens of thousands of pages did not show much difficulty. Of course it is the rare exceptions that cause nearly all the problems.)
Over time, of course, he and I both have more realistic views of what is possible with this data and what is not. But as I say, back in the beginning, if I had simply presented him with this code he probably would have called it "bug-riddled". But it's not. Where there are problems, it (nearly) always catches them, and logs a report.
But when I am actually doing a run, and tens of thousands of pages are being processed, and ONE causes the program to crash: is that a bug? If you had no way to anticipate that one particular, strange bit of text that was different from all the rest?
Slashdot Mirror
"If the heated plate is radiating 100 Joules then you insert the passive plate and once it reaches equilibrium it is radiating 10 Joules back toward the heated plate. What happens to that 10 Joules being radiated back?"
You tell me. But since it is radiating back at a cooler thermodynamic temperature, it won't be absorbed by the source. At equilibrium, if it is any distance at all from the (only) heat source, it does not absorb all the radiation from the source so it will not be as hot as that source. (And if there is no distance from the passive plate to the source, it is no longer a separate body... it become part of the source mass, which is an entirely different scenario.)
Since the passive plate MUST BE cooler than the source, there will be no net heat transfer from the plate to the source. Even if the plate were as warm as the source, there would still be no net transfer because T - T0 = 0.
Q.E.D.
I am aware that seems counter-intuitive to many people. But that's what the math says.
A not so smart Act to kill phones. That's how I interpret this.
No "whoosh" involved. It's GP who doesn't understand the point.
A picture frame is a picture frame. A phone is a phone.
If I make a phone in a diamond shape (just pulling something something out of the air that is easy to describe), and then YOU make a phone that is a diamond shape, then you might have violated my patent, even if you had previously manufactured can openers in a diamond shape.
They're different kinds of devices. Further, they are different kinds of devices that are not very likely to be confused with one another.
"Aye, very much, but the point was the LOOK of the device, that as said, was the basis for their own later products."
That might have been GP's point but if so I don't think it's a valid point.
If I make a TV that resembles a toaster, I haven't infringed on any toaster patents. (Including, probably, any design patents because they are completely different kinds of devices.)
"When I wanted a phone "killed" I'd just call up the CEO of that phone company and have him have his people disable the phone plan for "non-payment" or whatever."
You've missed the point.
It's not about having "a phone" killed. It's about the ability to have phoneS killed. Plural.
But understand: If the program halts, the problem does get resolved, one way or the other. It won't halt again on the same kind of problem in the subsequent runs.
("Source" = the sole heat source as in the thought experiment being discussed.)
"ICANN isn't independent of the US government because they will be arrested and detained (even if it requies extrajudician extraction) to face criminal charges. "
Do you listen to YOURSELF?
Arrested and detained FOR WHAT?
Yes, I agree that they reside in the United States, but the kind of situation you describe has never happened.
The UN building is in the U.S. Do you see U.N. officials getting arrested on a regular basis? The UN doesn't exactly always act in U.S. interest.
So what's your point?
"Sorry, but you're still making too much work for yourself by letting one faulty page halt the entire job."
NO, I definitely am not.
If the program goes through 1,000 chunks of text successfully, then chokes on # 1001, what is the likelihood that I will run into the same kind of issue when it parses 200,000 of them?
Answer, to be quite honest: unknown.
Therefore, the program halts, with a meaningful error message. That way, I can look at the problem and refine the code, so it WON'T halt again on the next trial run.
Understand that my goal is to minimize the amount of human intervention (parsing) necessary, while maximizing the total amount of successful parsing.
Yes, I have to make a judgment call on many of them. I must say to myself: "Does this look like something that is likely to occur again in hundreds of thousands of data points?" If the answer is yes, it is likely to occur often, then I must refine my code to handle that situation. If the answer is no, I can change the code to record this instance as something a human needs to look at, and resume its parsing.
"I don't see that the Stefan-Boltzmann law contradicts what I have said. Yes the NET heat flow is always in one direction. "
Then what's the argument? That was my only point. The net heat flow is always from warmer (thermodynamic temperature) to colder.
Always. Period.
Therefore, in Spencer's thought experiment, the passive body that is inserted into the system cannot make the source warmer than it already is.
That is Latour's whole point. With which you have just said you agree.
"Same thing happened to Samsung. Here's a digital picture frame they made in 2005 and sold in 2006."
Get real. People were buying digital picture frames for their keychains before the iPhone came out. It was hardly a Samsung invention. Patent for digital picture frames was applied for clear back in 1996, and it wasn't Samsung.
If you are talking about the idea of the digital tablet, you have to go clear back to the Newspad from the film "2001: A Space Odyssey" which aired in 1968.
Not really, you spend all your time working on a project that's doomed to failure because the client wont listen. When it does fall through you cop the blame and the idiot client tells everyone at the golf club how useless you are. This is what I mean by "in the long term", what you're proposing is short term gain with no consideration of long term effects.
But that's why, as TFA says, you always "Document The Troubles".
This is a lesson I learned the hard way. Keep every piece of paper, memo, email, etc. Skype text chat? Archive it.
I had one client try to weasel out of paying me for something, saying I hadn't done the work. I showed him the entire record of when I did it, as he was chatting with me about it on Skype the whole time, which was a matter of some hours.
I got paid. But getting paid for a few hours is not the main thing. If somebody tries to really screw you, as in the situation you folks are discussing, documentation can make ALL the difference.
I don't believe in broadcasting ill will toward clients publicly. But if you ever run into a situation like "Oh, yeah. Well, we considered hiring you but then we heard about what happened with Project X", you can pull out your documentation and show them that it was actually Sam who f*ed it up, not you. Fuck the golf course.
Of if you have an asshole associate who tries to take all your credit. Voila. Records that show otherwise. (No, you probably don't want to shoot down co-workers, but if they try to shoot you down first, let 'em fry.)
"Not sure if this is a rehash of the same fusion discussion here a few weeks/months ago..."
In part.
The NIF did manage to spark a fusion reaction that actually output more energy than was input to the fuel pellet.
However, it is important to note that it was not more energy than the total input to the system. The energy used to power the lasers was still more than the energy of the fusion reaction. So it wasn't "break even".
History is clear that the "general welfare" clause was a restrictive one rather than a permissive one.
I do not accept the Supreme Court as the final arbiter of Constitutionality. It has done a terrible job, and that's an understatement.
Yes, you are right. But that's the only exception of which I am aware. And to be honest, poke berries always looked a bit weird to me anyway.
Yes they do grow in N. America, and the leaves are edible. Didn't you ever hear the song "Poke Salad Annie"?
This. Thank you.
There was some misunderstanding over my use of the word "crash". My program doesn't crash. But when it hits a serious unanticipated problem, it does halt.
And that's a GOOD thing. Because if it didn't halt when it came across something anticipated, I wouldn't have a chance to change the code to anticipate it again later. So the first 10,000 might work fine, but all the next 100,000 could have errors and I wouldn't catch them until the damage was done .
No, I'm literally saying it probably can't be done, today. Maybe next week.
But in all honesty, I serious doubt even IBM's Watson would be able to 100% reliably parse all of this text, with its formatting errors and typos.
As I replied to the other person above: I didn't mean "crash" literally. I have errors sufficiently trapped that it doesn't actually crash. It just stops running. So it isn't an actual crash, but it IS a pain in the ass.
Apologies for any confusion. I have anticipated problems with errors in the text; those are handled automatically. UNanticipated errors cause the program to halt with an error message.
I agree that it shouldn't "crash", and it doesn't. Just an unfortunate choice of words.
" Each individual task should be isolated by an exception handler so that the failure of one job in a batch doesn't cause the failure of the whole batch."
Yes, but now you're getting into the area of "should be" versus "can be". Or perhaps more accurately, "practically can be".
As I was saying earlier: without trying to build a full-blown Watson-like text parsing engine (which is WAY beyond the scope of this project), it simply isn't possible to anticipate all the possible errors. This is TEXT, remember. And people can fuck up text in horrifically unpredictable ways. Regardless of whether it is a "first rule of programming" or not, it is only possible to account for the errors you can anticipate. Certainly, there are times when you probably should have anticipated something you did not. But some things are not anticipated.
Having said that: I DO trap errors. When I said the program "crashed", I just meant it stopped running and, spewed out a runtime-error message. Anticipated errors are all logged. Only unanticipated errors cause the program to halt. And even those are trapped and give me valuable debug information.
Next run, that error will be anticipated and (we hope) dealt with in the code so it doesn't happen again. But that doesn't preclude another unanticipated error from happening after another 10,000 or so documents.
Just look up the Stefan-Boltzmann law. Wikipedia has a pretty good explanation.
Regardless of whether a hotter radiator actually absorbs and re-emits, or reflects, or transfers, incoming cooler radiation, the NET effect is the same: it isn't retained by the hotter body.
When one body is hotter than another, NET heat flow is always in one direction.
"The standards are open for anyone to make their own [nation]net. With that in mind, it sure looks like everyone is leeching off the US-net and then whining that it isn't being twisted to their favored totalitarianisms and oppressions.
We have a special salute prepared for this kind of demand, and 90% of our citizens practice it regularly."
Precisely. There is nothing -- absolutely and literally nothing -- preventing any country from operating its own "intranet" and connecting or not connecting to the one operated by ICANN or not, as they please. Like China, for instance.
In fact, I am in favor of this approach. Set up one, big, international, NEUTRAL hub. (Which is basically what ICANN is, but whatever. Some people don't like the arrangment.) It should NOT be government-controlled, in any sense, by anybody. The UN is definitely out. To be perfectly honest, I would be happy if the UN would leave U.S. soil completely. But that's another story.
So anyway... set up your big hub and let countries connect or not, as they please. They can control the traffic to/from their country if they want. I don't give a damn.
The BIG problem with this scenario all around is government control. Frankly, I have grown to distrust the U.S. government almost as much as I distrust China's.
I read the .pdf, and I have this to say about it:
I simply don't trust surveys that don't publish the exact questions they used.
The wording, and how the questions are presented, are extremely important to the results. Most surveys are woefully unreliable anyway. But when you throw in the fact that you don't even know the actual questions asked, you might as well throw it away.
I don't give a damn if it was the National Science Foundation that conducted the survey, or the National Creationism Organization. List your questions when reporting your results, or don't bother me at all.
This is about the most benign form of advertising I can imagine.
It's on a page users don't have to see more than once, if they don't want to.
Even if they don't change their startup page, the ads go away pretty quickly, and permanently.
I've gotten that too.
Since we're talking rules of thumb here: in North America, all native berries with a blue or purple color are edible. (But not necessarily ornamental or garden plants; you don't know where they're from.)
Red berries: some are edible, some are not. Be familiar with those that are.
White berries: pretty much inedible. Many are poisonous, none are very nutritious. There are stories of people surviving for a time on snowberries, but... they're stories.
"That comes down to definition of a "bug". What is the intended operation? Is that 100% defined? No? It isn't defined what to do with sufficiently inappropriate errors in the input? Not handling a case that wasn't intended to be handled isn't a "bug"."
But now you're getting into the area of: what one person calls a bug, another might not.
It was certainly the customer's "intention" that 100% of the text be parsed 100% reliably. It did not take long for him to be disabused of this notion, but in the beginning, if I had told him that 0.5% of the pages would require human intervention, he might not have hired me. (I did not know that at the time, myself. "Random" sampling of the tens of thousands of pages did not show much difficulty. Of course it is the rare exceptions that cause nearly all the problems.)
Over time, of course, he and I both have more realistic views of what is possible with this data and what is not. But as I say, back in the beginning, if I had simply presented him with this code he probably would have called it "bug-riddled". But it's not. Where there are problems, it (nearly) always catches them, and logs a report.
But when I am actually doing a run, and tens of thousands of pages are being processed, and ONE causes the program to crash: is that a bug? If you had no way to anticipate that one particular, strange bit of text that was different from all the rest?