Wikipedia:Reference desk/Archives/Computing/2014 February 20
Computing desk | ||
---|---|---|
< February 19 | << Jan | February | Mar >> | February 21 > |
Welcome to the Wikipedia Computing Reference Desk Archives |
---|
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
February 20
[edit]List of webmail bigger than wikipedia one?
[edit]Any place with a list of webmails, that is bigger than the (http://en.wikipedia.org/wiki/Comparison_of_webmail_providers ) wikipedia one? 201.78.220.93 (talk) 13:39, 20 February 2014 (UTC)
Anachronism in Schoonschip article?
[edit]Given that the 68000 series of processors were only first released in 1979, and given that the article specifies that the program was written in assembler, how can this program have been written for the 680x0 architecture in the 1960s? Either the date of first development must be wrong, or the program must have been developed in something other than assembly language, or this program must first have been developed for some other processor architecture. -- 80.168.174.216 (talk) 15:05, 20 February 2014 (UTC)
- The README on the schoonschip archive linked from our article makes clear that this code dates to 1991. It is probable that it has a historical lineage dating to earlier code. Nimur (talk) 16:08, 20 February 2014 (UTC)
- Yup, search the web for schoonschip cdc for information on the original CDC 6600 version. 88.112.50.121 (talk) 17:17, 20 February 2014 (UTC)
- I've amended the article with some details of the program's early history. The first version ran on an IBM 7094, and was then ported to CDC. "Porting" assembly is really "rewriting", but unless architectures are radically different, you mostly end up with much the same structure and much the same data layout on the new machine. The IBM had only a 32kbyte address space, so we might imagine the original program (it'd be nice to find that) might assemble down to 16kbytes. Porting/rewriting 16k of assembly might be a chore, but it's perfectly tractable. A couple of decades later it was common to similarly port 8 bit computer and console games to different architectures, bugs and all. -- Finlay McWalterჷTalk 18:02, 20 February 2014 (UTC)
MP4 videos into WMV videos
[edit]Is there a program that is like RealPlayer but it can convert MP4 videos into WMV videos without having paying anything? Thanks. — Preceding unsigned comment added by 70.31.18.16 (talk) 15:48, 20 February 2014 (UTC)
- Yes, there is such a program. OsmanRF34 (talk) 17:34, 20 February 2014 (UTC)
- ffmpeg can convert most audio/visual formats to most other formats, and strip out the audio or video from a file. However, it is a command-line program, and not noted for it's user-friendliness CS Miller (talk) 18:46, 20 February 2014 (UTC)
- Format Factory would probably do the trick, and is easy to use. DanielDemaret (talk) 06:55, 22 February 2014 (UTC)
Why are algorithms and data structures related?
[edit]Why should it matter whether you are sorting apples or oranges? Or searching for a needle in a hay or a face in a crowd? OsmanRF34 (talk) 18:21, 20 February 2014 (UTC)
- You seem to be confusing data structure with data. If you intend to study computer science, you need to really understand this very important, albeit abstract, difference. Nimur (talk) 18:36, 20 February 2014 (UTC)
- One reason is that any useful algorithm has to be implemented, and you can improve performance by placing restrictions on it. The abstract case may always work, but it usually takes longer than a more specialized implementation (think of prime factorization). OldTimeNESter (talk) 21:56, 20 February 2014 (UTC)
- Suppose you work in a used car lot. There are a lot of black cars, white cars and red cars in a huge parking lot with numbered spaces. Your boss tells you that you should make it easier for the sales staff to direct customers to cars of the color they want.
- One approach would be to put all of the white cars in the lowest numbered spots, all of the black cars in the highest numbered spots and all of the red ones in the middle. You'd spend a lot of time driving cars around to make that happen.
- A better approach might be to write down a list of all the cars - and which parking slots they are in - and then make a new list with all of the white cars at the top of the list (along with their parking slot numbers) and all of the black ones at the bottom.
- The cars are the data items, the parking lot is an array of cars. The paper list is an array of pointers (slot numbers) to cars. The parking lot and the paper are both data structures. Clearly, it's a lot easier to rearrange the list on paper than it is to drive cars back and forth. So even though the sorting "algorithm" is the same, it's a lot easier to use with a better choice of data structure. You always have to be careful about this though. If these were not real cars in a parking lot - but toy cars on a shelf, then it's probably quicker to move the toys around than it is to list them all out on a sheet of paper. These kinds of trade-off are common things to consider when making a data structure for a particular kind of data element.
- The algorithm is completely separate from that. You could use an analog of a 'bubble sort' or a 'quick sort' to sort the cars in the parking lot - or the list of cars on paper...the algorithm being the same - albeit with a different data structure.
- Some algorithms work better with one data structure than another - often there is a trade-off between the amount of time you spend planning what you're doing versus actually moving data around. There are also situations where the algorithm choice is determined by the available data structures. If you have a spare parking lot just across the street - you might find that sorting the cars by driving them off to different slots across the street was a faster way to sort them out than to mess around with bits of paper...but if you only have one spare space in your only parking lot - then sorting the cars into order becomes a massively difficult task. (eg, Pick the right-most white car, drive it into the spare space, find the left-most black car, drive that into the space you just vacated, drive the white car out of the spare space and into the newly vacated space...what a pain!)
- There is no one "right" data structure or "right" algorithm for all kinds of data...which is why some people can make a career out of being experts in the field.
- For a case like that, with a very small number of unique values (just 3 colors, in this case), I like a bin sort. Using pointers makes it even better. However, I do think the buyers would prefer to go to the red car area and see all the red cars at once, not have to walk all over the lot to find them. So, it's more work up front (moving the cars), but less in the long run (accessing the cars). StuRat (talk) 07:30, 22 February 2014 (UTC)
Deleting the $hf_mig$ folder
[edit]An old XP computer I still use from time to time is running out of disk space. I have used disk cleanup, I regularly run CCleaner, I have deleted Java, all the $NtServicePackUninstall$ folders in the Windows directory, the entire content of the dllcache folder in the Windows/System32 directory. But there are still a few GB tied up in the $hf_mig$ folder. Can that folder be safely deleted (considering that Microsoft is not going to come up with updates for XP anyway), or will this cause problems? Count Iblis (talk) 19:37, 20 February 2014 (UTC)
- The role of $hf_mig$ is described here. As I read it, its contents are only used when installing hotfixes and service packs, and hotfixes are not distributed through Windows Update. Therefore, if the machine already runs XP SP3 and you will update it only through Windows Update from now on, it should be safe to delete $hf_mig$ even before support is terminated. -- BenRG (talk) 03:58, 21 February 2014 (UTC)