I am aware of the differences between -w and use warnings. I chose to use -w and $^W=0 within the localised scope of a subroutine who's sole purpose was to avoid them, which is I think, a legimite tactic given this was golf and only keystrokes count.

The reasons why my (fully tested*) code both produced warnings and apparently failed to produce the desired output, was because you ran it in a context different from that in which it was designed to run and made no attempt to correct for that change of context in any meaningful way.

In fact you deliberately suppressed the (correct) output for reasons I can only speculate on.

vis.

#! perl -w
use warnings;
use strict;

my $foo = {
  aa => { O => 'zz',  C => 'yy'  }, #
  bb => { O => 'xx',  C => 'xx'  },
  cc => { O => undef, C => 'ww'  }, #
  dd => { O => 'vv',  C => undef }, #
  ee => { O => undef, C => undef },
  ff => {             C => undef },
  gg => { O => 0,     C => 0     },
  hh => { O => undef, C => 0     }, #
};

#234567890123456789012345678901234567890123456789012345678901234567890
+1234567890123
sub f{no warnings;$a=pop;grep{!exists$a->{$_}{O}or$a->{$_}{O}ne$a->{$_
+}{C}}keys%$a} # 83!

print "@{[f($foo)]}\n";
__DATA__
C:\test>201598
dd ff aa hh cc
C:\test>
[download]

Even in this form, it still complies with the original spec and comes in at 83

*My original post contained both fully working program and its output unedited. No warnings, and the required output.

Wow. I cant believe you're still pursuing this. Your code didnt do what it was supposed to. You can mumble about "the context it was written in" all you like. The rules said "Since warnings are supposed to be avoided, use strict; use warnings;". And your code fails this part of the specification.

I chose to use -w and $^W=0 within the localised scope of a subroutine who's sole purpose was to avoid them, which is I think, a legimite tactic given this was golf and only keystrokes count.

As you said to me earlier

If you change the rules of Formula 1 to have a mandatory water section and then enter in a D.U.K.W., you'll likely win every race.

and
If you change the specs to the challenge, any thing is possible.

So you have changed the terms of the challenge to suit yourself. Very sportsmanlike. Not.

(fully tested*)

Fully tested under different terms than were specified for the challenge. Not fully tested under the terms of the challenge.

because you ran it in a context different from that in which it was designed to run and made no attempt to correct for that change of context in any meaningful way.

Im very sorry that I ran your code under the terms of the original challenge. Im very sorry I ran your code at all. (In fact I thought it was pretty neat, and tried to extend it. I now realize that I wasted my time.)

In fact you deliberately suppressed the (correct) output for reasons I can only speculate on.

What on earth are you talking about? Clearly you have completely lost the plot. I suppressed nothing. All I did was extend the test cases to handle a number of omitted difficult scenarios. Admittedly I didnt notice the rule that invalidated test case 'ii' but I apologised when you pointed out the rule (while lecturing me about changing the rules, something you seem to like to do yourself.) As for the warn=>die promotion I did that to automate the capturing and notification of warnings.

Please substantiate or retract your assertion that I suppressed something.

Even in this form, it still complies with the original spec and comes in at 83

Well, if this means that it pasess the provided test cases, then yes finally you have done it. However I dont believe that simply passing the test cases is sufficient. I believe that the spirit of the challenge was the following

How compact can a function be that, when given a HASH reference, returns a list of those entries which have changed. In other words, where the 'original' is not the same as 'new'. As a note, the 'new' value is always present, even if it is undef.

Which your code DOESNT do. Consider that undef ne '' is false. However the two are clearly different. Since this is the basis of your solution it fails the challenge and its size is irrelevent.

I have added more test cases, tracked down the annoying bug in Elusions code that causes the original hash to become corrupt (I changed F($foo) to F({%$foo}) to avoid this impacting other attempts.)

So despite all of your blustering you have posted four solutions that fail the challenge. And in the process insulted someone who started out impressed and friendly. Nice work!

Read more... (5 kB)

      Required: aa cc dd ff hh jj kk ll mm nn oo pp
----------------------------------------------------------------------
+--
   tadman golf: aa cc dd ff hh jj kk ll mm nn oo pp
    main::BUK() => Use of uninitialized value in string ne at c:\temp\
