The main reason they are using the buckets is to delay sorting costs as far as possible into the future so that there is less cost for most timers (as most timers are apparently deleted far before expiring). I'd suggest that the major performance gain is due to this lazy sorting, and not because their data structure avoids page faults. (Well, it does avoid page faults that the old linked list algorithm would have caused, but these page faults are due to the sorting going on in the original code which is avoided in the second. If timers did not expire, the two approaches would be quite similar, both generating page faults when sorting the linked lists, which likely have bad locality, and neither being as good as an IO-efficient algorithm.)
Using timer wheels as a heap structure wouldn't be appropriate unless many of the objects placed in the heap are removed prior to making it to the top of the heap. If this is not the case the sorting of the items from one bucket to the next bucket (sorting a linked list) would cause many page faults if the list didn't fit in internal memory. Timer wheels do nothing to address data locality which is the main problem faced by extremely large heaps. Your mention of in-order access is only true if the lists at each bucket as indeed stored sequentially in memory. This is hard to guarantee unless that space is reserved ahead of time or some dynamic reallocation scheme is used. I read the linked article as implying that simple linked lists were used, which generally have very bad data locality. Even if if a linear list was guaranteed, however, the sorting step when pushing things from one bucket down to the next bucket would incur page faults (assuming the list was too big to fit in memory) unless an I/O-efficient or cache-oblivious sort were used. (Which could easily be done, making an IO-efficient timer wheel structure.)
The algorithm discussed in the article is for a general purpose heap. In most heaps the main cost is in removing elements from the root of the heap as they bubble up through it, rather than deleting them prematurely (as is the case with timers). Different approaches for fundamentally different problems.
Not quite true... a 3-sphere is actually the *surface* of a 4-dimensional sphere. So, not exactly something that lives in our world. In topology, the dimensions refer to the dimensionality of the surface, and not the space the surface lives in (ie: a circle drawn on a piece of paper is a 1-sphere, but the surface it was drawn on is 2-dimensional).
I've been curious regarding this... assuming we could pluck them out in the same order from each 'vat', is there any way to generate two giant vats of stored entangled photons? One stays on the earth, the other travels with the ship. Photons are measured according to some kind of predetermined low-bandwidth schedule, which allows sending of little messages. These little messages could then trigger large high-bandwidth messages. The photons have thus been entangled as long as the ship has been traveling, but the message is still 'instantaneous' as far as the earth and the ship are concerned. Is bending the rules of faster-than-light information travel like this possible?
Why do things at a level of granularity of 100,000 lines? Why not get the quantum computer to do the 'repeat x times and pick the most common answer' at each instruction? It'll introduce exactly the same slow down factor, and vastly reduce the chance of error propagation.
Conventional computers already have a certain amount of error that creeps in. Suppose during a single tick of the clock cycle there is some chance P of an error occurring. Find the 'repetition factor' n such that the quantum computer guarantees you no more than the same amount of error P, and you've got a quantum computer that gives you exact answers (over arbitrarily long programs) with the same chance of error as a conventional computer having run the same number of arguments. It becomes more an issue of speed, rather than errors.
Having to repeat each fundamental step some large number of times slows down the computer. (To get 1/10^40 chance of error, repeat the calculation ~400 times given any individual calculation has a 21% chance of failure.) However, this will disappear as the underlying hardware is improved, which it invariably will be (given more years of development time, I'm sure errors will be reduced from 21% to far below 1%).
Many real world problems are already built around this notion, whereby we only know the answer to be correct with a high degree of confidence (see 'Monte Carlo algorithms'). The underlying process only needs to be correct more often than it's wrong (it could be 50% + epsilon versus 50% - epsilon) and we can just keep repeating the calculation until we get any arbitrary accuracy we wish.
No, it's actually a perfectly reasonable idea. Consider running the device (n+m) times. The probability of it being right n times and wrong m times is given by:
P(n,m) = (n+m)!/n!/m! 0.79^n 0.21^m
Now consider the probability of it being right (majority has the right answer) out of 2n+1 trials. This is the given by:
S(n) = sum( P(n+1+i,n-i), i=0..n )
This can be simplied to a closed form using Legendre and gamma functions, but that's kind of messy and it's far easier to just plug in values and do the summation. As it turns out, doing the experiment 15 times and taking the majority (plugging 7 into S(n)) will give you the correct answer 99.4% of the time. Doing things 35 times gets you to five nines of accuracy... completely reasonable in my books.
Assuming you've got a reasonably modern version of X, and a somewhat capable video card, then xrandr does exactly what you're looking for. Mind you, it's a command-line application, but it's definitely not hard to use. A frequent Ubuntu contributor made a nice little GTK GUI front-end to it called urandr. This does exactly what you want (configure per-output rotation, resolution, etc). The only caveat is that you need to have configured X to have a big enough virtual screen size (x.org, Screen section, Display subsection, Virtual keyword) to support any anticipated output resolutions (combined size of the entire desktop across all outputs).
In my aviation experience, if you are ever interrupted in a checklist, or unsure of where you are for some reason, then you restart the from the beginning. This forces you to be conscious of the checklist as you run through it, instead of working completely off of a muscle memory and running through the entire thing in a haze.
Not that this behaviour is entirely bad, in fact it's even sometimes desirable. It's exactly the reason why emergency checklists should be so thoroughly memorized: in a high stress situation where you may not have the time to think very deeply about your response, your muscle memory takes over and still gets everything in the checklist done.
PPM and context based algorithms generally have fairly similar compress and decompress times as well as similar resource usage. The algorithms work by keeping a huge table of statistics based on text already seen (and maybe some initial statistics based on some external corpus) and using that to come up with a table of probabilities as to what the compressor thinks the likelihood is of the next 'symbol' being any of its possible values. This table of probabilities is then used to encode the symbol using an arithmetic encoder. To decode the same symbol, the arithmetic decoder needs to be in the exact same state as the encoder was. So, the same table's must have been generated in the same manner, using the same resources. Also, arithmetic encoding is pretty much symmetric, so there is no real speed gain there. As such, I imagine the algorithm requires a fairly lengthy decompress time as well.
Matt Mahoney lists compression time, decompression time and memory usage (as well as other statistics) for the best Wikipedia compressors: http://www.cs.fit.edu/~mmahoney/compression/text.h tml. A brief look shows that most PPM and CM based algorithms are quite symmetric in performance.
Assymetric compression algorithms are ones that tend to spend a configurable amount of time looking for patterns in the data. The compressed stream ends up being an encoding of the pattern, and the decompressor simply grabs data according to the pattern and outputs it, which is quite fast. Think LZ based algorithms that spend a lot of time looking for string matches, and deciding the optimal way to output them. Or video encoding that spends a lot of time calculating how the scene has moved (how blocks in one frame are related spatially to those in another).
First question: You've got 2 marbles, so the best you can do involves 2 * (sqrt(100)-1) possible tests. If you had n marbles, you could do O(n100^(1/n)). So, using the first marble, drop if from the 10th, 20th, 30th, etc floors until it breaks. Say it breaks at the 30th. With the second, start testing the 21st, 22nd, etc. At most you will require 18 tests and only the two marbles. (I'm assuming the marbles maintain their integrity after repeated drops.)
Second question: Use an external memory sorting algorithm, of which the best reqires O(N/Blog[M/B](N/B)) IOs (M is the size of the internal memory, B is the size of a 'block' or single sector on the disk, N is the problem size). The last decade has seen the development of an entirely separate model of computation which counts disk accesses rather than clock cycles. All old problems are new again as algorithms are found that solve them optimally in this new paradigm. Certain problems (like sorting) have been solved so that they are simultaneously optimal from an IO and a clock cycle point of view. IO efficient sorting generally uses a merge sort. So, for this problem you would sort 2M of data at a time, and then merge as many of these chunks together as you could simultaneously (using the largest heap that would fit in the 2M, in this case you could easily merge all 50 sorted subchunks), then repeat. There's actually another model of computation called the 'cache oblivious model' which aims to build algorithms that are IO efficient across every level in the cache hierarchy of a modern computer (disk, disk cache, L2 cache, L1 cache). Again, there exists a sorting algorithm that is cache oblivious called a funnel sort. It also uses merge sorts, but the size of the merger at each level varies. Interesting stuff... (disclaimer, I am doing my PhD research on IO efficient and cache oblivious graph and computational geometry algorithms).
Third question: (I'm assuming that should read "You are NOT allowed to send any data before all the numbers have been sorted") There are 10^8 possible unique phone numbers. You could imagine using a large bit table to keep track of which values have been seen but this would require ~12MB of memory when we only have two. You could imagine 'run length' encoding such a table, where strings like '0000...1' are encoded as the number of preceding zeroes. Worst case scenario we could have up to 10^8-10^6 leading zeroes, requiring 27 bits to represent. So, we could encode the table using 3.2MB of memory. This is still too big. Go another level deep and use a variable length code to encode the run lengths. The worst case is still a 27 bit run length, so we'll require 5 bits to represent the number of bits required to represent the run length, followed by that number of bits actually encoding the length. Worst case scenario pushes all of the run lengths to the same size, in which case they are 10^8/10^6 = 100 bits long. This requires log[2](100) = 7 + 5 = 12 bits per encoded phone number, or 1.43MB of RAM. So, this'll fit, but its still pretty tight. This was just to see how hard it is to fit the data into the available space; while it does highlight a possible algorithmic approach its likely not going to be too efficient. Likely, using a radix tree over the phone numbers represented as 32 bit sequences (4 bits per digit) would be the best approach, although you'd have to be extremely frugal with your data structure to ensure it fits.
As other have already pointed out, this a very common technique. It is slowly being adopted as a standard in the VoIP and P2P world (Google Voice uses it, for one). RFC 3489 discusses this very technique, and defines a protocol to be spoken to the central server that is brokering the connection. For a good overview, you could check out the Wikipedia article. There is also a simple, cross-platform and open-source library available that implements the server and client side techniques, making it very easy to integrate this technique into other projects. Nonetheless, the article makes for a nice and simple description of the technique.
I'm not so sure about the usage for dogs, but I would totally use this on a motorcycle. They're so easy to steal that it would be a great thing to have some sort of relatively cheap and reliable tracking device installed. All they need is the ability to easily enable/disable the virtual perimeter (ie: disable it when you're riding, re-enable it when the bike is parked), and it'd be a great system!
(I'm speaking from experience of having had a new bike stolen, and having that terrible empty feeling in your gut realizing that there's nothing you can do about it. I eventually got it back, 2 weeks later, completely wrecked, found lying in 3 feet of water in a ditch!)
An easier solution is to just write something on the client side. Something that maybe scrapes all of the feeds, uses intelligent parsers to group together all of the dupes (and ignore entire season releases, etc), and then uses some selection criteria to grab the best quality (video quality, number of seeders, etc) torrent out of a pool of dupes. Match that with simple filter syntax (no need to use RegExps... series titles are 'normalized' behind the scenes, and matched that way), and you have a quick and easy poor man's TiVo.
Even better, it works with any RSS feed, and can scape some popular torrent sites as well. It then gives you a simple interface to browse it's generated database, and see what's out there. It can be launched and left running in the background and will just merrily go about doing it's job. Inspired by another project out there called TvTad, but fixing many shortcomings.
It's called FetchTv and it's written in Ruby, and when I get off my lazy arse I'll put it on SourceForge. In the meantime, if anybody's interested, let me know and I'll share it. (I warn people: it's fully functional, but not necessarily user friendly at this point)
I've found another (from June) article here (in french). For a long time people have been talking about ammonia as hydrogen storage, as it's quite high in energy density and is a relatively safe liquid. However, there are issues with gas expansion, pressurization and toxic fumes.
Essentially, these pellets are an ammonia storage system that stores ammonia nearly as efficiently (by weight and volume) as liquid ammonia. The above article says that they are relatively cheap to produce (initial costs of 1 euro/kilogram of material, which translates to roughly $12.88 USD for the energy equivalent of a gallon of gasoline). The article clearly states that the process is reversible, thus the base materials must be reusable. It does not state what the cost is of 'recharging' the pellets. The recharge cost would have to be at least 4x cheaper than production in order for it to be competitive with gasoline. The extraction technique is listed as 'desorption', which I imagine just means heating the pellets up and siphoning the extracted gas off. As for temperatures, and desorption rates, nothing is cited.
It doesn't state specifically how the reaction runs, but that ammonia is extracted from the pellets, which is then run through a standard ammonia converter (at temperatures of around 350 degrees celsius) to extract the hydrogen. It says the reaction runs quickly, so it's able to provide the hydrogen quickly enough.
The Amminex website has slightly more information available by clicking on the "ammonia storage" page, because it's the exact same technology as the hydrogen storage (link here)
And myself as well. And as for the cheque clearing thing, there's a little piece of legislature that was passed to make cheques more convenient. Essentially, banks can only hold cheques for so long before they have to let the funds clear (if they have no reason to believe it will bounce). Meanwhile, the cheque continues to take it's time to clear, and finally will bounce. This will happen a few days after you get the money.
Or, the other situation is that the cheques are forged as coming from a large commercial account. When the cheque is 'cleared', the bank system replies 'yes, there are sufficient funds in this account'. However, when the bank physically receives the forged cheque and gets around to looking at it (often not until the end of the month), THEN they will say it bounced, and go back to your bank for the money. This can take weeks potentially (in my case it took 2 weeks for them to get back to me).
The stupid thing is the banks are allowed to get away with this, and there is NO recourse.
Myself, I took action. I spent a few weeks tinkering with Yahoo Mail until I found an exploitable flaw. I then started tracking backwards (sending fake login screens via email) through all of the accounts until I got to the central account. This account was a personal active account, used for various purposes. By monitoring this account for a while I eventually got the guys full real name, his girlfriends name, the addresses and names of his family back in Nigeria, his address in London, the name and address of the place he worked, the school he went to and student number, a copy of his resume, and even his application number for a US greend card. However, no law enforcement agency (specifically Canadian or British) will do anything with the information, as it was 'ill gotten'. I wish there was something to do to chase the bastard down but I doubt it'll ever happen.
Another poster had mentioned that they are identical to stock Barton's, but more expensive. In my experience they've only been about $10-$15 more expensive (I've got an XP-M 2500+), and well worth the price to guarantee that you've got a 'cream of the crop' processor. Heck, in the article they only quote a $0.50 price difference!
Not only are they good for overclocking, but they're good for the opposite use too. Everybody complains about loud computers; why not get one of these mobile processors instead? I was able to run at normal clock speeds with an old (and quiet) HSF from an AMD 1.0GHz and still see temperatures below 40 degrees Celsius. Mine runs in a home-theater PC so top on my list was quiet, cool, and able to run in a small case (ie: with constrained fan dimensions). And it's done just that, while at the same time providing plenty of horsepower for real-time HDTV quality MPEG2 decoding, etc.
They do payments through PayPal, so you don't have to feel like you're giving private info to some dubious Russian folks. It's pretty easy to verify that you're truly at a real PayPal site, and not some fake front, so with a little caution you can feel secure in who you're dealing with.
IMHO, the best online store out there is www.allofmp3.com. This company is Russian based, and because of their somewhat lax copyright laws and much more lenient recording industry, they offer non-encumbered downloads at cheap prices. Basically, the site is pay-for-bandwidth. If you download a song at 128kbps MP3, you essentially pay a penny per minute of audio.
The other awesome thing about that site is the ability to selecte your download format from WMA, MP3, OGG, FLAC, etc, plus the particular quality settings. For most downloads the audio is converted on the fly from a high quality archive (~400kbps), and for others it is actually converted directly from the CD-DA source. In "Advanced Mode", it's almost equivalent to selecting your command-line switches for the transcoder of your choice!
I'm in no way affiliated with these guys, but I love their service. It's actually faster and more reliable for me to download music from these guys than it is to try and venture out onto the P2P networks. Heck, for quality 7 OGG music, I'm paying roughly $0.02 CAD/minute. Plus, they let you pay with PayPal, so it's not like your sending your credit card info to some random Russians.
It doesn't have to be that way. There could be a 'secret' shared between the server and the client doing the knocking. This 'secret' could then be used to 'sign' (any strong cryptographic hash) some command, which is then translated into a knock sequence. In this manner, knocks can be authenticated. You'd want to 'salt' the knock as well, so that no two knock sequences would likely be the same. This could be done by using some combination of the source IP/port and date (probably not time, too many synchronization issues there). The knock, when decoded on the server end, could poke a hole in the firewall for the knocking IP only.
Another way of producing 'salt' to make the knock signatures unique would be to keep a knock-server (a low risk app, IMO) running on a single port. Before knocking, the client would query the knock-server and get some 'salt'. This could then be used as above. I think there are still some possible attacks, but I'm sure with more thought a secure system could be devised.
In this manner, it most definitely WOULD be another layer of actual security, and not just obscurity (only knowledge of the shared 'secret' would allow successful knocking).
Not a house, but rather...
on
Cube House
·
· Score: 2, Interesting
...a submarine. I work as a reserve officer and spend several weeks every summer at a nearby air force base. This summer, a few guys in my office took it upon themselves to turn another office-mates cube into a submarine like environment. Using nothing but card-board and duct tape, they enclosed the cube from floor to ceiling. At the cube entrance they left a fully functioning hatch-style door complete with wheel. They then proceeded to decorate the outside to look like steel and rivets (not quite as much effort as your cube-house though).
The 3-click rule is actually based on a little math, and doesn't just come from nowhere. The question is this: given a finite number of leaves (end destinations), how should a menu be arranged to minimize the average amount of time required to access any leaf? The assumptions are that each 'menu' (level of the tree) takes the same amount of time to read/load/listen to, and that each final menu choice is equi-probable. Under these conditions, continuous optimization shows that a tree with exp(1) = 2.718... branches per node is optimal. Thus, the choice of 3 options per menu level is usually chosen.
Again, this rule is based on some fairly strict assumptions, and realistically, an optimal menu layout (in terms of minimizing clicks) may conflict with a logical menu layout (in terms of hierarchichal ordering).
Wouldn't this be trivial to implement? Imagine a very simple (closed) system consisting of cell phones on a standard digital network. You and a friend could decide to share a 'key' (which you manually type in to your phones, and associate with the other persons number). When you dial each other, your phones (recognizing which phone, by it's number, is on the other end), automatically applies some private-key non-expansive encryption algorithm to the compressed audio.
I have no idea of the data format or protocols involved in cellular communications, but assuming the phones were on the same network and spoke the same algorithm, then you could easily have encrypted calls from any two handsets.
Heck, this may even be possible through a simple cell-phone firmware upgrade, and nothing else. And I'm sure there are people out there who have reverse engineered the firmware on some cell phones (just like most handheld electronic devices out there).
Anybody with a little more knowledge know if something like this is possible?
Not only is the tZero a sporty little electric car with amazing acceleration, it can also achieve reasonable mileage and range using their hybrid range extended trailer. There are links in the AC Propulsion white papers section regarding the range extending trailer. Also, a link to a PDF
With this thing attached the car it gets a combined 40 MPG (highway driving at 100kph/60mph) and a range of around 380 miles. Not bad for a sports car. Another cool feature of the trailer is that it has a linked steering system; it's not a freewheeling trailer, rather the trailer wheels move with the car steering. This makes things like backing up (parallel parking and the like) much easier for those without experience towing a trailer.
asdfasdfasdfasdf said: The flipside is that the DirecTivos are more difficult to hack, and I don't think there's any easy way to Hack the HDVR2 (latest and 'greatest')
Not necessarily true. In fact, the DirecTiVos are just as easy to hack as the stand-alone TiVos, and most of the hacking work on the two types of boxes overlaps.
The TiVo hacking community is quite strong, and things have come a long way. If you haven't checked things out recently, then you owe it to yourself to do so. There are lots of cool hacks out there:
FTP or HTTP extraction of MPEG2 video
FTP or HTTP insertion of MPEG2 video
complete and useable WUI
sharing recordings between boxes
on screen caller display
on screen email/instant message notification
much more...
My favorite resource are the forums over at DealDatabase (http://www.dealdatabase.com/forum/). You'll find lots of info and links on hacking your TiVo (new or old, DirecTV or standalone). Oh, and the Series2 TiVo's have been thoroughly hacked as well.
asdfasdfasdfasdf said: The DirecTV Tivos copy the satellite stream including Dolby digital as they come off the Sat-- so they are as "perfect" as the source-- which means for hi-bitrate channels like HBO, it's not DVD quality, but it's better than any cable I've seen.
The DirecTiVo saves video at 480x480, standard 29.97 fps, with some channels coming in at 720x480. This is less then HDTV at its best (1920x1080), roughly the same quality as DVD (720x480), better than standard broadcast (~460x360), and much better than VHS (~300x360).
Slashdot Mirror
The main reason they are using the buckets is to delay sorting costs as far as possible into the future so that there is less cost for most timers (as most timers are apparently deleted far before expiring). I'd suggest that the major performance gain is due to this lazy sorting, and not because their data structure avoids page faults. (Well, it does avoid page faults that the old linked list algorithm would have caused, but these page faults are due to the sorting going on in the original code which is avoided in the second. If timers did not expire, the two approaches would be quite similar, both generating page faults when sorting the linked lists, which likely have bad locality, and neither being as good as an IO-efficient algorithm.)
Using timer wheels as a heap structure wouldn't be appropriate unless many of the objects placed in the heap are removed prior to making it to the top of the heap. If this is not the case the sorting of the items from one bucket to the next bucket (sorting a linked list) would cause many page faults if the list didn't fit in internal memory. Timer wheels do nothing to address data locality which is the main problem faced by extremely large heaps. Your mention of in-order access is only true if the lists at each bucket as indeed stored sequentially in memory. This is hard to guarantee unless that space is reserved ahead of time or some dynamic reallocation scheme is used. I read the linked article as implying that simple linked lists were used, which generally have very bad data locality. Even if if a linear list was guaranteed, however, the sorting step when pushing things from one bucket down to the next bucket would incur page faults (assuming the list was too big to fit in memory) unless an I/O-efficient or cache-oblivious sort were used. (Which could easily be done, making an IO-efficient timer wheel structure.)
The algorithm discussed in the article is for a general purpose heap. In most heaps the main cost is in removing elements from the root of the heap as they bubble up through it, rather than deleting them prematurely (as is the case with timers). Different approaches for fundamentally different problems.
Not quite true... a 3-sphere is actually the *surface* of a 4-dimensional sphere. So, not exactly something that lives in our world. In topology, the dimensions refer to the dimensionality of the surface, and not the space the surface lives in (ie: a circle drawn on a piece of paper is a 1-sphere, but the surface it was drawn on is 2-dimensional).
I've been curious regarding this... assuming we could pluck them out in the same order from each 'vat', is there any way to generate two giant vats of stored entangled photons? One stays on the earth, the other travels with the ship. Photons are measured according to some kind of predetermined low-bandwidth schedule, which allows sending of little messages. These little messages could then trigger large high-bandwidth messages. The photons have thus been entangled as long as the ship has been traveling, but the message is still 'instantaneous' as far as the earth and the ship are concerned. Is bending the rules of faster-than-light information travel like this possible?
Why do things at a level of granularity of 100,000 lines? Why not get the quantum computer to do the 'repeat x times and pick the most common answer' at each instruction? It'll introduce exactly the same slow down factor, and vastly reduce the chance of error propagation.
Conventional computers already have a certain amount of error that creeps in. Suppose during a single tick of the clock cycle there is some chance P of an error occurring. Find the 'repetition factor' n such that the quantum computer guarantees you no more than the same amount of error P, and you've got a quantum computer that gives you exact answers (over arbitrarily long programs) with the same chance of error as a conventional computer having run the same number of arguments. It becomes more an issue of speed, rather than errors.
Having to repeat each fundamental step some large number of times slows down the computer. (To get 1/10^40 chance of error, repeat the calculation ~400 times given any individual calculation has a 21% chance of failure.) However, this will disappear as the underlying hardware is improved, which it invariably will be (given more years of development time, I'm sure errors will be reduced from 21% to far below 1%).
Many real world problems are already built around this notion, whereby we only know the answer to be correct with a high degree of confidence (see 'Monte Carlo algorithms'). The underlying process only needs to be correct more often than it's wrong (it could be 50% + epsilon versus 50% - epsilon) and we can just keep repeating the calculation until we get any arbitrary accuracy we wish.
No, it's actually a perfectly reasonable idea. Consider running the device (n+m) times. The probability of it being right n times and wrong m times is given by:
P(n,m) = (n+m)!/n!/m! 0.79^n 0.21^m
Now consider the probability of it being right (majority has the right answer) out of 2n+1 trials. This is the given by:
S(n) = sum( P(n+1+i,n-i), i=0..n )
This can be simplied to a closed form using Legendre and gamma functions, but that's kind of messy and it's far easier to just plug in values and do the summation. As it turns out, doing the experiment 15 times and taking the majority (plugging 7 into S(n)) will give you the correct answer 99.4% of the time. Doing things 35 times gets you to five nines of accuracy... completely reasonable in my books.
Assuming you've got a reasonably modern version of X, and a somewhat capable video card, then xrandr does exactly what you're looking for. Mind you, it's a command-line application, but it's definitely not hard to use. A frequent Ubuntu contributor made a nice little GTK GUI front-end to it called urandr. This does exactly what you want (configure per-output rotation, resolution, etc). The only caveat is that you need to have configured X to have a big enough virtual screen size (x.org, Screen section, Display subsection, Virtual keyword) to support any anticipated output resolutions (combined size of the entire desktop across all outputs).
In my aviation experience, if you are ever interrupted in a checklist, or unsure of where you are for some reason, then you restart the from the beginning. This forces you to be conscious of the checklist as you run through it, instead of working completely off of a muscle memory and running through the entire thing in a haze.
Not that this behaviour is entirely bad, in fact it's even sometimes desirable. It's exactly the reason why emergency checklists should be so thoroughly memorized: in a high stress situation where you may not have the time to think very deeply about your response, your muscle memory takes over and still gets everything in the checklist done.
PPM and context based algorithms generally have fairly similar compress and decompress times as well as similar resource usage. The algorithms work by keeping a huge table of statistics based on text already seen (and maybe some initial statistics based on some external corpus) and using that to come up with a table of probabilities as to what the compressor thinks the likelihood is of the next 'symbol' being any of its possible values. This table of probabilities is then used to encode the symbol using an arithmetic encoder. To decode the same symbol, the arithmetic decoder needs to be in the exact same state as the encoder was. So, the same table's must have been generated in the same manner, using the same resources. Also, arithmetic encoding is pretty much symmetric, so there is no real speed gain there. As such, I imagine the algorithm requires a fairly lengthy decompress time as well.
h tml. A brief look shows that most PPM and CM based algorithms are quite symmetric in performance.
Matt Mahoney lists compression time, decompression time and memory usage (as well as other statistics) for the best Wikipedia compressors: http://www.cs.fit.edu/~mmahoney/compression/text.
Assymetric compression algorithms are ones that tend to spend a configurable amount of time looking for patterns in the data. The compressed stream ends up being an encoding of the pattern, and the decompressor simply grabs data according to the pattern and outputs it, which is quite fast. Think LZ based algorithms that spend a lot of time looking for string matches, and deciding the optimal way to output them. Or video encoding that spends a lot of time calculating how the scene has moved (how blocks in one frame are related spatially to those in another).
First question:
You've got 2 marbles, so the best you can do involves 2 * (sqrt(100)-1) possible tests. If you had n marbles, you could do O(n100^(1/n)). So, using the first marble, drop if from the 10th, 20th, 30th, etc floors until it breaks. Say it breaks at the 30th. With the second, start testing the 21st, 22nd, etc. At most you will require 18 tests and only the two marbles. (I'm assuming the marbles maintain their integrity after repeated drops.)
Second question:
Use an external memory sorting algorithm, of which the best reqires O(N/Blog[M/B](N/B)) IOs (M is the size of the internal memory, B is the size of a 'block' or single sector on the disk, N is the problem size). The last decade has seen the development of an entirely separate model of computation which counts disk accesses rather than clock cycles. All old problems are new again as algorithms are found that solve them optimally in this new paradigm. Certain problems (like sorting) have been solved so that they are simultaneously optimal from an IO and a clock cycle point of view. IO efficient sorting generally uses a merge sort. So, for this problem you would sort 2M of data at a time, and then merge as many of these chunks together as you could simultaneously (using the largest heap that would fit in the 2M, in this case you could easily merge all 50 sorted subchunks), then repeat. There's actually another model of computation called the 'cache oblivious model' which aims to build algorithms that are IO efficient across every level in the cache hierarchy of a modern computer (disk, disk cache, L2 cache, L1 cache). Again, there exists a sorting algorithm that is cache oblivious called a funnel sort. It also uses merge sorts, but the size of the merger at each level varies. Interesting stuff... (disclaimer, I am doing my PhD research on IO efficient and cache oblivious graph and computational geometry algorithms).
Third question:
(I'm assuming that should read "You are NOT allowed to send any data before all the numbers have been sorted")
There are 10^8 possible unique phone numbers. You could imagine using a large bit table to keep track of which values have been seen but this would require ~12MB of memory when we only have two. You could imagine 'run length' encoding such a table, where strings like '0000...1' are encoded as the number of preceding zeroes. Worst case scenario we could have up to 10^8-10^6 leading zeroes, requiring 27 bits to represent. So, we could encode the table using 3.2MB of memory. This is still too big. Go another level deep and use a variable length code to encode the run lengths. The worst case is still a 27 bit run length, so we'll require 5 bits to represent the number of bits required to represent the run length, followed by that number of bits actually encoding the length. Worst case scenario pushes all of the run lengths to the same size, in which case they are 10^8/10^6 = 100 bits long. This requires log[2](100) = 7 + 5 = 12 bits per encoded phone number, or 1.43MB of RAM. So, this'll fit, but its still pretty tight. This was just to see how hard it is to fit the data into the available space; while it does highlight a possible algorithmic approach its likely not going to be too efficient. Likely, using a radix tree over the phone numbers represented as 32 bit sequences (4 bits per digit) would be the best approach, although you'd have to be extremely frugal with your data structure to ensure it fits.
It was actually featured in a Slashdot story not long ago:
1 1/1952201
0 4-10.html). The guy behind the work is one Dr. Lucia Turin, and he has indeed achieved some commercial success through his company Flexitral.
http://science.slashdot.org/article.pl?sid=06/12/
Unfortunately, the original Nature article is now subscriber only (http://www.nature.com/news/2006/061204/full/0612
As other have already pointed out, this a very common technique. It is slowly being adopted as a standard in the VoIP and P2P world (Google Voice uses it, for one). RFC 3489 discusses this very technique, and defines a protocol to be spoken to the central server that is brokering the connection. For a good overview, you could check out the Wikipedia article. There is also a simple, cross-platform and open-source library available that implements the server and client side techniques, making it very easy to integrate this technique into other projects. Nonetheless, the article makes for a nice and simple description of the technique.
I'm not so sure about the usage for dogs, but I would totally use this on a motorcycle. They're so easy to steal that it would be a great thing to have some sort of relatively cheap and reliable tracking device installed. All they need is the ability to easily enable/disable the virtual perimeter (ie: disable it when you're riding, re-enable it when the bike is parked), and it'd be a great system!
(I'm speaking from experience of having had a new bike stolen, and having that terrible empty feeling in your gut realizing that there's nothing you can do about it. I eventually got it back, 2 weeks later, completely wrecked, found lying in 3 feet of water in a ditch!)
An easier solution is to just write something on the client side. Something that maybe scrapes all of the feeds, uses intelligent parsers to group together all of the dupes (and ignore entire season releases, etc), and then uses some selection criteria to grab the best quality (video quality, number of seeders, etc) torrent out of a pool of dupes. Match that with simple filter syntax (no need to use RegExps... series titles are 'normalized' behind the scenes, and matched that way), and you have a quick and easy poor man's TiVo.
Even better, it works with any RSS feed, and can scape some popular torrent sites as well. It then gives you a simple interface to browse it's generated database, and see what's out there. It can be launched and left running in the background and will just merrily go about doing it's job. Inspired by another project out there called TvTad, but fixing many shortcomings.
It's called FetchTv and it's written in Ruby, and when I get off my lazy arse I'll put it on SourceForge. In the meantime, if anybody's interested, let me know and I'll share it. (I warn people: it's fully functional, but not necessarily user friendly at this point)
I've found another (from June) article here (in french). For a long time people have been talking about ammonia as hydrogen storage, as it's quite high in energy density and is a relatively safe liquid. However, there are issues with gas expansion, pressurization and toxic fumes.
Essentially, these pellets are an ammonia storage system that stores ammonia nearly as efficiently (by weight and volume) as liquid ammonia. The above article says that they are relatively cheap to produce (initial costs of 1 euro/kilogram of material, which translates to roughly $12.88 USD for the energy equivalent of a gallon of gasoline). The article clearly states that the process is reversible, thus the base materials must be reusable. It does not state what the cost is of 'recharging' the pellets. The recharge cost would have to be at least 4x cheaper than production in order for it to be competitive with gasoline. The extraction technique is listed as 'desorption', which I imagine just means heating the pellets up and siphoning the extracted gas off. As for temperatures, and desorption rates, nothing is cited.
It doesn't state specifically how the reaction runs, but that ammonia is extracted from the pellets, which is then run through a standard ammonia converter (at temperatures of around 350 degrees celsius) to extract the hydrogen. It says the reaction runs quickly, so it's able to provide the hydrogen quickly enough.
The Amminex website has slightly more information available by clicking on the "ammonia storage" page, because it's the exact same technology as the hydrogen storage (link here)
And myself as well. And as for the cheque clearing thing, there's a little piece of legislature that was passed to make cheques more convenient. Essentially, banks can only hold cheques for so long before they have to let the funds clear (if they have no reason to believe it will bounce). Meanwhile, the cheque continues to take it's time to clear, and finally will bounce. This will happen a few days after you get the money.
Or, the other situation is that the cheques are forged as coming from a large commercial account. When the cheque is 'cleared', the bank system replies 'yes, there are sufficient funds in this account'. However, when the bank physically receives the forged cheque and gets around to looking at it (often not until the end of the month), THEN they will say it bounced, and go back to your bank for the money. This can take weeks potentially (in my case it took 2 weeks for them to get back to me).
The stupid thing is the banks are allowed to get away with this, and there is NO recourse.
Myself, I took action. I spent a few weeks tinkering with Yahoo Mail until I found an exploitable flaw. I then started tracking backwards (sending fake login screens via email) through all of the accounts until I got to the central account. This account was a personal active account, used for various purposes. By monitoring this account for a while I eventually got the guys full real name, his girlfriends name, the addresses and names of his family back in Nigeria, his address in London, the name and address of the place he worked, the school he went to and student number, a copy of his resume, and even his application number for a US greend card. However, no law enforcement agency (specifically Canadian or British) will do anything with the information, as it was 'ill gotten'. I wish there was something to do to chase the bastard down but I doubt it'll ever happen.
Another poster had mentioned that they are identical to stock Barton's, but more expensive. In my experience they've only been about $10-$15 more expensive (I've got an XP-M 2500+), and well worth the price to guarantee that you've got a 'cream of the crop' processor. Heck, in the article they only quote a $0.50 price difference!
Not only are they good for overclocking, but they're good for the opposite use too. Everybody complains about loud computers; why not get one of these mobile processors instead? I was able to run at normal clock speeds with an old (and quiet) HSF from an AMD 1.0GHz and still see temperatures below 40 degrees Celsius. Mine runs in a home-theater PC so top on my list was quiet, cool, and able to run in a small case (ie: with constrained fan dimensions). And it's done just that, while at the same time providing plenty of horsepower for real-time HDTV quality MPEG2 decoding, etc.
They do payments through PayPal, so you don't have to feel like you're giving private info to some dubious Russian folks. It's pretty easy to verify that you're truly at a real PayPal site, and not some fake front, so with a little caution you can feel secure in who you're dealing with.
IMHO, the best online store out there is www.allofmp3.com. This company is Russian based, and because of their somewhat lax copyright laws and much more lenient recording industry, they offer non-encumbered downloads at cheap prices. Basically, the site is pay-for-bandwidth. If you download a song at 128kbps MP3, you essentially pay a penny per minute of audio.
The other awesome thing about that site is the ability to selecte your download format from WMA, MP3, OGG, FLAC, etc, plus the particular quality settings. For most downloads the audio is converted on the fly from a high quality archive (~400kbps), and for others it is actually converted directly from the CD-DA source. In "Advanced Mode", it's almost equivalent to selecting your command-line switches for the transcoder of your choice!
I'm in no way affiliated with these guys, but I love their service. It's actually faster and more reliable for me to download music from these guys than it is to try and venture out onto the P2P networks. Heck, for quality 7 OGG music, I'm paying roughly $0.02 CAD/minute. Plus, they let you pay with PayPal, so it's not like your sending your credit card info to some random Russians.
It doesn't have to be that way. There could be a 'secret' shared between the server and the client doing the knocking. This 'secret' could then be used to 'sign' (any strong cryptographic hash) some command, which is then translated into a knock sequence. In this manner, knocks can be authenticated. You'd want to 'salt' the knock as well, so that no two knock sequences would likely be the same. This could be done by using some combination of the source IP/port and date (probably not time, too many synchronization issues there). The knock, when decoded on the server end, could poke a hole in the firewall for the knocking IP only.
Another way of producing 'salt' to make the knock signatures unique would be to keep a knock-server (a low risk app, IMO) running on a single port. Before knocking, the client would query the knock-server and get some 'salt'. This could then be used as above. I think there are still some possible attacks, but I'm sure with more thought a secure system could be devised.
In this manner, it most definitely WOULD be another layer of actual security, and not just obscurity (only knowledge of the shared 'secret' would allow successful knocking).
...a submarine. I work as a reserve officer and spend several weeks every summer at a nearby air force base. This summer, a few guys in my office took it upon themselves to turn another office-mates cube into a submarine like environment. Using nothing but card-board and duct tape, they enclosed the cube from floor to ceiling. At the cube entrance they left a fully functioning hatch-style door complete with wheel. They then proceeded to decorate the outside to look like steel and rivets (not quite as much effort as your cube-house though).
By the way, good job on the cube-house!
Oops... my mistake... I misinterpreted what they meant by the 3-click rule (I didn't RTFA)... /limps away sheepishly
The 3-click rule is actually based on a little math, and doesn't just come from nowhere. The question is this: given a finite number of leaves (end destinations), how should a menu be arranged to minimize the average amount of time required to access any leaf? The assumptions are that each 'menu' (level of the tree) takes the same amount of time to read/load/listen to, and that each final menu choice is equi-probable. Under these conditions, continuous optimization shows that a tree with exp(1) = 2.718... branches per node is optimal. Thus, the choice of 3 options per menu level is usually chosen.
Again, this rule is based on some fairly strict assumptions, and realistically, an optimal menu layout (in terms of minimizing clicks) may conflict with a logical menu layout (in terms of hierarchichal ordering).
Wouldn't this be trivial to implement? Imagine a very simple (closed) system consisting of cell phones on a standard digital network. You and a friend could decide to share a 'key' (which you manually type in to your phones, and associate with the other persons number). When you dial each other, your phones (recognizing which phone, by it's number, is on the other end), automatically applies some private-key non-expansive encryption algorithm to the compressed audio.
I have no idea of the data format or protocols involved in cellular communications, but assuming the phones were on the same network and spoke the same algorithm, then you could easily have encrypted calls from any two handsets.
Heck, this may even be possible through a simple cell-phone firmware upgrade, and nothing else. And I'm sure there are people out there who have reverse engineered the firmware on some cell phones (just like most handheld electronic devices out there).
Anybody with a little more knowledge know if something like this is possible?
Not only is the tZero a sporty little electric car with amazing acceleration, it can also achieve reasonable mileage and range using their hybrid range extended trailer. There are links in the AC Propulsion white papers section regarding the range extending trailer. Also, a link to a PDF
With this thing attached the car it gets a combined 40 MPG (highway driving at 100kph/60mph) and a range of around 380 miles. Not bad for a sports car. Another cool feature of the trailer is that it has a linked steering system; it's not a freewheeling trailer, rather the trailer wheels move with the car steering. This makes things like backing up (parallel parking and the like) much easier for those without experience towing a trailer.
Neat little car.
asdfasdfasdfasdf said:
The flipside is that the DirecTivos are more difficult to hack, and I don't think there's any easy way to Hack the HDVR2 (latest and 'greatest')
Not necessarily true. In fact, the DirecTiVos are just as easy to hack as the stand-alone TiVos, and most of the hacking work on the two types of boxes overlaps.
The TiVo hacking community is quite strong, and things have come a long way. If you haven't checked things out recently, then you owe it to yourself to do so. There are lots of cool hacks out there:
- FTP or HTTP extraction of MPEG2 video
- FTP or HTTP insertion of MPEG2 video
- complete and useable WUI
- sharing recordings between boxes
- on screen caller display
- on screen email/instant message notification
- much more...
My favorite resource are the forums over at DealDatabase (http://www.dealdatabase.com/forum/). You'll find lots of info and links on hacking your TiVo (new or old, DirecTV or standalone). Oh, and the Series2 TiVo's have been thoroughly hacked as well.asdfasdfasdfasdf said:
The DirecTV Tivos copy the satellite stream including Dolby digital as they come off the Sat-- so they are as "perfect" as the source-- which means for hi-bitrate channels like HBO, it's not DVD quality, but it's better than any cable I've seen.
The DirecTiVo saves video at 480x480, standard 29.97 fps, with some channels coming in at 720x480. This is less then HDTV at its best (1920x1080), roughly the same quality as DVD (720x480), better than standard broadcast (~460x360), and much better than VHS (~300x360).