User talk:Elphion/Archive 3

Archive 1

Archive 2

Archive 3

Disagreement

Hi, I just wanted to let you know that I'm sorry about the contentious nature of our disagreement on Talk:Saruman. I hope we can get past this and work together in the future. 74.109.214.27 (talk) 16:35, 3 February 2011 (UTC)

Since you (very handsomely) struck out your remarks on Carl's page, I won't answer them -- except for this point: it was precisely because you pleaded inexperience that I thought it important to point out why your remarks constituted "original research", a concept most new editors (and a lot of experienced ones) don't quite get. As original research, the conclusion would not be appropriate for the article, and the discussion even arguably not appropriate for the talk page. (See WP:TALK: the talk pages are not intended for blue-sky discussions -- though it's a temptation all of us succumb to from time to time.) It was meant solely for your information, never as a rebuke. There are plenty of snarky editors on WP, but I try not to be one of them. -- Elphion (talk) 18:42, 3 February 2011 (UTC)

Oh, and: it's traditional to add a welcome comment to a new editor's talk page (though frequently we don't bother until the editor gets a user id). It's a bit late to add something like that to your page, but consider yourself welcomed -- if sort of baptized by fire! -- Elphion (talk) 18:42, 3 February 2011 (UTC)

I had a notion that it would fall under WP:OR, and I had read a lot of the policies before I began writing at all. But, I wasn't sure to what extent OR was permitted or not permitted on a talk page for the purpose of exploring what can be said definitively about a particular subject. As for baptism by fire, I'd say it's fine. As to why I don't have a user id yet, well, probably laziness. 74.109.214.27 (talk) 19:33, 3 February 2011 (UTC)

Rings of Power

Thank you for your contributions. Please remember to mark your edits as "minor" only if they truly are minor edits. In accordance with Help:Minor edit, a minor edit is one that the editor believes requires no review and could never be the subject of a dispute. Minor edits consist of things such as typographical corrections, formatting changes, or rearrangement of text without modification of content. Additionally, the reversion of clear-cut vandalism and test edits may be labeled "minor". Thank you.

I viewed the edits you made to Rings of Power as not Minor edits. If you disagree please explain why and place a {{tb|Elphion}} tag on my talk page. I kept your edits because they looked good.Etineskid (talk) 23:13, 9 February 2011 (UTC)

The rewrite I did not mark minor. The others truly are minor. Which do you think are not? -- Elphion (talk) 23:20, 9 February 2011 (UTC)

I looked at the edits you did shown on the right side of the Diff page. They seem to be quite a few edits. You changed "destroy" to "forestall him by destroying" you added "until the end of the book". Your edit adding [[ and ]] to "Rivendell" would of been fine and where you added a comma is fine but the others are pretty major. Again let me know when you reply.Etineskid (talk) 23:43, 9 February 2011 (UTC)

They still look minor to me. The bit about not visible until the end perhaps less so than the others, but still hardly worth bothering about. What sense of the article have I changed? As the guideline says, there is gray area, and I'm probably somewhat over the line, though I think not by much. I do appreciate your feedback, and I'll think a bit longer before clicking the "m". -- Elphion (talk) 23:54, 9 February 2011 (UTC)

LZ77 and Deflate

Thanks for the correction on the LZW page! Do you think we should un-delete the text I deleted, claiming that LZW achieved the best compression ratios at the time? Because it's the Deflate (Huffman∘LZ77) algorithm that I was comparing. But sure enough, the original Ziv and Lempel paper describes an approach using fixed-width codewords in its output, and all of its compression claims are based on that. Does that approach measure up to LZW, in compression if not in speed?

Also, do you think it's worthwhile mentioning at that point that Deflate is Huff∘LZ77? I think it's interesting and somewhat ironic that LZW was displaced by, more or less, its own progenitor — once computers were fast enough.

Kragen Javier Sitaker (talk) 03:50, 28 February 2011 (UTC)

LZW was invented as an acceleration of LZ78 (via use of hashing to speed up the dictionary searches in the encoding process). This is generally faster than LZ77, especially when the latter is combined with Huffman coding as in DEFLATE (and therefore in PNG). Use of Huffman can achieve better compression ratios than LZW/LZ78, but it is also almost always slower to encode than LZW. (The difference is particularly noticeable when generating web images on the fly -- generating GIFs is always faster, by enough to make PNGs unusable for such an application on a high-volume site.) So there's a trade-off: if you want higher compression ratios, use DEFLATE; if speed is paramount, use LZW.

But DEFLATE gained traction primarily because of the copyright problems with LZ78/LZW -- first (and very noisily) in PKZIP, then in PDF and PNG -- not because of the better compression ratios. LZ78/LZW is still simpler and faster. These days, as the volume of material shipped around on the web has grown so much, compression ratios have become more important, but it was the copyright problems that started it all off. Why not apply Huffman coding to the output of LZW, after all?

The text you removed was probably technically incorrect anyway -- it's been known for some time that tuned Huffman coding yields the best possible compression, though at the time it probably was not available in an efficient commercial form. The reason LZW was so popular is that it is easy to implement, generally faster than most alternatives, and yields reasonable compression on a wide variety of data -- especially textual data, which was what it was primarily used for before GIF came along. All of that remains true today -- I think it's premature to write its obituary!

I don't know how the compression performance of LZ77 compares with LZ78. Welch's IEEE paper looks at comparison with other techniques, but it was all heuristic, not theoretical, and I don't remember whether he talked about compression in addition to speed. I wouldn't go into a lot of detail about DEFLATE in the LZW article, but saying that it's based on LZ77 might be of interest.

-- Elphion (talk) 07:35, 28 February 2011 (UTC)

I agree with your assertion about why LZW was originally popular, and that it remains popular.

For what it's worth, though, these days, there are a number of fast alternatives other than LZW, including LZO, LZF, FastLZ, and QuickLZ. Last time I benchmarked QuickLZ, I think it was considerably faster than compress, but maybe compress is not the most highly tuned LZW implementation?

Also, there are a number of practical algorithms now that fairly reliably get better ratios than Deflate, such as LZMA.

I don't think there were any copyright problems (algorithms aren't copyrightable) and I don't think the patent problems were with LZ78, only with LZW. You are certainly correct that the patent problems were a significant reason for people to switch from compress to gzip, but this was around 1995, so computers were already thirty times faster than when LZW was invented.