+golf.pl line 25.
sauoq No warns: aa cc dd hh jj kk ll mm
    main::sg_() => Use of uninitialized value in string eq at c:\temp\
+golf.pl line 27.
  Elusion golf: aa cc dd jj kk ll mm
 Demerphq defd: aa cc dd hh jj kk ll mm nn oo pp
Demerphq exist: aa cc dd ff hh jj kk ll mm nn oo pp
    main::ukf() => Use of uninitialized value in string ne at c:\temp\
+golf.pl line 33.
    main::ukg() => Use of uninitialized value in string ne at c:\temp\
+golf.pl line 32.
    main::ukh() => Use of uninitialized value in string ne at c:\temp\
+golf.pl line 34.
 browserUk F(): aa cc dd ff hh jj kk ll mm
[download]

---
demerphq
You haven't lived until you've done 140mph in a Jaguar E type convertable!

My continued technical defense of my code is in response to your request for "a retraction or substantiation" and in reaction to your apparent (and continuing)--unnecessary, unwarranted and unhelpful--personalisation of a technical debate.

There are three issues here:

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

   I say yes, you say no. Unless and until tadman speaks up as arbitar, I will continue to believe it is.

2. 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.
3. 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?

   If you are called to upgrade a piece of code that worked under Perl 5.1 (or whatever) before the warnings module became available, do you stick use warnings; at the top, and then say the guys that wrote it were useless when it fails? Of course not.

You questioned what I meant by "deliberately suppressed", and then go on to mention "warn=>die promotion". You got it. Hole in one. You added the signal handler, a deliberate act, "to suppress the warnings" you said, but then you replaced those warning with your own version of them. So, if fact the warnings were not suppressed, just changed to suit your output formatting requirements. I appreciate and always appreciated that this was your purpose (the formatting I mean), 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. 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>'.

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?

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".

I note that in your 'fixed' version:

• elusion's code (($h->{$_}{O}||$;)eq($h->{$_}{C}||$;)) has not changed from my original translation of it.
• Nor has the subroutine wrapper I placed around it.
• Whilst the logic is different, all the essential syntatic elements:
  • The assignment of the passed hashref : my$h=pop;
  • The references to the hash elements: $h->{$_}{O}
  • The grep: eg_{my$h=pop;grep{!<CONDITION>}%$h}

  in sub eg_{} are identical to those in sub sg_{} which shows none of these problems?

• 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.

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

And the flaw lies where?

If you want to get into the game of nitpicking regarding good coding practice, your own efforts fall short of that by using $a and $b without localising them. In my original code, I held back from absolute minimalism, in order to retain the safety of localising any global vars I used.

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)...".

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.

As for whether the original challenge had a technically sound base, if you read the last part of my original post, I noted that I thought that the challenge was flawed and postulated an alternative and supplied code to support it.

As I said, I agree that the terms of the challenge were not perfect, but then golf challenges and their solutions often do play fast and loose with what could be termed 'production quality coding standards', but them's was the terms, and under (my interpretation) of those terms (rather than your interpretation of them), my code met them.

In my adaption of sauoq's and elusion's code--which I did by way of comparison and in an attempt to understand their rather natty, partial solutions--I attempted to apply the same standards of both safety and golf to their's as I had done to my own. I even admitted that it could be that my adaption of their code in this way was responsible for it's apparent weaknesses. And therein lies the difference. I didn't attempt to belittle their code, only state that I couldn't get it to work. In the case of aristotle's code, I didn't understand it enough to even get it to compile.

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.

Had you said, "Ah! But your breaking the rules by using -w instead of no warnings;"; I possibly would have responded in my usual fashion when I err, "Mea culpa!", "My bad!" or similar , as is unfortunately all too frquently demonstrated all over the site. As it was:

• You scolded me for not testing my code, which I had.
• You stated categorically that it did work, when the output matched those specifed exactly.
• You stated, not even implied, that I didn't understand the difference between -w and use warnings;
• And then take umbrage when I have temerity to challenge your conclusions.

Hardly friendly.

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

No, I do not retract!

---

Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!