Talk:Semordnilap
Ruby Implementation
Do we really want literal copies of the dict file on the task page? --Rdm 13:58, 10 September 2012 (UTC)
I added a note to the submitters talk page and have chopped most of it from the example for now. --Paddy3118 17:13, 10 September 2012 (UTC)
What sort of a world is it where if someone says your dict looks big an Irish number chops it? From http://rosettacode.org/wiki/User_talk:Nigel_Galloway#Huge_Ruby_example I see I have two choices:
- A) modify it to read the dict from a file
- B) move it to a sub-page on its own
I choose C. Well B+ really. The + is, it finds a use for history, which I see relied on too often.--Nigel Galloway 11:53, 12 September 2012 (UTC)
- Does this mean you like pages being really big and slow to load (and perhaps enough to crash some phone browsers)? If so, perhaps we could all include a copy of that same dictionary in each implementation on the task page? As an upper bound (99 bottles of beer has what... 200 implementations?) the task page probably would not get too much bigger than 40 megabytes...
- That said, you also left out choices D), E) and F) (fetch dict from the url every time the code runs, or represent dict as a compressed blog, or do not bother implementing the task and let someone else do it). And, if we put some thought into it, we could probably come up with a G), H) or I) also. Maybe H) can be your "look up the big version in history"? --Rdm 12:28, 12 September 2012 (UTC)
- Hi Nigel, as I tried to explain, we try not to have overly large examples, and if you look around, those measures I outlined are used by others when they have large examples to post or others may create sub-pages for them without the snide remarks.
- There are other examples and tasks that use the dictionary and yours is the first example that chose to stick the whole dictionary in the source code. The program you wrote may work, but that is not the only consideration for its inclusion, we also like to have a main task page that doesn't put undue load on browsers and ~200K of source I thought was too much. (The line length was excessive too). --Paddy3118 16:47, 12 September 2012 (UTC)
- P.S. If you think the site makes the rules up as it goes along, then in essence you are correct. The users are encouraged and empowered to make RC 'better'. We may struggle at times, but I think Rdm and I made a reasonable request, and made an appropriate change. --Paddy3118 16:47, 12 September 2012 (UTC)
- Nigel, relying on page history that way slams my server. Seriously. Don't do that. MediaWiki only stores the most recent revision verbatim, and diffs from one revision to the next. In order to show a page fifteen revisions old, the server has to apply fourteen diffs. As for the rest of it, I recommend modifying the task to read from a dictionary file. Most non-Windows systems have a words file handy, and a link can be provided to the remainder. --Michael Mol 17:10, 12 September 2012 (UTC)
well formed dictionary
Perhaps this may be too general a statement, but I wish the dictionary specified would have capitalized or uppercased words in it (along with some words that have a blank in it, hyphenated words, words that start with an apostrophy ['til]) to test the program's metal a wee bit. Having words that may be capitalized would make the dictionary more realistic, or more to the point, make the program more realistic. This would mean having words like god and God in the dictionary (not to mention I), and thereby causing programs to handle "duplicate" words, and be sensitive to word case. Also, a true dictionary would have multiple entries for nouns vs. verbs and also homonyms (which would look like two different words), but in a dictionary that only lists unique entries, that might be moot here. Having a list of words, with each section (A,B,C...Z) separated by one or more blank lines would also be common. Having a well formed dictionary just allows programmers to assume too much (such as the words being in some kind of alphabetic order). But assuming everything will be in lowercase just makes for lazy programming (and I'm not saying that in a perjorative way). I don't think programming examples should be written just for the dictionary supplied, and from those assumptions, start taking shortcuts. I wrote the 2nd version of the REXX example to handle all that, with just an extra line of code. I'd also like world peace, ... -- Gerard Schildberger 22:25, 17 September 2012 (UTC)
Dead link
The file to be used for input appears to be missing or blank. I attempted to use a file of the same name I found in someone's github repository, but I am getting different output from the other examples and I suspect it may be a different file. Any advice on how to proceed? --Chunes (talk) 13:37, 3 November 2018 (UTC)
- After some poking around the website, I found this working link: http://wiki.puzzlers.org/pub/wordlists/unixdict.txt. I'll give this one a shot. --Chunes (talk) 13:49, 3 November 2018 (UTC)
Semordnilap Phrases
It's perhaps worth noting that Semordnilap phrases pose something of an open-ended problem (unless a specific phrase length limit is imposed). This would be complicated if there were also a requirement that the phrases represent valid english grammar. Perhaps the task should be clarified to eliminate phrases from consideration? I didn't notice anyone implementing support for them... --Rdm (talk) 02:09, 30 January 2020 (UTC)
- Semordnilap phrases is not just an "open-ended problem"; the problem is not even well-defined, and thus open for interpretation.
- Your interpretation, I assume, is that a Semordnilap phrase P is a concatenation of some words x1...xm contained in the dictionary (possibly delimited by punctuation such as spaces, commas, etc.), such that its reversal rev(P) = rev(xm)...rev(x1) is also a concatenation of some words in the dictionary, viz rev(P) = y1...yn for some words y1...yn in the dictionary. In other words, if you remove all punctuation from a Semordnilap phrase and reverse it, then you can divide the resulting word into one or more words of the dictionary. It is obvious that there are infinitely many such Semordnilap phrase pairs, so as you mentioned, a phrase length limit should be imposed.
- My initial interpretation was that a Semordnilap phrase is a phrase contained in the dictionary (eg. a phrase forming one line of the dictionary file). Then there are finitely many such phrases (assuming a finite dictionary), and phrase X is a Semordnilap of phrase Y iff X stripped of punctuation equals the reversal of Y stripped of punctuation.
- Your interpretation is, of course, more meaningful; but besides the problem of infinite solution space, there is the problem of grammatical correctness of both phrases, which would be rather difficult to deal with. That considered, I suggest removing the mentions of "phrases" from the task description altogether, and perhaps clarifying that dictionary entries are simple words (not containing any punctuation). Dick de Bill (talk) 13:52, 3 February 2020 (UTC)