Wikipedia:Reference desk/Archives/Computing/2015 January 2

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.

January 2

Ceramic disk capacitor size?

Hello,

I have a (broken) capacitor that I would like to know the size of. I believe it is ceramic disk type, it is black and has the letters "TP" on one line, with "8D13" written below that. I have looked online and cannot find anywhere how to figure what size capacitor this is? Thank you for any help. Elpenmaster (talk) 02:58, 2 January 2015 (UTC)

It's not this, is it?:

http://www.datasheet-pdf.com/datasheet/GeneralElectric/678931/TP8D13.pdf.html

But it doesn't seem to be a capacitor... 109.153.236.190 (talk) 03:21, 2 January 2015 (UTC)

Yes, that's it. I guess it is not a capacitor after all Elpenmaster (talk) 17:36, 2 January 2015 (UTC)

Zipping Files with 7Zip

I am cleaning my computer and I have found a lot of stuff that I dont want to delete and I was wondering if I could just zip the folders I want to keep for a long time in .7z I am worried about something going wrong down the line and I wont be able to get my data out of the .7z file so that I can use it again. Is this a crazy fear of mine? I have been zipping up my favorite folders with family pictures and documents that will be important 10 years from now, does .7z corrupt a lot? — Preceding unsigned comment added by 204.42.31.250 (talk) 10:37, 2 January 2015 (UTC)

All backups can go wrong, but 7Z is not particularly susceptible to corruption, and should still be available in ten years time. If the files are important, I'd be inclined to keep a separate uncompressed backup on a separate backup hard drive or DVD data disc. (My paranoia leads me to keep at least three separate backups of files that I might want in ten years time.) Dbfirs 13:01, 2 January 2015 (UTC)

I want all these files in 10 years time or longer but if something truly goes wrong and I lose it all its not the end of the world for me I will be very upset at the moment but starting over will be interesting. Hopefully I never have to do that. — Preceding unsigned comment added by 204.42.31.250 (talk) 13:08, 2 January 2015 (UTC)

Disk space is cheap and getting cheaper all the time, so compressing data for backups is rarely worth the effort. Image files are already compressed, so trying to compress them again in a compressed container like 7z will save only a further 1 or 2% - totally not worth the effort. The greatest risks for data loss are accidental deletion (when you forget what the backup is, think it's junk, and delete it) and media failure (hard disk errors, DVD scratches, tape tangles). Compressing and archiving the data on the same medium doesn't protect you from either risk. If you want to have some comfort that this data will be available to you in a decade, you need multiple copies on different media (an external hard disk, a flash drive, a DVD), some of which are offline (they're not connected all the time), some of which are in different locations (e.g. in a safe in a relative's basement). -- Finlay McWalterᚠTalk 13:33, 2 January 2015 (UTC)

7z is an open format, so it should be available for a long time. Besides compression, an archive format like 7z allows you to place related files in a container and provide error checking when decompressed. Finlay McWalter is very correct: redundant backups are what you need for essential data. --  Gadget850 ^talk 14:21, 2 January 2015 (UTC)--  Gadget850 ^talk 14:21, 2 January 2015 (UTC)

Yeah it significantly depends what sort of data you're storing. In my case, I admit I have a recent tendency to save various web pages so I have a personal record without having to rely on third party sites (when I want to show to other parties, I do use archive sites). Over time I can end up with quite a lot of these. I've also used tools like wget sometimes to get a page at regular intervals (e.g. during sales). Over time, this can add up to a lot, but since a lot of the data is redundant and of course the HTML and CSS is often fairly compressible, it definitely does help to compress and archive it. Just as importantly, having 1 million files can cause various performance issues for the file system and for searching (if you don't index the disk except for those places) so archiving helps there too. The OP mentioned documents, so it depends a lot on what sort of documents and how many. If it's just a few thousand or less, you probably aren't going to gain that much in terms of performance or spaace. If you're getting in to 100k documents, perhaps you will. Nil Einne (talk) 14:58, 2 January 2015 (UTC)

The latest stable version of 7-Zip, version 9.20, was released in 2010, and is downloaded over 300,000 times per week on SourceForge alone, and probably significantly more when you include other software download sites. People have compressed a lot of data with it, and I don't think there's been a single case of data corruption attributable to a bug in 7-Zip (otherwise the author would have released a fix). It's really not worth worrying about that. 7-Zip is open source software, and there are so many 7z archives out there that someone will port it to computers of the future, even if the original author doesn't. You are much more likely to have trouble plugging in the hard drive with the 7z archive on it than extracting from the 7z archive.

The only reason not to compress your data is that a single flipped bit in compressed data can snowball to a lot of flipped bits in the decompressed data (and hardware glitches can flip bits). If that worries you, you can still use 7-Zip to archive the files with no compression. That gives you the convenience of having everything bundled in one file and the security of CRC error checking, so you will at least know if a bit got flipped. -- BenRG (talk) 01:45, 4 January 2015 (UTC)

Article on Clipping (computer graphics) in need of attention.

It's in bad shape. I cleaned it up a bit and added a section on Z-clipping, but it still needs work. Any volunteers ? StuRat (talk) 17:17, 2 January 2015 (UTC)

Thanks StuRat. I'll have some spare time over the next weekend and may take a look at the article's condition for a major overhaul. Nimur (talk) 18:45, 2 January 2015 (UTC)

OK, looking forward to those improvements. StuRat (talk) 05:47, 3 January 2015 (UTC)

Well, the weekend drew to a close... there is always more work to be done, but I have completed my most significant changes to content and organization. First and foremost, I have verified the content and definitions by citing (and linking) several texts and online documentation resources. Of course, please feel free to review and edit for accuracy, editorial issues, and so forth. I will probably revisit the article in the next few days with some touch-ups. Nimur (talk) 22:20, 4 January 2015 (UTC)

OK, thanks. A couple questions on your Z-clipping changes:

1) Why did you remove my mention of using one or two dials as one method to control the Z-clipping planes ?

2) Your example of using a tall wall to hide game elements to improve performance seems to be something other than Z-clipping, so I suggest another section. StuRat (talk) 22:31, 4 January 2015 (UTC)

