Wikipedia talk:WikiProject Computer science

Quote_notation: overly optimistic

The article on "Quote_notation", although sort of interesting, is overly optimistic on the usefulness of this notation for general computation with fractions. There is an obvious problem that the length of a quote notated fraction is linear in its denominator, often even close to it.

This optimism is already there in the original article.

For example, the suggestion is that subtraction of two quote notated number is "just subtract". Here a bad counterexample: To subtract 1/19 from 1/17 (giving 2/323), you compute 2941176470588235'3 - 894736842105263159'9, and after subtraction you get a number with a repeating part of 144 digits, ending in ...4334365325077'4

This is not easy by any stretch of the imagination. However, the notation is still an interesting thought experiment, so I would suggest not to remove it, but just make it a bit more realistic.

Featured quality source review RFC

Editors in this WikiProject may be interested in the featured quality source review RFC that has been ongoing. It would change the featured article candidate process (FAC) so that source reviews would need to occur prior to any other reviews for FAC. Your comments are appreciated. --IznoRepeat (talk) 21:33, 11 November 2018 (UTC)

Boldface for computational complexity classes

In computational complexity theory it's traditional to denote complexity classes by short, inscrutable, boldface, all-capital abbreviations. Of course (as a project and an encyclopedia) we have to decide what is right for us. At the moment our articles are split between boldfacing complexity classes throughout (e.g., RE, AM, UP, PH, ⊕P, PP, ♯P, IP, ZPP, BQP, NC, L) and leaving them in standard type (e.g., EXPTIME, R, P, NP, PSPACE, APX, AC⁰). It would be nice to have a style guide imposing uniformity (or at least admitting to the current lack thereof).

Thoughts?

CRGreathouse (t | c) 07:06, 7 January 2019 (UTC)

Prefer normal weight. Boldface might be fine in a textbook, if you have complete freedom to choose other style elements. In a Wikipedia article it's too overloaded. --Trovatore (talk) 07:59, 7 January 2019 (UTC)

I'd be okay with sans-serif (in particular the LaTeX command \mathsf), as that's the convention used by many papers/textbooks. I don't think we should use boldface, per the reason given by Trovatore. Enterprisey (talk!) 03:29, 10 January 2019 (UTC)

I'm happy with just one vote, if it's Trovatore's, but I'd like to have somewhere to point to other than this Talk page before I start making changes. Is there a good subject-specific MOS somewhere? - CRGreathouse (t | c) 01:08, 11 January 2019 (UTC)

I agree with Enterprisey (talk · contribs) that \textsf is the most common convention (e.g. ${\textsf {NP}}$ instead of NP or NP); but for Wikipedia articles, this may be too distracting. I would be fine with normal weight text in running text, and \textsf inside of formulas on their own lines. I do think, per CRGreathouse (talk · contribs), that we should add this to an MOS -- perhaps a new section in Wikipedia:WikiProject Computer science/Manual of style? BenKuykendall (talk) 17:33, 18 February 2019 (UTC)

First choice for me is normal weight text font. Second choice is \textsf in a math formula. (I have different publications with different choices of these conventions, and in my own publications prefer \textsf but here I think the convenience of normal text outweighs the visual distinctiveness of \textsf, which is anyway much smaller than usual because most Wikipedia display styles use sans-serif body text.) Far behind either of those is bold. But behind even boldface is the current mess of sometimes bold and sometimes not. We should standardize this. —David Eppstein (talk) 18:50, 18 February 2019 (UTC)

If "inscrutable" is a term of art regarding fonts, it's one I've never come across... Do you mean "sans-serif" ? Regarding the question, I too would favour normal text font; \textsf is fine within a formula, but frankly I don't give a hoot, so long as it's clear what is meant, and it's consistent *within an article*. — Gamall Wednesday Ida (t · c) 19:29, 18 February 2019 (UTC)

@Gamall Wednesday Ida: I believe the "inscrutability" is due to the overwhelming number of (perhaps unfamiliar) initialisms; not due to the way we typeset them. This issue is perhaps avoidable, if we commit to referencing complexity classes by name (e.g. non-deterministic polynomial time instead of NP) but I do not think this would be a good policy. Wikipedia already has guidelines about the use of acronyms: MOS:ACRO (in summary: write out all but the most common acronyms in full in the first usage). BenKuykendall (talk) 20:53, 18 February 2019 (UTC)

Complexity class names like EXP and PSPACE are not acronyms. —David Eppstein (talk) 21:59, 18 February 2019 (UTC)

Oh, I see. Or rather I don't see how they are more -- or less -- inscrutable than any other jargon. I'm also not convinced that spelling them out -- even on first usage -- is likely to be useful; especially for the most common ones. If the reader cares AND they are not familiar with NP yet, then they need a lot more than a few extra words (that were already available on mouseover anyway) to understand what NP actually means. Actually, in the case of NP, I imagine that many, many, *more* people might know the class just as "NP" rather than as "non-deterministic polynomial time". For something more esoteric like ⊕P... that's certainly a class I for one didn't know, and "Parity P" helped me naught in guessing its definition. So yeah, I've trouble imagining a likely usecase where spelling them out might be useful. — Gamall Wednesday Ida (t · c) 02:42, 19 February 2019 (UTC)

Human Interaction Proof

Was wondering if someone from this WikiProject would mind taking a look at this new article and assssing it. It looks like a first attempt at writing an article by a new user. Subject matter seems quite technical, and it reads more like an academic paper than a Wikipedia article. I tried to do some basic formatting cleanup, but perhaps someone here is familiair with the subject matter and can help with the phrasing, etc. -- Marchjuly (talk) 02:16, 10 January 2019 (UTC)

The article contains a huge fork of CAPTCHA, which must be trimmed mercilessly. That done, we may take a closer look whether it is OR or covered somewhere else. Unfortunately I cannot do this due to computer access impairment.- Altenmann >talk 05:27, 10 January 2019 (UTC)

Missing deep learning topics

• GoogLeNet
• R-CNN
• Fast R-CNN
• Faster R-CNN
• Mask R-CNN
• RetinaNet

Articles about many notable deep networks are not created. --Sharouser (talk) 12:18, 18 February 2019 (UTC)

Weird Article alerts behavior

Why is Pareto efficiency listed under PR but the discussion link is broken? Qzekrom (talk) 02:16, 19 February 2019 (UTC)