Jump to content

User talk:CBM

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 71.141.88.54 (talk) at 05:07, 4 March 2011 (→‎User:WP 1.0 bot/Tables/Project/Pokémon). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

m:User:CBM Please leave new comments at the bottom of the page, using the "new section" button at the top of the page.

I will respond on this page unless you request otherwise.

Archives
1 2 3 4 5 6
7 8 9 10 11 12
13 14 15 16 17 18


My ANI

It seems right that I tell you I closed the ANI you opened against me. I know this isn't the norm and is typically discouraged (partly why I am telling you I did it). My AWB rights are revoked, I am retiring and no longer editing and I think at this point everyone has said what they needed to say. There is no reason to take up all that real estate on the ANI page for what amounts to beating a dead horse. If you disagree feel free to revert my changes. --Kumioko (talk) 16:02, 25 February 2011 (UTC)[reply]

Does noncomputable imply PSPACE-hard?

this is not obvious to me. --Trovatore (talk) 23:26, 28 February 2011 (UTC)[reply]

Say A is a set in PSPACE; in particular A is computable by some index e. Then given a string s, we just need to determine whether program e will halt on input s and return 1. There is an index for a program i that halts if and only if this happens, and moreover an appropriate i can be uniformly computed from s such that its length can be bounded by a polynomial of the length of s as long as we have a reasonable Goedel numbering (this is a polynomial-time version of the s-m-n theorem). So there is a polynomial-time many-one reduction of A to the halting problem. — Carl (CBM · talk) 02:19, 1 March 2011 (UTC)[reply]
Oh, that I believe. But I don't see why just any noncomputable set should be PSPACE-hard, as you seemed to suggest in your edit summary. --Trovatore (talk) 02:24, 1 March 2011 (UTC)[reply]
That edit summary not really accurate. I doubt that every noncomputable set is PSPACE hard; I think it should be just an exercise using a Kleene-Post type argument modified to use polynomially clocked Turing machines. But I don't work with complexity theory much so I would have to check the details to be sure. In any case it seems like it should be false. — Carl (CBM · talk) 02:34, 1 March 2011 (UTC)[reply]
I think the answer is "unknown" since P ≠ PSPACE is an open conjecture (that everyone believes is true). If P=PSPACE then obviously every PSPACE problem is already in P without even needing the undecidable set. But intuitively, if every noncomputable set is PSPACE-hard, I think that means PA ≥ PSPACE for a random oracle A, and that inequality looks obviously false, since it would give an immediate distinguisher between a cryptographic hash function and a random oracle, which "shouldn't happen" assuming P ≠ NP or some some slightly stronger version[1] of P ≠ NP. I could also be plain confused about the whole thing. 71.141.88.54 (talk) 00:15, 4 March 2011 (UTC)[reply]

Article Tahash Timeline

Please look at the article Tahash, and on the Discussion Page: "Consensus on Timeline" give your opinion about the Timeline. Thank you. --Michael Paul Heart (talk) 12:42, 3 March 2011 (UTC)[reply]

Possible PR fix?

Hi Carl, I have noticed that occasionally there are PRs which have no PR template on the article talk page. This happened recently on a PR Finetooth opened and when I asked him about it, this is what he said.

It's possible to install (but not save) the PR template on an article talk page, to view it in preview mode, and to click through and fill in the rest of the form without remembering to save on the article talk page. I think that's what I must have done, and I think that's the process that accounts for similar glitches that we see from time-to-time at PR. This is a form of operator error rather than a flaw in the template design, but maybe a guru could make a doofus-proof template that would not work unless saved first.

Does this seem like anything that could be done for {{PR}}? I have also posted this on Geometry guy's page. Thanks, Ruhrfisch ><>°° 14:23, 3 March 2011 (UTC)[reply]

I have one idea, but I need to test it some more. It's not straightforward to detect whether the page is in preview mode or is being viewed in regular mode, but maybe we can find a way to do it. — Carl (CBM · talk) 21:17, 3 March 2011 (UTC)[reply]
It is not a huge problem - happens a few times a month, so please do not spend a lot of time on it, just an idea. Ruhrfisch ><>°° 02:05, 4 March 2011 (UTC)[reply]

The bot has been changing "Pokémon" to "Pokémon". This breaks the links to relevant categories, and is incorrect. This has only happened twice, but I would like to prevent it from happening in the future. Thanks, Blake (Talk·Edits) 01:49, 4 March 2011 (UTC)[reply]

I'd also like to stop it. Unfortunately, it seems to be something changing on the toolserver; the bot code has not been changed at all recently, so there is no reason the behavior should change. I can't manage to figure out what causes it, but I keep trying. The problem is that seems to fix itself, so I can't seem to replicate the next day to figure out what's wrong. I made a change in the bot code just now, and the upload was correct. I will watchlist the page and keep an eye on it. — Carl (CBM · talk) 01:57, 4 March 2011 (UTC)[reply]
I think it's taking an already-encoded utf8 string and re-encoding it for some reason. The unicode to byte conversion at the output side is probably the first place to check. I've seen stuff like this happen in Python (I don't know much Perl) from bogus automatic conversions of ascii to unicode on (say) concatenating an ascii and a unicode string, sort of like floating-point contagion in mixed-mode arithmetic. The problems are intermittent because the conversions only happen with certain combinations of input data. 71.141.88.54 (talk) 03:12, 4 March 2011 (UTC)[reply]
Yes, the problem is double-encoded data. But when the bot code is working for a particular page, and doesn't change, the problem has to be coming from elsewhere. The trouble is too many layers that all try to correct for character sets; if they all just left everything as bytes it would be fine. So I have to either decode the final stuff, or not, depending on how it is by the time it gets to my scripts. The question that I can't answer is what layer below my code is changing. The strange thing is that if I just delete the cached version of the table that my bot created (cached on the toolserver) and have the same code recreate it, the recreated version doesn't have the problem. But the code is the same, so something else is causing it. I will figure it out eventually, but it's got me so far. — Carl (CBM · talk) 03:30, 4 March 2011 (UTC)[reply]
Are any other accented article name affected? Are you getting the titles from the MW API or from SQL or what? Did the problem just appear in the past couple weeks? I've seen some other weird errors since the recent MediaWiki upgrade including problems with piped links, and with edit buttons disappearing. Maybe it's worth asking on the dev irc channel or surfing bugzilla to see if anyone knows anything. 71.141.88.54 (talk) 05:07, 4 March 2011 (UTC)[reply]