in reply to Re: Re: Re: Re: Re: Re: Re: (Golf) Warningless Comparison
in thread (Golf) Warningless Comparison

Wow.

First off, I ++'ed this. At least now were debating/discussing properly.

To me this is all very ironic as I thought your solution and the test scenario you had written were interesting, and when I enhanced them and found issues and then posted them for discussion/review i fully expected an "isn't that interesting, well then lets see what we can learn from this." Instead you went into attack mode. First by saying I was changing the rules (hardly, they are written quite clearly), and then following that course with some pretty offensive comments like the DUKW nonsense. So not being one to back down I instead proceded forward. Adding test cases and refining the test scenario. I even figured out why you thought your code worked, and why I didnt, and posted it too. So ultimately what I thought would be a bit of golf sparring turned into a bitch fight. A bitch fight frankly you lost. And badly. The test cases prove my point and prove it well. Sorry but thats my opinion.

Now to deal with your comments.

Is the use of -w an acceptable alternative to use warnings in a golf contest.

In a golf contest that specifically states use warnings; I believe not. In a contest that specifically states "under -w" I believe so. In a contest that states "produces no warnings" or the equivelent then Id be willing to go both ways. This case is pretty clear to me, but I will bow to tadmans decision.

Is it legitimate to invent additional criteria that your entry passes in order to depose other solutions on the basis that your complying with "the spirit of the challenge". I think not. You obviously have your opinion.

Yes I do. And part of it is that I think yours is fundamentally flawed. Imagine if I post a golf challenge Produce the smallest script that you can that will add two numbers together correctly and return the result. Ie 1+2=3 3+4=7 So by your interpretation as long as your code will return 3 when passed 1,2 and 7 when passed 3,4 then it is a correct solution. But what happens if it returns 0 for all other cases? Or that it returns 42 when passed 4,3? Are we to consider this as correct solution. No I dont think so. And if you review the various golf challenges that have been made in the past you will see the precedent is on my side. People often provide new test cases that break posted solutions. It keeps people on their toes and it keeps them from accepting bogus solutions.

Is correct to take code intended for one context, move into a different context, take no steps to adjust it for that new context and then claim it fails?

What I should have rewritten your code to not use $^W? Whatever. To me this is just a rehash of point 1 that you made.

"to suppress the warnings" you said

Er no. Not once did I say "suppress warnings". Not once did I say the word "suppress" even. In fact every instance of that word was to found contained within your posts not mine. And in a contest that says "produces no warnings" then who cares _what_ the warning was, surely only who generated it is relevent?

but the net effect of that particularly convoluted peice of code in conjuction with an eval, is that you not only suppressed the standard warning text just to replace it with your own.

Nope. Never at any time did I replace a warning with another. I graduated the warning to a die() so that a given sub could only produce 0 warnings and survive the test. What use are 10 lines of the same warning? Also in the last test code I posted it prints out the sub name and the warning. But to me the key point was that the sub produced warnings therefore it failed the test.

You also suppressed the output from the code which demonstrated that it met the stated requirements <cite>"returns 'aa,cc,dd,ff,hh',</cite> by doing a '<cite>warningless comparisons</cite>'.

All I did was add a warnings handler that would clearly indicate which subs generated warnings and were thus not sufficient solutions. Im sorry that I didnt take the time to show both whether warnings had been produced, and what the functions had returned. But you had my code, why didnt you make the change and post it as a "fairer picture" or whatever? I wouldn't have minded.

In never said, nor meant to imply that this was a deliberate act, but why what you did do, was any better that allowing the warnings to be displayed alongside the output, I don't understand. Aesthetics?

Well I suppose, I have to admit I was more thinking utility. I think that "main::Foo() generated warnings" is a little easier to read and post than "use of unitilized string on line 22" or whatever. To be honest I thought you might have been impressed as personally I thought it was quite clever and quite reasonable given the criteria of the contest.

Worse, not only did this hooky arrangement do this, it also suppressed many other flaws in your testcase which came to light when I disabled it. You subsequently blame these on "that annoying bug in elusion's code".

Well first off let me illustrate the bug in elusions code. The following cut down version of my test case is sufficient to illustrate it.