I haven't tried huffman-coding LZW output. Does the compression ratio improve if you do that? compress does do a clever huffman-like thing that is guaranteed to improve the compression ratio over straight LZW --- the first 256 tokens are represented in 9 bits each, the next 512 in 10 bits each, and so on.

I haven't heard of "tuned Huffman coding". Do you mean adaptive huffman coding? I'm pretty sure both Burrows-Wheeler and PAQ outperform adaptive huffman on real-world data, and of course there's no theoretical ideal to fall back on, since nothing can compress uniform random data, so we're left speculating on what kinds of redundancy might or might not exist in real-world data. You can prove that any compression algorithm is optimal if your model of the redundancy that exists in the data perfectly matches what kind of compression the algorithm performs, although that's more natural with things like huffman coding (really, arithmetic coding) or the BWT than with LZW. The Hutter Prize speculates that the problem is AI-complete.

Kragen Javier Sitaker (talk) 03:15, 1 March 2011 (UTC)

(outdent) Sorry, I meant "patent", not "copyright" -- a slip of the brain. LZ78 was indeed patented, as noted in the Patents section of the LZW article, which gives a link to the patent. -- Elphion (talk) 09:42, 1 March 2011 (UTC)

Animated GIF listing

Thread moved from my talk page. Cuddlyable3 (talk) 00:52, 13 March 2011 (UTC)
Fair warning: would you like to revise the animated GIF listing at Graphics Interchange Format before I take a crack at it? -- Elphion (talk) 22:28, 12 March 2011 (UTC)

I created the animated GIF listing. Cuddlyable3 (talk) 00:52, 13 March 2011 (UTC)

Yes, I know. That's why I'm letting you know I intend to edit it, in case you'd like to make any changes first. -- Elphion (talk) 01:17, 13 March 2011 (UTC)

The Chronicles of Narnia

Hi - noticed that you've dropped in a few edits just now. No problems with them, but would you mind holding off on any more until the Copy Edit is completed? There's a tag at the top of the page. Thanks! -- Jake fuersturm (talk) 00:04, 30 March 2011 (UTC)

My edits were in areas that are not copy (the info box) or where the editor had asked for clarification. -- Elphion (talk) 00:10, 30 March 2011 (UTC)

Fair enough, but still risked an edit conflict, no? given that those edits were in a non-section -- Jake fuersturm (talk) 00:12, 30 March 2011 (UTC)

Unlikely, for the reasons mentioned -- but I'll desist for now. (I never actually read that tag before. Case of the boy who cried "wolf", I'm afraid -- tags have gotten to be like so much background noise on WP.) -- Elphion (talk) 00:26, 30 March 2011 (UTC)

Goths

Thanks for explaining! I didn't know that. 98.82.193.135 (talk) 15:08, 17 April 2011 (UTC)

Yes, it would have helped if the original revert had cited WP:OVERLINK. Unexplained reversions can be very frustrating. -- Elphion (talk) 16:23, 17 April 2011 (UTC)

License tagging for File:Quilt design as 46x46 uncompressed GIF.gif

Thanks for uploading File:Quilt design as 46x46 uncompressed GIF.gif. You don't seem to have indicated the license status of the image. Wikipedia uses a set of image copyright tags to indicate this information.

To add a tag to the image, select the appropriate tag from this list, click on this link, then click "Edit this page" and add the tag to the image's description. If there doesn't seem to be a suitable tag, the image is probably not appropriate for use on Wikipedia. For help in choosing the correct tag, or for any other questions, leave a message on Wikipedia:Media copyright questions. Thank you for your cooperation. --ImageTaggingBot (talk) 03:08, 24 May 2011 (UTC)

Well done with this image you made. Cuddlyable3 (talk) 07:08, 31 May 2011 (UTC)

Thanks. First image I ever uploaded. I used your hex dump as a model to spiff up the image info. -- Elphion (talk) 16:45, 31 May 2011 (UTC)

