Quite right. I was merely trying to illustrate that a proof can be extremely long, with many steps. And yet, the results can be widely accepted. I suppose my point would have been clearer had I replied to this post instead.
First of all, I highly doubt that all of those 1000 pages are devoted to solving the Poincare Conjecture. Perelman, if I remember correctly, studies Ricci curvature flows which is a large area of mathematics in its own right. In the course of his research, he discovered some things that led to this proof of the Poincare Conjecture. I would expect that the 1000 pages referred to by this article deal with many different consequences of Perelman's work. Mathematicians like to do things in full generality, so they would have studied broader consequences instead of focussing for so long on only one result.
Secondly, I would invite you to write down a complete proof of some well-known mathematical fact, the Stone-Weierstrass theorem say. You must prove this from first principles, starting with axiomatic set theory. I would be very surprised if you even managed to finish and even more surprised if the proof came in at under 1000 pages. This highlights what was mentioned by a sibling of mine: mathematics is divided into small steps and you would never dream of trying to prove something all at once.
Thirdly, this is the first ever proof of the Poincare conjecture. It is quite common in mathematics that a nicer proof of a known fact will be found.
Here's the thing about the GPLv3. It's taking away more freedom from both the developer and the user. It will prevent the developer from developing for whatever hardware he wants
Please explain to me how the existence of the GPLv3 will prevent developers from licensing their software under the GPLv2.
I think you missed his point. Queenslanders recently voted not to recycle their water on the grounds that it's too icky. OP was just curious as to whether we're all that stupid.
Let's change the example slightly, then; it wasn't well thought-out: put a space before and after "->" Then, the shell only needs to recognise the built-in command "->". Using the dynamic typing facilities provided by the operating system, it checks to see if the object "filename" has a method named lookup. If it doesn't print an error message. If it does, call it. This isn't really any more complicated than looking up the location of an executable in $PATH. It is different to (cat filename | lookup) because the lookup method is no longer specific to that file (or type of file). You will end up with massive namespace collisions if you put every method in the global scope.
They didn't. They just wrote tools to deal with flat files (awk, sed, grep, sort, uniq etc) which encouraged the use them.
And the exact same thing could conceivably happen with an object-based system.
"The difference would be in the way the information is organised and presented."
I really don't think so. Right now the OS knows all the metadata it needs to know. At best you are adding to that metadata.
Yes, the OS knows all the metadata it needs to know. It just isn't presented in a very friendly manner, especially to people writing programs and scripts.
"there were a good way of dealing with these objects from the shell"
There is. cat filename | perl -e (or some such equivalent in python or ruby)
The whole point of persistent objects is to provide a nicer, more uniform interface. Something like
(where, in this example, filename is a file representing a table). Therefore, the existing ways of dealing with these objects from the shell are not "good."
"these sorts of objects were used system-wide"
Facism doesn't work in OSS. How are you going to force everybody to use the same format for anything?
How did the inventors of UNIX force everybody to use flat files for all their data storage? By designing a system in which that model was integrated, consistent and made sense. If someone were to design and create a system based around the notion of persistent objects, the users of that system would use persistent objects system-wide. I don't see how that's fascist. The purpose of my statement was that persistent objects only make sense if there is a consistent system-wide interface.
You could do common things like read lines, read bytes, write lines, write bytes, check for EOF etc but for anything more sophisticated you would need some code that knew about the file. No different then what you have now.
The difference would be in the way the information is organised and presented. Anything you do in an object-oriented language can be done in a procedural language. But the object-oriented way of organising and viewing a program can sometimes be more intuitive and useful.
Right now I could serialize and object written in any language and save it to a file. In order to do anything with that file other then read bytes or lines I would have to have the original language and perhaps the serialization routine.
And that could* be very useful if
there were a good way of dealing with these objects from the shell
these sorts of objects were used system-wide
Think, for example, of how many useless lines of ad-hoc parsers there are in a modern *NIX system. Every start-up script and every program with a configuration file has some sort of parser built in. With a more powerful way of structuring data at the operating system level, these things could be done more elegantly and more robustly
* Of course, I don't know if it _would_ be useful, never having used such a system
The superclass, File say, would have all the methods that we normally associate with files. That is, it would represent the file as a stream of bytes that you can read from or write to. Since many files are plain text files anyway, all the normal ways of processing text apply.
Then you could have the ImageFile subclass, for example, which supports a method "Pixmap ImageFile::RenderImage ()". If the OS has the right libraries installed, it will abstract away from png, jpeg, etc. files. Of course, you can access the raw byte stream if you want, and render the image yourself. And you can detect the image type and look up the APIs for every different image rendering library out there (and if you want some very advanced feature, you probably will). But I think the file-with-a-type idea makes most things much simpler.
You link to Wikipedia as though it supports your claim, but I cannot find anything on that page suggesting that the eggshell-thinning theory has been disproved.
In fact, the second reference from the wikipedia article goes to epa.gov and states that DDT adversely affects avian and mammalian reproduction by eggshell thinning, infertility, and embryo- and fetotoxicity. Have I missed something?
XGL runs very well on my Thinkpad with an ATI Mobility Radeon 7500 using the Free, open source drivers that X.org provides. I imagine the situation is similar for any Radeon cards up to and including the 9200. I also understand that the Free, open source drivers for Intel chips support 3D acceleration.
Uhh... no. The purpose of terrorism is to advance political or ideological goals by the use of violence or the threat of violence, sometimes against civilians, to exert pressure on those in power.
While you are correct, I think the GP's point is valid (if poorly stated). The threat of violence only brings about change if people are afraid. If we would stop responding to terrorism with fear, terrorism would no longer be successful.
I think FDR's famous quote has never been more relevant.
Were exactly did you read this in the bible? In no place does it say kill this or that.
Leviticus, chapter 21, verses 10 and 11:
"If a man commits adultery with the wife of his heighbor, both the adulterer and the adulteress shall be put to death. The man who lies with his father's wife has uncovered his father's nakedness; both of them shall be put to death."
The mother-daughter menage-a-trois is in verse 14 and the bestiality is in verse 15.
I often find it hard to discover what people are talking about in mathematics because everyone in different fields has different notation and different definitions! I was reading a signal processing paper and they have a very confusing notation for matrix transpose, Hermitian transpose and complex conjugate -- they're all superscript stars that look slightly different. And they write polynomials in negative powers!
I guess the lesson is to always be very precise because there will always be someone with a different definition than yours...
As far as the B-T paradox goes, I always think of it in terms of the measure of unmeasureable sets because it is the only way I can get it to make sense. You take a bunch of points and translate and rotate them and get something with a bigger measure! But it works because you are translating and rotating unmeasurable sets so the normal rules don't apply. That's how I see it anyway.
OK, now this is boiling down to squabbling over details in definitions, but it is quite possible to define a measure as being a function {subsets of X} -> {real numbers} that behaves nicely on some \sigma-algebra. You can then define a measurable set as being any set A such that for all E \subset X,
m(E) = m(E intersect A) + m(E intersect A complement)
noting that E may or may not be measurable. This is, in fact, the way I learned measure theory.
We can equally well define a measure to be a function defined _only_ on some sigma-algebra, in which case it does not make sense to take a measure of an unmeasurable set. But the existence of multiple constructions (I'm sure there are others too) means that it's always less ambiguous (and not redundant) to say that a set is measurable when we want to take its measure.
And the Banach-Tarski paradox just shows that we cannot expect the measure of unmeasurable sets to behave at all intuitively (if we allow taking their measure, of course) under union, translation, rotation, and so on. It's kind of tangential to my point.
Give init-ng a go. It's similar to gentoo's init system for administration but it's very fast and it runs on debian. It's not the most stable piece of software in the world and I needed to tweak some init scripts manually, but it's worth a look.
Your england link isn't complete, but here are some stats (only up to '98) from the same site. You will notice that the murder rate is per million people. That is, the murder rate in 1998 was 1.2 per 100,000 compared to the USA's 6.3 (in 1998, 5.5 in 2004) per 100,000.
Oh, come on. I'm sitting on the fence about global warming personally, but comments like yours just demonstrate the extent to which people will deceive themselves in order to rant about their opponents.
Being warmer in 800 AD indicates...
What makes you think it was warmer in 800 AD? From the article:
Reliable records from trees and other sources go back only about 1,200 years, but this allowed the researchers to measure the magnitude of the current bout of warming against two of the best known long-term weather conditions, the Little Ice Age from about 1580 to 1850, and the Medieval Warm Period from 890 to 1170.
In other words, they only had data going back to 800 AD. And this is the warmest period among all their data.
...and this was while human "interference" was ramping up...
Not according to the whole carbon dioxide theory of global warming, which only predicts temperature rises in the last 150 years or so. Even supposing that is was warmer 1,200 years ago than it is now, this doesn't mean that temperatures have been going down while CO2 emissions were increasing.
But instead, you have to go off and rant about how this article proves your point of view. I bet you do the same for every article on global warming, whichever way the evidence in the article points. Do people ever consider both sides of an issue and make an unimpassioned judgements?
The old FORTRAN compiler could many times beat out an experianced assembly language programmer.
Yes, and I think that FORTRAN code performs quite well on Itanium. The problem is that C code, with its almost unrestricted use of pointers, doesn't lend itself easily to that sort of optimisation. If you have a chuck of code with lots of pointer references, the compiler will need to make some pretty big deductions on where those pointers could be pointing before it can hope to parallelise anything.
Slashdot Mirror
Quite right. I was merely trying to illustrate that a proof can be extremely long, with many steps. And yet, the results can be widely accepted. I suppose my point would have been clearer had I replied to this post instead.
First of all, I highly doubt that all of those 1000 pages are devoted to solving the Poincare Conjecture. Perelman, if I remember correctly, studies Ricci curvature flows which is a large area of mathematics in its own right. In the course of his research, he discovered some things that led to this proof of the Poincare Conjecture. I would expect that the 1000 pages referred to by this article deal with many different consequences of Perelman's work. Mathematicians like to do things in full generality, so they would have studied broader consequences instead of focussing for so long on only one result.
Secondly, I would invite you to write down a complete proof of some well-known mathematical fact, the Stone-Weierstrass theorem say. You must prove this from first principles, starting with axiomatic set theory. I would be very surprised if you even managed to finish and even more surprised if the proof came in at under 1000 pages. This highlights what was mentioned by a sibling of mine: mathematics is divided into small steps and you would never dream of trying to prove something all at once.
Thirdly, this is the first ever proof of the Poincare conjecture. It is quite common in mathematics that a nicer proof of a known fact will be found.
Please explain to me how the existence of the GPLv3 will prevent developers from licensing their software under the GPLv2.
I think you missed his point. Queenslanders recently voted not to recycle their water on the grounds that it's too icky. OP was just curious as to whether we're all that stupid.
Let's change the example slightly, then; it wasn't well thought-out: put a space before and after "->" Then, the shell only needs to recognise the built-in command "->". Using the dynamic typing facilities provided by the operating system, it checks to see if the object "filename" has a method named lookup. If it doesn't print an error message. If it does, call it. This isn't really any more complicated than looking up the location of an executable in $PATH. It is different to (cat filename | lookup) because the lookup method is no longer specific to that file (or type of file). You will end up with massive namespace collisions if you put every method in the global scope.
And the exact same thing could conceivably happen with an object-based system.
Yes, the OS knows all the metadata it needs to know. It just isn't presented in a very friendly manner, especially to people writing programs and scripts.
The whole point of persistent objects is to provide a nicer, more uniform interface. Something like
isn't nearly as easy as, say (where, in this example, filename is a file representing a table). Therefore, the existing ways of dealing with these objects from the shell are not "good."How did the inventors of UNIX force everybody to use flat files for all their data storage? By designing a system in which that model was integrated, consistent and made sense. If someone were to design and create a system based around the notion of persistent objects, the users of that system would use persistent objects system-wide. I don't see how that's fascist. The purpose of my statement was that persistent objects only make sense if there is a consistent system-wide interface.
The difference would be in the way the information is organised and presented. Anything you do in an object-oriented language can be done in a procedural language. But the object-oriented way of organising and viewing a program can sometimes be more intuitive and useful.
And that could* be very useful if
- there were a good way of dealing with these objects from the shell
- these sorts of objects were used system-wide
Think, for example, of how many useless lines of ad-hoc parsers there are in a modern *NIX system. Every start-up script and every program with a configuration file has some sort of parser built in. With a more powerful way of structuring data at the operating system level, these things could be done more elegantly and more robustly* Of course, I don't know if it _would_ be useful, never having used such a system
The superclass, File say, would have all the methods that we normally associate with files. That is, it would represent the file as a stream of bytes that you can read from or write to. Since many files are plain text files anyway, all the normal ways of processing text apply.
Then you could have the ImageFile subclass, for example, which supports a method "Pixmap ImageFile::RenderImage ()". If the OS has the right libraries installed, it will abstract away from png, jpeg, etc. files. Of course, you can access the raw byte stream if you want, and render the image yourself. And you can detect the image type and look up the APIs for every different image rendering library out there (and if you want some very advanced feature, you probably will). But I think the file-with-a-type idea makes most things much simpler.
You link to Wikipedia as though it supports your claim, but I cannot find anything on that page suggesting that the eggshell-thinning theory has been disproved.
In fact, the second reference from the wikipedia article goes to epa.gov and states that DDT adversely affects avian and mammalian reproduction by eggshell thinning, infertility, and embryo- and fetotoxicity. Have I missed something?
XGL runs very well on my Thinkpad with an ATI Mobility Radeon 7500 using the Free, open source drivers that X.org provides. I imagine the situation is similar for any Radeon cards up to and including the 9200. I also understand that the Free, open source drivers for Intel chips support 3D acceleration.
While you are correct, I think the GP's point is valid (if poorly stated). The threat of violence only brings about change if people are afraid. If we would stop responding to terrorism with fear, terrorism would no longer be successful.
I think FDR's famous quote has never been more relevant.
The mother-daughter menage-a-trois is in verse 14 and the bestiality is in verse 15.
I guess the lesson is to always be very precise because there will always be someone with a different definition than yours...
As far as the B-T paradox goes, I always think of it in terms of the measure of unmeasureable sets because it is the only way I can get it to make sense. You take a bunch of points and translate and rotate them and get something with a bigger measure! But it works because you are translating and rotating unmeasurable sets so the normal rules don't apply. That's how I see it anyway.
m(E) = m(E intersect A) + m(E intersect A complement)
noting that E may or may not be measurable. This is, in fact, the way I learned measure theory.We can equally well define a measure to be a function defined _only_ on some sigma-algebra, in which case it does not make sense to take a measure of an unmeasurable set. But the existence of multiple constructions (I'm sure there are others too) means that it's always less ambiguous (and not redundant) to say that a set is measurable when we want to take its measure.
And the Banach-Tarski paradox just shows that we cannot expect the measure of unmeasurable sets to behave at all intuitively (if we allow taking their measure, of course) under union, translation, rotation, and so on. It's kind of tangential to my point.
Why is it obvious? You can take the measure of an unmeasurable set, it just doesn't behave at all nicely.
Try this for unintuitive:
Find a Banach space X and two sets A and B such that A and B are disjoint, convex and dense and A U B = X.
(Yes, this was an assignment problem, but I've already finished that course)
Give init-ng a go. It's similar to gentoo's init system for administration but it's very fast and it runs on debian. It's not the most stable piece of software in the world and I needed to tweak some init scripts manually, but it's worth a look.
I just responded to your same statistic elsewhere, but I'll do it again here so people aren't misinformed.
The homicide rate per capita in the UK is 1.3 people per 100,000, not 13. In the US, it is around 6 per 100,000.
Your england link isn't complete, but here are some stats (only up to '98) from the same site. You will notice that the murder rate is per million people. That is, the murder rate in 1998 was 1.2 per 100,000 compared to the USA's 6.3 (in 1998, 5.5 in 2004) per 100,000.
There you go. GPS satellites have sufficiently accurate clocks that the relativistic effects are noticeable.
But instead, you have to go off and rant about how this article proves your point of view. I bet you do the same for every article on global warming, whichever way the evidence in the article points. Do people ever consider both sides of an issue and make an unimpassioned judgements?