The answer to both questions is that I attempted to make the article "technology-agnostic"; the two "dials" you refer to match implementations like OpenGL's camera perspective API, but are not universal in all APIs and all platforms. The same goes for the second question: one single z-buffer in a modern GPU can be used for both occlusion- and for distance-tests (e.g., "zNear" and "zFar" in OpenGL, which are the instances of your "dials" in that API)... so these are arguably the "same" feature. The gory details are, of course, implementation specific. If you'd like to dive deep into those details, please feel free to amend what I wrote, and cite sources! Nimur (talk) 23:15, 4 January 2015 (UTC)

Well, I'm a bit concerned that it's no longer readable by a general audience, and details like using dials to adjust the clipping planes help to make it more understandable to the masses. Some pics would also help. StuRat (talk) 23:20, 4 January 2015 (UTC)

Please let me know which parts are inaccessible to a general audience. I have been making a best effort to describe the process in plain language, and use wikilinks when appropriate; but I am not always aware when a phrase or term would be unfamiliar to the uninitiated. Nimur (talk) 00:10, 5 January 2015 (UTC)

"This viewport is defined by the geometry of the viewing frustum, and parameterizes the field of view." Wow, I couldn't make a simple subject sound any more complicated if I tried. StuRat (talk) 04:49, 6 January 2015 (UTC)

This sentence is evidently confusing to you. To me, it is written in plain English: it accurately and concisely states a factual relationship between several important concepts.

I am not able to refactor the sentence to be any more simple, except to add wikilinks for viewport, geometry, viewing frustum, and field of view.... and possibly the word "parameterizes". I admit that these technical terms might be unfamiliar to some people; but how can we describe a relationship between these nouns to somebody who does not know what these nouns even mean? (In my defense, I did paraphrase the definitions of each of those terms in the lead-up to the sentence that is confusing to you).

Perhaps we need a third opinion, as I am not able to satisfactorily explain the concept in a way that is understandable. Nimur (talk) 17:21, 6 January 2015 (UTC)

OK, does anyone else think the above sentence is simple to understand by a general audience ? StuRat (talk) 02:27, 8 January 2015 (UTC)

This reply is about the sentence "This viewport is defined by the geometry of the viewing frustum, and parameterizes the field of view." With wikilinks for the expressions "viewport", "geometry", "viewing frustum", "field of view", and "parameterizes", the sentence seems to be simple to understand by a general audience, if a reader unfamiliar with those expressions follows those links and allows enough time to digest their meanings, both independently and in the context of the sentence.

—Wavelength (talk) 21:22, 9 January 2015 (UTC)

The usual problem with sentences that require following links to understand is that those links also contain similar sentences, which require following more links, ad infinitum. Hence the need for sentences that can be understood on their own. StuRat (talk) 22:07, 9 January 2015 (UTC)

A writer can aim for a finite (and minimum) number of necessary clicks to more-basic definitions and explanations. However, condensing complex concepts has limits.

—Wavelength (talk) 03:38, 10 January 2015 (UTC)

Percent-encoding and mojibake, once again

