The zeal of federal courts which, unlike those in 33 US states, refuse to recognise the media's right not to reveal its sources, even threatens journalists whose investigations have no connection at all with terrorism.
I would just like to burn a few karma to say that is the most disjointed, stream-of-consciousness summary I have seen in some time. There's one tiny little terse sentence announding the existence of the new search functionality, and somehow it manages do do so without even what kind of "code" we're talking about. Then the rants begin. The remainder of the paragraph has an average of one parenthetical remark per sentence, including two in a single sentence; and fully two-thirds of the rant is complaining about the lack of Cobol, of all things.
Phew, I feel better.
There are lots of definitions of the word "law", such as #12 here:
a. A statement describing a relationship observed to be invariable between or among phenomena for all cases in which the specified conditions are met: the law of gravity.
b. A generalization based on consistent experience or results: the law of supply and demand.
Ok that explains why it's reasonable to go 5 years between computer purchases. But the GP said it was unreasonable to wait 5 years because of this announcement.
You seem to think the chances of winning a particular lottery are less than the chances of a neutron star pulling away the Earth during that lottery. I think what is meant is that the chances of winning a particular lottery with a particular ticket are less than the chances of a newtron star ever pulling away the Earth, but I could be mistaken.
I think the bookkeeping is a good way to deal with cache hierarchies. If you have a large amount of slow memory, and a small amount of fast memory, it makes sense to keep tons of rarely-used "just in case" bookkeeping data if it lets you make the hot code tighter and more efficient. For instance, instead of, say, an 80 KB working set in a statically-compiled program, you can have a 50 KB working set plus 200 KB of "just in case" crud. The latter program will perform much better on a machine with 1 GB of ram and a 64 KB L1 icache.
It seems fundamentally impossible to make a language like Python or Ruby fast. By their very nature everything has to be done at the last minute, based on string comparisons, and you can't do global optimizations really because at any moment the program might change itself and invalidate them.
We have this issue with Java too. I work on a the JIT compiler for one of the industry-leading Java implementations, and we have ways to register assumptions such that if they are ever violated, the jitted code is patched so it remains correct under the new conditions. That lets us be optimistic, assuming that the program won't take advantage of much of Java's dynamic nature, and those assumptions are (by design) usually correct.
I imagine a similar approach would help Python. For instance, in your example of a "fallback method", if you're really desperate, an early compile of the caller method could instument the call site and see what actual methods are usually dispatched there. On a subsequent compile, it could generate a PIC (polymorphic inline cache) that uses a class test and dispatches the target method (or inlines it), plus a registered assumption that nobody changes the target method for those classes. If they do (which is rare), the corresponding PIC slot would be invalidated. The fallback case in the PIC would do the full-blown string-based dispatch, and usually this slow path should be very rare.
Apparently you didn't read beyond the second sentence in my post, so let me fast-forward to the important bit:
It's silly to define a word like "planet" in terms of what it's not. There will always be new things we discover out there that we don't want to call "planets" and so we'll have to keep updating the definition. Instead, the IAU made an effort to define what a planet is.
...followed by the second most important bit:
If we don't use the terms defined by specialists in the field, what should we use?
I wonder if people realize that the "lowest common denominator" of two fractions is always 1? This phrase is an intermingling of "greatest common denominator" and "lowest common multiple".
Slashdot Mirror
ERROR: Stack overflow
They live off one of the products of nuclear decay.
Not 13 sq ft. It's a 13-foot plot. The depth isn't specified.
You're mistaken. Just try to start marketing "Coca-Cola" brand running shoes and see how far you get.
Ok, is Gaddafi a good guy or a bad guy?
I would just like to burn a few karma to say that is the most disjointed, stream-of-consciousness summary I have seen in some time. There's one tiny little terse sentence announding the existence of the new search functionality, and somehow it manages do do so without even what kind of "code" we're talking about. Then the rants begin. The remainder of the paragraph has an average of one parenthetical remark per sentence, including two in a single sentence; and fully two-thirds of the rant is complaining about the lack of Cobol, of all things.
Phew, I feel better.
Man walks on fucking moon.
Ok that explains why it's reasonable to go 5 years between computer purchases. But the GP said it was unreasonable to wait 5 years because of this announcement.
en tee
Charge the actual amount that you'd be willing to do it for. If you weren't willing to do it for 5x then you should have asked for more.
Slahdot is the fur coat.
You seem to think the chances of winning a particular lottery are less than the chances of a neutron star pulling away the Earth during that lottery. I think what is meant is that the chances of winning a particular lottery with a particular ticket are less than the chances of a newtron star ever pulling away the Earth, but I could be mistaken.
NOT having the receipt proves you didn't vote for the supposed kneecap-breaking thugs in question.
Can someone explain the joke for the humourously challenged?
I think the bookkeeping is a good way to deal with cache hierarchies. If you have a large amount of slow memory, and a small amount of fast memory, it makes sense to keep tons of rarely-used "just in case" bookkeeping data if it lets you make the hot code tighter and more efficient. For instance, instead of, say, an 80 KB working set in a statically-compiled program, you can have a 50 KB working set plus 200 KB of "just in case" crud. The latter program will perform much better on a machine with 1 GB of ram and a 64 KB L1 icache.
We have this issue with Java too. I work on a the JIT compiler for one of the industry-leading Java implementations, and we have ways to register assumptions such that if they are ever violated, the jitted code is patched so it remains correct under the new conditions. That lets us be optimistic, assuming that the program won't take advantage of much of Java's dynamic nature, and those assumptions are (by design) usually correct.
I imagine a similar approach would help Python. For instance, in your example of a "fallback method", if you're really desperate, an early compile of the caller method could instument the call site and see what actual methods are usually dispatched there. On a subsequent compile, it could generate a PIC (polymorphic inline cache) that uses a class test and dispatches the target method (or inlines it), plus a registered assumption that nobody changes the target method for those classes. If they do (which is rare), the corresponding PIC slot would be invalidated. The fallback case in the PIC would do the full-blown string-based dispatch, and usually this slow path should be very rare.
Do you still use the software that came with it? I find it clunky and awkward to use, and occasionally buggy.
Is there a more recent version of the software I can download somewhere? I've lost track of the company web site.
Please turn in your nerd badge on your way out.
4% return on investment in ONE DAY doesn't even compare with 10% return PER YEAR.
I wonder if people realize that the "lowest common denominator" of two fractions is always 1? This phrase is an intermingling of "greatest common denominator" and "lowest common multiple".