My purpose in asking the question is to find out how, specifically, you would define round(r).
It may be trickier than it seems. We have a set of real numbers, and we want to choose the nearest integer. But you claim that the integers are themselves real numbers. So the real number set itself does not provide sufficient information to define the function as "choose the nearest integer". Evidently we have to define the integers through some completely different means, and then claim that there is commonality with the reals. And to me that's not a compelling argument.
It's tempting to say, well, let's subtract the fractional part of r, that is, the part whose absolute value lies in the range [0,1). But clearly that's not a unique construction either.
I'm not saying that there is no satisfactory answer, just that I've never run across it. Add to this the general tendency to treat discrete and continuous domains very differently, and you'll see why I don't just accept the idea because it "intuitively" makes sense. According to my intuition, 1 and 1.0 are two very different things, because they make very different claims. One can be used for counting. The other cannot. So how can one be a subset of the other?
But in fact it's quite common in mathematics to enumerate the first tew elements of a set, and if the set is bounded, to supply the final element. That's what I've done here. The treatment is rigorous, and there should be no confusion of meaning in the context of our present discussion.
There are other uses of this notation. Someone else here was talking about hyperreal numbers, which introduces an interesting and topical subject which is also rigorous.
Speaking of rigorous, when you say that this notation is "completely meaningless", what you should really say is that it's completely meaningless to you.
This is interesting. I've always had misgivings about the notion that countable numbers were a subset of real numbers, given that the real number set is uncountable.
You may know the answer. How can you construct a set of integers from a set of real numbers? For example, given some irrational number r, how would you determine the nearest integer n which approximates it?
No, if it's quantifiable (and that is not a foregone conclusion, since we have no agreed definition of what it means for an atom to "be a part" of your body) the quantity would be expressed in natural numbers, not real numbers.
This appeared as a paradox to the classical Greeks because they had no concept of infinity or limits. Once mathematics introduced those concepts, the paradox disappeared.
Let me put it this way. I just renewed my car insurance. I insured one car. Even if the car has gained mass (as a result of rusting, say, or the addition of accessories) or lost mass, it is only meaningful to regard it as one car for the purposes of insuring it.
Remember when you were a kid and you would pretend that the cardboard tube from a roll of paper towels was a telescope? You would look down the tube and see a tiny piece of the world. That's what it's like to compose text using a line editor.
I was once compelled to write a WYSIWYG editor, in the days when all the system provided was a line editor equivalent to ed.
I noticed that the work became an order of magnitude faster once I was able to use my editor as a development tool.
By the equivalent of the "Analytical Engine" I assume you mean a project of such grand vision that it can never be completed with available resources. People try every century or so to resurrect the project, until they too run out of resources.
The Analytical Engine seems to meet that test. Two other projects also come immediately to mind:
The Cyc project started by Doug Lenat in 1984. It tests the hypothesis that intelligence arises with sufficient knowledge of the world by parsing information taken from news sources. So far it hasn't produced intelligence, but maybe we just need to be patient.
The
Clock of the Long Now which seems destined to produce an infinite series of ever more beautiful and more expensive prototypes.
You can't be a good sysadmin without being a reasonably competent programmer.
The ability to think algorithmically is the main quality that distinguishes good system administrators from mediocre ones. People who assert that it's an optional skill are the worst of all, because they don't even know that they don't know!
I see it all the time. The same thing happens with people who learn a programming language without learning programming principles. Sure, they can write simple programs that compile, and that even behave as expected. That's great. Everyone has to go through this stage. But you do not want to have to maintain their code.
God knows there are a lot of mediocre system administrators who think they're great. But if they can't even program, any site they design will turn into a nightmare, whether they recognize it or not. I should know. I've made a lot of good money cleaning up after them.
Agreed. You can't just compile and call it an interactive language. Where's the interaction then? Usually it's implemented as both. The compiler produces intermediate code which can be efficiently interpreted.
For sure if you're going to deliver more than one kind if interface they should relate to each other as much as possible.
Under this expanded mandate, let's also compare the programmatic interface to the system with the command and graphical interfaces. I've always been bothered that there isn't a tight relationship between the standard Unix command set and their programmatic equivalents. It's pretty accidental, and that's a shame. As long as the coupling is not rigorous, that means two learning curves as well as two compatibility surfaces to maintain.
I used to ponder this a lot, so
it was very instructive to work with the Symbolics Lisp Machine for a few years. Here we had an environment which was Lisp from the microcode upward. It was a completely fresh start, a chance to do it right. The operating system was very open. And with Lisp being an interpreted language, you'd think it would be dead easy to provide a rich CLI that gave direct access to both the system and the GUI.
Well, no, that's not how it worked out. Part of that is due to our natural fondness for line breaks as command delimiters. Lisp wants things to be delimited by parentheses. But that's not an insurmountable problem. Unfortunately, the Symbolics developers thought it was, and they instead went off and built a CLI that was only vaguely coupled with the corresponding system methods. It was heartbreaking to see such a basic advantage thrown away.
To make matters worse, when the CLI ended up throwing an exception (which was not all that uncommon in such an experimental environment) what you saw on the stack bore little resemblance to the documented system methods. See, most of those were not really methods at all but wrapper macros of one kind or another. So, you'd execute a shell command, which would invoke one of these macros, which would push some undocumented methods on the stack. And since the CLI didn't relate to the system documentation, you'd have to guess where to go to find the documented methods.
It could have been the best. Instead it was kind of the worst. Well, I guess it beat looking at IBM core dumps.
It wouldn't have been so bad if Microsoft had just supplied a generalized configuration parser for application developers to use. Then it could be applied to files, streams, digitally signed blobs, whatever.
But no, they had to build another way to lock you in, didn't they? So you don't get the security controls or network transparency of the file system. You're not reusing the file system, so you have added another source of complexity and another attack surface for security. You don't get composability or scope control where one subsystem can feed live configuration data to another.
And if the Registry breaks, you're kind of hooped. Sure, there's regedit, but it's off to the side, not part of the main paradigm. Mostly it serves to remind you of what you're missing. It's far from common practice to track changes to the Registry in order to monitor how an application has been configured. And that's because the application has not necessarily used the Registry. So tracking it is in general neither necessary nor sufficient.
Actually, I wanted to draw attention to the matter of language in general, not any particular implementation. Whether compiled or interpreted or both, it's the expressive power of the language that is significant to the discussion.
You're right and wrong about the acronym. The term has evolved since the original days. Very few environments which support a CLI today are confined to line interpretation, so for the sake of correctness the term has gradually been replaced with "command language interpreter".
About the only true line interpreter in common use is in Cisco IOS, and that's because it's used for configuration rather than scripting. (Just between us, I don't think the Cisco engineers wanted to give network admins that much rope.)
I'm probably showing my politics here. I prefer the contemporary term "command language interface", because it's expected to support an actual language, one capable of spanning multiple lines of text. Python, Tcl, and even VMS use this term.
You're right that "command line interface" was the original term, and it's still in use, but it really became obsolete 30 years ago.
This seems to be a message doomed to be endlessly repeated. That's because every person who has grown up surrounded by a GUI environment becomes unconsciously resistant to the idea that any alternative that isn't graphical could possibly have distinct advantages.
The distinct advantage of a CLI comes from the L in the acronym. It stands for language, and languages when implemented according to accepted design principles have valuable characteristics like composability and parameterization.
Languages give us the ability to create tangible things which can be named and shared and pointed at and talked about constructively. Thus we become ever more literate. How can we refer to an elaborate series of mouse gestures, except by precisely reconstructing the gestures? All we gain from that is practice in rote memorization.
I have a similar concern about opaque configuration. A system which is based on a configuration language lets you talk about configuration in a tangible way. You can save and copy and restore and manipulate and annotate configuration values.
But what happens if the system stores those values opaquely, so that you can't ever know what they are, or refer to them as something distinct from the system itself?
Let me tell you. What you have then is a maintenance nightmare. And they abound. No two systems behave in quite the same way, and yet nobody can say exactly what makes them different.
Your response seems to conflate two entirely different phenomena, and these go to the very heart of what Lessig was addressing. I think the distinction is especially noteworthy because, to the average Internet user, both appear to be free in exactly the same way. And they're not.
One, as you rightly point out, is that services such as Facebook have to be underwritten somehow. They're commercial ventures, pure and simple. So if they seem to be free, it's only because you haven't found the catch.
The other is the Internet platform which itself makes Facebook possible. Lessig describes it as "open and free", and he doesn't mean apparently free but truly, unconditionally, free. This kind of freedom is possible because it creates greater benefit than hoarding. There is no catch.
"Why would you spend a lot of money trying to build a service in Canada when Canadians take so much without paying for it?" said Graham Henderson, president of the Canadian Recording Industry Association, which represents major record labels.
Somebody please tell Mr. Henderson to take his head out of his ass. The fact, as he well knows, is that Canadians already pay hefty fees. We already pay for recorded music at a rate far in excess of the cost of distribution. Radio stations already pay royalty fees. And everyone already pays a surcharge on recording media and players so that we can be legally entitled to generate copies for personal use.
How did this media surcharge come about? Because Mr. Henderson's own organization, the CRIA, successfully lobbied for it! That's right. They insisted that Canadians must pay a surcharge in order to legally record music. And so we have been doing, ever since the late 1990s.
Mr. Henderson finds this convenient to forget, but the rest of us have not forgotten. Even those of us who do no music copying at all have already paid in full for entitlement to copy.
What makes this study fascinating is that the data support the notion that "white" in fact is a culture. That is, there are statistically significant correlations to this attribute.
Clearly, this is not the culture of populations as we usually understand it. I expect there would be an inverse correlation between "Jewish" and "bacon", for example, which would tend to disappear when this group is classified under white/black/asian/indian/etc.
But still, some of the correlations which do pop out are surprising and funny. To recognize them is to celebrate who we are as a species, in all our weirdness and diversity, and even in our stereotypes of ourselves and each other. I can handle that. Just remember that our interactions with each other are as one individual with another, and that each individual is unique, not the embodiment of a stereotype. I'm sure that my black Jewish gay Republican friends would agree.
Slashdot Mirror
The particular representation of numbers withiin computer systems is not a basis for reasoning about mathematics. Sorry.
My purpose in asking the question is to find out how, specifically, you would define round(r).
It may be trickier than it seems. We have a set of real numbers, and we want to choose the nearest integer. But you claim that the integers are themselves real numbers. So the real number set itself does not provide sufficient information to define the function as "choose the nearest integer". Evidently we have to define the integers through some completely different means, and then claim that there is commonality with the reals. And to me that's not a compelling argument.
It's tempting to say, well, let's subtract the fractional part of r, that is, the part whose absolute value lies in the range [0,1). But clearly that's not a unique construction either.
I'm not saying that there is no satisfactory answer, just that I've never run across it. Add to this the general tendency to treat discrete and continuous domains very differently, and you'll see why I don't just accept the idea because it "intuitively" makes sense. According to my intuition, 1 and 1.0 are two very different things, because they make very different claims. One can be used for counting. The other cannot. So how can one be a subset of the other?
You evidently don't like my notation.
But in fact it's quite common in mathematics to enumerate the first tew elements of a set, and if the set is bounded, to supply the final element. That's what I've done here. The treatment is rigorous, and there should be no confusion of meaning in the context of our present discussion.
There are other uses of this notation. Someone else here was talking about hyperreal numbers, which introduces an interesting and topical subject which is also rigorous.
Speaking of rigorous, when you say that this notation is "completely meaningless", what you should really say is that it's completely meaningless to you.
This is interesting. I've always had misgivings about the notion that countable numbers were a subset of real numbers, given that the real number set is uncountable.
You may know the answer. How can you construct a set of integers from a set of real numbers? For example, given some irrational number r, how would you determine the nearest integer n which approximates it?
No, if it's quantifiable (and that is not a foregone conclusion, since we have no agreed definition of what it means for an atom to "be a part" of your body) the quantity would be expressed in natural numbers, not real numbers.
You're describing Zeno's Paradox.
This appeared as a paradox to the classical Greeks because they had no concept of infinity or limits. Once mathematics introduced those concepts, the paradox disappeared.
Do natural numbers exist in the real world?
Let me put it this way. I just renewed my car insurance. I insured one car. Even if the car has gained mass (as a result of rusting, say, or the addition of accessories) or lost mass, it is only meaningful to regard it as one car for the purposes of insuring it.
Yes, exactly.
The decimal approximation is only equal to 1 in the limit. The equivalence strictly does not work if you make the approximation of finite length.
Generalizing from your example:
x=0.999...9
10x=9.99...0
So how is this different from Cyc?
Remember when you were a kid and you would pretend that the cardboard tube from a roll of paper towels was a telescope? You would look down the tube and see a tiny piece of the world. That's what it's like to compose text using a line editor.
I was once compelled to write a WYSIWYG editor, in the days when all the system provided was a line editor equivalent to ed. I noticed that the work became an order of magnitude faster once I was able to use my editor as a development tool.
The Analytical Engine seems to meet that test. Two other projects also come immediately to mind:
You can't be a good sysadmin without being a reasonably competent programmer.
The ability to think algorithmically is the main quality that distinguishes good system administrators from mediocre ones. People who assert that it's an optional skill are the worst of all, because they don't even know that they don't know!
I see it all the time. The same thing happens with people who learn a programming language without learning programming principles. Sure, they can write simple programs that compile, and that even behave as expected. That's great. Everyone has to go through this stage. But you do not want to have to maintain their code.
God knows there are a lot of mediocre system administrators who think they're great. But if they can't even program, any site they design will turn into a nightmare, whether they recognize it or not. I should know. I've made a lot of good money cleaning up after them.
Agreed. You can't just compile and call it an interactive language. Where's the interaction then? Usually it's implemented as both. The compiler produces intermediate code which can be efficiently interpreted.
For sure if you're going to deliver more than one kind if interface they should relate to each other as much as possible.
Under this expanded mandate, let's also compare the programmatic interface to the system with the command and graphical interfaces. I've always been bothered that there isn't a tight relationship between the standard Unix command set and their programmatic equivalents. It's pretty accidental, and that's a shame. As long as the coupling is not rigorous, that means two learning curves as well as two compatibility surfaces to maintain.
I used to ponder this a lot, so it was very instructive to work with the Symbolics Lisp Machine for a few years. Here we had an environment which was Lisp from the microcode upward. It was a completely fresh start, a chance to do it right. The operating system was very open. And with Lisp being an interpreted language, you'd think it would be dead easy to provide a rich CLI that gave direct access to both the system and the GUI.
Well, no, that's not how it worked out. Part of that is due to our natural fondness for line breaks as command delimiters. Lisp wants things to be delimited by parentheses. But that's not an insurmountable problem. Unfortunately, the Symbolics developers thought it was, and they instead went off and built a CLI that was only vaguely coupled with the corresponding system methods. It was heartbreaking to see such a basic advantage thrown away.
To make matters worse, when the CLI ended up throwing an exception (which was not all that uncommon in such an experimental environment) what you saw on the stack bore little resemblance to the documented system methods. See, most of those were not really methods at all but wrapper macros of one kind or another. So, you'd execute a shell command, which would invoke one of these macros, which would push some undocumented methods on the stack. And since the CLI didn't relate to the system documentation, you'd have to guess where to go to find the documented methods.
It could have been the best. Instead it was kind of the worst. Well, I guess it beat looking at IBM core dumps.
It wouldn't have been so bad if Microsoft had just supplied a generalized configuration parser for application developers to use. Then it could be applied to files, streams, digitally signed blobs, whatever.
But no, they had to build another way to lock you in, didn't they? So you don't get the security controls or network transparency of the file system. You're not reusing the file system, so you have added another source of complexity and another attack surface for security. You don't get composability or scope control where one subsystem can feed live configuration data to another.
And if the Registry breaks, you're kind of hooped. Sure, there's regedit, but it's off to the side, not part of the main paradigm. Mostly it serves to remind you of what you're missing. It's far from common practice to track changes to the Registry in order to monitor how an application has been configured. And that's because the application has not necessarily used the Registry. So tracking it is in general neither necessary nor sufficient.
Ooh. Don't get me going.
Actually, I wanted to draw attention to the matter of language in general, not any particular implementation. Whether compiled or interpreted or both, it's the expressive power of the language that is significant to the discussion.
You're right and wrong about the acronym. The term has evolved since the original days. Very few environments which support a CLI today are confined to line interpretation, so for the sake of correctness the term has gradually been replaced with "command language interpreter".
About the only true line interpreter in common use is in Cisco IOS, and that's because it's used for configuration rather than scripting. (Just between us, I don't think the Cisco engineers wanted to give network admins that much rope.)
I'm probably showing my politics here. I prefer the contemporary term "command language interface", because it's expected to support an actual language, one capable of spanning multiple lines of text. Python, Tcl, and even VMS use this term.
You're right that "command line interface" was the original term, and it's still in use, but it really became obsolete 30 years ago.
This seems to be a message doomed to be endlessly repeated. That's because every person who has grown up surrounded by a GUI environment becomes unconsciously resistant to the idea that any alternative that isn't graphical could possibly have distinct advantages.
The distinct advantage of a CLI comes from the L in the acronym. It stands for language, and languages when implemented according to accepted design principles have valuable characteristics like composability and parameterization.
Languages give us the ability to create tangible things which can be named and shared and pointed at and talked about constructively. Thus we become ever more literate. How can we refer to an elaborate series of mouse gestures, except by precisely reconstructing the gestures? All we gain from that is practice in rote memorization.
I have a similar concern about opaque configuration. A system which is based on a configuration language lets you talk about configuration in a tangible way. You can save and copy and restore and manipulate and annotate configuration values.
But what happens if the system stores those values opaquely, so that you can't ever know what they are, or refer to them as something distinct from the system itself? Let me tell you. What you have then is a maintenance nightmare. And they abound. No two systems behave in quite the same way, and yet nobody can say exactly what makes them different.
Your response seems to conflate two entirely different phenomena, and these go to the very heart of what Lessig was addressing. I think the distinction is especially noteworthy because, to the average Internet user, both appear to be free in exactly the same way. And they're not.
One, as you rightly point out, is that services such as Facebook have to be underwritten somehow. They're commercial ventures, pure and simple. So if they seem to be free, it's only because you haven't found the catch.
The other is the Internet platform which itself makes Facebook possible. Lessig describes it as "open and free", and he doesn't mean apparently free but truly, unconditionally, free. This kind of freedom is possible because it creates greater benefit than hoarding. There is no catch.
"Why would you spend a lot of money trying to build a service in Canada when Canadians take so much without paying for it?" said Graham Henderson, president of the Canadian Recording Industry Association, which represents major record labels.
Somebody please tell Mr. Henderson to take his head out of his ass. The fact, as he well knows, is that Canadians already pay hefty fees. We already pay for recorded music at a rate far in excess of the cost of distribution. Radio stations already pay royalty fees. And everyone already pays a surcharge on recording media and players so that we can be legally entitled to generate copies for personal use.
How did this media surcharge come about? Because Mr. Henderson's own organization, the CRIA, successfully lobbied for it! That's right. They insisted that Canadians must pay a surcharge in order to legally record music. And so we have been doing, ever since the late 1990s.
Mr. Henderson finds this convenient to forget, but the rest of us have not forgotten. Even those of us who do no music copying at all have already paid in full for entitlement to copy.
What part of "Score:5, Funny" do you people not understand?
Water could be extremely toxic to some life forms. You don't want to start out a first encounter on the wrong foot.
Christian: Welcome to Earth. Hey, you want to be baptized?
Alien: Sure!
Christian: Lean way back. Okay, here we go.
Alien: [tszzz]
But it's quite bursty.
Current lawmakers all smoked dope when they were students.
Probably not. But many did.
That doesn't mean that they are all in favor of legalizing marihuana.
Probably not. But many are.
What makes this study fascinating is that the data support the notion that "white" in fact is a culture. That is, there are statistically significant correlations to this attribute.
Clearly, this is not the culture of populations as we usually understand it. I expect there would be an inverse correlation between "Jewish" and "bacon", for example, which would tend to disappear when this group is classified under white/black/asian/indian/etc.
But still, some of the correlations which do pop out are surprising and funny. To recognize them is to celebrate who we are as a species, in all our weirdness and diversity, and even in our stereotypes of ourselves and each other. I can handle that. Just remember that our interactions with each other are as one individual with another, and that each individual is unique, not the embodiment of a stereotype. I'm sure that my black Jewish gay Republican friends would agree.