Per a request at WP:AN, I've just created 🇳🇱 as a redirect to Flag of the Netherlands; it's an emoji thing that displays a picture of the flag in some contexts. When I edit the page, I'm taken to https://en.wikipedia.org/w/index.php?title=%F0%9F%87%B3%F0%9F%87%B1&action=edit, and going to https://en.wikipedia.org/w/index.php?title=%F0%9F%87%B3%F0%9F%87%B1 takes me to the right place. However, if I chop off one percent-encoded character (https://en.wikipedia.org/w/index.php?title=%F0%9F%87%B3%F0%9F%87), I end up at П‡³ðŸ‡, which itself has a much longer URL, https://en.wikipedia.org/wiki/%C3%90%C5%B8%E2%80%A1%C2%B3%C3%B0%C5%B8%E2%80%A1. Finally, when I chop that page's final character (%A1), I end up at ߇³ðŸâ€. Three questions arise:

1. %F0%9F%87%B3 translates to 🇳, and %F0%9F%87 translates to П‡. Why doesn't %F0%9F%87%B3%F0%9F%87 take me to 🇳П‡?
2. Why does the URL change from %F0%9F%87%B3%F0%9F%87 to %C3%90%C5%B8%E2%80%A1%C2%B3%C3%B0%C5%B8%E2%80%A1?
3. Why does chopping %A1 give me a title completely different from П‡³ðŸ‡?

Last June, I asked a different percent-encoding question (thus the title on this question), and BenRG said URLs are supposed to be UTF-8 encoded, and C3 AB is the UTF-8 encoding of U+00EB, "Latin small letter e with diaeresis". AB by itself is not valid UTF-8, and some software somewhere tried to guess what it was supposed to mean. It guessed Latin-1 (or more likely Windows-1252), in which AB stands for U+00AB, "Left-pointing double angle quotation mark". Apparently Ben meant that the display of percent-encoded stuff depends on context and interpretation by the computer; is this the explanation? Nyttend (talk) 18:18, 2 January 2015 (UTC)

See Percent-encoding and UTF-8. The initial %F0 indicates a 4-byte character, but (in your examples) you're only sending 3 bytes. To answer your specific questions:

1. The "%F0%9F%87" isn't valid UTF-8 (as you're telling the parser it's 4-byte, but only giving it 3). The parser then considers the whole sequence as invalid (which it is), and instead interprets it as seven single-byte Windows-1252 characters.
2. This is the result of encoding the seven-character string as seven UTF-8 characters, some of which are 2-byte and some of which are 3-byte: %C3%90 [Ð] %C5%B8 [Ÿ] %E2%80%A1 [‡] %C2%B3 [³] %C3%B0 [ð] %C5%B8 [Ÿ] %E2%80%A1 [‡].
3. Removing the %A1 means the entire string isn't valid UTF-8, so the whole string is reinterpreted. It's the equivalent of changing the "MZ" to "MX" in an .EXE file. Tevildo (talk) 10:41, 3 January 2015 (UTC)

Just to clarify on #3, you're again going from UTF-8 to Windows-1252, so the URL with the missing %A1, which started as seven UTF-8 characters (16 bytes) is reinterpreted as fifteen Windows-1252 characters. Tevildo (talk) 15:22, 3 January 2015 (UTC)

And just to clarify further, that behavior isn't in any sense correct, it's just how the author of some code running on Wikipedia servers (possibly MediaWiki itself) decided to handle this situation, once upon a time. Different software might interpret the same URL differently, including decoding the valid UTF-8 sequences as UTF-8 (as you originally expected to happen). Case in point: when I navigated to ...?title=%F0%9F%87%B3%F0%9F%87 with Firefox's network monitor window open, it showed the URL as ...?title=🇳 – that is, it interpreted the valid UTF-8 sequence as UTF-8 and apparently just discarded the rest. When I navigated to ...?title=%80, the network monitor window showed it as a box with 0080 in it (meaning it interpreted it as Latin-1, where 0x80 means U+0080), but Wikipedia took me to Euro sign (meaning it interpreted it as Windows-1252, where 0x80 means U+20AC).

It looks like both Wikipedia's and Firefox's behavior here is explicitly forbidden by RFC 3987 section 3.2, last paragraph. They should probably follow the procedure described in that section, which decodes valid UTF-8 sequences and leaves everything else alone (so %F0%9F%87%B3%F0%9F%87 would decode to 🇳%F0%9F%87). -- BenRG (talk) 19:19, 4 January 2015 (UTC)

Non-mathematical part of good programming

What field of computer science, if any at all, deals with good programming practices? I mean, what discipline analyzes what makes good code good code, independent of language, but not including algorithms and picking the right data structure and technical stuff like that.--Noopolo (talk) 20:57, 2 January 2015 (UTC)

There are no specialized "fields" of computer science that deal with them, because computer science is always about "technical" things. They are social programming conventions, such as:

• Formatting: Indentation/braces, comments, naming conventions, etc.
• Structure: Organization of "code fragments" (functions, classes, modules/source files, etc.).

Czech is Cyrillized (talk) 11:46, 3 January 2015 (UTC)