use warnings; use strict; use Carp; use Data::Dumper; local $SIG{__WARN__}=sub {(my $str=join(" ",@_))=~s/[\n\r]//g;die("\t@ +{[(caller(1))[3]]}() => $str\n")}; my $foo = { aa => { O => 'zz', C => 'yy' }, # bb => { O => 'xx', C => 'xx' }, }; sub mysort {return sort {$a cmp $b} @_} sub eg_{my$h=pop;grep{!(($h->{$_}{O}||$;)eq($h->{$_}{C}||$;))}%$h} print Data::Dumper->Dump([$foo],[qw(foo_before)]),"\n"; eval { print " Elusion golf: ".join (" ",mysort eg_($foo))."\n"; }; print $@ if $@; print Data::Dumper->Dump([$foo],[qw(foo_after)]),"\n"; __END__ $foo_before = { 'aa' => { 'O' => 'zz', 'C' => 'yy' }, 'bb' => { 'O' => 'xx', 'C' => 'xx' } }; Elusion golf: aa
$foo_after = { 'HASH(0x1acf040)' => {}, 'aa' => { 'O' => 'zz', 'C' => 'yy' }, 'bb' => { 'O' => 'xx', 'C' => 'xx' }, 'HASH(0x1acef44)' => {} };
Obviously the original $foo contained no keys like "HASH(0x1acf040)" so Id say that "annoying bug in elusions code" is a pretty fair description. But somehow Im guessing that you looked into this comment about as deeply as you tested your code. Now if the "flaws" in my test scenario that you mention are the result of this bug then Id say im on pretty safe ground.

In fact the only thing that has changed between your latest version and the previous one that produced all the noise (when the signal handler was disabled) is the way your testcase calls the function.

Yes I did the shallow copy trick to keep Elusion from poluting the hash so that other people wouldn't get weird results. Thats what the {%$foo} bit does you know.

The very same function that displayed none of the same noise when called in my code?

And the flaw lies where?

You really need to work on your analysis skills browserUK. If you did analyse this stuff properly you would see that Elusions solution was the _last_ solution to be tested in your framework (the Aristotlean solution was commented out remember?) so you plain and simply werent testing to see if the hash had been corrupted. As I didn't change the solution except to pull whitespace out it has the same error. It would be visible by repeating my Dumper test, or of course by simply calling his solution first. All the following (working) solutions would produce keys like 'HASH(0x1acef44)' in addition to the keys one would expect. So the flaw is quite simply in the solution that you wrote with Elusions name on it.

your own efforts fall short of that by using $a and $b without localising them.

Ah! A lovely bit of cargo cult programming. It is true that using $a and $b is a bad habit that many, including me, try to point out to beginners as being a "verbotem". But that is primarily because beginners deal much better with hard and fast rules like "dont do that" instead of "there are a few subtle scenarios where you have to be careful about doing that". The truth is that the only place you really need to worry about $a and $b is when they are used as lexical variables in the same scope as a call to sort that uses them as well (sort access the GLOBAL's and the lexical's would mask them), or when you want to use the global $ab and $b for long term storage. Thus it is strongly recommended to beginners not to use $a and $b at all. This is similar to the approach taken with symbolic references. Typically people say "dont use them, they are evil". But if you look under the hood they are used all over the place, and often by the very same people who are found saying "symrefs are evil". So in this case its one of those "dont use them until you understand why you should tell people not to use them." Since I was using the global $a and $b there is no problem. In fact using these variables as temps makes quite a bit of sense, as they shouldn't ever be expected to maintain their state across scoping boundaries. Thus if someone is using them to keep important data and I have clobbered it then it is their problem not mine. But for me, Ive used them strictly in a write-then-read fashion which is perfectly safe.

Whilst, using -w; (very oft advocated advice here) & scoped $^W=0; as opposed to use warnings and scoped no warnings; may be seen (by some) as "creative interpretation" of the rules, it seemed to me to be well within the bounds of similar tactics used to reduce keystrokes in Perl golf. I'd remind you that the first word of the title of the original post was "(Golf)...".

Yes GOLF was the first word, and "Warningless" was the second. So dont you think that hoping to get the rules interpreted so that "warningless" == "under -w" instead of "warningless" == "produces no warnings under any circumstances" is kind of like cheating? I mean it only represents %33 (if not less, i havent considered -W) of the situations where warnings will be generated. Cmon, dude. You should have stuck your hands in the air and said "busted, i didnt think of that" and we all would have had a good laugh and maybe worked out an even cooler solution than any of those posted so far.

Your imposition of additional rules is an entirely different kettle of fish. My comments regarding those additions were intended as light-hearted analogies, not insults.

Well, Ive already dealt with the "additional rules" argument in enough ways that im not going there again. As for your comments, I say Balony. Sorry, but those were intended to piss me off. I think that anyone reading these posts would see that.

It appeared, and still appears to me that your code, rather than a simple attempt to extend mine, served only to support your interpretation of the rules and lay claim to the technical high ground.

Er the only code of yours that I extended was the test framework. Both of my solutions were reworks of code that I had written a long time ago for something else. (Broquaint would probably be able to bear witness of that. In the test code for BFDump I had to deal with a similar scenario, and I think you will find code might similar.) As for "support my interpretation" I think the issue is clear. My dex() solution is the only one besides tadmans that handles all of the test cases (including late additions). And it is the ONLY one that handles an existance mismatch going either way. (Yes i realize this was not necessary. But I saw no point in rewriting it.) Furthermore it generates not warnings under any circumstances. All of yours either generate warnings, fail to handle all of the possible cases, or both.

"Ah! But your breaking the rules by using -w instead of no warnings;";

Actually it was only after your reply that I looked into the matter. So I didnt know why, all I knew was that when i ran the test it didnt do what I expected. And I said to you

I suppose I should have stuck some emoticons or something in there, but note that I said "unfortunately" and "Guys". The first being that I regretted having to tell you, and the second being a comment to all and sundry. Both I though were reasonable, and while not being overflowing with niceties were hardly an attack. (In fact I more thought that it would be obvious to anyone that I wouldnt have wasted my time adding and enhancing your test framework if I didnt think it was interesting/respectable or whatever.)

You scolded me for not testing my code, which I had.

You and others missed out important test cases (undef versus the empty string, note that tadman himself makes a similar point about undef vs 0). Furthermore, i didnt make that comment to you directly but to all who participated in the thread. This is a learning site. You may be a saint, but that doesnt mean you dont have anything to learn. And frankly pointing out that peoples testing isn't as thorough as it should be can hardly come as a suprise to any experienced programmer.

You stated categorically that it did work, when the output matched those specifed exactly.

Im not sure I understand this (typo perhaps). You are correct. I catagorically stated that your code didnt meet the requirements. I stand by that. And frankly should the situation been reversed I would've said "oops, shit yeah thats true, I didnt think about that."

You stated, not even implied, that I didn't understand the difference between -w and use warnings;

Yes and I stand by that as well. Clearly you didn't. In fact id be suprised if many monks know all of the intracate details and differences. I know that I had to look up the finer points. And frankly anyone reading this thread knows the value of your claims to the contrary.

And then take umbrage when I have temerity to challenge your conclusions.

No I took umbrage when I found myself in a fight I thought was a conversation. I took umbrage when you tried to tell me your code didnt generate warnings, when i had just posted code that demonstrated the contrary. I took umbrage with your quite rudely telling me I was changing the rules when in fact you yourself were quietly interpreting the rules as suited you.

Hardly friendly.

I think taking someones posted code, adding stuff to it and posting it back can hardly be considered to be an unfriendly act. Especially not on a site like this. Furthermore go and review your replies. The very first words you stated were

Well personally I would say that first line is hardly a friendly rejoinder. And id say the second displays a lack of understanding of the warning system. The localization had no effect. And if -w is a fair interpretation of the rules then so is "use warnings;" and under the later you clearly were generating warnings. Note that you didnt say. "Er yeah, good point, mine is only warning free when used _without_ use warnings;" or anything like that.

Everything else that I'd like to say in response your last outburst, would be futile and unprofessional.

Well, then nuff said.

No, I do not retract!

Thats ok. You've already said enough foolish things that no retraction is necessary. Any sane observer will give the comment to which I refered the merit it deserves.

For my part I regret this entire thing. I thought that this might end up in a neat little analysis of some cool solutions, instead it degenerated into a debate of the rules of golf and the meaning of use warnings;. Hardly the most profitable use of either of our time.

FWIW, I honestly do wish you a good evening. (or localtime())

---

demerphq
my friends call me, usually because I'm late....