Creation of new domains is like extortion. For example, Disney will have to pay for disney.fun, disney.kids, disney.parks, disney.film, etc. just to make sure that those don't turn into porn sites or worse.
If you create an infinite supply of domain names with "disney" in them, their price naturally falls to 0. Disney would be unable to buy all domain names with "disney" in them, but squatters would be no more able to sell them or get paid for them, because it becomes a club anybody can join at any time. If you have disney.fun, disney.kids, disney.parks and disney.film, I can go and register disney.joy, disney.children, disney.resorts, disney.movies, disney.mickey, disney.niños, disney.parques, disney.fun-for-all-the-family, etc.
Disney would potentially need to pursue domain name registrations that violate its trademarks, but they already have to pursue such violations in non-domain-name cases anyway.
If you ask me, the TLD free-for-all idea can be pretty good. The TLD system was valuable in the early days of the net, before indexes and search engines, but it doesn't really add much value to the Internet anymore. If I can find any site I want through a search engine or internet directory site, then domain names can be anything whatsoever.
Yeah, I know this isn't the most serious thread around, but actually, serious answers to this question are interesting. So here goes: the very best archival medium for photos and videos is probably slide film. One of the big advantages of this particular analog medium is that it's easy to "read" the images even with your own eyes.
For all we know, somebody 80 years from now who stumbles upon one of our hard disks may have a hard time figuring out how to read the data and how to display it.
Analog has other advantages, even if the medium is not as self-evidently pictorial as slide film: analog can degrade more gracefully. A few bad bits in a critical section of some digital data can make it impossible to interpret the whole file. In an analog medium, that is less likely.
The biggest problem with their methodology isn't the sample size (though I would indeed bet their sample size for Google is too small). The biggest problems are that (a) the sample population is self-selected, and therefore, not random, and meaningfully unrepresentative; (b) the possibility that their respondents misreport their salaries and benefits.
Sampling error depends primarily on the absolute size of the sample, not its size relative to the population. This is the reason why you can often use a sample size in the dozens to test a hypothesis about a population of millions; e.g., if you're testing the male/female ratio of a population where the actual (unknown to you beforehand) is 49/51, the probability that a truly random sample of 100 will turn out with 90 males and 10 females is, very roughly, the same as the probability of flipping a fair coin 100 times and getting heads 90 times. Therefore, if your sample truly is random, you really are almost certain to get a decent estimate for the whole population.
With the surveys we're talking about, however, you have reason to disbelieve the results even if the sample size is large. To continue the analogy, if you selected the sample for your male/female experiment by responses to flyers in men's restrooms and nowhere else, then well, you might get an unrepresentative sample.
How much of that is social? I would think how a girl grows up is very different from how a boy grows up. If a boy joins boy scouts, goes hunting with dad, etc then he'll see a map as something with directions and distances. If a girl doesnt get these experiences, she may never see a map until she learns how to drive and at that point has internalized her surroundings by using landmarks.
It gets worse:
If the differences are really due to social upbringing, then you expect to find cultures where the men also navigate by landmarks. And guess what? It's actually extremely common. The American customs of using road maps to navigate and of labeling road direction with compass points are just that, customs.
It's not clear that there's a real difference between navigating with "procedural methods" and "spatial reasoning." A lot of people navigate "spatially" in terms of cardinal points are actually doing a procedural, landmark approach. E.g., in the Silly Valley, people judge what's "north" and "south" not by looking at the position of the sun, but rather, by the direction of El Camino and 101 (the two main roads).
1) ISPs are simply oversubscribing betting on people not using the bandwidth they are paying for.
Yeah, sure. Just like insurance companies overcharge you for insurance betting that most people won't have an accident, right?
Unless everybody really is using their full subscribed bandwidth 24/7, the most efficient IP network must be "oversubscribed" at every point. If we build a truckload of bandwidth, and discover that it's not actually being used, well, guess what, all we did is just waste a lot of money.
The Court's majority opinion is quite clear about this. The Nazi prisoners were not under the jurisdiction of the USA; they were under the joint jurisdiction of the Allied powers, which were temporary military occupiers in Germany, an independent state whose sovereignty was not contested, and which had a functioning government and courts. These prisoners were also provided with legal counsel and the opportunity to answer the charges against them in adversarial legal proceedings/
The Guantanamo prisoners are under the sole jurisdiction of the USA; the USA has full jurisdiction over Guantanamo Bay, which has no courts or authorities other than the USA military. The prisoners haven't had anything resembling legal proceedings against them; they're being held while the government investigates and decides whether to press charges. The prisoners also aren't provided with proper legal counsel--only with "advisors" that aren't bound to things like client-attorney privilege. The prisoners lack the ability to confront witnesses, and so on.
The "declaration of war" bits are irrelevant. In fact, the language of Court's opinion doesn't seriously pursue any denial that the US is engaged in a war against terrorism. (They do point out that if this is a war, it's one of the longest in the nation's history.) The whole point is that the government's power over people under its jurisdiction is not absolute, whether they are citizens or not, or whether they're being held in a state of the union or in an overseas military base that's de facto ruled by the USA and nobody else.
What this decision does is to make the Constitution follow the flag. This may be the death knell for rulings arising from the Insular Cases, especially Downes v. Bidwell.
Um, no. The decision reaffirms the Insular Cases.
The Insular Cases, as I certainly do hope that you know, do not say in simple terms that "the Constitution follows the flag." They say that not all of the provisions of the Constitution follow the flag. There are still constitutional constraints on the government's exercise of its jurisdiction over unincorporated territories.
For example, even though Puerto Rico, Guam and the US Virgin Islands are not an incorporated territories of the United States, Congress may not pass laws that deny them First Amendment rights to freedom of speech, freedom of the press, and so on, because those rights must extend to unincorporated territories. On the other hand, the SCOTUS has held that the constitutional right to a trial by one's peers does not extend to Puerto Rico, whose traditional civil law system does not provide for it.
The present ruling is firmly in this mold. The Court is saying, once again, that there are constitutional limitations on the government's power over unincorporated territory under its jurisdiction.
Classyfing Pluto as a Plutoid is not silly. Classifying Jupiter as a gas giant is not silly. Classying Mars as a telluric planet is not silly, either. This is exactly what you pointed out when you said that classifications were useful to catalog objects orbiting other stars.
You and GP are begging the question. Yes, classifications are "useful" to catalog objects orbiting other stars. But, what is the use of cataloguing objects orbiting stars, in the first place? What does it tell us? Does the classification of an object predict any properties of it that beyond those that were required to successfully classify it?
Two subpoints here:
You're committing a very common philosophical error, that I'll call ontological essentialism: the belief that there exists such a thing as a context-independent "correct" classification of things according to a given scheme. This error is leading you to think that there really must be a truth of the matter as to whether Pluto, as a thing in itself, is a "planet" or not.
The response to this is that classifications aren't properties of things in themselves, but rather, are context- and purpose-dependent distinctions that people impose on them.
Astronomy is a natural science. Natural science is concerned with making predictions. The most natural use of classifications in natural science is, therefore, as a predictive apparatus: a classification has predictive value if, when you observe the properties of an object required to classify it correctly, you can use the classification to predict further properties that you did not observe.
I've not seen anybody come even close to doing this for "planet." Once you observe all the things you need to observe to decide whether a celestial body is a planet or not, you're not in a position to predict anything else about the object.
This doesn't mean that scientists can't use non-predictive classifications for genuinely useful means; non-predictive classifications can be quite useful for communicating with other people (if somebody says "planet," it may not allow you to predict a lot about the object, but it helps you guess what the other person may be talking about). But usually, those classifications don't really need to be very precise.
In any science, it pays to be skeptical about the validity of received vocabulary and classifications. I like the way one of my professors puts it: when faced with terms like "planet," it is often valuable to step back and, instead of seeing them as the names for distinct kinds of things, to see them as the names of distinct kinds of problems that the people who came up with the term were trying to solve.
In this case, the problem is pretty simple. The ancients charted the movements of the lights in the night sky, and were concerned with formulating laws to explain their motion. The problem you hit right away when you start doing this is that a handful of those lights move in a manner that's very different from the vast majority of the others. Those weird, "wandering" ones are the so-called "planets," in the original sense. This goes back to point (1): the classification of some celestial objects as "planets" responds to the purpose of formulating and solving this problem.
Guess what? We're not the ancients. We don't have their problems in explaining the motion of those things. We have super-powerful telescopes that show us all sorts of funny rocks in space that they could never hope to see, moving in all sorts of weird trajectories. We have a theory of Newtonian mechanics that explains their trajectories as a specific case of more general laws, without having to formulate laws of weird-space-rock-motion. Why are we keen at all to try to get a precise fit between what we see and their vocabulary? The reason we have problems with deciding whether something like Eris is a "planet" is because we know a lot more than the ancients did. Insisting too eagerly on the classification just demonstrates a failure to appreciate how very different and superior our understanding is.
No, definitions of planets are important if you're looking for them elsewhere and wish to classify the objects you find orbiting other stars.
Your whole response is begging the question. Why would we need to classify the objects we find orbiting other stars into "planets" and non-"planets"?
The really big background assumption here is that "planet" is a natural kind. The real lesson from all the IAU Pluto reclassification nonsense should be that, actually, astronomy has shown "planet" not to be a natural kind.
Back in ancient times, when "planet" meant "light in the sky that moves in a very different kind of path from the other ones," and terrestial mechanics and astronomy were different sciences with different laws, there might have been a good case for calling "planet" a natural kind. Since Newton's time, however, we don't have separate laws for celestial and terrestrial motion. Newtonian mechanics allows for infinitely many intermediate cases between whatever paradigm examples of "planet" and "non-planet" you wish to pick, and will never draw a line between them.
Implicit type conversion is problematic, yes, but dynamic typing doesn't entail implicit conversion. Those are orthogonal design choices.
Implicit type conversion is when a language performs a type conversion in a context that would otherwise result in a type mismatch error. For example, in C, there are implicit conversions between numeric types; if you add an int to a long, the int gets implicitly converted to a long. In Java, there is an implicit conversion from objects to strings in the context of the string append operation; if you append a string to an object, using the '+' operator, the language implicitly converts your object to a string using the toString() method.
Those both are statically typed languages, so you see, this just further shows that dynamic typing isn't the problem. A dynamic language can refuse to perform implicit type conversions just as much as a statically typed one.
The problem with type conversions that you're talking about, doesn't have to do with dynamic vs. static typing; it's about execution of arbitrary code at runtime based on input values. Many implicit type conversions make it easier to exploit such programs. It's irrelevant whether the code with the malicious stuff injected is given to an interpreter or compiler, or whether the generated code's language is static or dynamic. If you allow the attacker to execute arbitrary code, the attacker takes over.
There's two types of color we're talking about here. There's the surface property of the objects if viewed in equal light, like the color of paint that was used to paint the squares or its reflectivity. Then there's the appearance of the object based on its current actual lighting conditions. I'll call these "absolute" and "shadowed" for want of better terms, hoping you'll understand.
There is absolutely no problem with our eyes perceiving both somethings absolute color and its shaded color. If you saw two objects of the same absolute shade, but one was in shadow, you would easily be able to see both that the objects were the same absolute color, while also perceiving the one in shadow to be darker.
I do not agree with the last statement there, because I'm not convinced that the "shadowed" color is a perceptual datum. Certainly there are people, e.g. painters, who through training and practice, learn to judge what the "shadowed" shades are in what they see. It does requires training and practice, which suggests that it's a skill, not perception. (Though it would be interesting to work through the argument that skills can change perception.)
Heh, that's what I thought at first as well (oh look, doubling speed every release, they must still be at the bottom of the curve) - but then how is it that they're essentially in the lead now? Or are you saying *all* previous js interpreters have been bad?
I don't know anything about Javascript interpreters in particular, but as a general rule, interpreters for any sort of "scripting" or "dynamic" languages tend to be pretty simplistic and weak. There are a lot of techniques for making language implementations run faster, but they almost always get applied to systems that emphasize compilation.
Even when people implement dynamic languages by compiling to bytecode, they tend to write very simple VMs where the operations are at a fairly high level, and are all costly to execute. The "compilers" tend to do very simple and quick translations to bytecode, without much optimization, because when compilation happens at runtime, you want to minimize compilation time. The bytecode VMs also usually do very little to optimize bytecode; there's hardly ever any type or data flow analysis of bytecode, bytecode-to-bytecode transformations, etc.
Nearly every interpreter out there could be made a lot faster without a lot of work.
How do you know so definitively the point of vision which I think is itself a shaky concept evolutionarily speaking since it is emergent.
That's a fair point. I was definitely sloppy about that, in the interest of advancing other parts of the argument.
When I say "the point of vision," I don't mean that nature is teleological. "The point of vision" is the set of functional assumptions that the researchers make, and guide their investigation. My argument is that by accepting the idea that people's "failure" to judge the squares as "the same color" constitutes an illusion, one thereby makes a bad assumption about visual perception (and about perception): that perception's function is to give us information about the light rays that hit the retina, instead of the things that reflected those rays to our retina.
I think your statements make a lot of sense, but I don't see how they are contradictory with the article or how they missed any big point. In fact, it seems to me that your "purpose" of vision fits quite well with their basic idea of "perception is only a representation of reality."
I'm not a representationalist, so I'm certainly disposed against that statement. In this one case, however, I'm not engaging in a general argument against representationalism, as much as attacking a specific representationalist analysis of the supposed "illusion."
By 3D "surface", I did not mean the surface of a table or a car, but the entire table or car itself, as a 3D "projection" on, for example, a 4D hyperplane.
Let me try it this way: perception is about acquiring information about the environment of an organism. The environment isn't just a 3D surface (in the mathematical sense you're using) that the organism sees; it's a world that the organism inhabits. The organism moves around the environment and interacts with its features and objects with its limbs, etc.
What makes the perception of 3D depth in a 2D drawing an illusion is the fact that it affords you the visual appearance of depth, without affording the organism movement in along three independent axes. The 3D "illusion" of a 3D "surface" that you attributed to vision of real world scenes, on the other hand, does afford movement in three axes. This is precisely the reason it's not illusory: it is fully part of the world that vision, coordinated with the other senses and the organism's possibilities of action, affords the organism.
According to physics of relativity, "insideness vs outsideness" is an illusion of consciousness.
I don't think physicists have very much to tell us about psychology or philosophy. What they think is not completely irrelevant, but it is not imbued with the authority you pretend it should.
Reality is a continuous field. i.e. If we were in a simulation you wouldn't know it. There is no object "out there" per se, all your mind is doing is discretizing a continuous surface of data that you percieve or have access to into chunked-objects that don't really exist. i.e. a tree is not seperate from the earth, which ultimately is not seperate from space, which is ultimately not seperate from the sun, all of these things are continuously connected in ways we don't fully understand.
Your problem is that your claim to know this is self-defeating. In order to "know" all this, you have to rely on your knowledge of a real world that you inhabit and interact with, with everyday objects at everyday scales.
A more philosophical way of putting it: there are two main, related problems with what you're saying here:
You're giving metaphysical status to the theories of contemporary physics. The "real" world is whatever physics says the world is; therefore, everything that physics leaves out (like everyday experience) must be "illusory."
You're granting metaphysics priority over epistemology. You want us to accept that physics gives us true knowledge of what is "real" and what is "illusory." However, the knowledge that physics offers us is the result of the interactions of people in an everyday world making predictions about what they will experience when they manipulate that everyday world in sophisticated ways. Knowledge of physical theories presupposes participation in the everyday world; therefore physical theories cannot tell us what is "real" and what is "illusory" in the metaphysical sense. You can only rescue that line of thought by assuming that knowledge itself is illusory (which I wouldn't be surprised if you do).
Needless to say, I don't think physics gives us a metaphysics, and I don't think metaphysical problems have a priority over epistemological ones.
I don't think they're missing that; I bet they'd agree with what you're saying. You just seem to disagree with their terminology (e.g. "illusion").
No, it's not just a disagreement about terminology. It's a disagreement about what the object of vision is. I take it we all agree that what vision does is to give us information about the environment. The disagreement is about assumptions about what that information is. Is it information about the rays of light that hit the retina, or about the surfaces that reflect or emit those rays of light?
Note that, in fact, the term "illusion" is not at all under dispute. I'm sure I'm going to agree with the folks who wrote that drivel about what it means for something to be an optical illusion: it's a case where the visual system gives you incorrect information about the object of vision. But this entails precisely that different assumptions about what the object of vision is will yield different conclusions about what is an illusion and what is not.
Also, what is the difference between seeing 3D in a 2D surface and seeing 3D in a 3D "surface"?
That in the former case, you're wrong about the object of vision. The object of vision is extended across three dimensions in the former case, but only in two in the latter. Real 3D scenes afford possibilities of action and motion that illusory ones do not. Try and see how far you can go grasping the cylinder in the fake 3D scene.
It's a fact of neuroscience that everything we experience is actually a figment of our imagination. Although our sensations feel accurate and truthful, they do not necessarily reproduce the physical reality of the outside world. Although our sensations feel accurate and truthful, they do not necessarily reproduce the physical reality of the outside world.
The whole philosophy of perception that this quote embodies is fundamentally wrong. As an example of this, take a look at the first so-called "illusion" in the slideshow: the Edward Adelson checkerboard-and-shadon example. This is called an "illusion" on the basis that our eyesight "misleads us" by telling us that a light square in the shadow is lighter than a dark one in the light, whereas they are, supposedly, "the same color." By "the same color," what they seem to mean is that the stimulus, i.e., the rays of light reflected or emitted from the squares that hit our retina, have the same spectrum and intensity.
What they're missing is that the point of vision, and perception in general, isn't to give us information about the rays of light that hit the retina. What vision does is give us information about the objects in our environment, which reflect or emit rays of light. The reason we see the two squares as having different colors, despite the fact that our retinas are getting the exact same pointwise stimulus from them, is because the visual system, using contextual information about light and shadow across the whole scene, can figure out that the surface spectral reflectivity of the two squares must be different. Square B looks lighter than square A because the visual system judges, correctly, that it must reflect more light. Or put alternatively: the visual system figures out that if the two squares were in the same light, the point stimulus from the reflected light rays would be different.
This is accurately reproducing an aspect of the physical reality of the outside world; vision is accurately reproducing the spectral reflectivity of surfaces in our environment, at the apparent expense of failing to reproduce the spectral distribution of the rays of light that hit our retina. But of course, the answer to that one is that the rays of light aren't the object of visual perception, they're just the means.
Seeing the squares as different colors is not an illusion. There is only one visual illusion in that example, and they don't remark on it: the illusion of seeing, in a flat surface, a 3D scene with light and shadow. The judgement that the two squares have different colors follows from that, because in the real-world scene the image depicts, those squares would in fact be surfaces with different colors when seen under the same light.
You don't seem to be very clear on the differences between strong vs. weak type systems, and static vs. dynamic types.
Python is strongly typed. In every place where a Python program can have a type error, the result is defined: some sort of exception is raised immediately, and can be handled regularly through the exception handling system, or to propagate uncaught and kill your program immediately and in a clean fashion.
C is weakly typed. Many kinds of type error can happen at runtime that will leave your program in an undefined state, which may continue indefinitely. E.g., you can do pointer arithmetic and read data from random locations in memory, and interpret it as any type you want instead of what it's supposed to be.
Python is a dynamically typed language. A valid Python program may not contain enough information to infer the type of the values that are assigned to its variables at runtime; or, in other words, any variable may be assigned any value of any type, values in Python must be tagged with their types at runtime, and Python runtime systems need to check the types of arguments at runtime are compatible with the types of the operations applied to them.
C is a statically typed language. The C compiler must be able to determine, at compilation time, the type of every variable, and every expression must type-check for a program to be valid. The way C ensures this is by requiring type declarations on every variable and function. However, that's not essential; languages like OCaml and Haskell are smart enough to infer the types of most of your variables and functions without declarations.
Now, having said all that, let's quote you:
Python assumes you know what the hell you're doing, so it won't throw errors if you create two variables, put an Int in each one, and do an Int operation on them, all without declaring a type...It'll figure out the type by context.
The main problem with this statement here is that you're not specifying what you mean by "context" here. There are two kinds of context that could be relevant: (a) compilation context; (b) runtime context. As it turns out, Python (because of dynamic typing) is allowed to use (b) to figure out the type. However, a language like OCaml can also "figure out the type by context," in the very different sense that it can analyze the program well enough at compilation to figure out that the variables are bound to ints, without your telling it. (And to make it more complicated: an implementation of a dynamically typed language is not required to check types at runtime in every case. A technique used by optimizing compilers for dynamically typed languages is to perform incomplete type inference on programs, figure out the types of variables as best as possible, and use this information to remove runtime type checks where the compiler can prove that they will always succeed. See this blog post for examples of people who've tried to do this for Python in various ways.)
However, if you try to multiply an Int by a String, it'll throw the same type errors any other strongly type language will. They call it "duck typing."
The phrase "multiply an Int by a String" turns out to be ambiguous. Most of the people who responded to you thought about it in terms of syntax: "foo" * 7. The thing is that Python overloads the * operator, and dispatches it to different concrete operations, depending on the type of the arguments. What Python does do is, when applying a concrete operation, throw the type errors.
But also, that is not what the term "duck typing" means. Read your own link. What you're mentioning is just plain old dynamic typing--raise a type error at runtime when the tagged type of the arguments does not match the type required by the operation.
"it's difficult to explain but these functional-language primitives are extraordinarily powerful, providing a kind of "zeroth dimension" of data manipulation."
It's not that difficult to explain. One way to do it is to explain them in terms of common looping patterns in imperative programs. One very common type of loop is the following (in pseudo-code):
result:= init_value for ( item in list ) { result:= operation(item,result) } return result
This loop pattern, with different choices of init_value and operation, is common to all sorts of code that work with lists, arrays or other types of sequences. For example, with init_value = 0 and operation = add, that's code for summing the elements of the list; with 1 and times, it's product of the elements of the list; with init_value = "" and operation = string_append, it's concatenation of a list of strings.
Well, that kind of loop is exactly what reduce is. Instead of writing the same damn loop over and over with minor variations of init_value and operation, you just pass the init_value and operation as arguments to a prewritten loop.
Map and filter are no less difficult; they correspond to different patterns of loops.
Eliminating pervasive null pointer exceptions is a trivial language design problem. It's as simple as this: (a) a variable of type Foo is never allowed to be null; (b) if somebody needs a nullable variable that may point to a Foo, then that variable must be declared with a different type: nullable Foo; (c) provide type conversions between plain and nullable types. It's trivial for the compiler to reject programs where a plain Foo variable can ever be assigned null. After you have that property, you have a compile-time guarantee that NPEs can only happen when converting from a nullable Foo to a plain Foo.
The key to understanding that code is to understand the <tt>reduce</tt> function. How many times have you written loops that look like this?
define do_thing_to_list(list) { result:= init_value for ( value in list ) { result:= operation(value, result) } return result }
I think it's a really safe bet that you write loops like that all the time. Well, reduce is just a higher-order function that abstracts that exact pattern. To sum a list of numbers, you just reduce over it with addition as the operation, and 0 as the init_value. To get the product of a list of numbers, same thing, but with multiplication and one. To concatenate a list of strings, you reduce it with the string append function and the empty list. The pattern is pervasive, and abstracting it makes code easier to understand.
GP's example is deliberately obfuscated, because in good code you just don't use reduce to do character-per-character I/O where the string of characters to output is expressed as a constant list of integers offsets that tell you how to calculate each character's ASCII code as an offset of the previous one. That is just an obfuscated way of printing a constant string.
Slashdot Mirror
Isn't that more or less what they always say when they come up with some new-fangled language?
If you create an infinite supply of domain names with "disney" in them, their price naturally falls to 0. Disney would be unable to buy all domain names with "disney" in them, but squatters would be no more able to sell them or get paid for them, because it becomes a club anybody can join at any time. If you have disney.fun, disney.kids, disney.parks and disney.film, I can go and register disney.joy, disney.children, disney.resorts, disney.movies, disney.mickey, disney.niños, disney.parques, disney.fun-for-all-the-family, etc.
Disney would potentially need to pursue domain name registrations that violate its trademarks, but they already have to pursue such violations in non-domain-name cases anyway.
If you ask me, the TLD free-for-all idea can be pretty good. The TLD system was valuable in the early days of the net, before indexes and search engines, but it doesn't really add much value to the Internet anymore. If I can find any site I want through a search engine or internet directory site, then domain names can be anything whatsoever.
Yeah, I know this isn't the most serious thread around, but actually, serious answers to this question are interesting. So here goes: the very best archival medium for photos and videos is probably slide film. One of the big advantages of this particular analog medium is that it's easy to "read" the images even with your own eyes.
For all we know, somebody 80 years from now who stumbles upon one of our hard disks may have a hard time figuring out how to read the data and how to display it.
Analog has other advantages, even if the medium is not as self-evidently pictorial as slide film: analog can degrade more gracefully. A few bad bits in a critical section of some digital data can make it impossible to interpret the whole file. In an analog medium, that is less likely.
Printing video to film is a really good idea if one is interested in longevity, actually. Film studios do it.
The biggest problem with their methodology isn't the sample size (though I would indeed bet their sample size for Google is too small). The biggest problems are that (a) the sample population is self-selected, and therefore, not random, and meaningfully unrepresentative; (b) the possibility that their respondents misreport their salaries and benefits.
Sampling error depends primarily on the absolute size of the sample, not its size relative to the population. This is the reason why you can often use a sample size in the dozens to test a hypothesis about a population of millions; e.g., if you're testing the male/female ratio of a population where the actual (unknown to you beforehand) is 49/51, the probability that a truly random sample of 100 will turn out with 90 males and 10 females is, very roughly, the same as the probability of flipping a fair coin 100 times and getting heads 90 times. Therefore, if your sample truly is random, you really are almost certain to get a decent estimate for the whole population.
With the surveys we're talking about, however, you have reason to disbelieve the results even if the sample size is large. To continue the analogy, if you selected the sample for your male/female experiment by responses to flyers in men's restrooms and nowhere else, then well, you might get an unrepresentative sample.
It gets worse:
Yeah, sure. Just like insurance companies overcharge you for insurance betting that most people won't have an accident, right?
Unless everybody really is using their full subscribed bandwidth 24/7, the most efficient IP network must be "oversubscribed" at every point. If we build a truckload of bandwidth, and discover that it's not actually being used, well, guess what, all we did is just waste a lot of money.
The Court's majority opinion is quite clear about this. The Nazi prisoners were not under the jurisdiction of the USA; they were under the joint jurisdiction of the Allied powers, which were temporary military occupiers in Germany, an independent state whose sovereignty was not contested, and which had a functioning government and courts. These prisoners were also provided with legal counsel and the opportunity to answer the charges against them in adversarial legal proceedings/
The Guantanamo prisoners are under the sole jurisdiction of the USA; the USA has full jurisdiction over Guantanamo Bay, which has no courts or authorities other than the USA military. The prisoners haven't had anything resembling legal proceedings against them; they're being held while the government investigates and decides whether to press charges. The prisoners also aren't provided with proper legal counsel--only with "advisors" that aren't bound to things like client-attorney privilege. The prisoners lack the ability to confront witnesses, and so on.
The "declaration of war" bits are irrelevant. In fact, the language of Court's opinion doesn't seriously pursue any denial that the US is engaged in a war against terrorism. (They do point out that if this is a war, it's one of the longest in the nation's history.) The whole point is that the government's power over people under its jurisdiction is not absolute, whether they are citizens or not, or whether they're being held in a state of the union or in an overseas military base that's de facto ruled by the USA and nobody else.
Um, no. The decision reaffirms the Insular Cases.
The Insular Cases, as I certainly do hope that you know, do not say in simple terms that "the Constitution follows the flag." They say that not all of the provisions of the Constitution follow the flag. There are still constitutional constraints on the government's exercise of its jurisdiction over unincorporated territories.
For example, even though Puerto Rico, Guam and the US Virgin Islands are not an incorporated territories of the United States, Congress may not pass laws that deny them First Amendment rights to freedom of speech, freedom of the press, and so on, because those rights must extend to unincorporated territories. On the other hand, the SCOTUS has held that the constitutional right to a trial by one's peers does not extend to Puerto Rico, whose traditional civil law system does not provide for it.
The present ruling is firmly in this mold. The Court is saying, once again, that there are constitutional limitations on the government's power over unincorporated territory under its jurisdiction.
You and GP are begging the question. Yes, classifications are "useful" to catalog objects orbiting other stars. But, what is the use of cataloguing objects orbiting stars, in the first place? What does it tell us? Does the classification of an object predict any properties of it that beyond those that were required to successfully classify it?
Two subpoints here:
The response to this is that classifications aren't properties of things in themselves, but rather, are context- and purpose-dependent distinctions that people impose on them.
I've not seen anybody come even close to doing this for "planet." Once you observe all the things you need to observe to decide whether a celestial body is a planet or not, you're not in a position to predict anything else about the object.
This doesn't mean that scientists can't use non-predictive classifications for genuinely useful means; non-predictive classifications can be quite useful for communicating with other people (if somebody says "planet," it may not allow you to predict a lot about the object, but it helps you guess what the other person may be talking about). But usually, those classifications don't really need to be very precise.
In this case, the problem is pretty simple. The ancients charted the movements of the lights in the night sky, and were concerned with formulating laws to explain their motion. The problem you hit right away when you start doing this is that a handful of those lights move in a manner that's very different from the vast majority of the others. Those weird, "wandering" ones are the so-called "planets," in the original sense. This goes back to point (1): the classification of some celestial objects as "planets" responds to the purpose of formulating and solving this problem.
Guess what? We're not the ancients. We don't have their problems in explaining the motion of those things. We have super-powerful telescopes that show us all sorts of funny rocks in space that they could never hope to see, moving in all sorts of weird trajectories. We have a theory of Newtonian mechanics that explains their trajectories as a specific case of more general laws, without having to formulate laws of weird-space-rock-motion. Why are we keen at all to try to get a precise fit between what we see and their vocabulary? The reason we have problems with deciding whether something like Eris is a "planet" is because we know a lot more than the ancients did. Insisting too eagerly on the classification just demonstrates a failure to appreciate how very different and superior our understanding is.
Your whole response is begging the question. Why would we need to classify the objects we find orbiting other stars into "planets" and non-"planets"?
The really big background assumption here is that "planet" is a natural kind. The real lesson from all the IAU Pluto reclassification nonsense should be that, actually, astronomy has shown "planet" not to be a natural kind.
Back in ancient times, when "planet" meant "light in the sky that moves in a very different kind of path from the other ones," and terrestial mechanics and astronomy were different sciences with different laws, there might have been a good case for calling "planet" a natural kind. Since Newton's time, however, we don't have separate laws for celestial and terrestrial motion. Newtonian mechanics allows for infinitely many intermediate cases between whatever paradigm examples of "planet" and "non-planet" you wish to pick, and will never draw a line between them.
Actually, all scientific hypotheses are unfalsifiable blobs. All that tells us is that falsifiability is a bad demarcation criterion for science.
Implicit type conversion is problematic, yes, but dynamic typing doesn't entail implicit conversion. Those are orthogonal design choices.
Implicit type conversion is when a language performs a type conversion in a context that would otherwise result in a type mismatch error. For example, in C, there are implicit conversions between numeric types; if you add an int to a long, the int gets implicitly converted to a long. In Java, there is an implicit conversion from objects to strings in the context of the string append operation; if you append a string to an object, using the '+' operator, the language implicitly converts your object to a string using the toString() method.
Those both are statically typed languages, so you see, this just further shows that dynamic typing isn't the problem. A dynamic language can refuse to perform implicit type conversions just as much as a statically typed one.
The problem with type conversions that you're talking about, doesn't have to do with dynamic vs. static typing; it's about execution of arbitrary code at runtime based on input values. Many implicit type conversions make it easier to exploit such programs. It's irrelevant whether the code with the malicious stuff injected is given to an interpreter or compiler, or whether the generated code's language is static or dynamic. If you allow the attacker to execute arbitrary code, the attacker takes over.
I might forgive you if you realize how you just demonstrated how useless such definitions actually are when it comes to increasing our knowledge.
I do not agree with the last statement there, because I'm not convinced that the "shadowed" color is a perceptual datum. Certainly there are people, e.g. painters, who through training and practice, learn to judge what the "shadowed" shades are in what they see. It does requires training and practice, which suggests that it's a skill, not perception. (Though it would be interesting to work through the argument that skills can change perception.)
I don't know anything about Javascript interpreters in particular, but as a general rule, interpreters for any sort of "scripting" or "dynamic" languages tend to be pretty simplistic and weak. There are a lot of techniques for making language implementations run faster, but they almost always get applied to systems that emphasize compilation.
Even when people implement dynamic languages by compiling to bytecode, they tend to write very simple VMs where the operations are at a fairly high level, and are all costly to execute. The "compilers" tend to do very simple and quick translations to bytecode, without much optimization, because when compilation happens at runtime, you want to minimize compilation time. The bytecode VMs also usually do very little to optimize bytecode; there's hardly ever any type or data flow analysis of bytecode, bytecode-to-bytecode transformations, etc.
Nearly every interpreter out there could be made a lot faster without a lot of work.
That's a fair point. I was definitely sloppy about that, in the interest of advancing other parts of the argument.
When I say "the point of vision," I don't mean that nature is teleological. "The point of vision" is the set of functional assumptions that the researchers make, and guide their investigation. My argument is that by accepting the idea that people's "failure" to judge the squares as "the same color" constitutes an illusion, one thereby makes a bad assumption about visual perception (and about perception): that perception's function is to give us information about the light rays that hit the retina, instead of the things that reflected those rays to our retina.
Let me try it this way: perception is about acquiring information about the environment of an organism. The environment isn't just a 3D surface (in the mathematical sense you're using) that the organism sees; it's a world that the organism inhabits. The organism moves around the environment and interacts with its features and objects with its limbs, etc.
What makes the perception of 3D depth in a 2D drawing an illusion is the fact that it affords you the visual appearance of depth, without affording the organism movement in along three independent axes. The 3D "illusion" of a 3D "surface" that you attributed to vision of real world scenes, on the other hand, does afford movement in three axes. This is precisely the reason it's not illusory: it is fully part of the world that vision, coordinated with the other senses and the organism's possibilities of action, affords the organism.
I don't think physicists have very much to tell us about psychology or philosophy. What they think is not completely irrelevant, but it is not imbued with the authority you pretend it should.
Your problem is that your claim to know this is self-defeating. In order to "know" all this, you have to rely on your knowledge of a real world that you inhabit and interact with, with everyday objects at everyday scales.
A more philosophical way of putting it: there are two main, related problems with what you're saying here:
Needless to say, I don't think physics gives us a metaphysics, and I don't think metaphysical problems have a priority over epistemological ones.
No, it's not just a disagreement about terminology. It's a disagreement about what the object of vision is. I take it we all agree that what vision does is to give us information about the environment. The disagreement is about assumptions about what that information is. Is it information about the rays of light that hit the retina, or about the surfaces that reflect or emit those rays of light?
Note that, in fact, the term "illusion" is not at all under dispute. I'm sure I'm going to agree with the folks who wrote that drivel about what it means for something to be an optical illusion: it's a case where the visual system gives you incorrect information about the object of vision. But this entails precisely that different assumptions about what the object of vision is will yield different conclusions about what is an illusion and what is not.
That in the former case, you're wrong about the object of vision. The object of vision is extended across three dimensions in the former case, but only in two in the latter. Real 3D scenes afford possibilities of action and motion that illusory ones do not. Try and see how far you can go grasping the cylinder in the fake 3D scene.
Quoting from the slide show link:
The whole philosophy of perception that this quote embodies is fundamentally wrong. As an example of this, take a look at the first so-called "illusion" in the slideshow: the Edward Adelson checkerboard-and-shadon example. This is called an "illusion" on the basis that our eyesight "misleads us" by telling us that a light square in the shadow is lighter than a dark one in the light, whereas they are, supposedly, "the same color." By "the same color," what they seem to mean is that the stimulus, i.e., the rays of light reflected or emitted from the squares that hit our retina, have the same spectrum and intensity.
What they're missing is that the point of vision, and perception in general, isn't to give us information about the rays of light that hit the retina. What vision does is give us information about the objects in our environment, which reflect or emit rays of light. The reason we see the two squares as having different colors, despite the fact that our retinas are getting the exact same pointwise stimulus from them, is because the visual system, using contextual information about light and shadow across the whole scene, can figure out that the surface spectral reflectivity of the two squares must be different. Square B looks lighter than square A because the visual system judges, correctly, that it must reflect more light. Or put alternatively: the visual system figures out that if the two squares were in the same light, the point stimulus from the reflected light rays would be different.
This is accurately reproducing an aspect of the physical reality of the outside world; vision is accurately reproducing the spectral reflectivity of surfaces in our environment, at the apparent expense of failing to reproduce the spectral distribution of the rays of light that hit our retina. But of course, the answer to that one is that the rays of light aren't the object of visual perception, they're just the means.
Seeing the squares as different colors is not an illusion. There is only one visual illusion in that example, and they don't remark on it: the illusion of seeing, in a flat surface, a 3D scene with light and shadow. The judgement that the two squares have different colors follows from that, because in the real-world scene the image depicts, those squares would in fact be surfaces with different colors when seen under the same light.
You don't seem to be very clear on the differences between strong vs. weak type systems, and static vs. dynamic types.
Python is strongly typed. In every place where a Python program can have a type error, the result is defined: some sort of exception is raised immediately, and can be handled regularly through the exception handling system, or to propagate uncaught and kill your program immediately and in a clean fashion.
C is weakly typed. Many kinds of type error can happen at runtime that will leave your program in an undefined state, which may continue indefinitely. E.g., you can do pointer arithmetic and read data from random locations in memory, and interpret it as any type you want instead of what it's supposed to be.
Python is a dynamically typed language. A valid Python program may not contain enough information to infer the type of the values that are assigned to its variables at runtime; or, in other words, any variable may be assigned any value of any type, values in Python must be tagged with their types at runtime, and Python runtime systems need to check the types of arguments at runtime are compatible with the types of the operations applied to them.
C is a statically typed language. The C compiler must be able to determine, at compilation time, the type of every variable, and every expression must type-check for a program to be valid. The way C ensures this is by requiring type declarations on every variable and function. However, that's not essential; languages like OCaml and Haskell are smart enough to infer the types of most of your variables and functions without declarations.
Now, having said all that, let's quote you:
The main problem with this statement here is that you're not specifying what you mean by "context" here. There are two kinds of context that could be relevant: (a) compilation context; (b) runtime context. As it turns out, Python (because of dynamic typing) is allowed to use (b) to figure out the type. However, a language like OCaml can also "figure out the type by context," in the very different sense that it can analyze the program well enough at compilation to figure out that the variables are bound to ints, without your telling it. (And to make it more complicated: an implementation of a dynamically typed language is not required to check types at runtime in every case. A technique used by optimizing compilers for dynamically typed languages is to perform incomplete type inference on programs, figure out the types of variables as best as possible, and use this information to remove runtime type checks where the compiler can prove that they will always succeed. See this blog post for examples of people who've tried to do this for Python in various ways.)
The phrase "multiply an Int by a String" turns out to be ambiguous. Most of the people who responded to you thought about it in terms of syntax: "foo" * 7. The thing is that Python overloads the * operator, and dispatches it to different concrete operations, depending on the type of the arguments. What Python does do is, when applying a concrete operation, throw the type errors.
But also, that is not what the term "duck typing" means. Read your own link. What you're mentioning is just plain old dynamic typing--raise a type error at runtime when the tagged type of the arguments does not match the type required by the operation.
"it's difficult to explain but these functional-language primitives are extraordinarily powerful, providing a kind of "zeroth dimension" of data manipulation."
:= init_value := operation(item,result)
It's not that difficult to explain. One way to do it is to explain them in terms of common looping patterns in imperative programs. One very common type of loop is the following (in pseudo-code):
result
for ( item in list ) {
result
}
return result
This loop pattern, with different choices of init_value and operation, is common to all sorts of code that work with lists, arrays or other types of sequences. For example, with init_value = 0 and operation = add, that's code for summing the elements of the list; with 1 and times, it's product of the elements of the list; with init_value = "" and operation = string_append, it's concatenation of a list of strings.
Well, that kind of loop is exactly what reduce is. Instead of writing the same damn loop over and over with minor variations of init_value and operation, you just pass the init_value and operation as arguments to a prewritten loop.
Map and filter are no less difficult; they correspond to different patterns of loops.
Eliminating pervasive null pointer exceptions is a trivial language design problem. It's as simple as this: (a) a variable of type Foo is never allowed to be null; (b) if somebody needs a nullable variable that may point to a Foo, then that variable must be declared with a different type: nullable Foo; (c) provide type conversions between plain and nullable types. It's trivial for the compiler to reject programs where a plain Foo variable can ever be assigned null. After you have that property, you have a compile-time guarantee that NPEs can only happen when converting from a nullable Foo to a plain Foo.
The key to understanding that code is to understand the <tt>reduce</tt> function. How many times have you written loops that look like this?
:= init_value := operation(value, result)
define do_thing_to_list(list) {
result
for ( value in list ) {
result
}
return result
}
I think it's a really safe bet that you write loops like that all the time. Well, reduce is just a higher-order function that abstracts that exact pattern. To sum a list of numbers, you just reduce over it with addition as the operation, and 0 as the init_value. To get the product of a list of numbers, same thing, but with multiplication and one. To concatenate a list of strings, you reduce it with the string append function and the empty list. The pattern is pervasive, and abstracting it makes code easier to understand.
GP's example is deliberately obfuscated, because in good code you just don't use reduce to do character-per-character I/O where the string of characters to output is expressed as a constant list of integers offsets that tell you how to calculate each character's ASCII code as an offset of the previous one. That is just an obfuscated way of printing a constant string.