This is an area that tends to get left out of computer science or engineering. Things like how big a persons desk is, how their interactions with others is organized and how often they are interrupted unexpectedly, how quiet it is, how good the lighting is, whether the air is fresh, how problems are raised, how timescales are set, how the main aims are expressed, ... it goes on ... and on ... these social and environmental aspects can be far more important than any programming standards. Dmcq (talk) 13:56, 3 January 2015 (UTC)

As asked, the question is hard to answer. What makes "good code" in one language may differ when looking at a different language. Functions, classes, etc may be arranged differently depending on which language that you're looking at. So any sort of class on what makes good code will be wrong if it tries to cover every language with one blanket statement. And then some businesses have their own style guidelines about how code should be written which might clash with what other businesses are doing with the same language. e.g. I know you worked for XYZ but here at ABC we want the comments before the line they address not after, etc. Dismas|^(talk) 14:18, 3 January 2015 (UTC)

Software engineering is where the programming takes place (that is why it is "Software" engineering). Inside of that broad field, you will find topics that cover software development, such as project management and programming techniques. As for "what is best" - there is no answer. It depends on who is deciding what is best. For example, I type very quickly and have difficulty keeping my programming as fast as my thinking. So, I don't want to press space-space-space-space to indent. I press tab and use an autoindenter. I think that is best. Many (very very many) are violently opposed to the use of tabs for indentation in code. 199.15.144.250 (talk) 20:01, 5 January 2015 (UTC)

Some aspects of this are more managerial in nature - and would be rather similar for non-software disciples - so (to use that earlier example), the size of someones desk or the number and size of computer monitors they use will probably be very similar for a web designer or a CAD engineer - so that's going to fall into the fields of ergonomics and project management. Some management techniques such as Scrum (software development) are being used more widely than just in software engineering, so those too are migrating out of the "software engineering" discipline.

For the actual day-to-day programming tasks, relatively little of what most people do is related to mathematics. I've spent most of my career doing 3D computer graphics, which is definitely high up on the mathematical scale of things - but even so, I doubt I spend more than maybe 5% of my time "doing mathematics" - most of it is more to do with data structures, data flows, that kind of thing. Algorithms are another activity...somewhat related to the mathematical stuff - but not necessarily.

I don't think there is any sub-field of software engineering that's to do with how to structure code (irrespective of language, algorithms or math)...that's more or less the entire subject!

SteveBaker (talk) 20:13, 5 January 2015 (UTC)

What benchmark to use to measure the speed of a programming language?

What tasks are the more telling towards the aptitudes of a language? Are the methods used to measure numeric problems, different from the methods used to measure symbolic problems? --Noopolo (talk) 20:59, 2 January 2015 (UTC)

Languages don't have speed per se - implementations of the same language can differ by orders of magnitude. But in general, yes, you need benchmarks that reflect the workload you are interested in. Take a look at Standard Performance Evaluation Corporation for a number of different benchmarks they publish. Symbolic systems typically are better represented by SPECint, numerical problems typically better by SPECfp. There are many other benchmarks out there. For your particular interest, take a look at this site. But as the name suggests, this is more for fun than for serious comparisons. --Stephan Schulz (talk) 22:07, 2 January 2015 (UTC)

I'm guessing you mean speed of the program once it is compiled. Going to the limit the fastest language then will always be assembler language. The problem is you've really got to take account of the problem of writing the program, in general more effort on programming means less time on each run. For comparing languages people normally take a not too difficult a problem and ask for it to be coded in a reasonably straightforward way in the different languages. Unless the program is going to run millions of times like on a web server or in computer game or it is a very large problem it isn't normally worth anybody's time to do any optimization. The article Comparison of programming languages gives a comparison of basic features of some languages and might give you some leads. A Google search on terms from there you think are relevant to you might get some actual comparisons that are of interest to you. Dmcq (talk) 13:45, 3 January 2015 (UTC)

User:Dmcq says that to go to the limit of speed after the program is fully compiled one should use assembler language. Of course that depends on the skill of the programmer, and one of the advantages to using a good-quality optimizing compiler is to permit reasonably good programmers, as opposed to super-programmers, to write reasonably performing programs. In in the early 1970's, I remember hearing an assembly language programmer say, about Unisys FORTRAN, that the only way an excellent assembly language programmer could equal the speed of FORTRAN was by using the same techniques as used by the FORTRAN compiler. A good mature procedural-language compiler (maturity meaning time taken to optimize the code) can do almost as well as assembler (which is of course also procedural). As Dmcq says, further optimization isn't useful unless the program will be run thousands or millions of times. Any further optimization (beyond that done by a good compiler) should be done based on the hot-spot principle. It is sometimes called the 80-20 principle, but optimizing the 20% of the code that is run 80% of the time may still not give the return of a 90-10 or 95-5 optimization. Robert McClenon (talk) 15:23, 3 January 2015 (UTC)