I adjusted "raster" to "raster line" because a raster is defined as the full set of image lines. Cuddlyable3 (talk) 07:34, 1 June 2011 (UTC)

Yes, that's OK and clearer; though, honestly, in actual usage I've never heard "raster" used for anything other than a single raster line.

File:240x340x128-color uncompressed.gif

The image looks ok on this page

I tried to make a larger uncompressed gif 240x240x128-color. The file is 58,933 bytes.
I wonder whether we have missed something because it displays differently in these programs:

• The image looks ok on this page.
• PAINT in Windows ME: Shows only the upper 204 lines
• PAINT in Vista: Cannot read file
• My computer - preview in Windows ME: Shows whole image
• Computer - preview in Vista: Shows whole image
• Extra large icon in Vista: Shows about 240 lines
• The GIMP: Reports "Ran off the end of my bits" and cannot open the file
• IRFAN - Shows whole image and can resave correctly as a compressed gif.

I hope you don't mind me asking you to look at this. I could send you the file. Cuddlyable3 (talk) 11:38, 13 June 2011 (UTC)

It's just a glitch in the sub-block chain. The byte count for the last sub-block before the 2-byte STOP sub-block should be 0x64, not 0x65. (0x65 incorrectly includes the length byte in the count.) Cheers, -- Elphion (talk) 17:54, 13 June 2011 (UTC)

Thanks. That correction fixed my file to pass all the tests except The GIMP which must have a bug including an updated version 4.6.11 of The GIMP. Cuddlyable3 (talk) 20:23, 14 June 2011 (UTC) I corrected my post by striking. Cuddlyable3 (talk) 19:09, 15 June 2011 (UTC)

Isn't "running off the end of the bits" how a buffer overflow attack would work?83.216.149.7 (talk) 22:03, 9 December 2011 (UTC)

I think what Gimp meant is that it reached the end of the file ("the end of the bits") without finding the terminating sub-block for the image data -- so it knew something wasn't right. (My guess is that Gimp creates a table of offsets into the image data sub-blocks before processing the data.) The alternative is to stop processing data once the requisite number of pixels are filled -- which is how the other programs managed to cobble together something to display. Certainly there's potential for overruning a buffer (say, Gimp's sub-block table) if you blindly continue to generate the table without checking to be sure that you still have space in the table, but I doubt that's what's going on here. Gimp just found the file structure corrupt. -- Elphion (talk) 22:59, 9 December 2011 (UTC)

Middle-earth consensus

Hi there Elphion, looking at the guidelines for the middle-earth project, specifically the discussion about using past tense in the articles. Looking at the debate it only consists of four users, this seems a bit small to create a consensus that overrides community standards. Do you know any other discussions that went on? Cheers Carl Sixsmith (talk) 20:12, 9 September 2011 (UTC)

No, I always assumed that was settled long before my time. -- Elphion (talk) 22:24, 9 September 2011 (UTC)

CS Lewis

Please stop your disruptive editing as you did to CS Lewis. If you continue to vandalize Wikipedia, you may be blocked from editing. 143.239.7.3 (talk) 19:47, 10 November 2011 (UTC)

I have no dog in this fight, but the referenced edit by Elphion was definately not vandalism, and in fact followed the discussion on the talk page (no consensus.) It would appear to be a POV warpath on the part of 143.239.7.3. 78.26 (talk) 20:19, 10 November 2011 (UTC)

Giant impact hypothesis

The figure that was removed was from a paper by Belbruno and Gott (2005) and assumed that the Moon-forming impactor came from the L4 or L5 Lagrangian point. However, no one has ever demonstrated that a planetary embryo could grow at these regions of space. The N-body simulations of others (i.e. Chambers 2001 and others) have never discussed such a possibility. Hence, the relevance of this paper to the question of lunar origin is dubious. — Preceding unsigned comment added by Thekaveman (talk • contribs) 03:44, 30 November 2011 (UTC)

I've started a section at Talk:Giant impact hypothesis and copied your response above to that page. See my response there. -- Elphion (talk) 08:09, 30 November 2011 (UTC)

Thanks for Uncompressed GIF

Just wanted to say thanks for making that. I'd never considered the possibility of making an uncompressed GIF but the technique makes absolute sense. I've added it to my image test suite and plan to write some code to save uncompressed GIF as a speed optimisation. 83.216.149.7 (talk) 19:24, 9 December 2011 (UTC)

You're certainly welcome! I hasten to add that the technique was not my idea; it surfaced about the time the patent issue for the compression algorithm blew up. Also, when you say "speed optimisation", be aware that the file transfer speed (obviously proportional to space) will probably not be optimized: uncompressed GIFs often run up to ten to twenty times the size of regular GIFs, depending on the characteristics of the data. -- Elphion (talk) 19:34, 9 December 2011 (UTC)

It's supposed to be a saving of compression/file time. It's not so relevant to GIF, more of a PNG or JPEG thing. The time to write the bigger file might remove any gain from not compressing. I suppose the uncompressed GIF would be simpler to load.83.216.149.7 (talk) 22:10, 9 December 2011 (UTC)