Some historians believe that this notable discrepancy may well have been behind the famous rant from King Philip II, where he threw his throne at a courtier while screaming "I'll kill those fucking Dutch!"...
"Around October, somebody was just walking around my neighborhood, and they told me they really liked our lights and that it really made the season for them," Hansen said. "If I am the one that triggers the season for somebody, then it really makes it worthwhile."
And this article was posted to Slashdot AFTER that happened, and there is STILL no "Update: Dell actually apologized before we posted this article, 'cause we're dumb."
You're doing them a huge disservice by letting this stand uncorrected, kdawson.
For the 3rd question I'd have difficulty. AFAICS you'd have to use some form of compression to be able to do it (you have to hold 8M characters in 2M RAM - you could convert the phone numbers to 'real' numbers, but that'd still be 4MB in 2MB RAM)
Well, 10**7 -> 10,000,000, and 2 ** 24 -> 16,777,216, so you could hold even the largest 7-digit number in an unsigned 3-byte (24-bit) integer (fitting a million of them into ~2.9 MB), but not the 8-digit numbers mentioned in the parent post.
I'm assuming that we still (a) only have 2MB of RAM to work with, (b) the OS and programs themselves don't live in this region of working RAM, and (c) we don't want to have to figure out how to sort compressed numbers (unless that compression scheme happens to work by virtue of sorted ordering)...
Now, if all these numbers were equally distributed among any given starting digit, then we could have equally-sized regions of memory corresponding to that first digit (and leave it off of the actual integer in memory)... if we were to order them from 9 down to 0, then we'd only have to sort each of these subregions internally, as the regions themselves are already sorted.
Since we have no guarantee about the distribution of the numbers, however, we might start with 10 small regions of memory, each dedicated to a given starting digit, and expand them as necessary (moving any data out of the way as needed).
That'll shave off a digit and bring us down to the aforementioned ~2.9MB, but that's still more than we've got to work with. And, as we don't want to have to keep track of 23-bit integers (or however many digits we're shaving off), let's go to 16 bits. 2 ** 16 -> 65,536, 10 ** 4 -> 10,000. So we've got at least 4 digits to work with (9999), or if we're clever, any 5-digit suffix that's less than 65,536. We'll assume the worst case for now, and say that grants us 2-bytes per 4-digit suffix, but requires us to keep track of the other 4 digits in the form of 65,536 distinct memory regions (which, if the numbers are evenly spaced, would only allow 32 bytes, or 16 4-digit suffixes per region, but if they're evenly spaced, then that's okay).
That allows us to track the million phone numbers in exactly 2 million bytes, or ~1.9 MB, plus 2**16 24-bit integers to point to the addresses of each region (region size can be calculated on the fly by subtracting the address of the next region from the address of the current one), or 196,608 bytes... whoops, we can't have that, as 2 million bytes of data leaves us only 97,152 bytes to work with!
So let's see... if we have (2**16) regions (and we can't usefully force things to be byte-aligned... (2-byte-aligned is possible, but un-useful, as I'm trying my damndest not to have to deal with fractional-byte-length integers!)... well, there are (2**16) regions of memory, with a minimum size of 2 bytes each (henceforth we shall call 2 bytes a WORD). And each region contains a MAXIMUM of (2**16) unique WORDS (assume that we can merge duplicate entries in this sort). So any region would have a maximum address offset of (2**16) WORDS from the previous region.
So we can store the addresses as 16-bit offsets from the previous region (maybe adding 1 to each number, as we want a range of 1-65,536, not 0-65,535, although if we're only using up to 4 digits of each number, it doesn't matter), for 2 * 65,536 bytes -> 131,072 bytes, which is still 33,920 bytes more than we've got!
But wait! If each region had even 257 unique numbers, there would only be ~3,892 regions: So we can store 3,892 * 4 bytes of special pointers (2 bytes to identify the region number, 2 bytes to identify the offset from its predecessor region), and 65,536 bytes of (offset-1) pointers for small regions. Looking up a region's true address involves (1) crawling the special pointers and seeing if the region is mentioned there; if so, grab the offset; if not, (2) look for its (offset - 1) in the small-regions offset array. Rep
Is it the python language that brings you joy or the framework?
Both. Imagine a Venn diagram of (Joyful for Hackers ( ) Smart for Business). Python and Django (IMO) both hit that sweet spot, the rare, tiny sliver where both circles intersect.
If it were just Python by itself, then I'd be using either TG or pylons, but both of those are attempting to be rails (in pylons' case, rails on steroids), which, after becoming much too familiar with rails, is not what I want.
A lot of the things we've been doing in rails made me realize that django would be a much better fit, and is a much better-designed system.
Note that I feel that Django's simple templating system is itself an advantage, as I've had to (a) remove logic from too many views ("templates" in django parlance), and integrate too many html/css designs from our web designers into too many web apps. The django template system (and the fact that it can live elsewhere from the main app) is designed to achieve clear separation of concerns in both these areas.
In the same parking lot is "House of Tokushima", which makes the delicious "Niku-Iri" ramen.
Down the street, before the intersection of Saratoga and Stevens Creek, there is Ramen Halu, which serves (among other things) a delicious regional ramen called (naturally!) Halu Ramen, which contains thicker noodles and a hearty pork broth. (Not everyone likes it, but I think it's delicious, and a great place to go when you're really hungry...)
"3Sharp, the company that authored the Microsoft study, clearly state on their site that their goal in creating 3Sharp was 'to use the robustness, flexibility, and sheer native capabilities of the Microsoft communication and collaboration technologies to enhance the business of our customers.'"
This statement seems to imply that the study might not be impartial.
Other than the fact that these guys get paid by Microsoft on a regular basis to create product demos of MS products, I don't see any conflict of interest.
There is, however, an aspect of Ajax that often seems to get lost in the rush to play with the new browser tricks; Ajax enhanced web applications still need to work closely with server-side components.
Not quite true. You can use an XMLHttpRequest to pull data from any site, if you know where in the document to look. Even if the page returned isn't well-formed XML, you can still screen-scrape, then put the data to use on your page.
"I mean, I of course see the point of removing Jörg Schilling from the equation, but the guys from ark linux have already made a clean fork a few months ago called dvdrtools ( http://www.arklinux.org/projects/dvdrtools ) ( server seems to be down at the moment )."
Oh yeah?
You should see all the wonderful stuff I have when my server is down!;-D
Slashdot Mirror
:-D
He is now accepting callers, he is calling you "dude!"
Keep it. I've got a Pit Bull[tm] Now!
Some historians believe that this notable discrepancy may well have been behind the famous rant from King Philip II, where he threw his throne at a courtier while screaming "I'll kill those fucking Dutch!"...
Steve Ballmer in a past life...
;-)
I don't know that! .... Aaaaiiieeeeeeeeeeeeeeeeeee!!!!!!!!!
No, you misheard: you triggered the seizures!
Can germs get V.D.?
I attempt to disbelieve!
Think older than that.
The phrase "Klaatu Barada Nikto!" was originally from The Day The Earth Stood Still. It was a password spoken to disable the robot Gort.
It's the end of Civilization as we know it!
Dell already apologized: http://direct2dell.com/one2one/archive/2007/06/16/ 18397.aspx
And this article was posted to Slashdot AFTER that happened, and there is STILL no "Update: Dell actually apologized before we posted this article, 'cause we're dumb."
You're doing them a huge disservice by letting this stand uncorrected, kdawson.
Well, 10**7 -> 10,000,000, and 2 ** 24 -> 16,777,216, so you could hold even the largest 7-digit number in an unsigned 3-byte (24-bit) integer (fitting a million of them into ~2.9 MB), but not the 8-digit numbers mentioned in the parent post.
I'm assuming that we still (a) only have 2MB of RAM to work with, (b) the OS and programs themselves don't live in this region of working RAM, and (c) we don't want to have to figure out how to sort compressed numbers (unless that compression scheme happens to work by virtue of sorted ordering)...
Now, if all these numbers were equally distributed among any given starting digit, then we could have equally-sized regions of memory corresponding to that first digit (and leave it off of the actual integer in memory)... if we were to order them from 9 down to 0, then we'd only have to sort each of these subregions internally, as the regions themselves are already sorted.
Since we have no guarantee about the distribution of the numbers, however, we might start with 10 small regions of memory, each dedicated to a given starting digit, and expand them as necessary (moving any data out of the way as needed).
That'll shave off a digit and bring us down to the aforementioned ~2.9MB, but that's still more than we've got to work with. And, as we don't want to have to keep track of 23-bit integers (or however many digits we're shaving off), let's go to 16 bits. 2 ** 16 -> 65,536, 10 ** 4 -> 10,000. So we've got at least 4 digits to work with (9999), or if we're clever, any 5-digit suffix that's less than 65,536. We'll assume the worst case for now, and say that grants us 2-bytes per 4-digit suffix, but requires us to keep track of the other 4 digits in the form of 65,536 distinct memory regions (which, if the numbers are evenly spaced, would only allow 32 bytes, or 16 4-digit suffixes per region, but if they're evenly spaced, then that's okay).
That allows us to track the million phone numbers in exactly 2 million bytes, or ~1.9 MB, plus 2**16 24-bit integers to point to the addresses of each region (region size can be calculated on the fly by subtracting the address of the next region from the address of the current one), or 196,608 bytes... whoops, we can't have that, as 2 million bytes of data leaves us only 97,152 bytes to work with!
So let's see... if we have (2**16) regions (and we can't usefully force things to be byte-aligned... (2-byte-aligned is possible, but un-useful, as I'm trying my damndest not to have to deal with fractional-byte-length integers!)... well, there are (2**16) regions of memory, with a minimum size of 2 bytes each (henceforth we shall call 2 bytes a WORD). And each region contains a MAXIMUM of (2**16) unique WORDS (assume that we can merge duplicate entries in this sort). So any region would have a maximum address offset of (2**16) WORDS from the previous region.
So we can store the addresses as 16-bit offsets from the previous region (maybe adding 1 to each number, as we want a range of 1-65,536, not 0-65,535, although if we're only using up to 4 digits of each number, it doesn't matter), for 2 * 65,536 bytes -> 131,072 bytes, which is still 33,920 bytes more than we've got!
But wait! If each region had even 257 unique numbers, there would only be ~3,892 regions: So we can store 3,892 * 4 bytes of special pointers (2 bytes to identify the region number, 2 bytes to identify the offset from its predecessor region), and 65,536 bytes of (offset-1) pointers for small regions. Looking up a region's true address involves (1) crawling the special pointers and seeing if the region is mentioned there; if so, grab the offset; if not, (2) look for its (offset - 1) in the small-regions offset array. Rep
Not the fruit stand! Please say the fruit is ok!!
Is it the python language that brings you joy or the framework?
Both. Imagine a Venn diagram of (Joyful for Hackers ( ) Smart for Business). Python and Django (IMO) both hit that sweet spot, the rare, tiny sliver where both circles intersect.
If it were just Python by itself, then I'd be using either TG or pylons, but both of those are attempting to be rails (in pylons' case, rails on steroids), which, after becoming much too familiar with rails, is not what I want.
A lot of the things we've been doing in rails made me realize that django would be a much better fit, and is a much better-designed system.
Note that I feel that Django's simple templating system is itself an advantage, as I've had to (a) remove logic from too many views ("templates" in django parlance), and integrate too many html/css designs from our web designers into too many web apps. The django template system (and the fact that it can live elsewhere from the main app) is designed to achieve clear separation of concerns in both these areas.
I code web apps in rails for work. I come home and play in Django. There is my renewed joy...
In the same parking lot is "House of Tokushima", which makes the delicious "Niku-Iri" ramen.
Down the street, before the intersection of Saratoga and Stevens Creek, there is Ramen Halu, which serves (among other things) a delicious regional ramen called (naturally!) Halu Ramen, which contains thicker noodles and a hearty pork broth. (Not everyone likes it, but I think it's delicious, and a great place to go when you're really hungry...)
~o~ Lasers tried to destroy the metal, but the metal was too strong! ~o~
No way!
My sheer native capabilities tell me it ain't so!
> Only build Jewish robots.
;-D
Like Optimus Prime!
Not quite true. You can use an XMLHttpRequest to pull data from any site, if you know where in the document to look. Even if the page returned isn't well-formed XML, you can still screen-scrape, then put the data to use on your page.
"EA's Summer Interns Weigh In ...at 300 pounds"
Well, since there's three of them, that's an average of 100 pounds each. So they're the skinny-type coders, not the hefty ones...
Or that could be their wages as interns, in which case it's not slave labor, it's slave labour.... o.O
"I mean, I of course see the point of removing Jörg Schilling from the equation, but the guys from ark linux have already made a clean fork a few months ago called dvdrtools ( http://www.arklinux.org/projects/dvdrtools ) ( server seems to be down at the moment )."
;-D
Oh yeah?
You should see all the wonderful stuff I have when my server is down!
I don't think the "beat-down" is a valid rhetorical device... ;-)